Re: [TLS] GSS-API extension draft available

[Bodo Moeller <[e-mail]>]

On Tue, Dec 19, 2006 at 09:26:10PM +0100, Martin Rex wrote:
> Jeffrey Altman wrote:

>> In RFC 2712 (TLS Kerberos Ciphers) the Kerberos session key is used as
>> the pre-master secret.  This mechanism has severe problems because it
>> means that each and every TLS session that is created for as long as the
>> Kerberos service ticket is valid will use the same pre-master secret.

> This looks like an extremely poor choice to me, given the (lack of)
> entropy in Kerberos sessions keys, in particular of the installed base
> and the predominant interorable enctype when rfc2712 was issued.

>> What this proposal does is replace RFC 2712 with a generic GSS-API
>> method of generating a unique pre-master secret when used with the GSS
>> Kerberos5 mechanism.  GSS-API does not provide a method to extract key
>> data from the underlying mechanism because doing so would result in a
>> mechanism specific dependency and violate the GSS-API abstraction.

> Using the entropy from the GSS-API prf is fine.  [...]

In terms of entropy, the RFC 2712 approach does not have a problem.
While the premaster secret is fixed for a given Kerberos ticket, any
master secret will also depend on the client hello and server hello
randomness of the specific connection and thus, for practical
purposes, be unique.  This is similar to the fixed DH ciphersuites for
TLS (which no-one uses, though), in which the premaster secret is fixed
for any given client certificate/server certificate combination.

However, it is not entropy in general that counts.  While the client
hello and server hello do provide entropy, this is public entropy and
thus cannot contribute much to long-term encryption security.  What you
can do to obtain better security with the RFC 2712 Kerberos ciphersuites
is immediate renegotiation using an anonymous DH (or ECDH) ciphersuite:
then Kerberos is relied upon for authentication, and the DH key exchange
(which happens in an authenticated context) is relied upon for obtaining
the symmetric keys that will be used for the actual application data.
I don't think any RFC 2712 implementation has been designed with this in
mind, but it would be a quite reasonable approach to use the protocol.


It appears to me that when we use the GSS-API PRF for Kerberos V 
(RFC 4402) as suggested in draft-santesson-tls-gssapi-01.txt, we have
solved the wrong problem.  Using the PRF will give use a unique
premaster secret for each session, which we don't really need.  Using
the PRF will not include any additional *secret* entropy, which is what
we actually need -- at least if the main worry is the lack of entropy in
the Kerberos session key.

I may have misunderstood what the proposed GSS-API based handshake would
be doing in the Kerberos V case.  But if it works the way I think it
works (without mixing in secret entropy from a key exchange such as
DH/ECDH), then to improve the level of security compared with RFC 2712
as apparently is desired, we'd still have to perform an immediate
renegotiation to benefit from an appropriate key exchange mechanism.

Bodo


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls