In the extreme case (client gets different server every time, and none
of the servers can understand tickets generated by other servers), it
will degrade to normal TLS (full handshake done every time).
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.
2. Without a mandated ticket format, the opaque blob sent to the
client could be more akin to a cookie than a ticket. Section 5
does not contain normative language (e.g. no use of MUST,
SHOULD, etc.) relating to the required security properties.
What the specification does not currently have is a detailed
"instructions for those who want to design their own ticket format"
section. Personally I do not think it would be a very useful thing to
include. It might actually encourage people to design their own ticket
formats, and there's no way the section could cover all the possible
ways to get things wrong :-)
The problem is that without normative language, almost any
implementation can claim compliance, regardless of whether they use the
recommended ticket format or heed the security considerations.
The sample ticket format doesn't contain an algorithm identifier
because we didn't think of any case where the same server would want
to issue tickets using multiple algorithms (e.g., use different
algorithms for different clients).
The server might at some point want to change algorithms for all clients,
no? Or might it not want to be able to verify that the ticket was
constructed using algorithms that it supports? Or even that the ticket
utilizes the format recommended in this specification, as opposed to
another format?
The recommended ticket construction does include a timestamp saying
when the ticket was issued.
If a client submits a ticket that is unacceptable to the server for some
reason (expired, not the right format, etc.) does it get back an error
message letting it know whether to continue to cache the ticket?
For example, if the server understands the ticket and says it has expired,
this is different from not being able to understand the ticket.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf