From aa23650777efb3dfd84993631f4505af8e4b66f2 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Mon, 16 Dec 2002 10:47:48 +0000 Subject: *** empty log message *** --- doc/protocol/draft-ietf-tls-compression-03.txt | 783 ------------------------- doc/protocol/draft-ietf-tls-compression-04.txt | 447 ++++++++++++++ doc/protocol/draft-ietf-tls-srp-03.txt | 730 ----------------------- doc/protocol/draft-ietf-tls-srp-04.txt | 730 +++++++++++++++++++++++ doc/tex/gnutls.bib | 8 +- doc/tex/programs.tex | 2 +- 6 files changed, 1182 insertions(+), 1518 deletions(-) delete mode 100644 doc/protocol/draft-ietf-tls-compression-03.txt create mode 100644 doc/protocol/draft-ietf-tls-compression-04.txt delete mode 100644 doc/protocol/draft-ietf-tls-srp-03.txt create mode 100644 doc/protocol/draft-ietf-tls-srp-04.txt diff --git a/doc/protocol/draft-ietf-tls-compression-03.txt b/doc/protocol/draft-ietf-tls-compression-03.txt deleted file mode 100644 index 726e1bcd47..0000000000 --- a/doc/protocol/draft-ietf-tls-compression-03.txt +++ /dev/null @@ -1,783 +0,0 @@ - - -Network Working Group S. Hollenbeck -Internet-Draft VeriSign, Inc. -Updates: 2246 (if approved) October 23, 2002 -Expires: April 23, 2003 - - - Transport Layer Security Protocol Compression Methods - draft-ietf-tls-compression-03.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - 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. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - The Transport Layer Security (TLS) protocol (RFC 2246) includes - 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. - - - - - -Hollenbeck Expires April 23, 2003 [Page 1] - -Internet-Draft TLS Compression Methods October 2002 - - -Conventions Used In This Document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Compression History and Packet Processing . . . . . . . . . . 5 - 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 2] - -Internet-Draft TLS Compression Methods October 2002 - - -1. Introduction - - The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes - 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. While this single - compression method helps ensure that TLS implementations are - interoperable, the lack of additional standard compression methods - has limited the ability of implementers to develop interoperable - implementations that include data compression. - - TLS is used extensively to secure client-server connections on the - World Wide Web. While these connections can often be characterized - as short-lived and exchanging relatively small amounts of data, TLS - is also being used in environments where connections can be long- - lived and the amount of data exchanged can extend into thousands or - millions of octets. XML [4], for example, is increasingly being used - as a data representation method on the Internet, and XML tends to be - verbose. Compression within TLS is one way to help reduce the - bandwidth and latency requirements associated with exchanging large - 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. - Standardization of the compressed data formats and compression - algorithms associated with the compression methods is beyond the - scope of this document. - - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 3] - -Internet-Draft TLS Compression Methods October 2002 - - -2. Compression Methods - - TLS [2] includes the following compression method structure in - sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6: - - enum { null(0), (255) } CompressionMethod; - - which allows for later specification of up to 256 different - compression methods. This definition is updated to segregate the - range of allowable values into three zones: - - 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are - reserved for future standardization efforts of the IETF TLS - working group. - - 2. Values from 64 decimal (0x40) through 192 decimal (0xC0) are - 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 - formal reference that describes the compression method. - - 3. Values from 193 decimal (0xC1) through 255 decimal (0xFF) are - reserved for private use. - - Additional information describing the role of the IANA in the - 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; - - 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. - - 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 - compression method within TLS. - - - - -Hollenbeck Expires April 23, 2003 [Page 4] - -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. - -2.1 Compression History and Packet Processing - - Some compression methods have the ability to maintain history - information when compressing and decompressing packet payloads. The - compression history allows a higher compression ratio to be achieved - on a stream as compared to per-packet compression, but maintaining a - 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. - -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] - -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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 6] - -Internet-Draft TLS Compression Methods October 2002 - - -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 - this document or other documents that describe compression methods - for use with TLS. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 7] - -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] - -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 - 2434. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 9] - -Internet-Draft TLS Compression Methods October 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, - but still don't hide it fully. Use of TLS compression SHOULD take - 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] - -Internet-Draft TLS Compression Methods October 2002 - - -7. Acknowledgements - - The concepts described in this document were originally discussed on - the IETF TLS working group mailing list in December, 2000. The - 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 - Mavroyanopoulos, Alexey Melnikov, and Bodo Moeller. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 11] - -Internet-Draft TLS Compression Methods October 2002 - - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and - P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January - 1999. - - [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 12] - -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, . - - [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] - -Internet-Draft TLS Compression Methods October 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hollenbeck Expires April 23, 2003 [Page 14] \ No newline at end of file diff --git a/doc/protocol/draft-ietf-tls-compression-04.txt b/doc/protocol/draft-ietf-tls-compression-04.txt new file mode 100644 index 0000000000..0d5d46a468 --- /dev/null +++ b/doc/protocol/draft-ietf-tls-compression-04.txt @@ -0,0 +1,447 @@ + + +Network Working Group S. Hollenbeck +Internet-Draft VeriSign, Inc. +Updates: 2246 (if approved) December 2, 2002 +Expires: June 2, 2003 + + + Transport Layer Security Protocol Compression Methods + draft-ietf-tls-compression-04.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 2, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The Transport Layer Security (TLS) protocol (RFC 2246) includes + 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 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 June 2, 2003 [Page 1] + +Internet-Draft TLS Compression Methods December 2002 + + +Conventions Used In This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Compression Methods . . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Compression History and Packet Processing . . . . . . . . . . 4 + 2.2 ZLIB Compression . . . . . . . . . . . . . . . . . . . . . . . 5 + 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 June 2, 2003 [Page 2] + +Internet-Draft TLS Compression Methods December 2002 + + +1. Introduction + + The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes + 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. While this single + compression method helps ensure that TLS implementations are + interoperable, the lack of additional standard compression methods + has limited the ability of implementers to develop interoperable + implementations that include data compression. + + TLS is used extensively to secure client-server connections on the + World Wide Web. While these connections can often be characterized + as short-lived and exchanging relatively small amounts of data, TLS + is also being used in environments where connections can be long- + lived and the amount of data exchanged can extend into thousands or + millions of octets. XML [4], for example, is increasingly being used + as a data representation method on the Internet, and XML tends to be + verbose. Compression within TLS is one way to help reduce the + bandwidth and latency requirements associated with exchanging large + amounts of data while preserving the security services provided by + 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 this compression method is beyond the + scope of this document. + +2. Compression Methods + + TLS [2] includes the following compression method structure in + sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6: + + enum { null(0), (255) } CompressionMethod; + + which allows for later specification of up to 256 different + compression methods. This definition is updated to segregate the + range of allowable values into three zones: + + 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are + reserved for future standardization efforts of the IETF TLS + working group. + + 2. Values from 64 decimal (0x40) through 192 decimal (0xC0) are + + + +Hollenbeck Expires June 2, 2003 [Page 3] + +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 + formal reference that describes the compression method. + + 3. Values from 193 decimal (0xC1) through 255 decimal (0xFF) are + reserved for private use. + + Additional information describing the role of the IANA in the + allocation of compression method identifiers is described in Section + 5. + + In addition, this definition is updated to include assignment of an + identifier for the ZLIB compression method: + + enum { null(0), ZLIB(1), (255) } CompressionMethod; + + 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. + + 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 + + Some compression methods have the ability to maintain history + information when compressing and decompressing packet payloads. The + compression history allows a higher compression ratio to be achieved + on a stream as compared to per-packet compression, but maintaining a + 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. 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. + + + + + + +Hollenbeck Expires June 2, 2003 [Page 4] + +Internet-Draft TLS Compression Methods December 2002 + + +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 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 method described in + this document or other documents that describe compression methods + for use with TLS. + +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. + +5. IANA Considerations + + 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 June 2, 2003 [Page 5] + +Internet-Draft TLS Compression Methods December 2002 + + + Some symmetric encryption ciphersuites do not hide the length of + symmetrically encrypted data at all. Others hide it to some extent, + but still don't hide it fully. Use of TLS compression SHOULD take + into account that the length of compressed data may leak more + information than the length of the original uncompressed data. + +7. Acknowledgements + + The concepts described in this document were originally discussed on + the IETF TLS working group mailing list in December, 2000. The + 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, Elgin Lee, Nikos + Mavroyanopoulos, Alexey Melnikov, and Bodo Moeller. + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and + P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January + 1999. + + [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, . + + [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] + +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 June 2, 2003 [Page 7] + +Internet-Draft TLS Compression Methods December 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hollenbeck Expires June 2, 2003 [Page 8] \ No newline at end of file diff --git a/doc/protocol/draft-ietf-tls-srp-03.txt b/doc/protocol/draft-ietf-tls-srp-03.txt deleted file mode 100644 index 65ee1660e1..0000000000 --- a/doc/protocol/draft-ietf-tls-srp-03.txt +++ /dev/null @@ -1,730 +0,0 @@ - - - -Transport Layer Security Working D. Taylor -Group Forge Research Pty Ltd -Internet-Draft September 4, 2002 -Expires: March 5, 2003 - - - Using SRP for TLS Authentication - draft-ietf-tls-srp-03 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - 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. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This memo presents a technique for using the SRP [2] (Secure Remote - Password) protocol as an authentication method for the TLS - [1](Transport Layer Security) protocol. - - - - - - - - - - - -Taylor Expires March 5, 2003 [Page 1] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. SRP Authentication in TLS . . . . . . . . . . . . . . . . . 4 - 2.1 Modifications to the TLS Handshake Sequence . . . . . . . . 4 - 2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . . 4 - 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.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 - 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 - References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires March 5, 2003 [Page 2] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - -1. Introduction - - At the time of writing, TLS uses public key certificiates with RSA/ - 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 - 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 - additional security than implementing a public key infrastructure in - certain situations. - - SRP is an authentication method that allows the use of user names and - passwords over unencrypted channels without revealing the password to - an eavesdropper. SRP also supplies a shared secret at the end of the - authetication sequence that can be used to generate encryption keys. - - This document describes the use of the SRP authentication method for - TLS. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "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] - -Internet-Draft Using SRP for TLS Authentication September 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. - - This document presents a new sequence of handshake messages for - handshakes using the SRP authentication method. - -2.1.1 Message Sequence - - Handshake Message Flow for SRP Authentication - - Client Server - | | - Client Hello (U) ------------------------> | - | <---------------------------- Server Hello (s, N, g) - | <---------------------------- Certificate* - Client Key Exchange (A) -----------------> | - | <---------------------------- Server Key Exchange (B) - | <---------------------------- Server Hello Done - change cipher spec | - Finished --------------------------------> | - | change cipher spec - | <---------------------------- Finished - | | - - * 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]. - - Extended client and server hello messages, as defined in [7], are - used to to send the initial client and server values. - - 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]. - -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] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - - 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 - 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. - -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. - -2.3 Changes to the Handshake Message Contents - - This section describes the changes to the TLS handshake message - contents when SRP is being used for authentication. The definitions - of the new message contents and the on-the-wire changes are given in - Section 2.6. - -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 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 - - The server MUST send a certificate if it agrees to an SRP cipher - suite that requires the server to provide additional authentication - in the form of a digital signature. See Section 2.5 for details of - which ciphersuites defined in this document require a server - certificate to be sent. - - - - -Taylor Expires March 5, 2003 [Page 5] - -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 - - 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 - - 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. - - If the server has sent a certificate message, the server key exchange - message MUST be signed. - -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]. - -2.5 Cipher Suite Definitions - - The following cipher suites are added by this draft. The usage of - AES ciphersuites is as defined in [4]. - - CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x50 }; - - CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 }; - - CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 }; - - CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0x53 }; - - CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x54 }; - - CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x55 }; - - - -Taylor Expires March 5, 2003 [Page 6] - -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 }; - - CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x58 }; - - Cipher suites that do not include a digitial signature algorithm - identifier assume the server is authenticated by its possesion of the - SRP database. - - 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 - server key exchange message using a matching private key. - - Implementations conforming to this specification MUST implement the - TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the - TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA - ciphersuites, and MAY implement the remaining ciphersuites. - -2.6 New Message Structures - - This section shows the structure of the messages passed during a - handshake that uses SRP for authentication. The representation - language used is the same as that used in [1]. - -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. - -2.6.2 Client Hello - - The user name (U) is encoded in an SRPExtension structure, and sent - in an extended client hello message, using an extension of type - "srp". - - - - - - - - - - - - - -Taylor Expires March 5, 2003 [Page 7] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - - 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; - - -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". - -2.6.4 Client Key Exchange - - When the value of KeyExchangeAlgorithm is set to "srp", the client's - ephemeral public key (A) is sent in the client key exchange message, - encoded in an ClientSRPPublic structure. - - An extra value, srp, has been added to the enumerated - KeyExchangeAlgorithm, originally defined in TLS [1]. - - struct { - select (KeyExchangeAlgorithm) { - case rsa: EncryptedPreMasterSecret; - case diffie_hellman: ClientDiffieHellmanPublic; - case srp: ClientSRPPublic; /* new entry */ - } exchange_keys; - } ClientKeyExchange; - - enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm; - - struct { - opaque srp_A<1..2^16-1>; - } 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] - -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] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - -3. Security Considerations - - If an attacker is able to steal the SRP verifier file, the attacker - can masquerade as the real host. Filesystem based X.509 certificate - installations are vulnerable to a similar attack unless the server's - certificate is issued from a PKI that maintains revocation lists, and - the client TLS code can both contact the PKI and make use of the - revocation list. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires March 5, 2003 [Page 10] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - -References - - [1] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January - 1999. - - [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 - 1999. - - [4] 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 - 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- - tn3270e-telnet-tls-06 (work in progress), April 2002. - - [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. - Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in - progress), July 2002. - - -Author's Address - - David Taylor - Forge Research Pty Ltd - - EMail: DavidTaylor@forge.com.au - URI: http://www.forge.com.au/ - - - - - - - - - - - - - - - - - - -Taylor Expires March 5, 2003 [Page 11] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - -Appendix A. Acknowledgements - - Thanks to all on the IETF tls mailing list for ideas and analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires March 5, 2003 [Page 12] - -Internet-Draft Using SRP for TLS Authentication September 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Taylor Expires March 5, 2003 [Page 13] - - diff --git a/doc/protocol/draft-ietf-tls-srp-04.txt b/doc/protocol/draft-ietf-tls-srp-04.txt new file mode 100644 index 0000000000..093f9ec87f --- /dev/null +++ b/doc/protocol/draft-ietf-tls-srp-04.txt @@ -0,0 +1,730 @@ + + + +Transport Layer Security Working D. Taylor +Group Forge Research Pty Ltd +Internet-Draft November 29, 2002 +Expires: May 30, 2003 + + + Using SRP for TLS Authentication + draft-ietf-tls-srp-04 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on May 30, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This memo presents a technique for using the SRP [2] (Secure Remote + Password) protocol as an authentication method for the TLS + [1](Transport Layer Security) protocol. + + + + + + + + + + + +Taylor Expires May 30, 2003 [Page 1] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. SRP Authentication in TLS . . . . . . . . . . . . . . . . . 4 + 2.1 Modifications to the TLS Handshake Sequence . . . . . . . . 4 + 2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . . 4 + 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 certificate . . . . . . . . . . . . . . . . . . . . . 5 + 2.3.3 Server key exchange . . . . . . . . . . . . . . . . . . . . 5 + 2.3.4 Client 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 Key Exchange . . . . . . . . . . . . . . . . . . . . 7 + 2.6.4 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 9 + 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 + References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires May 30, 2003 [Page 2] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + +1. Introduction + + At the time of writing, TLS uses public key certificiates with RSA/ + 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 [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 + additional security than implementing a public key infrastructure in + certain situations. + + SRP is an authentication method that allows the use of user names and + passwords over unencrypted channels without revealing the password to + an eavesdropper. SRP also supplies a shared secret at the end of the + authetication sequence that can be used to generate encryption keys. + + This document describes the use of the SRP authentication method for + TLS. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires May 30, 2003 [Page 3] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + +2. SRP Authentication in TLS + +2.1 Modifications to the TLS Handshake Sequence + + The advent of SRP-6 [3] allows the SRP protocol to be implemented + using the standard sequence of handshake messages defined in [1]. + + The parameters to various messages are given in the following + diagram. + +2.1.1 Message Sequence + + Handshake Message Flow for SRP Authentication + + Client Server + | | + Client Hello (I) ------------------------> | + | <---------------------------- Server Hello + | <---------------------------- Certificate* + | <---------------------------- Server Key Exchange (N, g, s, B) + | <---------------------------- Server Hello Done + Client Key Exchange (A) -----------------> | + [Change cipher spec] | + Finished --------------------------------> | + | [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 I, N, g, s, A, and + B are defined in [3]. + + An extended client hello message, as defined in [8], is used to send + the client identifier (the user name). + + 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 + + + +Taylor Expires May 30, 2003 [Page 4] + +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 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 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 + + Implementations conforming to this document MUST use the SHA-1 + message digest with the SRP algorithm. + +2.3 Changes to the Handshake Message Contents + + This section describes the changes to the TLS handshake message + contents when SRP is being used for authentication. The definitions + of the new message contents and the on-the-wire changes are given in + Section 2.6. + +2.3.1 Client hello + + The user name is appended to the standard client hello message using + the hello message extension mechanism defined in [8]. + +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 + in the form of a digital signature. See Section 2.5 for details of + which ciphersuites defined in this document require a server + certificate to be sent. + + 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.3 Server key exchange + + The server key exchange message contains the prime (N), the generator + + + +Taylor Expires May 30, 2003 [Page 5] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + + (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 (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 [5]. + + CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x50 }; + + CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 }; + + CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 }; + + CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0x53 }; + + CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x54 }; + + CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x55 }; + + CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0x56 }; + + CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x57 }; + + CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x58 }; + + Cipher suites that do not include a digitial signature algorithm + identifier assume the server is authenticated by its possesion of the + SRP database. + + + +Taylor Expires May 30, 2003 [Page 6] + +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 + server key exchange message using a matching private key. + + Implementations conforming to this specification MUST implement the + TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the + TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA + ciphersuites, and MAY implement the remaining ciphersuites. + +2.6 New Message Structures + + This section shows the structure of the messages passed during a + handshake that uses SRP for authentication. The representation + language used is the same as that used in [1]. + +2.6.1 ExtensionType + + A new value, "srp(6)", has been added to the enumerated + 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 (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] + +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. + + 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 */ + 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 */ + + + + + + + +Taylor Expires May 30, 2003 [Page 8] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + +2.6.4 Client Key Exchange + + When the value of KeyExchangeAlgorithm is set to "srp", the client's + ephemeral public key (A) is sent in the client key exchange message, + encoded in an ClientSRPPublic structure. + + An extra value, srp, has been added to the enumerated + KeyExchangeAlgorithm, originally defined in TLS [1]. + + struct { + select (KeyExchangeAlgorithm) { + case rsa: EncryptedPreMasterSecret; + case diffie_hellman: ClientDiffieHellmanPublic; + case srp: ClientSRPPublic; /* new entry */ + } exchange_keys; + } ClientKeyExchange; + + enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm; + + struct { + opaque srp_A<1..2^16-1>; + } ClientSRPPublic; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires May 30, 2003 [Page 9] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + +3. Security Considerations + + If an attacker is able to steal the SRP verifier file, the attacker + can masquerade as the real host. Filesystem based X.509 certificate + installations are vulnerable to a similar attack unless the server's + certificate is issued from a PKI that maintains revocation lists, and + the client TLS code can both contact the PKI and make use of the + revocation list. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Taylor Expires May 30, 2003 [Page 10] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + +References + + [1] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January + 1999. + + [2] Wu, T., "The SRP Authentication and Key Exchange System", RFC + 2945, September 2000. + + [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. + + [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for + Transport Layer Security (TLS)", RFC 3268, June 2002. + + [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. + + [7] Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf- + tn3270e-telnet-tls-06 (work in progress), April 2002. + + [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. + + +Author's Address + + David Taylor + Forge Research Pty Ltd + + EMail: DavidTaylor@forge.com.au + URI: http://www.forge.com.au/ + + + + + + + + + + + + + + + +Taylor Expires May 30, 2003 [Page 11] + +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 May 30, 2003 [Page 12] + +Internet-Draft Using SRP for TLS Authentication November 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Taylor Expires May 30, 2003 [Page 13] + + diff --git a/doc/tex/gnutls.bib b/doc/tex/gnutls.bib index d904e2ce74..25e861e687 100644 --- a/doc/tex/gnutls.bib +++ b/doc/tex/gnutls.bib @@ -39,8 +39,8 @@ title = "Using SRP for TLS Authentication", month = "September", year = {2002}, - note = "Internet draft, work in progress. Available from http://www.normos.org/ietf/draft/draft-ietf-tls-srp-03.txt", - url = "http://www.normos.org/ietf/draft/draft-ietf-tls-srp-03.txt" + note = "Internet draft, work in progress. Available from http://www.normos.org/ietf/draft/draft-ietf-tls-srp-04.txt", + url = "http://www.normos.org/ietf/draft/draft-ietf-tls-srp-04.txt" } @Misc{TLSPGP, @@ -57,8 +57,8 @@ title = "Transport Layer Security Protocol Compression Methods", month = "October", year = {2002}, - note = "Internet draft, work in progress. Available from http://www.normos.org/ietf/draft/draft-ietf-tls-compression-03.txt", - url = "http://www.normos.org/ietf/draft/draft-ietf-tls-compression-03.txt" + note = "Internet draft, work in progress. Available from http://www.normos.org/ietf/draft/draft-ietf-tls-compression-04.txt", + url = "http://www.normos.org/ietf/draft/draft-ietf-tls-compression-04.txt" } @Misc{CBCATT, diff --git a/doc/tex/programs.tex b/doc/tex/programs.tex index da82f636dd..493864255e 100644 --- a/doc/tex/programs.tex +++ b/doc/tex/programs.tex @@ -25,7 +25,7 @@ $ gnutls-srpcrypt --create-conf /etc/tpasswd.conf \item This command will create /etc/tpasswd and will add user 'test' (you will also be prompted for a password). Verifiers are stored by default in the -way libsrp expects (using a modified SHA()). +way libsrp expects. \begin{verbatim} $ gnutls-srpcrypt --passwd /etc/tpasswd \ --passwd-conf /etc/tpasswd.conf -u test -- cgit v1.2.1