Hello Paul, >> 3) Similar to OpenPGP: Negotiate cert-type >> >> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos >> Tickets. > > How is this type of TLS connection prevented from being MITM'ed by > someone replaying kerberos tickets (which it cannot read itself)
In Kerberos, the KDC-generated and client-cached Tickets are always sent with an additional Authenticator; this is client-signed message that is generated while sending and holds a timestamp to the ms level. The combination is rejected when the timestamp is more off than a small clock skew window at the server. Replay is avoided in Kerberos by observing the Authenticator's uniqueness within that small window. This however, has scaling problems, for instance in redundant server farms. An Authenticator can hold a "checksum", which is a hash nowadays. We can use this field to store a hash of the prior TLS messages, including the ECDH exchange and ServerRandom. This is already done by default in the ClientVerify, so nothing special needs to be done for that. The hashes are typed, with an IANA registry; unkeyed hashes are possible, though none beyond SHA1 appears to have been needed for its current uses, but we can expand that. Finally, the pre-master secret for all four design alternatives consists of the ECDH session key and the session key exchanged by the Ticket. Replay of ECDH is impossible if the server continually refreshes its offers, at least not to be repeated within the clock skew window, which has been a major focus point in my 00 draft. Lacking the session key, an attacker that attempts replay of a Ticket will not be able to generate the proper Finished messages. FWIW, I am proposing to extend the sizes of those hashes. Thanks, -Rick _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
