Re: [TLS] GSS-API extension draft available

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

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

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?

Jeffrey Altman

Re: [TLS] GSS-API extension draft available

Attachment: smime.p7s