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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf