Re: [TLS] GSS-API extension draft available

On Wed, Dec 20, 2006 at 07:45:33AM -0500, Jeffrey Altman wrote:
> Bodo Moeller wrote:

>> 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.

> Currently the input to the GSS PRF would be:
> 
> OM_uint32  minor_status;
> gss_ctx_id_t  gss_context;
> gss_buffer_t  prf_in;
> gss_buffer_t  prf_out;
> ssize_t       output_len = sizeof(pre-master-secret);
> 
> GSS_Pseudo_random( &minor_status,
>   		   gss_context,
> 		   GSS_C_PRF_KEY_FULL,
> 		   prf_in,
> 	           output_len,
>                    prf_out);
> 		
> where prf_in is the concatenation of all of the previous TLS messages
> in the exchange up until the completion of the GSS handshake:
> 
>   prf_in = ClientHello || ServerHello || ....

I see.  This is something that I had not managed to gather from
draft-santesson-tls-gssapi-01.txt.  (Why not use just
ClientHello.random and ServerHello.random instead of the complete TLS
handshake data collected so far?)

> What I hear you saying is that we should add an ephemeral-ephemeral DH
> exchange in which case the prf_in will become:
> 
>   prf_in = g^xy mod p || ClientHello || ServerHello || ....
> 
> where g^xy mod p is the DH key.
> 
> 
> Correct?

Yes, this looks much better -- at least when the key exchange
mechanism is used with Kerberos V.  For other GSS-API mechanisms,
the DH computation might just be overhead.

The renegotiation approach, while appearing somewhat ad-hoc, has some
advantages in terms of flexibility at the cost of some extra protocol
rounds (but little extra computational effort): It can accomodate DH
and ECDH and any other key exchanges.  For GSS-API mechanisms for
which an additional key exchange is not necessary, there simply
wouldn't have to be a second handshake.  (Of course, to ensure
interoperability, the specification would have to provide appropriate
instructions.)

Still it probably would be the best to integrate all components of the
key exchange into a single TLS handshake.  I am just not sure what the
best protocol design would be: Have separate ciphersuites without 
a ServerKeyExchange, with DH, with ECDH?  Or use some additional
negotiation mechanism (based on TLS extensions) to choose if and how
ServerKeyExchange (and ClientKeyExchange) should be used?

Bodo

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls