Re: [TLS] Design Alternatives for Kerberos + DH

[Rick van Rein <[e-mail]>]

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