4 ms·

Kerberos doesn't really scale to the Web at this time. It could, but it would be much better if we could just improve the WebPKI and make a true hierarchical P

Kerberos doesn't really scale to the Web at this time. It could, but it would be much better if we could just improve the WebPKI and make a true hierarchical PKI that mirrors the DNS. The latter can be done either by having registries and registrars operate name-constrained (possibly by convention) CAs, or by adopting DANE (DNSSEC Authenticated Network Entities).

andyjpb 6y ago
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!
tptacek 6y ago
This is a proposal that we delegate not just domain names, and not just TLS certificates, but authentication for applications themselves to a tree-structured PKIs whose trunks are controlled de jure by world governments.
- cryptonector 6y ago
  Nonsense. Everything is controlled de jure by "world governments" as it is. Certainly the WebPKI CAs are.
  - tptacek 6y ago
    I'm having trouble following. Is it nonsense, or is everything controlled by world governments?
    - cryptonector 6y ago
      Your argument is nonsense. There's nothing so special about WebPKI CAs or DNS zone operators. Both -as all entities- are subject to the jurisdiction of some national government in this here world. See my reply to u/tialaramex's reply to you above.
      - tptacek 6y ago
        You've written several hundreds words on this thread without apparently reading the 2 lines I wrote to prompt you. Try again. I'm not talking about the WebPKI; your suggestion was far more extreme than having the DNS take over the WebPKI --- which is also not going to happen, but I'm not here to debate that.
- tialaramex 6y ago
  de jure the sovereign entities that you're labelling "world governments" already control everything, that's sort of the point of being a sovereign entity. Even to the extent that there are exceptions to the rules they make, they made those exceptions too. For example, the sovereign entities agreed centuries ago that none of them owns the open oceans but vessels that sail on those oceans shall display the flag of a sovereign entity and the entity thus flagged shall be responsible for that vessel's conduct and operation. This flag state regime proves to be problematic in certain ways in practice. So what happened? Did some alternate power arise to challenge the sovereign entities in this regard? Nope. The European countries, annoyed by "flags of convenience" on the vessels they saw just arbitrarily instituted a new policy, under the Paris Memorandum Of Understanding. No need to "challenge" any existing rules, as sovereign entities they were entitled to just make up new ones. Vessels entering a European port needed to obey the Paris MOU rules, sometimes getting inspected and if necessary prevented from leaving until they rectified any problems to the port's satisfaction. Was that legal? It was now because sovereign entities had agreed that it was so. The new model was a big success and similar Port State Inspection rules soon followed elsewhere.

andyjpb 6y ago

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!

tptacek 6y ago

This is a proposal that we delegate not just domain names, and not just TLS certificates, but authentication for applications themselves to a tree-structured PKIs whose trunks are controlled de jure by world governments.

cryptonector 6y ago
Nonsense. Everything is controlled de jure by "world governments" as it is. Certainly the WebPKI CAs are.
- tptacek 6y ago
  I'm having trouble following. Is it nonsense, or is everything controlled by world governments?
  - cryptonector 6y ago
    Your argument is nonsense. There's nothing so special about WebPKI CAs or DNS zone operators. Both -as all entities- are subject to the jurisdiction of some national government in this here world. See my reply to u/tialaramex's reply to you above.
    - tptacek 6y ago
      You've written several hundreds words on this thread without apparently reading the 2 lines I wrote to prompt you. Try again. I'm not talking about the WebPKI; your suggestion was far more extreme than having the DNS take over the WebPKI --- which is also not going to happen, but I'm not here to debate that.
tialaramex 6y ago
de jure the sovereign entities that you're labelling "world governments" already control everything, that's sort of the point of being a sovereign entity. Even to the extent that there are exceptions to the rules they make, they made those exceptions too. For example, the sovereign entities agreed centuries ago that none of them owns the open oceans but vessels that sail on those oceans shall display the flag of a sovereign entity and the entity thus flagged shall be responsible for that vessel's conduct and operation. This flag state regime proves to be problematic in certain ways in practice. So what happened? Did some alternate power arise to challenge the sovereign entities in this regard? Nope. The European countries, annoyed by "flags of convenience" on the vessels they saw just arbitrarily instituted a new policy, under the Paris Memorandum Of Understanding. No need to "challenge" any existing rules, as sovereign entities they were entitled to just make up new ones. Vessels entering a European port needed to obey the Paris MOU rules, sometimes getting inspected and if necessary prevented from leaving until they rectified any problems to the port's satisfaction. Was that legal? It was now because sovereign entities had agreed that it was so. The new model was a big success and similar Port State Inspection rules soon followed elsewhere.