Bernard Aboba wrote:
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.
The MAC will check out only if the servers are using the same key.
If the servers regularly generate new keys (as is suggested in the
document, although not with an uppercase keyword), this implies either
that they have different keys (so MAC won't match and the server won't
attempt to interpret the ticket) or there's some server-to-server key
distribution mechanism between cluster members.
Any server-to-server protocols are very much beyond the scope of
this document, so we don't expect any interoperability there.
But perhaps the document should contain more explicit requirements
about key management (e.g. the keys used to protect the tickets
must not be used for any other purpose, including sharing with other
non-identical nodes)...
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.
It's certainly true that "implements all the MUSTs in the document"
does not imply the system is secure, but that applies pretty much
to any document (unless it says "the system MUST be secure" :-).
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?
Yes, changing the algorithm for all clients is a realistic
possibility. But if you generate new keys when you change the
algorithm (which you really should do anyway), then it's enough
to verify that the MAC is correct (if it isn't, it isn't really
important to know why it was not correct).
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.
Currently, there are not special error messages to communicate why the
ticket was not accepted, since I don't think the client really needs
to know the reason. If the ticket is not accepted, the server simply
starts full TLS handshake, and once that's done, may either send a new
ticket, or indicate that it doesn't want to use "stateless session
resumption" this time (by sending a zero-length ticket).
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf