Hello Nico and List (*), Thanks very much for your PKCROSS draft! Here is my feedback to it, which I hope is useful. If things are unclear, too bold or misunderstood, just let me know. Inasfar as you like parts the things that I propose here, I’m willing to provide textual changes to the draft. Just send me the source if you’d appreciate that.
(*) List, if this discussion should (or should not) take place here, let me/us know. I’m not sure what is desired. Cheers, Rick van Rein OpenFortress / ARPA2.net ## Summary and positioning • PKINIT and kx509 achieve opposite effects, they swap X.509 certificates for Kerberos5 tickets, and vice versa • Your PKCROSS proposal transits from x509 at the local realm to PKINIT at a remote realm • Looks like your new draft is the “client empowering” variation, which should work regardless of support by the KDC (well, assuming kx509 of course); this is useful in the interest of individual clients and in situations where the client’s software can be influenced; • The older PKCROSS proposal could relatively be referred to as “infrastructural”, where KDCs implement the support to couple with remote realms; • Although the krb5 -> x509 -> krb5 path could emulate an infrastructural mode inside a user’s KDC, I think it would not be as scalable as it could/should be; it requires a public key exchange per user principal, so it scales less well than a direct PKINIT to crossover between KDCs; also, there will be more delay times; • I therefore think that PKCROSS needs to describe two approaches; one is “client empowering” and the other is “infrastructural” in style. ##Infrastructural PKCROSS Given that, • PKINIT can request tickets based on X.509, even from remote realms (with a suitable policy) • PKINIT can setup authenticated DH exchanges between PKINIT client and KDC, either with fresh DH offers or by reusing ones with an expiration date • Cross-realm requests are unidirectional (but the process can be applied in reverse if need be) We can, • Give an “infrastructural” treatment to cross-realm PKINIT requests; they are easily recognised through the “krbtgt” service name, krbtgt/SERVICE.REALM@USER.REALM and it is fair to require that they only occur between the KDC for SERVICE.REALM and the KDC for USER.REALM • In the KDC for SERVICE.REALM, use DANE and/or other DNS/CA tricks to lookup the CA for USER.REALM after mapping the realm to a DNS name (using x for uppercase X and =x for lowercase x) • In the KDC for USER.REALM, use DANE and/or other DNS/CA tricks to lookup the CA for the SERVICE.REALM signatures after mapping the realm to a DNS name (using x for uppercase X and =x for lowercase x) As far as I can tell, this falls within the existing PKINIT framework; it only adds a specific approach to accept “krbtgt/” names in PA_PK_AS_REQs that are probably simply being rejected at present. In other words, this adds a few pathways in the incomig logic of a KDC, to test for “krbtgt/” requests and to pickup CAs from DANE, but otherwise it uses plain functionality that is already present for PKINIT. We might even require DH (which I think is a good idea). When a KDC is asked for a cross-realm ticket that it cannot satisfy locally, it would look for the “krbtgt/” realm-crossing ticket, and failing to find that it would engage in the client-side PKINIT exchange. To make things absolutely clear and separated-out, we could define an PK_PA_AS_REQ alternative especially for use with this form and still share most of the PKINIT code for fulfilling it. But, give the clearly distinguishable “krbtgt/” ticket service, that does not seem to add very much. ## On DANE stapling An optional extension with DANE / DNSSEC stapling would be possible. I think this would make sense at the general PKINIT abstraction level, independent of the PKCROSS use case. In other words, it would be clearer to settle this facility in an orthogonal (and more generic) document than the one pinning down PKCROSS. It may be awkward to define stapling for PKCROSS alone, and not update PKINIT accordingly. And it may be awkward for the PKCROSS spec to have this kind of impact on PKINIT. Note that dependencies on DNS resolvers can only be avoided if DANE stapling is required from all PKCROSS submitters; this pulls in the responsibilities for maintaining a valide signature path and staying up to date with the DNS root keys. This is perhaps not so trivial in real applications. There may be a need for authenticated denial in the mechanisms for DANE stapling; if it was decided to rely on DANE without DNSSEC as a proof, then it must be proven that a realm has chosen not to be secure; this would make it fall out of those KDC that “insist on DNSSEC”, and for good reason, but it would be available to less-tight realms. DANE stapling would need to accommodate a similar feature of verifying authenticated denial. In general, it is my experience that DNS is always more complex than initially thought. And that DNSSEC is much worse. This is FUD founded on gut feeling, I know, but I haven’t seen stapling specs yet. It is probably good to discuss the matter on the OpenDNSSEC user/developer lists as soon as a concrete specification for stapling is available. I’m not worried about KDC dependencies on specialist libraries that actually add value, of which I think DNSSEC is a very good example. However, it is also possible to rely on an independent DNS resolver run on the KDC-host; this makes good security sense. It is my belief that this can be even more valuable when “insisting on DNSSEC” is supported in such a resolver, at least as an option, http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec ## Security of the Client-Empowering Path I am a bit worried about the possibilities that may arise, to tick-tock back and forth between Kerberos5 and X.509 credentials, and for clients to setup a path hopping from realm to realm. I am not certain if this is possible, and whether it could give rise to abuse. It depends on how principal names are formed, I suppose, and on how they look. This is not currently specified in either PKINIT or kx509, right? This might mean that some constraints need to be put up in this specification to mitigate abuse based on this pattern. One of my concerns is moving from a poorly authenticated realm to a more strictly authenticating one. This might help to build the impression of a strongly established identity, even if its background is flimsy. We should figure out if PKCROSS would be opening up too much. I would suggest approaching the draft from the angle of security choices, and define flags for them: • Was a trusted root CA used? (subjective!) • Was DANE used? • Was DNSSEC used to protect all DNS-data? Based on these flags, choices could be made. For example, to never publish credentials with more flags than with which they were verified/verifiable. If need be, sub-realms could help to provide some variation in this respect. A per-realm policy setting could define the exported security flags, and demand those same flags as a minimum security level for incoming AS_REQs. It is probably wise to not reuse the DH exchanges for opposite trust directions? They would be separately negotiated, and separate exchanges could limit the impact of strange differences between the two directions of trust. The KDC configuration has hierarchical realms, but there is no root realm (AFAIK) comparable to the DNS zone “.” — so, that would not be a place to relay traffic to this approach (which might be through an external componetn). There is a CA facility, but it has no entry for “*” or other notation for default/catch-all. In fact, this is good; the only reason to contact another realm is to route inquiries for “krbtgt/SERVICE.REALM@USER.REALM” and it might be good to route only those special forms. TODO: Not sure if the client asks for those; not sure if the clients all get access to the local KDC’s copy of the key (making them indistinguishable) or if they each get their own. My suspicion is that the KDC holds the service ticket that services its realm, and creates a random key for the client and TGT service in the server’s KDC, as with any service. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
