Hello, Based on the feedback in this WG, I'm now redefining TLS-KDH to keep ECDH and Kerberos orthogonal. That simplifies matters enormously. I can now see a few design alternatives. If you have any response to them, it is kindly appreciated!
1) Continue to use KeyExchange This variation sends a Ticket + Authenticator in the ClientKeyExchange, but DH is now mentioned in plaintext instead of encrypted in the Authenticator. PRO: Prior handshake can be taken into account in an Authenticator hash (a.k.a. "checksum"). CON: Special case for KeyExchange; doesn't integrate automatically with TLS 1.3. 2) Embed the Ticket + Authenticator in a PSK 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
