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."
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.
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 :-)
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?)
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.
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.
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).
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?
The recommended ticket construction does include a timestamp saying
when the ticket was issued.
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf