*** empty log message ***

4 files changed, 289 insertions, 625 deletions

diff --git a/doc/protocol/draft-ietf-tls-compression-03.txt b/doc/protocol/draft-ietf-tls-compression-04.txt
index 726e1bcd47..0d5d46a468 100644
--- a/doc/protocol/draft-ietf-tls-compression-03.txt
+++ b/doc/protocol/draft-ietf-tls-compression-04.txt
@@ -2,12 +2,12 @@
 
 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
 
@@ -30,7 +30,7 @@ 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
 
@@ -42,19 +42,19 @@ Abstract
    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]
 
-Internet-Draft          TLS Compression Methods             October 2002
+Internet-Draft          TLS Compression Methods            December 2002
 
 
 Conventions Used In This Document
@@ -66,19 +66,18 @@ 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
 
 
 
@@ -108,9 +107,10 @@ Table of Contents
 
 
 
-Hollenbeck               Expires April 23, 2003                 [Page 2]
+
+Hollenbeck                Expires June 2, 2003                  [Page 2]
 
-Internet-Draft          TLS Compression Methods             October 2002
+Internet-Draft          TLS Compression Methods            December 2002
 
 
 1. Introduction
@@ -139,36 +139,12 @@ Internet-Draft          TLS Compression Methods             October 2002
    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]
-
-Internet-Draft          TLS Compression Methods             October 2002
-
-
 2. Compression Methods
 
    TLS [2] includes the following compression method structure in
@@ -185,6 +161,14 @@ Internet-Draft          TLS Compression Methods             October 2002
        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
@@ -197,37 +181,25 @@ Internet-Draft          TLS Compression Methods             October 2002
    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]
-
-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
 
@@ -238,278 +210,76 @@ Internet-Draft          TLS Compression Methods             October 2002
    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]
 
-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]
-
-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]
-
-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
+   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]
 
-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,
@@ -517,50 +287,6 @@ Internet-Draft          TLS Compression Methods             October 2002
    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
@@ -568,55 +294,9 @@ Internet-Draft          TLS Compression Methods             October 2002
    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]
-
-Internet-Draft          TLS Compression Methods             October 2002
-
-
 Normative References
 
    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
@@ -629,20 +309,43 @@ Normative References
    [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]
+
+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
 
 
 
@@ -668,54 +371,15 @@ Normative References
 
 
 
-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, <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
 
 
 
@@ -724,9 +388,9 @@ Author's Address
 
 
 
-Hollenbeck               Expires April 23, 2003                [Page 13]
+Hollenbeck                Expires June 2, 2003                  [Page 7]
 
-Internet-Draft          TLS Compression Methods             October 2002
+Internet-Draft          TLS Compression Methods            December 2002
 
 
 Full Copyright Statement
@@ -780,4 +444,4 @@ Acknowledgement
 
 
 
-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
diff --git a/doc/protocol/draft-ietf-tls-srp-03.txt b/doc/protocol/draft-ietf-tls-srp-04.txt
index 65ee1660e1..093f9ec87f 100644
--- a/doc/protocol/draft-ietf-tls-srp-03.txt
+++ b/doc/protocol/draft-ietf-tls-srp-04.txt
@@ -3,12 +3,12 @@
 
 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
 
@@ -31,7 +31,7 @@ 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
 
@@ -53,9 +53,9 @@ Abstract
 
 
 
-Taylor                   Expires March 5, 2003                  [Page 1]
+Taylor                    Expires May 30, 2003                  [Page 1]
 
-Internet-Draft      Using SRP for TLS Authentication      September 2002
+Internet-Draft      Using SRP for TLS Authentication       November 2002
 
 
 Table of Contents
@@ -68,18 +68,16 @@ 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
@@ -109,9 +107,11 @@ Table of Contents
 
 
 
-Taylor                   Expires March 5, 2003                  [Page 2]
+
+
+Taylor                    Expires May 30, 2003                  [Page 2]
 
-Internet-Draft      Using SRP for TLS Authentication      September 2002
+Internet-Draft      Using SRP for TLS Authentication       November 2002
 
 
 1. Introduction
@@ -120,8 +120,8 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
    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
@@ -140,14 +140,8 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
    "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.
 
 
 
@@ -165,21 +159,26 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
 
 
 
-Taylor                   Expires March 5, 2003                  [Page 3]
+
+
+
+
+
+
+Taylor                    Expires May 30, 2003                  [Page 3]
 
-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
 
@@ -187,66 +186,65 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
 
           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]
 
-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
 
@@ -258,15 +256,9 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
 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
@@ -274,50 +266,48 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
    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
+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]
+
+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 };
 
@@ -331,13 +321,6 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
 
       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 };
@@ -348,6 +331,13 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
    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
@@ -367,52 +357,98 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
 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]
+
+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]
-
-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]
+
+Internet-Draft      Using SRP for TLS Authentication       November 2002
+
 
 2.6.4 Client Key Exchange
 
@@ -438,61 +474,26 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
    } 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 */
 
 
 
@@ -500,10 +501,9 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
 
 
 
-
-Taylor                   Expires March 5, 2003                  [Page 9]
+Taylor                    Expires May 30, 2003                  [Page 9]
 
-Internet-Draft      Using SRP for TLS Authentication      September 2002
+Internet-Draft      Using SRP for TLS Authentication       November 2002
 
 
 3. Security Considerations
@@ -557,9 +557,9 @@ Internet-Draft      Using SRP for TLS Authentication      September 2002
 
 
 
-Taylor                   Expires March 5, 2003                 [Page 10]
+Taylor                    Expires May 30, 2003                 [Page 10]
 
-Internet-Draft      Using SRP for TLS Authentication      September 2002
+Internet-Draft      Using SRP for TLS Authentication       November 2002
 
 
 References
@@ -570,20 +570,23 @@ 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.
 
@@ -610,18 +613,17 @@ Author's Address
 
 
 
-
-
-
-Taylor                   Expires March 5, 2003                 [Page 11]
+Taylor                    Expires May 30, 2003                 [Page 11]
 
-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.
 
 
 
@@ -667,11 +669,9 @@ Appendix A. Acknowledgements
 
 
 
-
-
-Taylor                   Expires March 5, 2003                 [Page 12]
+Taylor                    Expires May 30, 2003                 [Page 12]
 
-Internet-Draft      Using SRP for TLS Authentication      September 2002
+Internet-Draft      Using SRP for TLS Authentication       November 2002
 
 
 Full Copyright Statement
@@ -725,6 +725,6 @@ Acknowledgement
 
 
 
-Taylor                   Expires March 5, 2003                 [Page 13]
+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