Network Working Group S. Hollenbeck
Internet-Draft VeriSign, Inc.
-Updates: 2246 (if approved) October 23, 2002
-Expires: April 23, 2003
+Updates: 2246 (if approved) December 2, 2002
+Expires: June 2, 2003
Transport Layer Security Protocol Compression Methods
- draft-ietf-tls-compression-03.txt
+ draft-ietf-tls-compression-04.txt
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 23, 2003.
+ This Internet-Draft will expire on June 2, 2003.
Copyright Notice
features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and to then apply the algorithm
associated with the selected method as part of the TLS Record
- Protocol. TLS defines one standard compression method,
- CompressionMethod.null, which specifies that data exchanged via the
- record protocol will not be compressed. This document describes
- additional compression methods associated with lossless data
- compression algorithms for use with TLS.
-
+ Protocol. TLS defines one standard compression method which
+ specifies that data exchanged via the record protocol will not be
+ compressed. This document describes an additional compression method
+ associated with a lossless data compression algorithm for use with
+ TLS, and it describes a method for the specification of additional
+ TLS compression methods.
-Hollenbeck Expires April 23, 2003 [Page 1]
+Hollenbeck Expires June 2, 2003 [Page 1]
\f
-Internet-Draft TLS Compression Methods October 2002
+Internet-Draft TLS Compression Methods December 2002
Conventions Used In This Document
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Compression History and Packet Processing . . . . . . . . . . 5
+ 2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1 Compression History and Packet Processing . . . . . . . . . . 4
2.2 ZLIB Compression . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3 LZS Compression . . . . . . . . . . . . . . . . . . . . . . . 5
- 3. Intellectual Property Considerations . . . . . . . . . . . . . 7
- 4. Internationalization Considerations . . . . . . . . . . . . . 8
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
- Normative References . . . . . . . . . . . . . . . . . . . . . 12
- Informative References . . . . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
+ 3. Intellectual Property Considerations . . . . . . . . . . . . . 5
+ 4. Internationalization Considerations . . . . . . . . . . . . . 5
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
+ Normative References . . . . . . . . . . . . . . . . . . . . . 6
+ Informative References . . . . . . . . . . . . . . . . . . . . 6
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
-Hollenbeck Expires April 23, 2003 [Page 2]
+
+Hollenbeck Expires June 2, 2003 [Page 2]
\f
-Internet-Draft TLS Compression Methods October 2002
+Internet-Draft TLS Compression Methods December 2002
1. Introduction
amounts of data while preserving the security services provided by
TLS.
- This document describes additional compression methods associated
- with lossless data compression algorithms for use with TLS.
+ This document describes an additional compression method associated
+ with a lossless data compression algorithm for use with TLS.
Standardization of the compressed data formats and compression
- algorithms associated with the compression methods is beyond the
+ algorithms associated with this compression method is beyond the
scope of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck Expires April 23, 2003 [Page 3]
-\f
-Internet-Draft TLS Compression Methods October 2002
-
-
2. Compression Methods
TLS [2] includes the following compression method structure in
working group.
2. Values from 64 decimal (0x40) through 192 decimal (0xC0) are
+
+
+
+Hollenbeck Expires June 2, 2003 [Page 3]
+\f
+Internet-Draft TLS Compression Methods December 2002
+
+
reserved for assignment by the IANA for specifications developed
outside the TLS working group. Assignments from this range of
values MUST be made by the IANA and MUST be associated with a
allocation of compression method identifiers is described in Section
5.
- In addition, this definition is updated to include assignment of two
- additional compression methods:
-
- enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
+ In addition, this definition is updated to include assignment of an
+ identifier for the ZLIB compression method:
- These two compression methods are defined to provide implementers
- with alternatives based on compression performance, ease of
- implementation, and licensing requirements (see Section 3 for a
- description of intellectual property considerations). ZLIB is
- generally known as a freely-available, widely-deployed compression
- method, whereas LZS is generally known to provide memory footprint
- and performance advantages in stateful networking applications.
+ enum { null(0), ZLIB(1), (255) } CompressionMethod;
- As described in section 6 of RFC 2246, TLS is a stateful protocol.
- Compression methods used with TLS can be either stateful (the
- compressor maintains it's state through all compressed records) or
- stateless (the compressor compresses each record independently), but
- there seems to be little known benefit in using a stateless
+ As described in section 6 of RFC 2246 [2], TLS is a stateful
+ protocol. Compression methods used with TLS can be either stateful
+ (the compressor maintains it's state through all compressed records)
+ or stateless (the compressor compresses each record independently),
+ but there seems to be little known benefit in using a stateless
compression method within TLS.
+ The ZLIB compression method described in this document is stateful.
+ It is recommended that other compression methods that might be
+ standardized in the future be stateful as well.
-
-
-Hollenbeck Expires April 23, 2003 [Page 4]
-\f
-Internet-Draft TLS Compression Methods October 2002
-
-
- All of the compression methods described in this document are
- stateful. It is recommended that other compression methods that
- might be standardized in the future be stateful as well.
+ Compression algorithms can occasionally expand, rather than compress,
+ input data. A compression method that exceeds the expansion limits
+ described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS.
2.1 Compression History and Packet Processing
history across packets implies that a packet might contain data
needed to completely decompress data contained in a different packet.
History maintenance thus requires both a reliable link and sequenced
- packet delivery. History information MAY be maintained and exploited
- when using the compression methods described in this document if TLS
- is being used with a protocol that provides reliable, sequenced
- packet delivery.
+ packet delivery. Since TLS and lower-layer protocols provide
+ reliable, sequenced packet delivery, compression history information
+ MAY be maintained and exploited if supported by the compression
+ method.
-2.2 ZLIB Compression
- The ZLIB compression method and encoding format is described in RFC
- 1950 [5] and RFC 1951 [6]. Examples of ZLIB use in IETF protocols
- can be found in RFC 1979 [7], RFC 2394 [8], and RFC 3274 [9].
- ZLIB allows the sending compressor to select from among several
- options to provide varying compression ratios, processing speeds, and
- memory requirements. The receiving decompressor will automatically
- adjust to the parameters selected by the sender.
- ZLIB has the ability to maintain history information when compressing
- and decompressing packet payloads. If TLS is not being used with a
- protocol that provides reliable, sequenced packet delivery, the
- sender MUST flush the compressor completely each time a compressed
- payload is produced. All data that was submitted for compression
- MUST be included in the compressed output, with no data retained to
- be included in a later output payload. Flushing ensures that each
- compressed packet payload can be decompressed completely.
-2.3 LZS Compression
- The Lempel Zif Stac (LZS) compression method and encoding format is
- described in ANSI publication X3.241 [10]. Examples of LZS use in
- IETF protocols can be found in RFC 1967 [11], RFC 1974 [12], and RFC
- 2395 [13].
-
- LZS has the ability to maintain history information when compressing
- and decompressing packet payloads. If TLS is not being used with a
- protocol that provides reliable, sequenced packet delivery, the
-
-
-
-Hollenbeck Expires April 23, 2003 [Page 5]
+Hollenbeck Expires June 2, 2003 [Page 4]
\f
-Internet-Draft TLS Compression Methods October 2002
-
-
- compression history MUST be reset by the sender before compressing
- data and the decompression history MUST be reset by the receiver
- before decompressing data to ensure that compressed packet payloads
- can be decompressed completely. The sender MUST flush the compressor
- completely each time a compressed payload is produced. All data that
- was submitted for compression MUST be included in the compressed
- output, with no data retained to be included in a later output
- payload. Flushing ensures that each compressed packet payload can be
- decompressed completely.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+Internet-Draft TLS Compression Methods December 2002
+2.2 ZLIB Compression
-Hollenbeck Expires April 23, 2003 [Page 6]
-\f
-Internet-Draft TLS Compression Methods October 2002
+ The ZLIB compression method and encoding format is described in RFC
+ 1950 [5] and RFC 1951 [6]. Examples of ZLIB use in IETF protocols
+ can be found in RFC 1979 [7], RFC 2394 [8], and RFC 3274 [9].
+ ZLIB allows the sending compressor to select from among several
+ options to provide varying compression ratios, processing speeds, and
+ memory requirements. The receiving decompressor MUST automatically
+ adjust to the parameters selected by the sender. All data that was
+ submitted for compression MUST be included in the compressed output,
+ with no data retained to be included in a later output payload.
+ Flushing ensures that each compressed packet payload can be
+ decompressed completely.
3. Intellectual Property Considerations
Many compression algorithms are subject to patent or other
intellectual property rights claims. Implementers are encouraged to
seek legal guidance to better understand the implications of
- developing implementations of the compression methods described in
+ developing implementations of the compression method described in
this document or other documents that describe compression methods
for use with TLS.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck Expires April 23, 2003 [Page 7]
-\f
-Internet-Draft TLS Compression Methods October 2002
-
-
4. Internationalization Considerations
The compression method identifiers specified in this document are
machine-readable numbers. As such, issues of human
internationalization and localization are not introduced.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck Expires April 23, 2003 [Page 8]
-\f
-Internet-Draft TLS Compression Methods October 2002
-
-
5. IANA Considerations
- This document does not have a direct impact on the IANA, but it does
- define ranges of compression method values for future assignment.
- Values from the range reserved for future standardization efforts of
- the TLS working group MUST be assigned according to the "Standards
- Action" policy described in RFC 2434 [3]. Values from the range
- reserved for private use MUST be used according to the "Private Use"
- policy described in RFC 2434. Values from the general IANA pool MUST
- be assigned according to the "IETF Consensus" policy described in RFC
+ Section 2 of this document describes a registry of compression method
+ identifiers to be maintained by the IANA, including assignment of an
+ identifier for the ZLIB compression method. Identifier values from
+ the range reserved for future standardization efforts of the TLS
+ working group MUST be assigned according to the "Standards Action"
+ policy described in RFC 2434 [3]. Values from the range reserved for
+ private use MUST be used according to the "Private Use" policy
+ described in RFC 2434. Values from the general IANA pool MUST be
+ assigned according to the "IETF Consensus" policy described in RFC
2434.
+6. Security Considerations
+ This document does not introduce any topics that alter the threat
+ model addressed by TLS. The security considerations described
+ throughout RFC 2246 [2] apply here as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck Expires April 23, 2003 [Page 9]
+Hollenbeck Expires June 2, 2003 [Page 5]
\f
-Internet-Draft TLS Compression Methods October 2002
-
+Internet-Draft TLS Compression Methods December 2002
-6. Security Considerations
-
- This document does not introduce any topics that alter the threat
- model addressed by TLS. The security considerations described
- throughout RFC 2246 [2] apply here as well.
Some symmetric encryption ciphersuites do not hide the length of
symmetrically encrypted data at all. Others hide it to some extent,
into account that the length of compressed data may leak more
information than the length of the original uncompressed data.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck Expires April 23, 2003 [Page 10]
-\f
-Internet-Draft TLS Compression Methods October 2002
-
-
7. Acknowledgements
The concepts described in this document were originally discussed on
author acknowledges the contributions to that discussion provided by
Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen. Later
suggestions that have been incorporated into this document were
- provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Nikos
+ provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Elgin Lee, Nikos
Mavroyanopoulos, Alexey Melnikov, and Bodo Moeller.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck Expires April 23, 2003 [Page 11]
-\f
-Internet-Draft TLS Compression Methods October 2002
-
-
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+Informative References
+ [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
+ "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
+ October 2000, <http://www.w3.org/TR/REC-xml>.
+ [5] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, May 1996.
+ [6] Deutsch, P., "DEFLATE Compressed Data Format Specification
+ version 1.3", RFC 1951, May 1996.
+ [7] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
+ [8] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,
+ December 1998.
+ [9] Gutmann, P., "Compressed Data Content Type for Cryptographic
+ Message Syntax (CMS)", RFC 3274, June 2002.
+Hollenbeck Expires June 2, 2003 [Page 6]
+\f
+Internet-Draft TLS Compression Methods December 2002
+Author's Address
+ Scott Hollenbeck
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ US
+ EMail: shollenbeck@verisign.com
-Hollenbeck Expires April 23, 2003 [Page 12]
-\f
-Internet-Draft TLS Compression Methods October 2002
-
-
-Informative References
-
- [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
- "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
- October 2000, <http://www.w3.org/TR/REC-xml>.
-
- [5] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
- Specification version 3.3", RFC 1950, May 1996.
-
- [6] Deutsch, P., "DEFLATE Compressed Data Format Specification
- version 1.3", RFC 1951, May 1996.
-
- [7] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
-
- [8] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,
- December 1998.
- [9] Gutmann, P., "Compressed Data Content Type for Cryptographic
- Message Syntax (CMS)", RFC 3274, June 2002.
- [10] American National Standards Institute, "Data Compression
- Method, Adaptive Coding with Sliding Window of Information
- Interchange", ANSI X3.241, 1994.
- [11] Schneider, K., Friend, R. and K. Fox, "PPP LZS-DCP Compression
- Protocol (LZS-DCP)", RFC 1967, August 1996.
- [12] Friend, R., Simpson, W. and K. Fox, "PPP Stac LZS Compression
- Protocol", RFC 1974, August 1996.
- [13] Friend, R. and R. Monsour, "IP Payload Compression Using LZS",
- RFC 2395, December 1998.
-Author's Address
- Scott Hollenbeck
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- US
- EMail: shollenbeck@verisign.com
-Hollenbeck Expires April 23, 2003 [Page 13]
+Hollenbeck Expires June 2, 2003 [Page 7]
\f
-Internet-Draft TLS Compression Methods October 2002
+Internet-Draft TLS Compression Methods December 2002
Full Copyright Statement
-Hollenbeck Expires April 23, 2003 [Page 14]
\ No newline at end of file
+Hollenbeck Expires June 2, 2003 [Page 8]
\ No newline at end of file
Transport Layer Security Working D. Taylor
Group Forge Research Pty Ltd
-Internet-Draft September 4, 2002
-Expires: March 5, 2003
+Internet-Draft November 29, 2002
+Expires: May 30, 2003
Using SRP for TLS Authentication
- draft-ietf-tls-srp-03
+ draft-ietf-tls-srp-04
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on March 5, 2003.
+ This Internet-Draft will expire on May 30, 2003.
Copyright Notice
-Taylor Expires March 5, 2003 [Page 1]
+Taylor Expires May 30, 2003 [Page 1]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
Table of Contents
2.2 SRP Verifier Message Digest Selection . . . . . . . . . . . 5
2.3 Changes to the Handshake Message Contents . . . . . . . . . 5
2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3.2 Server hello . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3.3 Server certificate . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3.2 Server certificate . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3.3 Server key exchange . . . . . . . . . . . . . . . . . . . . 5
2.3.4 Client key exchange . . . . . . . . . . . . . . . . . . . . 6
- 2.3.5 Server key exchange . . . . . . . . . . . . . . . . . . . . 6
2.4 Calculating the Pre-master Secret . . . . . . . . . . . . . 6
2.5 Cipher Suite Definitions . . . . . . . . . . . . . . . . . . 6
2.6 New Message Structures . . . . . . . . . . . . . . . . . . . 7
2.6.1 ExtensionType . . . . . . . . . . . . . . . . . . . . . . . 7
2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . . 8
- 2.6.4 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 8
- 2.6.5 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 8
+ 2.6.3 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 7
+ 2.6.4 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
-Taylor Expires March 5, 2003 [Page 2]
+
+
+Taylor Expires May 30, 2003 [Page 2]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
1. Introduction
DSA digital signatures, or Kerberos, for authentication.
These authentication methods do not seem well suited to the
- applications now being adapted to use TLS (IMAP [3], FTP [5], or
- TELNET [6], for example). Given these protocols (and others like
+ applications now being adapted to use TLS (IMAP [4], FTP [6], or
+ TELNET [7], for example). Given these protocols (and others like
them) are designed to use the user name and password method of
authentication, being able to safely use user names and passwords to
authenticate the TLS connection provides a much easier route to
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
- Changes in this version:
- Changed the order of the s, N, and g parameters for the Server
- Hello message in the handshake sequence diagram to conform to the
- SRPExtension structure.
- Removed the requirement to add leading zeros to encoded numbers
- whose most significant bit is set.
-Taylor Expires March 5, 2003 [Page 3]
+
+
+
+
+
+
+Taylor Expires May 30, 2003 [Page 3]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
2. SRP Authentication in TLS
2.1 Modifications to the TLS Handshake Sequence
- The SRP protocol can not be implemented using the sequence of
- handshake messages defined in [1] due to the sequence in which the
- SRP messages must be sent.
+ The advent of SRP-6 [3] allows the SRP protocol to be implemented
+ using the standard sequence of handshake messages defined in [1].
- This document presents a new sequence of handshake messages for
- handshakes using the SRP authentication method.
+ The parameters to various messages are given in the following
+ diagram.
2.1.1 Message Sequence
Client Server
| |
- Client Hello (U) ------------------------> |
- | <---------------------------- Server Hello (s, N, g)
+ Client Hello (I) ------------------------> |
+ | <---------------------------- Server Hello
| <---------------------------- Certificate*
- Client Key Exchange (A) -----------------> |
- | <---------------------------- Server Key Exchange (B)
+ | <---------------------------- Server Key Exchange (N, g, s, B)
| <---------------------------- Server Hello Done
- change cipher spec |
+ Client Key Exchange (A) -----------------> |
+ [Change cipher spec] |
Finished --------------------------------> |
- | change cipher spec
+ | [Change cipher spec]
| <---------------------------- Finished
| |
+ Application Data <--------------> Application Data
* Indicates optional or situation-dependent messages that are not
always sent.
The identifiers given after each message name refer to the SRP
- variables included in that message. The variables U, g, N, s, A, and
- B are defined in [2].
+ variables included in that message. The variables I, N, g, s, A, and
+ B are defined in [3].
- Extended client and server hello messages, as defined in [7], are
- used to to send the initial client and server values.
+ An extended client hello message, as defined in [8], is used to send
+ the client identifier (the user name).
- The client key exchange message is sent during the sequence of server
- messages. This modification is required because the client must send
- its public key (A) before it receives the servers public key (B), as
- stated in Section 3 of [2].
+ Servers MAY add an SRP extension to the server hello message. For
+ the cipher suites defined in this document no information is carried
+ in the SRP extension in the server hello message. The option to add
+ an SRP extension to the server hello message is given in case it is
+ required in future.
2.1.2 Session Re-use
The short handshake mechanism for re-using sessions for new
- connections, and renegotiating keys for existing connections will
-Taylor Expires March 5, 2003 [Page 4]
+Taylor Expires May 30, 2003 [Page 4]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
+ connections, and renegotiating keys for existing connections will
still work with the SRP authentication mechanism and handshake.
When a client attemps to re-use a session that uses SRP
- authentication, it MUST still include the SRP extension carrying the
- user name (U) in the client hello message, in case the server cannot
- or will not allow re-use of the session, meaning a full handshake
+ authentication, it MUST include the SRP extension carrying the user
+ name (I) in the client hello message, in case the server cannot or
+ will not allow re-use of the session, meaning a full handshake
sequence is required.
- If a client requests an existing session and the server agrees to use
- it (meaning the short handshake will be used), the server MAY omit
- the SRP extension from the server hello message, as the information
- it contains is not used in the short handshake.
+ If the server does agree to re-use an existing session the server
+ MUST ignore the information in the SRP extension of the client hello
+ message, except for its inclusion in the finished message hashes.
+ This is to ensure attackers cannot replace the authenticated identity
+ without supplying the proper authentication information.
2.2 SRP Verifier Message Digest Selection
- The cipher suites defined in this document use the SHA-1 message
- digest with the SRP algorithm, as specified in [2]. Implementations
- conforming to this document MUST use the SHA-1 message digest.
-
- Future documents may define other cipher suites that use different
- message digests, or other similar functions, with the SRP algorithm.
+ Implementations conforming to this document MUST use the SHA-1
+ message digest with the SRP algorithm.
2.3 Changes to the Handshake Message Contents
2.3.1 Client hello
The user name is appended to the standard client hello message using
- the hello message extension mechanism defined in [7].
-
-2.3.2 Server hello
+ the hello message extension mechanism defined in [8].
- The the generator (g), the prime (N), and the salt value (s) read
- from the SRP password file are appended to the server hello message
- using the hello message extension mechanism defined in [7].
-
-2.3.3 Server certificate
+2.3.2 Server certificate
The server MUST send a certificate if it agrees to an SRP cipher
suite that requires the server to provide additional authentication
which ciphersuites defined in this document require a server
certificate to be sent.
-
-
-
-Taylor Expires March 5, 2003 [Page 5]
-\f
-Internet-Draft Using SRP for TLS Authentication September 2002
-
-
Because the server's certificate is only used for generating a
digital signature in SRP cipher suites, the certificate sent MUST
contain a public key that can be used for generating digital
signatures.
-2.3.4 Client key exchange
+2.3.3 Server key exchange
+
+ The server key exchange message contains the prime (N), the generator
+
- The client key exchange message carries the client's public key (A),
- which is calculated using both information known locally, and
- information received in the server hello message. This message MUST
- be sent before the server key exchange message.
-2.3.5 Server key exchange
+Taylor Expires May 30, 2003 [Page 5]
+\f
+Internet-Draft Using SRP for TLS Authentication November 2002
+
- The server key exchange message contains the server's public key (B).
- The server key exchange message MUST be sent after the client key
- exchange message.
+ (g), and the salt value (s) read from the SRP password file based on
+ the value of (I) received in the client hello extension. The server
+ key exchange message also contains the server's public key (B).
If the server has sent a certificate message, the server key exchange
message MUST be signed.
+2.3.4 Client key exchange
+
+ The client key exchange message carries the client's public key (A).
+
2.4 Calculating the Pre-master Secret
The shared secret resulting from the SRP calculations (S) (defined in
[2]) is used as the pre-master secret.
The finished messages perform the same function as the client and
- server evidence messages specified in [2]. If either the client or
- the server calculate an incorrect value, the finished messages will
- not be understood, and the connection will be dropped as specified in
- [1].
+ server evidence messages (M1 and M2) specified in [2]. If either the
+ client or the server calculate an incorrect value, the finished
+ messages will not be understood, and the connection will be dropped
+ as specified in [1].
2.5 Cipher Suite Definitions
The following cipher suites are added by this draft. The usage of
- AES ciphersuites is as defined in [4].
+ AES ciphersuites is as defined in [5].
CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x50 };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x55 };
-
-
-Taylor Expires March 5, 2003 [Page 6]
-\f
-Internet-Draft Using SRP for TLS Authentication September 2002
-
-
CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0x56 };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x57 };
identifier assume the server is authenticated by its possesion of the
SRP database.
+
+
+Taylor Expires May 30, 2003 [Page 6]
+\f
+Internet-Draft Using SRP for TLS Authentication November 2002
+
+
Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
require the server to send a certificate message containing a
certificate with the specified type of public key, and to sign the
2.6.1 ExtensionType
A new value, "srp(6)", has been added to the enumerated
- ExtensionType, defined in [7]. This value is used as the extension
- number for the extensions in both the client hello message and the
- server hello message.
+ ExtensionType, defined in [8]. This value MUST be used as the
+ extension number for the SRP extension.
2.6.2 Client Hello
- The user name (U) is encoded in an SRPExtension structure, and sent
+ The user name (I) is encoded in an SRPExtension structure, and sent
in an extended client hello message, using an extension of type
"srp".
+ enum { client, server } ClientOrServerExtension;
+ struct {
+ select(ClientOrServerExtension) {
+ case client:
+ opaque srp_I<1..2^8-1>;
+ case server:
+ /* empty struct */
+ }
+ } SRPExtension;
+2.6.3 Server Key Exchange
+ When the value of KeyExchangeAlgorithm is set to "srp", the server's
+ SRP parameters are sent in the server key exchange message, encoded
+ in a ServerSRPParams structure.
+ If a certificate is sent to the client the server key exchange
+Taylor Expires May 30, 2003 [Page 7]
+\f
+Internet-Draft Using SRP for TLS Authentication November 2002
+ message must be signed. The following table gives the
+ SignatureAlgorithm value to be used for each ciphersuite.
-Taylor Expires March 5, 2003 [Page 7]
-\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+ Ciphersuite SignatureAlgorithm
+ TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA anonymous
+
+ TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA rsa
+
+ TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA dsa
+
+ TLS_SRP_SHA_WITH_AES_128_CBC_SHA anonymous
+
+ TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA rsa
+
+ TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA dsa
+
+ TLS_SRP_SHA_WITH_AES_256_CBC_SHA anonymous
+
+ TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA rsa
+
+ TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA dsa
- enum { client, server } ClientOrServerExtension;
struct {
- select(ClientOrServerExtension) {
- case client:
- opaque srp_U<1..2^8-1>;
- case server:
- opaque srp_s<1..2^8-1>
- opaque srp_N<1..2^16-1>;
- opaque srp_g<1..2^16-1>;
- }
- } SRPExtension;
+ select (KeyExchangeAlgorithm) {
+ case diffie_hellman:
+ ServerDHParams params;
+ Signature signed_params;
+ case rsa:
+ ServerRSAParams params;
+ Signature signed_params;
+ case srp: /* new entry */
+ ServerSRPParams params;
+ Signature signed_params;
+ };
+ } ServerKeyExchange;
+
+ struct {
+ opaque srp_N<1..2^16-1>;
+ opaque srp_g<1..2^16-1>;
+ opaque srp_s<1..2^8-1>
+ opaque srp_B<1..2^16-1>;
+ } ServerSRPParams; /* SRP parameters */
-2.6.3 Server Hello
- The generator (g), the prime (N), and the salt value (s) are encoded
- in an SRPExtension structure, which is sent in an extended server
- hello message, using an extension of type "srp".
+
+
+
+
+Taylor Expires May 30, 2003 [Page 8]
+\f
+Internet-Draft Using SRP for TLS Authentication November 2002
+
2.6.4 Client Key Exchange
} ClientSRPPublic;
-2.6.5 Server Key Exchange
- When the value of KeyExchangeAlgorithm is set to "srp", the server's
- ephemeral public key (B) is sent in the server key exchange message,
-Taylor Expires March 5, 2003 [Page 8]
-\f
-Internet-Draft Using SRP for TLS Authentication September 2002
- encoded in an ServerSRPPublic structure.
- The following table gives the SignatureAlgorithm value to be used for
- each ciphersuite.
- Ciphersuite SignatureAlgorithm
- TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA anonymous
- TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA rsa
- TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA dsa
- TLS_SRP_SHA_WITH_AES_128_CBC_SHA anonymous
- TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA rsa
- TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA dsa
- TLS_SRP_SHA_WITH_AES_256_CBC_SHA anonymous
- TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA rsa
- TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA dsa
- struct {
- select (KeyExchangeAlgorithm) {
- case diffie_hellman:
- ServerDHParams params;
- Signature signed_params;
- case rsa:
- ServerRSAParams params;
- Signature signed_params;
- case srp: /* new entry */
- ServerSRPPublic params;
- Signature signed_params;
- };
- } ServerKeyExchange;
- struct {
- opaque srp_B<1..2^16-1>;
- } ServerSRPPublic; /* SRP parameters */
-
-Taylor Expires March 5, 2003 [Page 9]
+Taylor Expires May 30, 2003 [Page 9]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
3. Security Considerations
-Taylor Expires March 5, 2003 [Page 10]
+Taylor Expires May 30, 2003 [Page 10]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
References
[2] Wu, T., "The SRP Authentication and Key Exchange System", RFC
2945, September 2000.
- [3] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
+ [3] Wu, T., "SRP-6: Improvements and Refinements to the Secure
+ Remote Password Protocol", October 2002.
+
+ [4] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
1999.
- [4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+ [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
- [5] Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
+ [6] Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
09 (work in progress), April 2002.
- [6] Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
+ [7] Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
tn3270e-telnet-tls-06 (work in progress), April 2002.
- [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
+ [8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
progress), July 2002.
-
-
-
-Taylor Expires March 5, 2003 [Page 11]
+Taylor Expires May 30, 2003 [Page 11]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
Appendix A. Acknowledgements
Thanks to all on the IETF tls mailing list for ideas and analysis.
+ Thanks to Tom Wu for adapting the SRP protocol so it fits the
+ standard TLS handshake message sequence.
-
-
-Taylor Expires March 5, 2003 [Page 12]
+Taylor Expires May 30, 2003 [Page 12]
\f
-Internet-Draft Using SRP for TLS Authentication September 2002
+Internet-Draft Using SRP for TLS Authentication November 2002
Full Copyright Statement
-Taylor Expires March 5, 2003 [Page 13]
+Taylor Expires May 30, 2003 [Page 13]
\f
projects / thirdparty / gnutls.git / commitdiff
