3 ms·

What part of Kerberos is currently the scaling limit? One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefi

What part of Kerberos is currently the scaling limit? One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure. Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop. Kerberos realms also closely resemble DNS names and discovery can be tied into SRV records and well-known-names. Kerberos tries really hard to do authentication and rely on other, existing systems for the other bits. If your resolver supports DNNSEC then it'll check your Kerberos-related DNS records as well. On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation. Corporations and other entities typically use Active Directory on local domain that's not otherwise used on The Internet. SSH keys are trusted on a per-key basis, so I don't see a great need for it to be tied into the Web/SSL CA systems because trust is established in other ways and it's almost always with an entity that you already know or have a relationship with. Of course, there's a case for delegation, etc within an organisation, but that's a different problem to delegation in global DNS. I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness. So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?

cryptonector 6y ago
> What part of Kerberos is currently the scaling limit? Cross-realm trust setup. > One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure. Well, no, you could use the WebPKI for SSH, it's just that you wouldn't want to: it's too dangerous. The WebPKI isn't really a PKI as PKIs were intended to be. What I would say is that we really need to fix the WebPKI problem. > Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop. Quite true. This is a key strength of Kerberos. The trend I'm observing in corporate networks though is towards HTTP for everything, and there, Kerberos just doesn't fit in the way it does in GSS applications. In HTTP the way to use Kerberos is as a bearer token system. > On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation. Well, not so much in corporate networks, and certainly I don't need hierarchical authorization on the web so much, though in fact many sites like to use each other for authentication and authorization. E.g., CIs let you authenticate with GitHub/GitLab/... credentials via HTTP redirect-based mechanisms. This isn't so much about hierarchy as about federation. But that federation is predicated on WebPKI, which isn't-but-should-be-damnit hierarchical. > I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness. Oh boy, tell me about it. I've been involved in half a dozen mergers and acquisitions... Even today, too many systems do "realm-chopping", which re-creates the collision problems that you solve by adopting Kerberos or alike. > So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth? Back to scaling, the problem is that cross-realm trust setup is utterly manual and unsafe. In order to scale to the Web using DNS hierarchy it needs to be made automatic, probably using DNSSEC/DANE, or a proper PKI run by the DNS registries and registrars (besides DNSSEC, which is a PKI, of course). Of course, if we had a proper PKI, we wouldn't really need Kerberos anyways. The two things, PKI and Needham-Schröder protocols like Kerberos, are duals. But there is a slight semantics different between the two that strongly favors PKI: in PKI any CA can impersonate any entity within its namespace, but one CA cannot MITM protocols like TLS when crossing namespaces (and when using certificates for both, the client and the server), whereas in Kerberos, any KDC in the trust path from client to server can not only impersonate clients in its purview to the server, but also MITM any clients to any servers when that KDC is in the trust path. Also, constructing a global DNS-based proper Kerberos infrastructure is comparable in difficulty to constructing a global proper PKI. (EDIT: And since we really need a PKI... and the two are duals...) Lastly, Kerberos has more online infrastructure requirements than PKI, though PKI really needs to be used with short-lived or otherwise fresh certificates in order to avoid the need for online revocation infrastructure. This difference also strongly favors PKI (EDIT: I wrote this favors Kerberos, but I'd meant PKI). BTW, here's a very simple protocol based on DNSSEC/DANE that looks a lot like TLS 1.3 with the zero rtt option: lookup the server's long-term public ECDH key in DNS (with DNSSEC/DANE), send {client_ephemeral_public_ECDH_key, SNI, E(shared_ECDH_key, client_certificate, validation_chain, signature)} to the server, and expect back {server_ephemeral_public_ECDH_key, MAC(shared_secret, client's message)}. The shared secret in the first message would be based on the client ephemeral and the server's long-term key, while the shared secret in the second would be based on both ephemeral keys and the server's long-term key as well. The client certificate could be signed by a DANE-authenticated CA, and the validation chain could be just the DNSSEC chain. The client certificate could be a key agreement certificate, in which case the signature would be more like a MAC using an agreed key. This might seem familiar to you... it's exactly the same as the good old AUTH_DH/mech_dh from Sun, but with DNSSEC as its publickey database. This scheme has a lot of properties like Kerberos, such as supporting .5 and 1.0 round-trip handshakes!

cryptonector 6y ago

> What part of Kerberos is currently the scaling limit? Cross-realm trust setup. > One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure. Well, no, you could use the WebPKI for SSH, it's just that you wouldn't want to: it's too dangerous. The WebPKI isn't really a PKI as PKIs were intended to be. What I would say is that we really need to fix the WebPKI problem. > Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop. Quite true. This is a key strength of Kerberos. The trend I'm observing in corporate networks though is towards HTTP for everything, and there, Kerberos just doesn't fit in the way it does in GSS applications. In HTTP the way to use Kerberos is as a bearer token system. > On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation. Well, not so much in corporate networks, and certainly I don't need hierarchical authorization on the web so much, though in fact many sites like to use each other for authentication and authorization. E.g., CIs let you authenticate with GitHub/GitLab/... credentials via HTTP redirect-based mechanisms. This isn't so much about hierarchy as about federation. But that federation is predicated on WebPKI, which isn't-but-should-be-damnit hierarchical. > I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness. Oh boy, tell me about it. I've been involved in half a dozen mergers and acquisitions... Even today, too many systems do "realm-chopping", which re-creates the collision problems that you solve by adopting Kerberos or alike. > So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth? Back to scaling, the problem is that cross-realm trust setup is utterly manual and unsafe. In order to scale to the Web using DNS hierarchy it needs to be made automatic, probably using DNSSEC/DANE, or a proper PKI run by the DNS registries and registrars (besides DNSSEC, which is a PKI, of course). Of course, if we had a proper PKI, we wouldn't really need Kerberos anyways. The two things, PKI and Needham-Schröder protocols like Kerberos, are duals. But there is a slight semantics different between the two that strongly favors PKI: in PKI any CA can impersonate any entity within its namespace, but one CA cannot MITM protocols like TLS when crossing namespaces (and when using certificates for both, the client and the server), whereas in Kerberos, any KDC in the trust path from client to server can not only impersonate clients in its purview to the server, but also MITM any clients to any servers when that KDC is in the trust path. Also, constructing a global DNS-based proper Kerberos infrastructure is comparable in difficulty to constructing a global proper PKI. (EDIT: And since we really need a PKI... and the two are duals...) Lastly, Kerberos has more online infrastructure requirements than PKI, though PKI really needs to be used with short-lived or otherwise fresh certificates in order to avoid the need for online revocation infrastructure. This difference also strongly favors PKI (EDIT: I wrote this favors Kerberos, but I'd meant PKI). BTW, here's a very simple protocol based on DNSSEC/DANE that looks a lot like TLS 1.3 with the zero rtt option: lookup the server's long-term public ECDH key in DNS (with DNSSEC/DANE), send {client_ephemeral_public_ECDH_key, SNI, E(shared_ECDH_key, client_certificate, validation_chain, signature)} to the server, and expect back {server_ephemeral_public_ECDH_key, MAC(shared_secret, client's message)}. The shared secret in the first message would be based on the client ephemeral and the server's long-term key, while the shared secret in the second would be based on both ephemeral keys and the server's long-term key as well. The client certificate could be signed by a DANE-authenticated CA, and the validation chain could be just the DNSSEC chain. The client certificate could be a key agreement certificate, in which case the signature would be more like a MAC using an agreed key. This might seem familiar to you... it's exactly the same as the good old AUTH_DH/mech_dh from Sun, but with DNSSEC as its publickey database. This scheme has a lot of properties like Kerberos, such as supporting .5 and 1.0 round-trip handshakes!