additional information. Other authentication mechanisms, such as
Kerberos [RFC2712], would require different client identity data.
5. Security Considerations
This section addresses security issues related to the usage of a
ticket. Tickets must be authenticated and encrypted to prevent
modification or eavesdropping by an attacker. Several attacks
described below will be possible if this is not carefully done.
Implementations should take care to ensure that the processing of
tickets does not increase the chance of denial of service as
described below.
5.1. Invalidating Sessions
The TLS specification requires that TLS sessions be invalidated when
errors occur. [CSSC] discusses the security implications of this in
detail. In the analysis in this paper, failure to invalidate
sessions does not pose a security risk. This is because the TLS
handshake uses a non-reversible function to derive keys for a session
so information about one session does not provide an advantage to
attack the master secret or a different session. If a session
invalidation scheme is used, the implementation should verify the
integrity of the ticket before using the contents to invalidate a
session to ensure that an attacker cannot invalidate a chosen
session.
5.2. Stolen Tickets
An eavesdropper or man-in-the-middle may obtain the ticket and
attempt to use the ticket to establish a session with the server;
however, since the ticket is encrypted and the attacker does not know
the secret key, a stolen ticket does not help an attacker resume a
session. 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 ticket’s contents.
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
to 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.
5.4. Denial of Service Attacks
The key_name field defined in the recommended ticket format helps the
server efficiently reject tickets that it did not issue. However, an
adversary could store or generate a large number of tickets to send
to the TLS server for verification. To minimize the possibility of a
denial of service, the verification of the ticket should be
lightweight (e.g., using efficient symmetric key cryptographic
algorithms).
5.5. Ticket Protection Key Management
A full description of the management of the keys used to protect the
ticket is beyond the scope of this document. A list of RECOMMENDED
practices is given below.
o The keys should be generated securely following the randomness
recommendations in [RFC4086].
o The keys and cryptographic protection algorithms should be at
least 128 bits in strength.
o The keys should not be used for any other purpose than generating
and verifying tickets.
o The keys should be changed regularly.
o The keys should be changed if the ticket format or cryptographic
protection algorithms change.
5.6. Ticket Lifetime
The TLS server controls the lifetime of the ticket. Servers
determine the acceptable lifetime based on the operational and
security requirements of the environments in which they are deployed.
The ticket lifetime may be longer than the 24-hour lifetime
recommended in [RFC2246]. TLS clients may be given a hint of the
lifetime of the ticket. Since the lifetime of a ticket may be
unspecified, a client has its own local policy that determines when
it discards tickets.
5.7. Alternate Ticket Formats and Distribution Schemes
If the ticket format or distribution scheme defined in this document
is not used, then great care must be taken in analyzing the security
of the solution. In particular, if confidential information, such as
a secret key, is transferred to the client, it MUST be done using
secure communication so as to prevent attackers from obtaining or
modifying the key. Also, the ticket MUST have its integrity and
confidentiality protected with strong cryptographic techniques to
prevent a breach in the security of the system.
5.8. Identity Privacy, Anonymity, and Unlinkability
This document mandates that the content of the ticket is
confidentiality protected in order to avoid leakage of its content,
such as user-relevant information. As such, it prevents disclosure
of potentially sensitive information carried within the ticket.
The initial handshake exchange, which was used to obtain the ticket,
might not provide identity confidentiality of the client based on the
properties of TLS. Another relevant security threat is the ability
for an on-path adversary to observe multiple TLS handshakes where the
same ticket is used and therefore to conclude that they belong to the
same communication endpoints. Application designers that use the
ticket mechanism described in this document should consider that
unlinkability [ANON] is not necessarily provided.
While a full discussion of these topics is beyond the scope of this
document, it should be noted that it is possible to issue a ticket
using a TLS renegotiation handshake that occurs after a secure tunnel
has been established by a previous handshake. This may help address
some privacy and unlinkability issues in some environments.
6. Acknowledgements
The authors would like to thank the following people for their help
with preparing and reviewing this document: Eric Rescorla, Mohamad
Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of
the TLS working group.
[CSSC] describes a solution that is very similar to the one described
in this document and gives a detailed analysis of the security
considerations involved. [RFC2712] describes a mechanism for using
Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
of tickets to avoid server state. [EAP-FAST] makes use of a similar
mechanism to avoid maintaining server state for the cryptographic
tunnel. [SC97] also investigates the concept of stateless sessions.
7. IANA Considerations
IANA has assigned a TLS extension number of 35 to the SessionTicket
TLS extension from the TLS registry of ExtensionType values defined
in [RFC4366].
IANA has assigned a TLS HandshakeType number 4 to the
NewSessionTicket handshake type from the TLS registry of
HandshakeType values defined in [RFC4346].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
8.2. Informative References
[AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information
Processing Standards (FIPS) Publication 197,
November 2001.
[ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
Unobservability, Pseudonymity, and Identity Management -
A Consolidated Proposal for Terminology",
http://dud.inf.tu-dresden.de/literatur/
Anon_Terminology_v0.26-1.pdf, Draft 0.26, December 2005.
[CBC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation -
Methods and Techniques", NIST Special Publication 800-
38A, December 2001.
[CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and System
Security (TISSEC) , Volume 7, Issue 4, November 2004.
[EAP-FAST] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
"EAP Flexible Authentication via Secure Tunneling (EAP-
FAST)", Work in Progress, April 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, December 2005.
[SC97] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on
Information and Communication Security (ICICS ’97), 1997.
[SHA1] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", Federal Information Processing
Standards (FIPS) Publication 180-2, August 2002.
Authors’ Addresses
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
EMail: jsalowey@cisco.com
Hao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
US
EMail: hzhou@cisco.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).