Re: [TLS] Design Alternatives for Kerberos + DH

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

Hello Benjamin / TLS WG,

I didn't mean to drop the list, so your full response is hereby included.

>>> No, mutual authentication requires the client to receive a message from
>>> the server.
>> Yes, I know -- the server needs to handle the session key or the subkey
>> to prove posession of its KDC-stored service key.  By using it, the client
>> can be convinced or server identity.
>
> Good to hear.  Other readers, perhaps, did not.

>>> This could be implicit
>> I think it automatically is with TLS, since the Finished messages won't
>> succeed until both parties have derived the same master secret, which
>> if it involves the session key or subkey proves the server's identity in an
>> implicit manner.
>
> From just your short descriptions, it was unclear to me what exactly
> went into the master secret from the Kerberos side, so I wanted to be sure.

Yes, balancing with terseness.  The master secret is calculated as
always, incorporating the pre-master secret as well as client/server
random and, under RFC 7627, all of the handshake messages up to and
including ClientKeyExchange.

The pre-master is the combination of the ECDH shared secret and the
session key(s) from Kerberos.  For the latter, we can choose one or more
from:
 * The session key generated by the KDC for this client/server
combination session (lasting as long as the service ticket, usually
about a day)
 * A subkey inserted into the Authenticator by the client for this
particular connection (which can avoid replay during ticket life)
 * Possibly: a random byte string from the server, "decrypted" with the
session key, to form a connection-specific key that hinges on
server-side entropy

I think my preference would be a combination of 2nd and 3rd because that
incorporates entropy from both sides; although entropy from both sides
is also incorporated through the ClientHello and ServerHello Random
bytes, these are not encrypted to conceal it from MITM as in the 2nd and
3rd options.  This is a bit paranoid perhaps --the ECDH mechanism
achieves a similar thing already-- but the appeal of 2nd and 3rd as very
light-weight and makes it much more difficult to crack.
>> I do believe a long-enough Finished message is required though.  For
>> the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth
>> to match the required certainty from the message; if we mix Kerberos
>> client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then
>> a client SHOULD negotiate a high-enough value and the server MUST
>> support that.  It requires TLS 1.2 to do these things.
>>
>
> Well, hmm, that's an interesting question.  (Note, of course, that the
> current Kerberos AES enctypes only use 96 bits of HMAC-SHA1 for their
> MIC.)


Keyed hashes such as HMAC-SHA1 don't seem to add much here, and they
would have a grave impact on how the hashes are calculated in TLS stacks
(because the key is only known later in the exchange).  I would suggest
that we follow TLS' hash preferences, since we are going to rely on
those hashes having been computed through the prior exchange of TLS
messages, and add those to the IANA Registry for Kerberos Checksum Type
Numbers; this currently includes SHA1 and I doubt that anyone would
protest to extensions with stronger unkeyed hashes.


> The client can obtain information indicating that the server has
> the correct Kerberos key both from the decrypted contents of the
> Finished message

I assume you meant "by matching the Finished message with one generated
locally".

> and also from the integrity protection of the
> TLSCiphertext, since both use material derived from the master secret. 

Yes, TLSCiphertext is also protected, but my main concern is with
Finished, because I would not like accept a TLS connection under
doubtful circumstances, just to be OK when an application only sets up
TLS as a means of authentication.  With the longer Finished messages,
that would not happen.

> So I guess I'm not yet convinced that the verify_data_length should be
> twice the bitlength of the negotiated symmetric cipher, but perhaps I'm
> missing something obvious.

I'm not sure if it should be 1x or 2x the cipher length.  Most important
to me is that it must be longer than the 12 bytes that were standard up
to TLS 1.1 and default in TLS 1.2.

-RIck