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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf