ietf
[Top] [All Lists]

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

2005-12-23 10:42:42
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>