< draft-salowey-tls-rfc4507bis-00.txt   draft-salowey-tls-rfc4507bis-01.txt >
Network Working Group J. Salowey Network Working Group J. Salowey
Internet-Draft H. Zhou Internet-Draft H. Zhou
Obsoletes: 4507 (if approved) Cisco Systems Obsoletes: 4507 (if approved) Cisco Systems
Intended status: Standards Track P. Eronen Intended status: Standards Track P. Eronen
Expires: December 13, 2007 Nokia Expires: February 28, 2008 Nokia
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
June 11, 2007 August 27, 2007
Transport Layer Security (TLS) Session Resumption without Server-Side Transport Layer Security (TLS) Session Resumption without Server-Side
State State
draft-salowey-tls-rfc4507bis-00.txt draft-salowey-tls-rfc4507bis-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2007. This Internet-Draft will expire on February 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a mechanism that enables the Transport Layer This document describes a mechanism that enables the Transport Layer
Security (TLS) server to resume sessions and avoid keeping per-client Security (TLS) server to resume sessions and avoid keeping per-client
session state. The TLS server encapsulates the session state into a session state. The TLS server encapsulates the session state into a
skipping to change at page 2, line 15 skipping to change at page 2, line 15
resume a session using the obtained ticket. This document obsoletes resume a session using the obtained ticket. This document obsoletes
RFC 4507. RFC 4507.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7 3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7
3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 7 3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8
3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9 3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9
4. Recommended Ticket Construction . . . . . . . . . . . . . . . 9 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 11 5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12
5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12 5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
5.5. Ticket Protection Key Management . . . . . . . . . . . . . 12 5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13
5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 12 5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13
5.7. Alternate Ticket Formats and Distribution Schemes . . . . 12 5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13
5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 13 5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Discussion of Changes to RFC4507 . . . . . . . . . . 15 Appendix A. Discussion of Changes to RFC4507 . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
This document defines a way to resume a Transport Layer Security This document defines a way to resume a Transport Layer Security
(TLS) session without requiring session-specific state at the TLS (TLS) session without requiring session-specific state at the TLS
server. This mechanism may be used with any TLS ciphersuite. This server. This mechanism may be used with any TLS ciphersuite. This
document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1 document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1
defined in [RFC4346]. The mechanism makes use of TLS extensions defined in [RFC4346]. The mechanism makes use of TLS extensions
defined in [RFC4366] and defines a new TLS message type. defined in [RFC4366] and defines a new TLS message type.
skipping to change at page 3, line 42 skipping to change at page 3, line 42
protected data structure that is created by the server and consumed protected data structure that is created by the server and consumed
by the server to rebuild session-specific state. by the server to rebuild session-specific state.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Protocol 3. Protocol
This specification describes a mechanism to distribute encrypted This specification describes a mechanism to distribute encrypted
session-state information in the form of a ticket. The ticket is session-state information to the client in the form of a ticket and a
mechanism to present the ticket back to the server. The ticket is
created by a TLS server and sent to a TLS client. The TLS client created by a TLS server and sent to a TLS client. The TLS client
presents the ticket to the TLS server to resume a session. presents the ticket to the TLS server to resume a session.
Implementations of this specification are expected to support both Implementations of this specification are expected to support both
mechanisms. Other specifications can take advantage of the session mechanisms. Other specifications can take advantage of the session
tickets, perhaps specifying alternative means for distribution or tickets, perhaps specifying alternative means for distribution or
selection. For example, a separate specification may describe an selection. For example, a separate specification may describe an
alternate way to distribute a ticket and use the TLS extension in alternate way to distribute a ticket and use the TLS extension in
this document to resume the session. This behavior is beyond the this document to resume the session. This behavior is beyond the
scope of the document and would need to be described in a separate scope of the document and would need to be described in a separate
specification. specification.
skipping to change at page 5, line 21 skipping to change at page 5, line 22
(SessionTicket extension) --------> (SessionTicket extension) -------->
ServerHello ServerHello
(empty SessionTicket extension) (empty SessionTicket extension)
NewSessionTicket NewSessionTicket
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 2: Message flow for abbreviated handshake using Figure 2: Message flow for abbreviated handshake using new session
new ticket
session ticket
A recommended ticket format is given in Section 4. A recommended ticket format is given in Section 4.
If the server cannot or does not want to honor the ticket, then it If the server cannot or does not want to honor the ticket, then it
can initiate a full handshake with the client. can initiate a full handshake with the client.
In the case that the server does not wish to issue a new ticket at In the case that the server does not wish to issue a new ticket at
this time, it just completes the handshake without including a this time, it just completes the handshake without including a
SessionTicket extension or NewSessionTicket handshake message. This SessionTicket extension or NewSessionTicket handshake message. This
is shown below (this flow is identical to Figure 1 in RFC 2246, is shown below (this flow is identical to Figure 1 in RFC 4346,
except for the session ticket extension in the first message): except for the session ticket extension in the first message):
Client Server Client Server
ClientHello ClientHello
(SessionTicket extension) --------> (SessionTicket extension) -------->
ServerHello ServerHello
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest* CertificateRequest*
skipping to change at page 6, line 26 skipping to change at page 6, line 26
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 3: Message flow for server completing full handshake without Figure 3: Message flow for server completing full handshake without
issuing new session ticket issuing new session ticket
It is also permissible to have an exchange similar to Figure 3 using
the abbreviated handshake defined in Figure 2 of RFC 4346 where the
client uses the SessionTicket extension to resume the session, but
the server does not wish issue a new ticket and therefore does not
send a SessionTicket extension.
If the server rejects the ticket, it may still wish to issue a new If the server rejects the ticket, it may still wish to issue a new
ticket after performing the full handshake as shown below (this flow ticket after performing the full handshake as shown below (this flow
is identical to Figure 1, except the SessionTicket extension in the is identical to Figure 1, except the SessionTicket extension in the
Client Hello is not empty): Client Hello is not empty):
Client Server Client Server
ClientHello ClientHello
(SessionTicket extension) --------> (SessionTicket extension) -------->
ServerHello ServerHello
skipping to change at page 7, line 44 skipping to change at page 8, line 18
The SessionTicket extension has been assigned the number 35. The The SessionTicket extension has been assigned the number 35. The
extension_data field of SessionTicket extension contains the ticket. extension_data field of SessionTicket extension contains the ticket.
3.3. NewSessionTicket Handshake Message 3.3. NewSessionTicket Handshake Message
This message is sent by the server during the TLS handshake before This message is sent by the server during the TLS handshake before
the ChangeCipherSpec message. This message MUST be sent if the the ChangeCipherSpec message. This message MUST be sent if the
server included a SessionTicket extension in the ServerHello. This server included a SessionTicket extension in the ServerHello. This
message MUST NOT be sent if the server did not include a message MUST NOT be sent if the server did not include a
SessionTicket extension in the ServerHello. In the case of a full SessionTicket extension in the ServerHello. This message is included
handshake, the server MUST verify the client's Finished message in the hash used to create and verify the Finished message. In the
before sending the ticket. The client MUST NOT treat the ticket as case of a full handshake, the server MUST verify the client's
valid until it has verified the server's Finished message. If the Finished message before sending the ticket. The client MUST NOT
server determines that it does not want to include a ticket after it treat the ticket as valid until it has verified the server's Finished
has included the SessionTicket extension in the ServerHello, then it message. If the server determines that it does not want to include a
sends a zero-length ticket in the NewSessionTicket handshake message. ticket after it has included the SessionTicket extension in the
ServerHello, then it sends a zero-length ticket in the
NewSessionTicket handshake message.
If the server successfully verifies the client's ticket, then it MAY If the server successfully verifies the client's ticket, then it MAY
renew the ticket by including a NewSessionTicket handshake message renew the ticket by including a NewSessionTicket handshake message
after the ServerHello in the abbreviated handshake. The client after the ServerHello in the abbreviated handshake. The client
should start using the new ticket as soon as possible after it should start using the new ticket as soon as possible after it
verifies the server's Finished message for new connections. Note verifies the server's Finished message for new connections. Note
that since the updated ticket is issued before the handshake that since the updated ticket is issued before the handshake
completes, it is possible that the client may not put the new ticket completes, it is possible that the client may not put the new ticket
into use before it initiates new connections. The server MUST NOT into use before it initiates new connections. The server MUST NOT
assume that the client actually received the updated ticket until it assume that the client actually received the updated ticket until it
skipping to change at page 9, line 40 skipping to change at page 10, line 16
This section describes a recommended format and protection for the This section describes a recommended format and protection for the
ticket. Note that the ticket is opaque to the client, so the ticket. Note that the ticket is opaque to the client, so the
structure is not subject to interoperability concerns, and structure is not subject to interoperability concerns, and
implementations may diverge from this format. If implementations do implementations may diverge from this format. If implementations do
diverge from this format, they must take security concerns seriously. diverge from this format, they must take security concerns seriously.
Clients MUST NOT examine the ticket under the assumption that it Clients MUST NOT examine the ticket under the assumption that it
complies with this document. complies with this document.
The server uses two different keys: one 128-bit key for AES [AES] in The server uses two different keys: one 128-bit key for AES [AES] in
CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104] CBC mode [CBC] encryption and one 256-bit key for HMAC-SHA-256
[SHA1]. [RFC4634].
The ticket is structured as follows: The ticket is structured as follows:
struct { struct {
opaque key_name[16]; opaque key_name[16];
opaque iv[16]; opaque iv[16];
opaque encrypted_state<0..2^16-1>; opaque encrypted_state<0..2^16-1>;
opaque mac[20]; opaque mac[32];
} ticket; } ticket;
Here, key_name serves to identify a particular set of keys used to Here, key_name serves to identify a particular set of keys used to
protect the ticket. It enables the server to easily recognize protect the ticket. It enables the server to easily recognize
tickets it has issued. The key_name should be randomly generated to tickets it has issued. The key_name should be randomly generated to
avoid collisions between servers. One possibility is to generate new avoid collisions between servers. One possibility is to generate new
random keys and key_name every time the server is started. random keys and key_name every time the server is started.
The actual state information in encrypted_state is encrypted using The actual state information in encrypted_state is encrypted using
128-bit AES in CBC mode with the given IV. The MAC is calculated 128-bit AES in CBC mode with the given IV. The MAC is calculated
using HMAC-SHA1 over key_name (16 octets)and IV (16 octets), followed using HMAC-SHA-256 over key_name (16 octets)and IV (16 octets),
by the length of the encrypted_state field (2 octets) and its followed by the length of the encrypted_state field (2 octets) and
contents (variable length). its contents (variable length).
struct { struct {
ProtocolVersion protocol_version; ProtocolVersion protocol_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
CompressionMethod compression_method; CompressionMethod compression_method;
opaque master_secret[48]; opaque master_secret[48];
ClientIdentity client_identity; ClientIdentity client_identity;
uint32 timestamp; uint32 timestamp;
} StatePlaintext; } StatePlaintext;
skipping to change at page 11, line 9 skipping to change at page 11, line 45
exchange protocols provided by TLS, the ClientIdentity structure exchange protocols provided by TLS, the ClientIdentity structure
contains the authentication type of the client used in the initial contains the authentication type of the client used in the initial
exchange (see ClientAuthenticationType). To offer the TLS server exchange (see ClientAuthenticationType). To offer the TLS server
with the same capabilities for authentication and authorization, a with the same capabilities for authentication and authorization, a
certificate list is included in case of public-key-based certificate list is included in case of public-key-based
authentication. The TLS server is therefore able to inspect a number authentication. The TLS server is therefore able to inspect a number
of different attributes within these certificates. A specific of different attributes within these certificates. A specific
implementation might choose to store a subset of this information or implementation might choose to store a subset of this information or
additional information. Other authentication mechanisms, such as additional information. Other authentication mechanisms, such as
Kerberos [RFC2712], would require different client identity data. Kerberos [RFC2712], would require different client identity data.
Other TLS extensions may require the inclusion of additional data in
the StatePlaintext structure.
5. Security Considerations 5. Security Considerations
This section addresses security issues related to the usage of a This section addresses security issues related to the usage of a
ticket. Tickets must be authenticated and encrypted to prevent ticket. Tickets must be authenticated and encrypted to prevent
modification or eavesdropping by an attacker. Several attacks modification or eavesdropping by an attacker. Several attacks
described below will be possible if this is not carefully done. described below will be possible if this is not carefully done.
Implementations should take care to ensure that the processing of Implementations should take care to ensure that the processing of
tickets does not increase the chance of denial of service as tickets does not increase the chance of denial of service as
skipping to change at page 12, line 4 skipping to change at page 12, line 41
session. A TLS server MUST use strong encryption and integrity session. A TLS server MUST use strong encryption and integrity
protection for the ticket to prevent an attacker from using a brute protection for the ticket to prevent an attacker from using a brute
force mechanism to obtain the ticket's contents. force mechanism to obtain the ticket's contents.
5.3. Forged Tickets 5.3. Forged Tickets
A malicious user could forge or alter a ticket in order to resume a 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 session, to extend its lifetime, to impersonate as another user, or
to gain additional privileges. This attack is not possible if the to gain additional privileges. This attack is not possible if the
ticket is protected using a strong integrity protection algorithm ticket is protected using a strong integrity protection algorithm
such as a keyed HMAC-SHA1. such as a keyed HMAC-SHA-256.
5.4. Denial of Service Attacks 5.4. Denial of Service Attacks
The key_name field defined in the recommended ticket format helps the The key_name field defined in the recommended ticket format helps the
server efficiently reject tickets that it did not issue. However, an server efficiently reject tickets that it did not issue. However, an
adversary could store or generate a large number of tickets to send adversary could store or generate a large number of tickets to send
to the TLS server for verification. To minimize the possibility of a to the TLS server for verification. To minimize the possibility of a
denial of service, the verification of the ticket should be denial of service, the verification of the ticket should be
lightweight (e.g., using efficient symmetric key cryptographic lightweight (e.g., using efficient symmetric key cryptographic
algorithms). algorithms).
skipping to change at page 12, line 38 skipping to change at page 13, line 27
o The keys should be changed regularly. o The keys should be changed regularly.
o The keys should be changed if the ticket format or cryptographic o The keys should be changed if the ticket format or cryptographic
protection algorithms change. protection algorithms change.
5.6. Ticket Lifetime 5.6. Ticket Lifetime
The TLS server controls the lifetime of the ticket. Servers The TLS server controls the lifetime of the ticket. Servers
determine the acceptable lifetime based on the operational and determine the acceptable lifetime based on the operational and
security requirements of the environments in which they are deployed. security requirements of the environments in which they are deployed.
The ticket lifetime may be longer than the 24-hour lifetime The ticket lifetime may be longer than the 24-hour lifetime
recommended in [RFC2246]. TLS clients may be given a hint of the recommended in [RFC4346]. TLS clients may be given a hint of the
lifetime of the ticket. Since the lifetime of a ticket may be lifetime of the ticket. Since the lifetime of a ticket may be
unspecified, a client has its own local policy that determines when unspecified, a client has its own local policy that determines when
it discards tickets. it discards tickets.
5.7. Alternate Ticket Formats and Distribution Schemes 5.7. Alternate Ticket Formats and Distribution Schemes
If the ticket format or distribution scheme defined in this document If the ticket format or distribution scheme defined in this document
is not used, then great care must be taken in analyzing the security is not used, then great care must be taken in analyzing the security
of the solution. In particular, if confidential information, such as of the solution. In particular, if confidential information, such as
a secret key, is transferred to the client, it MUST be done using a secret key, is transferred to the client, it MUST be done using
skipping to change at page 14, line 11 skipping to change at page 14, line 45
7. IANA Considerations 7. IANA Considerations
IANA has assigned a TLS extension number of 35 to the SessionTicket IANA has assigned a TLS extension number of 35 to the SessionTicket
TLS extension from the TLS registry of ExtensionType values defined TLS extension from the TLS registry of ExtensionType values defined
in [RFC4366]. in [RFC4366].
IANA has assigned a TLS HandshakeType number 4 to the IANA has assigned a TLS HandshakeType number 4 to the
NewSessionTicket handshake type from the TLS registry of NewSessionTicket handshake type from the TLS registry of
HandshakeType values defined in [RFC4346]. HandshakeType values defined in [RFC4346].
8. References This document does not require any actions or assignments from IANA.
8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
skipping to change at page 15, line 8 skipping to change at page 15, line 46
[CBC] National Institute of Standards and Technology, [CBC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation - "Recommendation for Block Cipher Modes of Operation -
Methods and Techniques", NIST Special Publication 800-38A, Methods and Techniques", NIST Special Publication 800-38A,
December 2001. December 2001.
[CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and caching for TLS", Transactions on Information and
System Security (TISSEC) , Volume 7, Issue 4, System Security (TISSEC) , Volume 7, Issue 4,
November 2004. November 2004.
[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 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999. October 1999.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851, Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007. May 2007.
[SC97] Aura, T. and P. Nikander, "Stateless Connections", [SC97] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on Proceedings of the First International Conference on
Information and Communication Security (ICICS '97) , 1997. 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.
Appendix A. Discussion of Changes to RFC4507 Appendix A. Discussion of Changes to RFC4507
RFC 4507 [RFC4507] defines a mechanism to resume a TLS session RFC 4507 [RFC4507] defines a mechanism to resume a TLS session
without maintaining server side state by specifying an encrypted without maintaining server side state by specifying an encrypted
ticket that is maintained on the client. The client presents this ticket that is maintained on the client. The client presents this
ticket to the server in a SessionTicket hello extension. The ticket to the server in a SessionTicket hello extension. The
encoding in RFC 4507 used the XDR style encoding specified in TLS encoding in RFC 4507 used the XDR style encoding specified in TLS
[RFC4346]. [RFC4346].
An error in the encoding caused the specification to differ from An error in the encoding caused the specification to differ from
 End of changes. 26 change blocks. 
48 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/