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

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Dec 2005 09:40:46 -0800 (PST)

Review of draft-salowey-tls-ticket-06.txt

This document describes a mechanism for TLS session resumption without 
Server-Side state.  However, the document does not actually mandate 
support for any particular ticket format, and the recommended ticket 
format appears to lack some features, such as key-lifetime 
specification, support for multiple algorithms and binding 
of the key to its context. 

I'd also note that this document has been the subject of two IPR 
disclosures:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=532
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=537

I am therefore concerned about whether this specification is likely to 
produce widely deployed, interoperable implementations. 

-------------------------------------------------------------------
Section 4 states:

"  This section describes a recommended format and protection for the
   ticket.  Note that the ticket is opaque to the client so the
   structure is not subject to interoperability concerns, so
   implementations may diverge from this format.  If implementations do
   diverge from this format they must take security concerns seriously."

There are a number of issues with this:

1. Interoperability problems.  While it is true that changes to the
ticket format will not cause *client* interoperability problems, it
will cause interoperability problems with servers.  For example, if
heterogeneous TLS servers are deployed, then it is possible that a
ticket given out by one server will not be able to be interpretted
by another server in the same cluster.  As a result, this specification
essentially mandates that TLS deployments be homogeneous. 

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.

In fact, it is not even clear that the recommended ticket construction
includes all of the necessary security properties. 

For example, the ticket structure refers to "opaque encrypted_state" but 
does not describe what kind of stat needs to be included here.  For 
example, there is no requirement for binding between the key and the client 
identity or session-id.

Section 5.2 states:

"A TLS server MUST use strong encryption and integrity
protection for the ticket to prevent an attacker from using a brute
force mechanism to obtain the tickets contents."

While the recommended ticket construction uses 128-bit AES in CBC
mode and HMAC-SHA1, there is no general statement about what
"strong encryption" means.  Perhaps a reference would be appropriate. 
The specification also doesn't state how the MAC and encryption keys 
relate (presumably they need to be cryptographically independent, right?)

5.3  Forged Tickets

   A malicious user could forge or alter a ticket in order to resume a
   session, to extend its lifetime, to impersonate as another user or
   gain additional privileges.  This attack is not possible if the
   ticket is protected using a strong integrity protection algorithm
   such as a keyed HMAC-SHA1.

This brings up the issue of how this specification provides for
crypto-agility.  The recommended ticket construction does not
include an algorithm identifier, and instead mandates use of
128-bit AES in CBC mode and HMAC-SHA-1.  What happens if 
alternative algorithms are required? The IV and MAC fields are 
of fixed size.  

5.5  Ticket Protection Key Lifetime

   The management of the keys used to protect the ticket is beyond the
   scope of this document.  It is advisable to limit the lifetime of
   these keys to ensure they are not overused.

Since there is no server-side state, and the recommended ticket
construction does not include a key-lifetime, how is the server to
limit the lifetime of the tickets? 

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

---

From: [email-masked]
Date: Tue, 27 Dec 2005 16:45:16 +0200

Thanks for your review, Bernard!

Please find below some replies to your comments:

> Section 4 states:
> 
> "  This section describes a recommended format and protection for
>    the ticket.  Note that the ticket is opaque to the client so 
>    the structure is not subject to interoperability concerns,
>    so implementations may diverge from this format.  If 
>    implementations do diverge from this format they must take 
>    security concerns seriously."
> 
> 1. Interoperability problems.  While it is true that changes to
> the ticket format will not cause *client* interoperability
> problems, it will cause interoperability problems with servers.
> For example, if heterogeneous TLS servers are deployed, then it is
> possible that a ticket given out by one server will not be able to
> be interpretted by another server in the same cluster.  As a
> result, this specification essentially mandates that TLS
> deployments be homogeneous.

No, the specification does not mandate this: the performance
benefits will just be smaller in heterogeneous deployments. 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).

However, the extreme case is probably not the most common one.  
If you're sharing the same private key between multiple TLS servers,
they're probably often homogeneous. And even if they are not, various
load balancers (etc.) often some have amount of "stickiness", meaning
the client usually gets the same server as last time.

Most of these things are probably implementation considerations
that we don't have to include in the specification.

> 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.
>
> In fact, it is not even clear that the recommended ticket
> construction includes all of the necessary security properties.
> 
> For example, the ticket structure refers to "opaque encrypted_state"
> but does not describe what kind of stat needs to be included here.

If you scroll down a couple lines, you'll find the "StatePlaintext"
structure which does describe it.

> For example, there is no requirement for binding between the key 
> and the client identity or session-id.

The sample ticket construction does include the client identity,
and the interaction with session-id is described in section 3.4 
(the session ID is empty).

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 :-)

> protection for the ticket to prevent an attacker from using a 
> brute force mechanism to obtain the tickets contents."
> 
> The specification also doesn't state how the MAC and encryption 
> keys relate (presumably they need to be cryptographically 
> independent, right?)

The document does try to say that people who don't know what
encryption algorithms are good enough for their environment should 
not design their own ticket formats :-)

> 5.3  Forged Tickets
> 
>    A malicious user could forge or alter a ticket in order to resume
>    a session, to extend its lifetime, to impersonate as another user
>    or gain additional privileges.  This attack is not possible if 
>    the ticket is protected using a strong integrity protection 
>    algorithm such as a keyed HMAC-SHA1.
> 
> alternative algorithms are required? The IV and MAC fields 
> are of fixed size.  

The specification provides crypto-agility by not mandating the use 
of the sample ticket format from Section 4. 

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 management of the keys used to protect the ticket is beyond 
>    the scope of this document.  It is advisable to limit the 
>    lifetime of these keys to ensure they are not overused.
> 
> construction does not include a key-lifetime, how is the server 
> to limit the lifetime of the tickets? 

The recommended ticket construction does include a timestamp saying
when the ticket was issued. 

Best regards,
Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 31 Dec 2005 18:22:08 -0800 (PST)

> In the extreme case (client gets different server every time, and none 
> of the servers can understand tickets generated by other servers), it

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

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

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

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