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