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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls