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

From: Eric Rescorla <[email-masked]>
Date: Sun, 01 Jan 2006 11:03:53 -0800

Bernard Aboba <[email-masked]> writes:

>> 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. 

I'm not sure I understand this, Bernard. The client doesn't need
to know anything about the ticket format or get to decide
anything about the mac. It's just the server talking to itself. 

-Ekr

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 1 Jan 2006 15:34:49 -0800 (PST)

> anything about the mac. It's just the server talking to itself. 

The client does not need to crack the ticket.  However, it is possible for 
the client to submit a ticket to a server that doesn't understand it.  For 
example, wireless LAN networks can span the globe, and require many 
backend servers, all of which may not be located at the same location, or 
run the same version of the same software.  However, clients may only 
cache tickets by SSID. 

If a client obtains a ticket from Server A, running software version X, 
and then sends it to server B, running software version Y, how is Server B 
supposed to figure out that it is the wrong version?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Jan 2006 16:17:10 -0800 (PST)

> > anything about the mac. It's just the server talking to itself. 

In WLAN environments, the client has no way to restrict ticket submission 
to a given server.  Rather, clients assume that any server associated with 
a given SSID is a potential ticket validator.  Unfortunately, SSIDs 
(unlike domain names) are not globally unique.  In fact, millions of APs 
ship every year with same default SSID.  As a result, it will be very 
common for clients to submit tickets to servers who did not create them 
and are using completely different formats, algorithms and even protocol 
versions. 

Since the recommended ticket format includes only the client identity and 
not the server identity, and does not include information on the 
algorithms or formats used in constructing the ticket, the document is in 
effect setting a up a large scale "fuzzing experiment" in which random 
bits are submitted by clients to servers in order to see how they will 
react.

---

From: [email-masked]
Date: Tue, 3 Jan 2006 13:20:08 +0200

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

---

From: [email-masked]
Date: Tue, 3 Jan 2006 13:23:54 +0200

Bernard Aboba wrote:

> If a client obtains a ticket from Server A, running software
> version X, and then sends it to server B, running software
> version Y, how is Server B supposed to figure out that it is the
> wrong version?

This becomes a problem only if the servers are using the same key
to MAC the tickets. (If they're using different keys, the MAC 
won't match anyway, and server B doesn't need to know what version 
server A is using.)

But you're quite right, this could be a problem if one shares
the keys in heterogeneous environment, and the document should
probably warn about this.

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Jan 2006 13:58:06 +0200

Pasi,

>If the servers regularly generate new keys (as is suggested in the
Yes.

>must not be used for any other purpose, including sharing with other
This change would be useful, I think. I would also like
to see the MAC/encryption-keys-are-independent requirement
that Bernard was talking about.

>important to know why it was not correct).
Doesn't the key_version field also provide a hint
as to whether the ticket is something that you
can recognize? Presumably, you could have multiple
versions, if you wanted to support old/new algorithms
and associated keys for a while...

In any case, it seems that it would be useful to add
a requirement that new keys and key_version values
be generated upon algorithm/format changes.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Jan 2006 05:47:06 -0800 (PST)

> 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

If there is no rnormative requirement that the MAC field actually contain 
a MAC, how can we assume this?  And if there is no algorithm indication, 
how do we know how long the MAC field is? 

> can recognize? 

If the key_version field was globally and temporally unique (for example, 
if it included the server name + a counter) then it would provide that 
information.  But it's just a 32-bit integer.  If servers start
at zero, the chance of collision will be qu ite high.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Jan 2006 06:02:59 -0800 (PST)

> 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. 

> 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.

---

From: [email-masked]
Date: Tue, 3 Jan 2006 16:32:08 +0200

Bernard Aboba wrote:

> 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...

> 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