> 2) Embed the Ticket + Authenticator in a PSK I don’t fully understand the constraints of the Kerberos+DH use-case, but using DHE-PSK seems like the best idea. The planned session resumption mechanism for TLS 1.3 also uses DHE-PSK, and uses a session ticket mechanism that is not so far from the Kerberos ticket. The Kerberos session key would then get mixed in (as a semi-static secret) to the ECDHE shared secret and both client and server would obtain mutual authentication (based on the Kerberos key).
It may be best to try and fit Kerberos into this existing mechanism, unless there is some fundamental incompatibility. Best, Karthik > > This uses the binary blurb of the PSK to wrap the Ticket and Authenticator. > > PRO: Client authenticates very early, in the ClientHello. > > CON: PSK is untyped, so it requires separate agreement on the contents. It > is impossible to incorporate ServerHello information in the exchange. The > server has not indicated if it supports Kerberos, so the client must make a > leap of faith. PSK replies the selected PSK identifier, rather than send a > response message; it is not designed for messaging purposes. > > > 3) Similar to OpenPGP: Negotiate cert-type > > There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets. > > PRO: Good integration with TLS: Tickets are transported in the > ClientCertificate, and an Authenticator is the ClientVerify. DH is > independent and can move to the earlier phase for TLS 1.3. > > CON: Decision on client credential type must be made in ClientHello, when not > all data may be available (namely, the sequence of tickets leading to the > TLS-protected service). Also impacts the cert-type used in the ServerCert. > > > 4) Define an X.509 embedding for Tickets > > Certificates provide an id/key binding with a signature by a trusted party; > although the AlgorithmIdentifiers used here are new, they do fit in the X.509 > framework. This is rather out-of-the-box thinking, so I tested the idea, see > https://github.com/arpa2/kerberos2pkix > > PRO: Minimal changes to TLS, since Kerberos is now a signing algorithm. The > server can independently authenticate using RSA & co (on top of Kerberos' > mutual authentication). Ticket + timestamp-Authenticator go into an X.509 > ClientCertificate, and an Authenticator including the hash over prior TLS > messages can go into ClientVerify. CertificateRequest can mix options for > Kerberos, RSA, and so on, and client selects whatever it can get to locally, > giving the best user experience. We can also support user-to-user > connections and S4U2Proxy a.k.a. "Constrained Delegation". > > CON: These certificates are symmetrically keyed, which is uncommon. > Certificates are not readable to anyone, but only to the remote peer. > Certificate owner is ideally read from the embedded ticket, rather than from > the subject field. > > > My money is on the last two, but option 4. really needs feedback because it > is a bit wild. When I get an idea where to go, I will be happy to write a > new draft version... a much smaller and simpler one this time! > > Cheers, > -Rick > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
