Hello, >> What messages do you need to transfer for Kerberos? Is it only a ping-pong?
Yes, the plan is to send a Ticket + Authenticator and since the server cannot send "pong", to use the (elongated) "Finished" message to replace the validating function of the "pong". > The client (or server, or both) can pick > a subsession key encrypted by the session key in the Ticket, Currently, only the client could do this. We might pile the subsession key into the pre-master secret if we decide that it adds to security. If we really want the server to send one too, it might send a random string of the right size, and it could be decrypted to a key. That's possible with symmetric algorithms after all... and after receiving the Ticket, the server can do the same to discover its secret subsession key :) > if > another message is passed that uses a subsession key for > confidentiality/integrity (such as a response from the server to perform > "mutual" (i.e., server) authentication, then there is less need for a > replay cache. The key idea in 00 was to not use a subsession key but instead rely on Diffie-Hellman for the same function, to avoid replay caches. Because a replay cache would be a devastating part of a TLS infrastructure that could block these CipherSuites from being rolled out. > An additional key-confirmation message to validate the > server-selected subsession key (such as actual application traffic being > encrypted in that key) is helpful for the security analysis, but not > always available depending on the constraints of the application protocol. It still surprises me, but Kerberos is able to send a message one-way and achieve mutual authentication. The trick is of course that prior key exchanges have setup links that make this possible. That's already been taken care of in client apps and libraries, so I'm trying to make good use of it in TLS. -Rick _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
