Hi Karthikeyan,
> I don’t fully understand the constraints of the Kerberos+DH use-case, but > using DHE-PSK seems like the best idea. It certainly has some virtue to view Kerberos as a preshared key (on steroids). But let me explain what bothers me about that appraoch :- * PSK was designed to carry "hints", not "wrapped-up keys". It feels like we'd not be using it entirely properly. * To avoid replay without (distributed) replay-protection caches, we need a ping-pong exchange. PSK sends back a literal copy of what it got sent, which means that we cannot send back a cryptographic reply. Normally, we would do just that in the Kerberos Application Protocol. When we have an Authenticator in a separate ClientVerify message, it automatically ranges over all past TLS messages, incorporating DH, server random and the Ticket that is being proposed. With the PSK approach, it all gets stuffed into one TLS message and we'll be defining things that are not in line with generic structures for TLS. * PSK carries untyped information. This means that a client and server need out-of-band agreement on the meaning of the PSK format. And we probably agree that educated guesses based on magic numbers are not good for a security protocol. This means that use of PSK is limited to pre-arranged client/server combinations. Meanwhile, Kerberos is hoping to expand to make clients and services authenticate even when they have never met before. > 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). Yes, that is nice and orthogonal. However, we do need the entropy of ECDHE and server random to be mixed in with the Authenticator to make replay undoable. The best way to do that orthogonally is to rely on a hash of prior exchanges, which is not possible, at least under 1.2, with structures that mix Diffie-Hellman and PSK fields. Combined with this being a variation of PSK, I would expect it to lead to more exceptional code than what is being proposed as 3) and 4) -- and exceptional code often is badly-tested code. > It may be best to try and fit Kerberos into this existing mechanism, unless > there is some fundamental incompatibility. I follow the same line of thought, but think integration with the ClientCertificate / ClientVerify is more natural. Tickets are not just keys, they also carry identity, and bind them together. Once again, the reasoning is that this directs the questions to a TLS stack to the right place, without a need to bypass it to elsewhere for this one usecase. Thanks! -Rick _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
