Bernard Aboba wrote: > > The MAC will check out only if the servers are using the same key. > > That's not necessarily true. Since the ticket is not > self-describing. and there is no normative language relating to > ticket construction, there is no guarantee that implementations will > put the MAC field in the same place or use the same algorithm. This > could be fixed by including a globally and temporally unique ticket > identifier, and mandating that the MAC field be put at the end. If the servers use different keys, it does not matter where the MAC field is placed, or whether the same or different algorithm is used. If it would, the MAC algorithm would be seriously flawed, and totally unsuitable for this use even if the field locations were fixed... > > 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" :-). > > While it's certainly true that normative language doesn't guarantee > security, most specifications do use normative language, if only to > pin down some basic features of the specification. It is quite > possible for this specification to allow innovation along many > dimensions, by mandating a few critical items, enough to avoid > interoperability problems, and leaving the rest open. I don't share your enthusiasm about using the uppercase RFC2119 keywords, but would adding a couple of requirements along the following lines satisfy your concerns? "The key(s) used to protect the tickets - MUST be generated securely, taking [RFC4086] into account - MUST be at least 128 bits in strength - MUST NOT be used for any other purpose than generating and verifying tickets of a particular ticket format in a single logical TLS server (which may encompass multiple CPUs or hosts in a distributed environment). - MUST be changed regularly - MUST be changed if the ticket format changes - MUST NOT be used with multiple cryptographic algorithms" Since the document is an extension of TLS session resumption (which happens between a single logical TLS client and server who have been in contact before), I don't think we need to include interoperability between servers in the document. All that is required is that a server can recognize whether the ticket is something it sent out earlier. The simplest way to do this is to MAC the ticket with a key known only to the server; addiong globally unique "issued-by-server-known-as-X" fields is not necessary for this purpose, and would IMHO just encourage clients to inspect the tickets and hurt interoperability. Best regards, Pasi _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf