Jeffrey Altman <[EMAIL PROTECTED]>:
[...]
> The AUTH KRB5 draft actually specifies how the checksum should be
> computed. Now if what you are telling me is that we need to
> incorporate different parameters based upon the method used to
> generate the master secret this is not going to be so easy to do.
> We would need a separate checkum format for ADH, EDH, and RSA key
> generation techniques. Correct?
You could use the data that is used for the Finished message -- it
includes a hash of the whole handshake and thus has all of the above.
7.4.9. Finished
[...]
Meaning of this message:
The finished message is the first protected with the just-
negotiated algorithms, keys, and secrets. Recipients of finished
messages must verify that the contents are correct. Once a side
has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.
struct {
opaque verify_data[12];
} Finished;
verify_data
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
finished_label
For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the
string "server finished".
handshake_messages
All of the data from all handshake messages up to but not
including this message. This is only data visible at the
handshake layer and does not include record layer headers.
This is the concatenation of all the Handshake structures as
defined in 7.4 exchanged thus far.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
