RE: IETF Last Call: draft-salowey-tls-ticket-06.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]