From what I can see, the Ticket structure does not uniquely identify the
ticket type or ticket version, so that there is no easy way for the server
to determine what type of ticket has been submitted to it, or whether the
client is using the recommended format or not. The server checks the mac
in the last 20 octets, and if this is valid, then it decrypts the
encrypted_state. However, if the client were using the same mac, but a
different ticket format, the mac could check out, but the StatePlaintext
would not match. A Ticket Type/Version field would make it clear to the
server whether it is handling a Ticket of known type.
I'm not sure I understand this, Bernard. The client doesn't need
to know anything about the ticket format or get to decide
anything about the mac. It's just the server talking to itself.
The client does not need to crack the ticket. However, it is possible for
the client to submit a ticket to a server that doesn't understand it. For
example, wireless LAN networks can span the globe, and require many
backend servers, all of which may not be located at the same location, or
run the same version of the same software. However, clients may only
cache tickets by SSID.
If a client obtains a ticket from Server A, running software version X,
and then sends it to server B, running software version Y, how is Server B
supposed to figure out that it is the wrong version?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf