*** empty log message ***

2 files changed, 1235 insertions, 1175 deletions

diff --git a/doc/protocol/draft-ietf-tls-ecc-01.txt b/doc/protocol/draft-ietf-tls-ecc-01.txt
new file mode 100644
index 0000000000..5f40986274
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-ecc-01.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+TLS Working Group                                     Simon Blake-Wilson
+INTERNET-DRAFT                                                Tim Dierks
+Expires: September 14, 2001                                   Chris Hawk
+                                                          Certicom Corp.
+                                                           15 March 2001
+
+
+                       ECC Cipher Suites for TLS
+                      <draft-ietf-tls-ecc-01.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 may be found at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories may be found at
+ http://www.ietf.org/shadow.html.
+
+
+                               Abstract
+
+ This document describes additions to TLS to support Elliptic Curve
+ Cryptography (ECC). In particular it defines new key exchange 
+ algorithms which use the Elliptic Curve Digital Signature Algorithm 
+ (ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme 
+ (ECDH), and it defines how to perform client authentication with ECDSA
+ and ECDH.
+
+ 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 [MUST].
+
+ Please send comments on this document to the TLS mailing list.
+
+
+
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 1]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+
+                          Table of Contents
+
+  1.    Introduction ................................................. 2
+  2.    Elliptic Curve Key Exchange Algorithms ....................... 4
+  2.1.  ECDH_ECDSA ................................................... 5
+  2.2.  ECDH_ECDSA_EXPORT ............................................ 5
+  2.3.  ECDH_RSA ..................................................... 6
+  2.4.  ECDH_RSA_EXPORT .............................................. 6
+  2.5.  ECDH_anon .................................................... 6
+  2.6.  ECDH_anon_EXPORT ............................................. 6
+  3.    ECC Client Authentication .................................... 7
+  3.1.  ECDSA_sign ................................................... 7
+  3.2.  ECDSA_fixed_ECDH ............................................. 8
+  3.3.  RSA_fixed_ECDH ............................................... 9 
+  4.    Data Structures and Computations ............................. 9
+  4.1.  Server Certificate .......................................... 10
+  4.2.  Server Key Exchange ......................................... 11
+  4.3.  Certificate Request ......................................... 15
+  4.4.  Client Certificate .......................................... 15
+  4.5.  Client Key Exchange ......................................... 16
+  4.6.  Certificate Verify .......................................... 18
+  4.7.  Computing the Master Secret ................................. 19  
+  5.    Cipher Suites ............................................... 19
+  6.    Security Considerations ..................................... 20
+  7.    Intellectual Property Rights ................................ 20
+  8.    Acknowledgments ............................................. 21
+  9.    References .................................................. 21
+  10.   Authors' Addresses .......................................... 22
+
+
+1.  Introduction
+
+This document describes additions to TLS to support Elliptic Curve
+Cryptography (ECC). In particular, it defines:
+
+- new key exchange algorithms which use the Elliptic Curve Digital
+  Signature Algorithm (ECDSA), and the Elliptic Curve Diffie-Hellman 
+  Key Agreement Scheme (ECDH); and
+
+- new client authentication methods which use ECDSA and ECDH.
+
+In order to enable the use of these features within TLS, the document
+defines enhanced data structures to convey the information that the
+mechanisms need to exchange, the computational procedures involved in
+the operation of the mechanisms, and new cipher suites based on the
+mechanisms. 
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 2]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+Use of ECC within TLS may provide both bandwidth and computational
+savings compared to other public-key cryptographic techniques. 
+Furthermore, the efficiencies provided by ECC may increase as security
+requirements increase based on Moore's law - this is illustrated by the
+following table, based on [LEN], which gives approximate comparable key
+sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems based
+on the running times of the best algorithms known today.
+
+              Symmetric    |  ECC    |  DH/DSA/RSA
+                 80        |  163    |  1024
+                128        |  283    |  3072
+                192        |  409    |  7680
+                256        |  571    |  15360
+
+             Table 1: Comparable key sizes (in bits) 
+
+The savings that ECC may offer are likely to become increasingly
+desirable with the widespread use of TLS by wireless devices -
+discussed, for example, in [TLS-EXT].
+
+This document assumes the reader is familiar with both ECC and TLS. ECC
+is described in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], IEEE
+1363 [IEEE1363], and SEC 1 [SEC1]. TLS is described in RFC 2246 [TLS].
+
+The choice of mechanisms included in this document was motivated by a
+desire to provide mechanisms which are secure, which are as efficient
+as possible, and which are capable of replicating all of the
+functionality and operating modes found in the existing TLS mechanisms
+based on integer factorization and discrete logarithm cryptographic
+systems. TLS includes a substantial variety of functionality and
+operating modes in consideration of the variety of applications with
+which TLS is used.
+
+The desire described above led to the inclusion of a substantial number
+of ECC-based mechanisms. In order to encourage interoperability, a
+small subset of the mechanisms are identified as "recommended" - these
+mechanisms are capable of meeting the requirements of many
+applications and they should therefore be used unless an application
+profile of this document states otherwise, or unless in a particular
+environment considerations such as export regulations mandate
+otherwise. 
+
+The remainder of this document is organized as follows. Section 2
+specifies key exchange algorithms for TLS using ECC. Section 3
+specifies how client authentication is performed using ECC. Section 4
+describes the TLS-specific data structures and computations involved in
+the operation of the ECC mechanisms. Section 5 defines cipher suites
+based on the ECC key exchange algorithms. Sections 6-8 discuss security
+considerations, intellectual property rights, and acknowledgements
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 3]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+respectively. Section 9 supplies references cited elsewhere in the
+document, and Section 10 gives the authors' contact details.
+
+
+2.  Elliptic Curve Key Exchange Algorithms
+
+This document defines six new key exchange algorithms based on ECC for
+use within TLS.
+
+The table below summarizes the new key exchange algorithms.
+
+   Key
+   Exchange
+   Algorithm          Description                        Key size limit
+
+   ECDH_ECDSA         ECDH with ECDSA signatures         None
+   ECDH_ECDSA_EXPORT  ECDH with ECDSA signatures         ECDH=163 bits,
+                                                         ECDSA=none
+   ECDH_RSA           ECDH with RSA signatures           None
+   ECDH_RSA_EXPORT    ECDH with RSA signatures           ECDH=163 bits,
+                                                         RSA = none
+   ECDH_anon          Anonymous ECDH, no signatures      None
+   ECDH_anon_EXPORT   Anonymous ECDH, no signatures      ECDH=163 bits
+
+                     Table 2: Key exchange algorithms
+
+Note that the key exchange algorithms marked "anon" do not provide
+authentication of the server or the client, and, like other "anon" TLS
+key exchange algorithms, may be subject to man-in-the-middle attacks.
+Implementations of these algorithms SHOULD provide authentication by
+other means.
+
+The remainder of this section describes these key exchange algorithms
+in detail. For each key exchange algorithm, this involves specification
+of the contents of the handshake messages related to key exchange -
+server certificate, server key exchange, client certificate, and client
+key exchange - as well as specification of the computations involved in
+the calculation of the master secret.
+
+2.1.  ECDH_ECDSA
+
+ECDH is used to compute the master secret. The server is authenticated
+via a certificate containing an ECDH public key signed with ECDSA.
+
+Specifically this key exchange algorithm MUST proceed as follows:
+
+- The server provides a static ECDH public key in the server
+  certificate message using the format described in Section 4.1. The
+  certificate is signed using ECDSA.
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 4]
+
+INTERNET-DRAFT                                           20 January 2000
+
+
+- The server key exchange message is not sent.
+
+- Unless client authentication using ECDH is performed as specified in
+  Sections 3.2 and 3.3, the client provides an ephemeral ECDH public
+  key in the client key exchange message using the format described in
+  Section 4.5. In this case, the client certificate and certificate
+  verify message are not sent unless client authentication is performed 
+  using ECDSA as specified in Section 3.1, or another signature
+  algorithm. 
+
+- If client authentication using ECDH is performed, the client provides
+  a static ECDH public key in the client certificate message using the
+  format described in Section 4.4. In this case an empty client key
+  exchange message is sent using the format described in Section 4.5, and
+  the certificate verify message is not sent.
+
+- The client and server compute the master secret using their ECDH key
+  pairs as specified in Section 4.7.
+
+ECDH computations for this key exchange algorithm are performed
+according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
+ECSVDP-DH secret value derivation primitive, and the KDF1 key
+derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are
+performed according to ANSI X9.62 [ANSIX962] using the hash function
+SHA-1 [FIPS180-1].
+
+
+2.2.  ECDH_ECDSA_EXPORT
+
+Export-strength ECDH is used to compute the master secret. The server
+is authenticated via a certificate containing an ECDH public key signed
+with ECDSA.
+
+This key exchange algorithm MUST proceed in the same way as ECDH_ECDSA,
+except that the key size for ECDH public keys is constrained to 163
+bits or less. Here the key size of an elliptic curve public key refers
+to the size of the underlying finite field over which the elliptic
+curve is defined.
+
+
+2.3.  ECDH_RSA
+
+ECDH is used to compute the master secret. The server is authenticated
+via a certificate containing an ECDH public key signed with RSA.
+
+This key exchange MUST proceed in the same way as ECDH_ECDSA, except
+that the server's certificate is signed with RSA.
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 5]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+2.4.  ECDH_RSA_EXPORT
+
+Export-strength ECDH is used to compute the master secret. The server
+is authenticated via a certificate containing an ECDH public key signed
+with RSA. 
+
+This key exchange algorithm MUST proceed in the same way as ECDH_RSA,
+except that the key size for ECDH public keys is constrained to be 163
+bits or less.
+
+
+2.5.  ECDH_anon
+
+Anonymous ECDH is used to compute the master secret.
+
+Specifically this key exchange algorithm MUST proceed as follows:
+
+- The server certificate message is not sent.
+
+- The server provides an ephemeral ECDH public key in the server key
+  exchange message using the format described in Section 4.2.
+
+- The client certificate message is not sent.
+
+- The client provides an ephemeral ECDH public key in the client key
+  exchange message using the format described in Section 4.5.
+
+- The client and server compute the master secret using their ECDH
+  key pairs as specified in Section 4.7.
+
+ECDH computations for this key exchange algorithm are performed
+according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
+ECSVDP-DH secret value derivation primitive, and the KDF1 key
+derivation primitive using SHA-1 [FIPS180-1].
+
+
+2.6.  ECDH_anon_EXPORT  
+
+Export-strength, anonymous ECDH is used to compute the master secret.
+This key exchange algorithm MUST proceed in the same way as ECDH_anon,
+except that the key size for ECDH public keys is constrained to 163
+bits or less.
+
+
+3.  ECC Client Authentication
+
+This document defines three new ECC-based client authentication methods
+- ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH.
+
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 6]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+To encourage interoperability, implementations SHOULD support
+ECDSA_fixed_ECDH. Implementations MAY support any of the other client
+authentication methods.
+
+The remainder of this section specifies these ECC-based client
+authentication methods. The following information is provided for each
+method: which key exchange algorithms the method may be used with, what
+constraints apply to the method, and the formats of the certificate
+request, client certificate, client key exchange, and certificate
+verify messages.
+
+
+3.1.  ECDSA_sign
+
+The client supplies a certificate containing an ECDSA public key, and
+authenticates itself by signing the certificate verify message with its
+ECDSA key pair. 
+
+This client authentication method MUST proceed as follows.
+
+Applicable key exchange algorithms:
+
+- This client authentication method is eligible for use with all the
+  non-anonymous ECC-based key exchange algorithms specified in Section
+  2, and all the existing non-anonymous TLS key exchange algorithms
+  specified in [TLS].
+
+Restrictions:
+
+- In order to perform this method, the client must possess a certified
+  ECDSA public key.
+
+Message exchange:
+
+- The server requests use of the ECDSA_sign method by sending a
+  certificate request message containing the value "ecdsa_sign" using
+  the format described in Section 4.3. When the client receives this
+  request, it checks that it possesses an appropriate certificate and 
+  that it is willing to proceed.
+
+- If the client proceeds, it sends its certificate containing its ECDSA
+  public key in the client certificate message using the format
+  described in Section 4.4. It signs the handshake messages exchanged
+  so far with its ECDSA key pair and conveys the resulting signature to
+  the server in the certificate verify message using the format
+  specified in Section 4.6. 
+
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 7]
+
+INTERNET-DRAFT                                             15 March 2001
+
+- (If the client does not proceed, it may perform client authentication
+  using another method suggested by the server in the certificate
+  request message in which case the client certificate and the
+  certificate verify message are sent in accordance with the selected
+  method, or it may proceed with the key exchange without client
+  authentication - in which case the client certificate and certificate
+  verify messages are not sent.)
+
+ECDSA computations for this client authentication method are performed
+according to ANSI X9.62 [ANSIX962] using the hash function SHA-1
+[FIPS180-1]. 
+
+3.2.  ECDSA_fixed_ECDH
+
+The client supplies an ECDSA-signed certificate containing an ECDH
+public key using the same elliptic curve domain parameters as the
+server's ECDH public key. The client authenticates itself by computing
+the master secret and the finished message. (This achieves
+authentication because these computations can only be performed by a
+party possessing the private key corresponding to one of the ECDH
+public keys exchanged.)
+
+This client authentication method MUST proceed as follows.
+
+Applicable key exchange algorithms:
+
+- This method is eligible for use with all the non-anonymous ECC-based
+  key exchange algorithms specified in Section 2.
+
+Restrictions:
+
+- In order to perform this client authentication method, the client
+  must possess an ECDSA-signed certificate containing an ECDH public
+  key using the same elliptic curve domain parameters as the ECDH
+  public key supplied by the server in the server certificate message. 
+
+Message exchange:
+
+- The server requests use of the ECDSA_fixed_ECDH method by sending a
+  certificate request message containing the value "ecdsa_fixed_ecdh"
+  using the format described in Section 4.3. When the client receives
+  this request, it checks that it possesses an appropriate certificate
+  and that it is willing to proceed.
+
+- If the client proceeds, it sends its certificate containing its ECDH
+  public key in the client certificate message using the format
+  described in Section 4.4. It sends an empty client key exchange
+  message using the format described in Section 4.5. It does not send
+  the certificate verify message. It uses its static ECDH key pair,
+  along with the server's ECDH public key) when computing the master
+  secret and finished message.
+
+Blake-Wilson, Dierks, Hawk                                      [Page 8]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+- (If the client does not proceed, it may perform client authentication
+  using another method suggested by the server in the certificate
+  request message, or it may proceed with the key exchange without
+  client authentication - in which case the client certificate and
+  certificate verify messages are not sent.)
+
+ECDH computations for this key exchange algorithm are performed
+according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
+ECSVDP-DH secret value derivation primitive, and the KDF1 key
+derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are
+performed according to ANSI X9.62 [ANSIX962] using the hash function
+SHA-1 [FIPS180-1].
+
+
+3.3.  RSA_fixed_ECDH
+
+The client supplies an RSA-signed certificate containing an ECDH
+public key using the same elliptic curve domain parameters as the
+server's ECDH public key. The client authenticates itself by computing
+the master secret and the finished message. (This achieves
+authentication because these computations can only be performed by a
+party possessing the private key corresponding to one of the ECDH
+public keys exchanged.)
+
+This client authentication method MUST proceed in the same manner as
+the ECDSA_fixed_ECDH method, except that the client's certificate must
+be signed with RSA, and the server requests use of the method by
+sending a certificate request message containing the value
+"rsa_fixed_ecdh". 
+
+
+4.  Data Structures and Computations
+
+This section specifies the data structures and computations used by the
+ECC-based mechanisms specified in Sections 2 and 3. The presentation
+language used here is the same as that used in RFC 2246 [TLS]. Because
+these specifications extend the TLS protocol specification, these
+descriptions should be merged with those in TLS and in any other
+specifications which extend TLS. This means that enum types may not
+specify all the possible values and structures with multiple formats
+chosen with a select() clause may not indicate all the possible cases.  
+ 
+
+4.1.  Server Certificate
+  
+This message is sent in the following key exchange algorithms:
+
+All the non-anonymous ECC-based key exchange algorithms specified in
+Section 2.
+
+
+Blake-Wilson, Dierks, Hawk                                      [Page 9]
+
+INTERNET-DRAFT                                             15 March 2001
+ 
+
+Meaning of this message:
+
+This message is used to authentically convey the server's static public
+key to the client. The appropriate certificate types are given in the
+following table.
+
+       Key Exchange Algorithm  Certificate Type
+
+       ECDH_ECDSA              ECC public key; the certificate must
+                               allow the key to be used for key
+                               agreement. The certificate must be
+                               signed with ECDSA.
+
+       ECDH_ECDSA_EXPORT       ECC public key which can be used for key
+                               agreement; key size must be 163 bits or
+                               less. Certificate must be signed with
+                               ECDSA.
+
+       ECDH_RSA                ECC public key which can be used for key
+                               agreement. Certificate must be signed
+                               with RSA.
+
+       ECDH_RSA_EXPORT         ECC public key which can be used for key
+                               agreement; key size must be 163 bits or
+                               less. Certificate must be signed with
+                               RSA.
+
+                       Table 3: Server certificate types
+
+[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
+X.509 certificates. Servers SHOULD use the elliptic curve domain
+parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
+[FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same
+identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key
+usage extension may be used to further delimit the use of the key. When
+a key usage extension is present, the "keyAgreement" bit MUST be set
+for ECDH certificates.
+
+Structure of this message:
+
+Identical to the TLS Certificate format.
+
+Actions of the sender:
+
+The server constructs an appropriate certificate chain and conveys it
+to the client in the Certificate message.
+
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 10]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+Actions of the receiver:
+
+The client validates the certificate chain, extracts the server's
+public key, and checks that the key is of the correct type for the key
+exchange algorithm.
+
+
+4.2.  Server Key Exchange
+  
+This message is sent in the following key exchange algorithms:
+
+Both the anonymous ECC-based key exchange algorithms specified in
+Section 2.
+
+Meaning of this message:
+
+This message is used to convey the server's ephemeral ECDH public key
+(and the corresponding elliptic curve domain parameters) to the client.
+
+Structure of this message:
+
+The TLS ServerKeyExchange message is extended as follows.
+
+     enum { ec_diffie_hellman } KeyExchangeAlgorithm;
+
+ec_diffie_hellman
+Indicates the ServerKeyExchange message is to contain an ECDH public
+key. 
+
+     enum { explicit_prime (1), explicit_char2 (2),
+            named_curve (3), (255) } ECCurveType;
+
+explicit_prime
+Indicates the elliptic curve domain parameters will be conveyed
+verbosely, and that the underlying finite field is a prime field.
+
+explicit_char2
+Indicates the elliptic curve domain parameters will be conveyed
+verbosely, and that the underlying finite field is a characteristic 2
+field.
+
+named_curve
+Indicates that a named curve will be used. The use of this option is
+strongly recommended. 
+
+     struct {
+         opaque a <1..2^8-1>;
+         opaque b <1..2^8-1>;
+         opaque seed <0..2^8-1>;
+     } ECCurve;
+
+Blake-Wilson, Dierks, Hawk                                     [Page 11]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+a, b 
+These parameters specify the coefficients of the elliptic curve. Each
+value contains the byte string representation of a field element
+following the conversion routine in [X9.62], section 4.3.3.
+
+seed 
+This is an optional parameter used to derive the coefficients of a
+randomly generated elliptic curve.
+
+     struct {
+         opaque point <1..2^8-1>;
+     } ECPoint;
+
+point 
+This is the byte string representation of an elliptic curve point
+following the conversion routine in [X9.62], section 4.3.6.
+
+     enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
+
+ec_basis_trinomial
+Indicates representation of a characteristic two field using a
+trinomial basis.
+
+ec_basis_pentanomial
+Indicates representation of a characteristic two field using a
+pentanomial basis.
+
+     enum {
+         sect163k1 (1), sect163r1 (2), sect163r2 (3),
+         sect193r1 (4), sect193r2 (5), sect233k1 (6),
+         sect233r1 (7), sect239k1 (8), sect283k1 (9),
+         sect283r1 (10), sect409k1 (11), sect409r1 (12),
+         sect571k1 (13), sect571r1 (14), secp160k1 (15),
+         secp160r1 (16), secp160r2 (17), secp192k1 (18),
+         secp192r1 (19), secp224k1 (20), secp224r1 (21),
+         secp256k1 (22), secp256r1 (23), secp384r1 (24),
+         secp521r1 (25), (255)
+     } NamedCurve;
+
+sect163k1, etc
+Indicates use of the corresponding recommended curve specified in SEC 2
+[SEC2]. Note that many of these curves are also recommended in ANSI
+X9.62 [ANSIX962], and FIPS 186-2 [FIPS186-2].
+
+
+
+
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 12]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+     struct {
+         ECCurveType    curve_type;
+         select (curve_type) {
+             case explicit_prime:
+                 opaque      prime_p <1..2^8-1>;
+                 ECCurve     curve;
+                 ECPoint     base;
+                 opaque      order <1..2^8-1>;
+                 opaque      cofactor <1..2^8-1>; 
+             case explicit_char2:
+                 uint16      m;
+                 ECBasisType basis;
+                 select (basis) {
+                     case ec_trinomial:
+                         opaque  k <1..2^8-1>;
+                     case ec_pentanomial:
+                         opaque  k1 <1..2^8-1>;
+                         opaque  k2 <1..2^8-1>;
+                         opaque  k3 <1..2^8-1>;
+                 };
+                 ECCurve     curve;
+                 ECPoint     base;
+                 opaque      order <1..2^8-1>;
+                 opaque      cofactor <1..2^8-1>;
+             case named_curve:      
+                 NamedCurve namedcurve;
+         };
+     } ECParameters;
+
+curve_type 
+This identifies the type of the elliptic curve domain parameters.
+
+prime_p
+This is the odd prime defining the field Fp.
+
+curve
+Specifies the coefficients a and b of the elliptic curve E.
+
+base 
+Specifies the base point G on the elliptic curve.
+
+order 
+Specifies the order n of the base point.
+
+cofactor
+Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number 
+of points on the elliptic curve E defined over the field Fq.
+
+m 
+This is the degree of the characteristic-two field F2^m.
+
+Blake-Wilson, Dierks, Hawk                                     [Page 13]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+k 
+The exponent k for the trinomial basis representation x^m+x^k+1.
+
+k1, k2, k3 
+The exponents for the pentanomial representation x^m+x^k3+x^k2+x^k1+1. 
+
+namedcurve
+Specifies a recommended set of elliptic curve domain parameters.
+
+     struct {
+         ECParameters    curve_params;
+         ECPoint         public;
+     } ServerECDHParams;
+
+
+curve_params 
+Specifies the elliptic curve domain parameters associated with the
+ECDH public key.
+
+public
+The ephemeral ECDH public key.
+
+     select (KeyExchangeAlgorithm) {
+         case ec_diffie_hellman:
+             ServerECDHParams    params;
+             Signature           signed_params;
+     } ServerKeyExchange;
+
+params
+Specifies the ECDH public key and associated domain parameters.
+
+signed_params
+This element is empty for all the key exchange algorithms specified in
+this document.
+
+Actions of the sender:
+
+The server selects elliptic curve domain parameters and an ephemeral
+ECDH public key corresponding to these parameters according to the
+ECKAS-DH1 scheme from IEEE 1363 [IEEE1363]. It conveys this information
+to the client in the ServerKeyExchange message using the format defined
+above. 
+
+Actions of the recipient:
+
+The client retrieves the server's elliptic curve domain parameters and
+ephemeral ECDH public key from the ServerKeyExchange message.
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 14]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+4.3.  Certificate Request
+  
+This message is sent when requesting the following client
+authentication methods:
+
+Any of the ECC-based client authentication methods specified in 
+Section 3. 
+
+Meaning of this message:
+
+The server uses this message to indicate which client authentication
+methods the server would like to use.
+
+Structure of this message:
+
+The TLS CertificateRequest message is extended as follows.
+
+     enum {
+         ecdsa_sign (5), rsa_fixed_ecdh (6),
+         ecdsa_fixed_ecdh(7), (255)
+     } ClientCertificateType;
+
+ecdsa_sign, etc
+Indicates that the server would like to use the corresponding client
+authentication method specified in Section 3.
+
+Actions of the sender:
+
+The server decides which client authentication methods it would like to
+use, and conveys this information to the client using the format
+defined above.
+
+Actions of the receiver:
+
+The client determines whether it has an appropriate certificate for use
+with any of the requested methods, and decides whether or not to
+proceed with client authentication.
+
+
+4.4. Client Certificate
+
+This message is sent in the following client authentication methods:
+
+All the ECC-based client authentication methods specified in Section 3.
+
+Meaning of this message:
+
+This message is used to authentically convey the client's static public
+key to the server. The appropriate certificate types are given in the
+following table.
+
+Blake-Wilson, Dierks, Hawk                                     [Page 15]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+       Client Authentication   Certificate Type
+       Method
+
+       ECDSA_sign              ECC public key which can be used for
+                               signing.
+
+       ECDSA_fixed_ECDH        ECC public key which can be used for key
+                               agreement. Certificate must be signed
+                               with ECDSA.
+
+       RSA_fixed_ECDH          ECC public key which can be used for key
+                               agreement. Certificate must be signed
+                               with RSA.
+
+                       Table 4: Client certificate types
+
+[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
+X.509 certificates. Clients SHOULD use the elliptic curve domain
+parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
+[FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same
+identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key
+usage extension may be used to further delimit the use of the key. When
+a key usage extension is present, the "keyAgreement" bit MUST be set
+for ECDH certificates, and the "digitalSignature" bit MUST be set for
+ECDSA certificates. 
+
+Structure of this message:
+
+Identical to the TLS Certificate format.
+
+Actions of the sender:
+
+The client constructs an appropriate certificate chain, and conveys it
+to the server in the Certificate message.
+
+Actions of the receiver:
+
+The TLS server validates the certificate chain, extracts the client's
+public key, and checks that the key is of the correct type for the
+client authentication method.
+
+
+4.5.  Client Key Exchange
+  
+This message is sent in the following key exchange algorithms:
+
+All the ECC-based key exchange algorithms specified in Section 2. If
+client authentication with fixed ECDH is not being used, the message
+contains the client's ephemeral ECDH public key, otherwise the message
+is empty.
+
+Blake-Wilson, Dierks, Hawk                                     [Page 16]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+Meaning of the message:
+
+This message is used to convey ephemeral data relating to the key
+exchange belonging to the client (such as its ephemeral ECDH public
+key). 
+
+Structure of this message:
+
+The TLS ClientKeyExchange message is extended as follows.
+
+     enum { yes, no } EphemeralPublicKey;
+
+yes, no
+Indicates whether or not the client is providing an ephemeral ECDH
+public key.
+
+     struct {
+         select (EphemeralPublicKey) {
+             case yes: ECPoint  ecdh_Yc;
+             case no:  struct { };
+         } ecdh_public;
+     } ClientECDiffieHellmanPublic;        
+
+ecdh_Yc
+Contains the client's ephemeral ECDH public key.
+
+     struct {
+         select (KeyExchangeAlgorithm) {
+             case ec_diffie_hellman: ClientECDiffieHellmanPublic;
+         } exchange_keys;
+     } ClientKeyExchange;
+
+Actions of the sender:
+
+The client selects an ephemeral ECDH public key corresponding to the
+parameters it received from the server according to the ECKAS-DH1
+scheme from IEEE 1363 [IEEE1363]. It conveys this information to the
+client in the ClientKeyExchange message using the format defined
+above. 
+
+Actions of the recipient:
+
+The server retrieves the client's ephemeral ECDH public key from the
+ServerKeyExchange message and checks that the public key represents a
+point of the elliptic curve. 
+
+
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 17]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+4.6.  Certificate Verify
+
+This message is sent in the following client authentication methods:
+
+ECDSA_sign
+
+Meaning of the message:
+
+This message contains an ECDSA signature on the handshake messages in
+order to authenticate the client to the server.
+
+Structure of this message:
+
+The TLS CertificateVerify message is extended as follows.  
+
+     enum { ec_dsa } SignatureAlgorithm;
+
+     select (SignatureAlgorithm) {
+         case ec_dsa:
+             digitally-signed struct {
+                 opaque sha_hash[20];
+             };
+     } Signature;
+
+In the CertificateVerify message, the signature field contains the
+client's ECDSA signature on the handshake messages exchanged so far.
+According to [ANSIX962], the signature consists of a pair of integers r
+and s. These integers are both converted into byte strings of the same
+length as the curve order n using the conversion routine specified in
+Section 4.3.1 of [ANSIX962], the two byte strings are concatenated, and
+the result is placed in the signature field.
+
+Actions of the sender:
+
+The client computes its signature over the handshake messages exchanged
+so far using its ECDSA key pair with ECDSA computations performed as
+specified in [ANSIX962] with the hash function SHA-1 [FIPS186-2]. The
+client conveys its signature to the server in the CertificateVerify
+message using the format defined above.
+
+Actions of the receiver:
+
+The server extracts the client's signature from the CertificateVerify
+message, and verifies the signature using the client's ECDSA public key
+that it received in the ClientCertificate message.
+
+
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 18]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+4.7.  Computing the Master Secret
+
+In all the ECC-based key exchange algorithms specified in Section 2,
+the client and server compute the master key as follows:
+
+- They both compute a single shared secret K of length 20 bytes using
+  their ECDH key pairs with ECDH computations performed as specified by 
+  the ECKAS-DH1 scheme in [IEEE1363] with the ECSVDP-DH secret value
+  derivation primitive, and the KDF1 key derivation primitive using
+  SHA-1 [FIPS180-1].
+
+- They both use K as the pre_master_secret, and compute the
+  master_secret  from the pre_master_secret as specified in [TLS].
+
+
+5.  Cipher Suites
+
+The table below defines the cipher suites specified in this document
+for use with the key exchange algorithms specified in Section 2.
+
+  CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA                = { 0x00, 0x47 }
+  CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA             = { 0x00, 0x48 }
+  CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA             = { 0x00, 0x49 }
+  CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA        = { 0x00, 0x4A }
+  CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA         = { 0x00, 0x4B }
+  CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA         = { 0x00, 0x4C }
+  CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_40_SHA       = { 0x00, 0x4B }
+  CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA       = { 0x00, 0x4C }
+  CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA                  = { 0x00, 0x4D }
+  CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA               = { 0x00, 0x4E }
+  CipherSuite TLS_ECDH_RSA_WITH_DES_CBC_SHA               = { 0x00, 0x4F }
+  CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00, 0x50 }
+  CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x51 }
+  CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x52 }
+  CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA         = { 0x00, 0x53 }
+  CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA         = { 0x00, 0x54 }
+  CipherSuite TLS_ECDH_anon_NULL_WITH_SHA                 = { 0x00, 0x55 }
+  CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA              = { 0x00, 0x56 }
+  CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA              = { 0x00, 0x57 }
+  CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA         = { 0x00, 0x58 }
+  CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA     = { 0x00, 0x59 }
+  CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA        = { 0x00, 0x5A }
+
+                       Table 5: TLS ECC cipher suites 
+
+The key exchange method, cipher, and hash algorithm for each of these
+cipher suites are easily determined by examining the name. Ciphers
+other than AES ciphers, and hash algorithms are defined in [TLS]. AES
+ciphers are defined in [TLS-AES].
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 19]
+
+INTERNET-DRAFT                                             15 March 2001
+
+The cipher suites which use the "NULL" cipher or one of the "EXPORT"
+key exchange algorithms are considered to be "exportable" cipher suites
+for the purposes of the TLS protocol.
+
+Use of the following cipher suites is recommended in general - server
+implementations SHOULD support all of these cipher suites, and client
+implementations SHOULD support at least one of them:
+
+TLS_ECDH_ECDSA_WITH_RC4_128_SHA
+TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
+TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
+
+Implementations MAY support any of the other cipher suites.
+
+6.  Security Considerations
+
+This document is entirely concerned with security mechanisms. 
+
+This document is based on [TLS], [ANSIX9.62], and [IEEE1363] and the 
+appropriate security considerations of those documents apply.  
+
+In addition implementers should take care to ensure that code which 
+controls security mechanisms is free of errors which might be exploited
+by attackers.
+
+7. Intellectual Property Rights
+
+The IETF has been notified of intellectual property rights claimed in
+regard to the specification contained in this document. For more 
+information, consult the online list of claimed rights
+(http://www.ietf.org/ipr.html).
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain 
+to the implementation or use of the technology described in this 
+document or the extent to which any license under such rights might or 
+might not be available; neither does it represent that it has made any 
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and 
+standards-related documentation can be found in BCP-11. Copies of
+claims of rights made available for publication and any assurances of 
+licenses to be made available, or the result of an attempt made to 
+obtain a general license or permission for the use of such proprietary 
+rights by implementers or users of this specification can be obtained 
+from the IETF Secretariat.
+
+8. Acknowledgments
+
+The authors wish to thank Bill Anderson, Paul Fahn, Gilles Garon, John
+Kennedy, and Brian Minard for their help preparing this document.
+
+Blake-Wilson, Dierks, Hawk                                     [Page 20]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+9.  References
+
+[ANSIX9.62]  ANSI X9.62-1999, "Public Key Cryptography For The Financial  
+             Services Industry: The Elliptic Curve Digital Signature 
+             Algorithm (ECDSA)", American National Standards Institute,
+             1998.
+
+[FIPS180]    FIPS 180-1, "Secure Hash Standard", National Institute of 
+             Standards and Technology, 1995.
+
+[FIPS186-2]  FIPS 186-2, "Digital Signature Standard", National Institute
+             of Standards and Technology, 2000.
+
+[IEEE1363]   IEEE 1363, "Standard Specifications for Public Key
+             Cryptography", Institute of Electrical and Electronics
+             Engineers, 2000.
+
+[MUST]       S. Bradner, "Key Words for Use in RFCs to Indicate 
+             Requirement Levels", RFC 2119, March 1997.
+
+[PKIX-ALG]   L. Bassham, R. Housley and W. Polk, "Algorithms and
+             Identifiers for the Internet X.509 Public Key
+             Infrastructure Certificate and CRL Profile", PKIX Working
+             Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt,
+             March 2001.
+
+[PKIX-CERT]  W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509
+             Public Key Infrastructure Certificate and CRL Profile", PKIX
+             Working Group Internet-Draft, 
+             draft-ietf-pkix-new-part1-05.txt, March 2001.
+                
+[SEC1]       SEC 1, "Elliptic Curve Cryptography", Standards for Efficient 
+             Cryptography Group, 2000.
+
+[SEC2]       SEC 2, "Recommended Elliptic Curve Domain Parameters",
+             Standards for Efficient Cryptography Group, 2000.
+
+[TLS]        T. Dierks and C. Allen, "The TLS Protocol - Version 1.0,"
+             IETF RFC 2246, January 1999.
+
+[TLS-AES]    P. Chown, "AES Ciphersuites for TLS", TLS Working Group
+             Internet-Draft, draft-ietf-tls-ciphersuite-03.txt,
+             January 2001. 
+
+[TLS-EXT]    S. Blake-Wilson and M. Nystrom, "Wireless Extensions to TLS",
+             TLS Working Group Internet-Draft,
+             draft-ietf-tls-wireless-00.txt, November 2000.
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 21]
+
+INTERNET-DRAFT                                             15 March 2001
+
+
+10.  Authors' Addresses
+
+Authors:
+
+Simon Blake-Wilson
+Certicom Corp.
+sblake-wilson@certicom.com
+
+Tim Dierks
+Certicom Corp.
+timd@consensus.com
+
+Chris Hawk
+Certicom Corp.
+chawk@certicom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blake-Wilson, Dierks, Hawk                                     [Page 22]
+
+
diff --git a/doc/protocol/draft-ietf-tn3270e-telnet-tls-05.txt b/doc/protocol/draft-ietf-tn3270e-telnet-tls-05.txt
deleted file mode 100644
index 387cfd625f..0000000000
--- a/doc/protocol/draft-ietf-tn3270e-telnet-tls-05.txt
+++ /dev/null
@@ -1,1175 +0,0 @@
-Internet Engineering Task Force                             Michael Boe
-INTERNET-DRAFT draft-ietf-tn3270e-telnet-tls-05.txt      Jeffrey Altman
-expires April 2001
-                                                       October 24, 2000
-
-                        TLS-based Telnet Security
-
-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 the 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.
-Its 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.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1998 - 2000). All Rights Reserved.
-
-Abstract
-
-Telnet service has long been a standard Internet protocol. However, a
-standard way of ensuring privacy and integrity of Telnet sessions has
-been lacking. This document proposes a standard method for Telnet
-servers and clients to use the Transport Layer Security (TLS) protocol.
-It describes how two Telnet participants can decide whether or not to
-attempt TLS negotiation, and how the two participants should process
-authentication credentials exchanged as a part of TLS startup.
-
-Changes since -04 Draft
-
-  Incorporated changes submitted by Eric Rescorla and Russ Housley.
-  Mostly minor in nature except for an expansion of the text in 
-  section 4.1.1 on how certificate verification should be performed.
-  This section was taken almost verbatim from RFC 2818.
-
-  Minor changes include:
-
-  . change MUST to SHOULD in section 3.2
-
-  . clarification to reference to Kerberos cipher suites in 4.1.1
-
-  . expansion of discussion on mutual authentication via Telnet
-    AUTH in section 4.1.3.
-
-  . both client and server should shutdown connection upon error
-    detection in section 4.1.3
-
-  . correction to name of PKIX Working Group in section 5.1
-
-  . expansion of discussion of finished message discussion in 5.2.
-  
-  . TLS 3.1 replaced by TLS 1.0 in section 6.1
-
-  . removal of "dangerous to encrypt twice" comment from 7.0
-
-  . expansion of references.
-
-Changes since -03 Draft
-
-  Major changes to sections describing authentication of clients 
-  and servers.
-
-Changes since -02 Draft
-
-   o Clarify server actions in response to client initiating the TLS
-     negotiation.
-
-   o Replace the parochial term "mainframe" with "application-server."
-
-   o Nuke explicit references to RFC1416, since there's a new RFC in the
-     works for this and the reference isn't normative anyway.
-
-   o Use dNSName language similar to that used in the most recent HTTP TLS
-     draft.
-
-   o Delete beginning paragraph describing server-authentication in TLS.
-     Unclear and possibly wrong.
-
-   o Delete explicit references to SASL, since we don't actually describe
-     ways of using SASL.
-
-   o Add section describing interaction between AUTH and STARTTLS option
-     negotiations.
-
-Changes since -01 Draft
-   o Drop possibility of a continuing a Telnet session if the TLS
-     negotiation fails.
-
-   o Assert that server sending DO STARTTLS must be willing to negotiate
-     a TLS session
-
-   o Change SHOULD to MUST with respect to a server requesting a client
-     certificate.
-
-   o Add paragraph on commonName to section on check of X.509
-     certificate.
-
-   o Sharpen language concerning notification of possible
-     server-certificate mismatch.
-
-   o drop place-holder section on Kerberos 5 security; replace with
-     section on non-PKI-based authentication (after TLS negotiation).
-
-   o Prohibit fallback to SSL 2.0.
-
-   o Give more details about how authentication-after-TLS-negotiation
-     can be achieved.
-
-   o Simplify post-TLS Telnet negotiation state-assumptions by resetting
-     them to initial-state.
-
-Changes since -00 Draft
-   o Add local authentication/authorization operational model.
-
-   o Change behavior of Telnet machine to reset at start of TLS
-     negotiation.
-
-   o Insert narrative questioning the utility of allowing continuation of
-     Telnet session after TLS has ended.
-
-   o change examples to reflect the above changes.
-
-   o Fix several typos.
-
-Contents
-
-1    Introduction
-
-2    Command Names and Codes (assigned by IANA)
-
-3    Command Meanings
-
-     3.1  Usage of commands and interactions with other Telnet options
-
-     3.2  TLS Negotiation Failure
-
-4    Authentication and Authorization
-
-     4.1     Authentication of the Client by the Server
-
-     4.1.1   PKI-based Authentication via TLS handshake
-
-     4.1.2   Non-PKI Authentication via TLS handshake
-
-     4.1.3   Telnet AUTH option
-
-     4.1.4   Traditional Username and Password
-
-     4.2     Authentication of the Server by the Client
-
-     4.2.1   PKI-based Authentication via TLS handshake
-
-     4.2.2   Non-PKI based authentication via TLS handshake 
-
-     4.2.3   Authentication by Telnet AUTH option
-     
-5    Security
-
-     5.1     PKI-based certificate processing      .    .    .
-
-     5.2     Client and Server authentication of anonymous TLS connections
-
-     5.3     Display of security levels      .    .    .    .    .    .
-
-     5.4     Trust Relationships and Implications    .    .    .    .
-
-     5.5     Telnet negotation handling
-
-6    TLS Variants and Options
-
-     6.1     Support of previous versions of TLS      .    .    .    .
-
-     6.2     Using Kerberos V5 with TLS       .    .    .    .    .    .
-
-7    Protocol Examples
-
-     7.1     Successful TLS negotiation      .    .    .    .    .    .
-
-     7.2     Successful TLS negotiation, variation   .    .    .    .
-
-     7.3     Unsuccessful TLS negotiation    .    .    .    .    .    .
-
-     7.4     Authentication via Telnet Auth Kerberos 4 after TLS negotiation
-
-8    References 
-
-9    Authors
-
-
-1    Introduction
-
-This document describes the START_TLS Telnet option.  It allows TLS
-to be activated at the beginning of a Telnet connection to provide
-authentication and confidentiality of the Telnet session.  This document
-also defines a set of advisory security policy response codes for use
-when negotiating TLS from within Telnet.
-
-We are interested in addressing the interaction between the Telnet
-client and server that will support this secure requirement with the
-knowledge that this is only a portion of the total end-user to
-application path. Specifically, it is often true that the Telnet server
-does not reside on the target machine (it does not have access to a list
-of identities which are allowed to access to that application-server),
-and it is often true (e.g. 3270 access) that the telnet server can not
-even identify that portion of the emulation stream which contains user
-identification/password information. Additionally, it may be the case
-that the Telnet client is not co-resident with the end user and that it
-also may be unable to identify that portion of the data stream that deals
-with user identity. We make the assumption here that there is a trust
-relationship and appropriate protection to support that relationship
-between the Telnet Server and the ultimate application engine such that
-data on this path is protected and that the application will authenticate
-the end user via the emulation stream as well as use this to control
-access to information. We further make the assumption that the path
-between the end user and the client is protected.
-
-To hold up the Telnet part of the overall secure path between the user
-and the application-server, the Telnet data stream must appear
-unintelligible to a third party. This is done by creating a shared
-secret between the client and server. This shared secret is used to
-encrypt the flow of data and (just as important) require the client to
-verify that it is talking to correct server (the one that the
-application-server trusts rather than an unintended man-in-the-middle)
-with the knowledge that the emulation stream itself will be used by the
-application-server to verify the identity of the end-user. Rather than
-create a specialized new protocol which accomplishes these goals we
-instead have chosen to use an existing IETF protocol, Transport Layer
-Security (TLS) (formerly known as Secure Sockets Layer (SSL)).  
-
-The Telnet [TELNET] application protocol can certainly benefit from the
-use of TLS. Since 1992 Telnet has supported over a dozen forms of 
-end user authentication and DES encryption via the AUTH and ENCRYPT
-options.  Since 1995, TLS (as SSL) has been used to provide privacy and
-integrity protection to Telnet data streams via Telnet AUTH and via
-dedicated IANA assigned port numbers (telnets 992).  TLS offers a broad 
-range of security levels that allow sites to proceed at an "evolutionary"
-pace in deploying authentication, authorization and confidentiality
-policies, databases and distribution methods.
-
-This document describes how TLS can be used to provide the following:
-
-   o creation and refresh of a shared secret;
-
-   o negotiation and execution of data encryption and optional
-     compressesion;
-
-   o primary negotiation of authentication; and, if chosen
-
-   o execution of public-key or symmetric-key based authentication.
-
-TLS at most offers only authentication of the peers conducting the TLS
-dialog. In particular, it does not offer the possibility of the client
-providing separate credentials for authorization than were presented for
-authentication.  After the establishment of peer to peer trust based
-on TLS, other forms of end user authentication including Telnet AUTH
-may be used to provide credentials for use in determining end user
-authorization.
-
-Traditional Telnet servers have operated without such early presentation
-of authorization credentials for many reasons (most of which are
-historical). However, recent developments in Telnet server technology
-make it advantageous for the Telnet server to know the authorized
-capabilities of the remote client before choosing a communications link
-(be it `pty' or SNA LU) and link-characteristics to the host system (be
-that "upstream" link local or remote to the server). Thus, we expect to
-see the use of client authorization to become an important element of the
-Telnet evolution. Such authorization methods may require certificates
-presented by the client via TLS, or by the use of Telnet AUTH option, or
-some other as yet unstandardized method.
-
-This document describes the START_TLS telnet option which allows TLS to
-be activated at the beginning of a Telnet connection using the standard
-"telnet" port (IANA tcp\23). It also defines a set of advisory security-
-policy response codes for use when negotiating TLS over Telnet.
-
-Conventions Used in this Document
-The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and
-"MAY" in this document are to be interpreted as described in [KEYWORDS].
-
-Formal syntax is defined using ABNF [ABNF].
-
-In examples, "C:" and "S:" indicate lines sent by the the client and
-server, respectively.
-
-
-2  Command Names and Codes (assigned by IANA)
-
-   START_TLS   46 (decimal)
-
-   FOLLOWS      1 (decimal)
-
-3 Command Meanings
-
-   This document makes reference to a "server" and a "client".  For the
-   purposes of this document, the "server" is the side of the connection
-   that did the passive TCP open (TCP LISTEN state), and the "client" is
-   the side of the connection that did the active open.
-
-   IAC DONT START_TLS
-
-     The sender is either not a server or is not interested in 
-     negotiating a TLS connection.
-
-   IAC WONT START_TLS
-
-     The sender is either not a client or is not interested in
-     negotiating a TLS connection.
-
-   IAC DO START_TLS
-
-     The server side of the connection sends this command to indicate
-     a desire to negotiate a TLS connection.  This command MUST NOT 
-     be sent by the client and if received by the server MUST be refused
-     with IAC WONT START_TLS.
-
-   IAC WILL START_TLS
-
-     The client side of the connection sends this command to indicate
-     a desire to negotiate a TLS connection.  This command MUST NOT
-     be sent by the server and if received by the client MUST be refused
-     with IAC DONT START_TLS.
-
-   IAC SB START_TLS FOLLOWS IAC SE
-
-     The FOLLOWS sub-command when sent indicates that the next byte of
-     data received after this command MUST be a TLS negotiation as 
-     described in [TLS].  This sub-command is sent by both the client and
-     the server.  After this sub-command has been sent, the sender MUST NOT
-     respond to nor initiate any additional telnet commands or 
-     sub-commands.  When this sub-command has been sent and received the
-     TLS negotiation will commence.  When sent by a client this sub-
-     command will be followed by a TLS ClientHello.  When sent by a server
-     this sub-command will be followed by a TLS ServerHello.
-
-3.1  Usage of commands and interactions with other Telnet options
-
-The START_TLS option is an asymmetric option, with the server side 
-allowed to send IAC DO START_TLS and the client allowed to send
-IAC WILL START_TLS. Sub-commands are used to synchronize the link
-in preparation for negotiating TLS. This synchronization takes
-the form of a three-way handshake:
-
- 1.  As per normal Telnet option processing rules, the client MUST
-     respond to the server's IAC DO START_TLS with either IAC WONT
-     START_TLS or IAC WILL START_TLS (if it hasn't already done so). 
-     Once the client has sent IAC WILL START_TLS and received
-     IAC DO START_TLS, it MUST immediately send a FOLLOWS sub-command
-     (IAC SB START_TLS FOLLOWS IAC SE) to indicate it is ready to begin
-     a TLS negotiation.  Once the FOLLOWS sub-command has been sent, the
-     client MUST ignore all telnet negotiations except for the FOLLOWS
-     sub-command.  When the FOLLOWS sub-command has been received the
-     client MUST halt use of the telnet protocol, reset the telnet state
-     machine and begin a TLS negotiation by sending a ClientHello message.
-
- 2.  If the client initiates by sending IAC WILL START_TLS, the server
-     MUST respond with either IAC DO START_TLS or IAC DONT START_TLS.
-
- 3.  The server SHOULD NOT send additional Telnet data or commands after
-     sending IAC DO START_TLS except in response to client Telnet options
-     received until after it receives either a negative response from the
-     client (IAC WONT START_TLS) or a successful negotiation of TLS has 
-     occurred.  If the client's START_TLS option response is negative, the
-     server is free to send additional Telnet data or commands. If the
-     client's response is affirmative (IAC WILL START_TLS), then the server
-     MUST send the FOLLOWS sub-command (IAC SB START_TLS FOLLOWS IAC SE)
-     and await the FOLLOWS sub-command from the client.  When the FOLLOWS
-     sub-command has been sent and received the server MUST halt use of the
-     telnet protocol, reset the telnet state machine, and begin a TLS
-     negotiation by sending a TLS ServerHello message.
-
- 4.  If both START_TLS and AUTH [AUTH] are offered, START_TLS SHOULD be sent
-     first and MUST take precedence if both are agreed to. AUTH MAY be
-     renegotiated after successful establishment of the TLS session if
-     end-user authentication via a supported method is desired.
-
- 5.  If a TLS session has been established, the ENCRYPT [ENCRYPT] option
-     MUST NOT be negotiated in either direction.
-
- 6.  When the FOLLOWS sub-command has been sent and received the Telnet
-     state machine is reset.  This means that the state of all telnet 
-     options is reset to the WONT/DONT state and any data received via
-     subcommands is forgotten.  After a sucessful TLS negotiation the 
-     Telnet negotiations will be restarted as if a new connection had
-     just been established with one exception.  Since TLS is already in
-     use, the START_TLS option MUST NOT be negotiated.
-
-3.2   TLS Negotiation Failure
-
-The behavior regarding TLS negotiation failure is covered in [TLS], and
-does not indicate that the TCP connection be broken; the semantics are
-that TLS is finished and all state variables cleaned up. The TCP connection
-may be retained.
-
-However, it's not clear that either side can detect when the last of the
-TLS data has arrived. So if TLS negotiation fails, the TCP connection
-SHOULD be reset and the client MAY reconnect. To avoid infinite loops of
-TLS negotiation failures, the client MUST remember to not negotiate
-START_TLS if reconnecting due to a TLS negotiation failure.
-
-
-4    Telnet Authentication and Authorization
-
-Telnet servers and clients can be implemented in a variety of ways that
-impact how clients and servers authenticate and authorize each other.
-However, most (if not all) the implementations can be abstracted via the
-following four communicating processes:
-
-SES  Server End System. This is an application or machine to which client
-     desires a connection. Though not illustrated here, a single Telnet
-     connection between client and server could have multiple SES
-     terminations.
-
-Server  The Telnet server.
-
-Client  The Telnet client, which may or may not be co-located with the
-     CES. The Telnet client in fact be a gateway or proxy for downstream
-     clients; it's immaterial.
-
-CES  Client End System. The system communicating with the Telnet Client.
-     There may be more than one actual CES communicating to a single
-     Telnet Client instance; this is also immaterial to how Client and
-     Server can sucessfully exchange authentication and authorization
-     details. However, see Section 5.4 for a discussion on trust
-     implications.
-
-What is of interest here is how the Client and Server can exchange
-authentication and authorization details such that these components can
-direct Telnet session traffic to authorized End Systems in a reliable,
-trustworthy fashion.
-
-What is beyond the scope of this specification are several related
-topics, including:
-
-   o How the Server and SES are connected, and how they exchange data or
-     information regarding authorization or authentication (if any).
-
-   o How the Client and CES are connected, and how they exchange data or
-     information regarding authorization or authentication (if any).
-
-System-to-system communications using the Telnet protocol have
-traditionally used no authentication techniques at the Telnet level.
-More recent techniques have used Telnet to transport authentication
-exchanges (RFC 2941). In none of these systems, however, is a remote system
-allowed to assume more than one identity once the Telnet preamble
-negotiation is over and the remote is connected to the application-
-endpoint. The reason for this is that the local party must in some way
-inform the end-system of the remote party's identity (and perhaps
-authorization). This process must take place before the remote party
-starts communicating with the end-system. At that point it's too late
-to change what access a client may have to an server end-system: that
-end-system has been selected, resources have been allocated and
-capability restrictions set. 
-
-This process of authentication, authorization and resource allocation
-can be modeled by the following simple set of states and transitions:
-
-`unauthenticated'    The local party has not received any credentials
-     offered by the remote. A new Telnet connection starts in this state.
-
-     The `authenticating' state will be entered from this state if the
-     local party initiates the authentication process of the peer. The
-     Telnet START_TLS negotiation is considered an initiation of the
-     authentication process.
-
-     The `authorizing' state will be entered from this state either if
-     the local party decides to begin authorization and resource
-     allocation procedures unilaterally...or if the local party has
-     received data from the remote party destined for local end-system.
-
-`authenticating'    The local party has received at least some of the
-     credentials needed to authenticate its peer, but has not finished
-     the process.
-
-     The `authenticated' state will be entered from this state if the
-     local party is satisfied with the credentials proferred by the
-     client.
-
-     The `unauthenticated' state will be entered from this state if the
-     local party cannot verify the credentials proffered by the client or
-     if the client has not proffered any credentials. Alternately, the
-     local party may terminate the Telnet connection instead of returning
-     it to the `unauthenticated' state.
-
-`authenticated'   The local party has authenticated its peer, but has not
-     yet authorized the client to connect to any end-system resources.
-
-     The `authenticating' state will be entered from this state if the
-     local party decides that further authentication of the client is
-     warranted.
-
-     The `authorizing' state will be entered from this state if the local
-     party either initiates authorization dialog with the client (or
-     engages in some process to authorize and allocate resources on
-     behalf of the client), or has received data from the remote party
-     destined for a local end-system.
-
-`authorizing'   The local party is in the process of authorizing its peer
-     to use end-system resources, or may be in the process of allocating
-     or reserving those resources.
-
-     The `transfer-ready' state will be entered when the local party is
-     ready to allow data to be passed between the local end-system and
-     remote peer.
-
-     The `authenticated' state will be entered if the local party
-     determines that the current authorization does not allow any access
-     to a local end-system. If the remote peer is not currently
-     authenticated, then the `unauthenticated' state will be entered
-     instead.
-
-`transfer-ready'    The party may pass data between the local end-system to
-     its peer.
-
-     The `authorizing' state will be entered if the local party (perhaps
-     due to a request by the remote peer) deallocates the communications
-     resources to the local-end system. Alternately, the local party may
-     enter the `authenticated' or the `unauthenticated' state.
-
-In addition to the "orderly" state transitions noted above, some
-extraordinary transitions may also occur:
-
- 1.  The absence of a guarantee on the integrity of the data stream
-     between the two Telnet parties also removes the guarantee that the
-     remote peer is who the authentication credentials say the peer is.
-     Thus, upon being notified that the Telnet session is no longer using
-     an integrity layer, the local party must at least deallocate all
-     resources associated with a Telnet connection which would not have
-     been allocable had the remote party never authenticated itself.
-
-     In practice, this deallocation-of-resources restriction is hard to
-     interpret consistently by both Telnet endpoints. Therefore, both
-     parties MUST return to the initial Telnet state after negotiation of
-     TLS. That is, it is as if the Telnet session had just started.
-
-     This means that the states may transition from whatever the current
-     state is to `unauthenticated'. Alternately, the local party may
-     break the Telnet connection instead.
-
- 2.  If the local party is notified at any point during the Telnet
-     connection that the remote party's authorizations have been reduced
-     or revoked, then the local party must treat the remote party as being
-     unauthenticated. The local party must deallocate all resources
-     associated with a Telnet connection which would not have been
-     allocable had the remote party never authenticated itself.
-
-     This too may mean that the states may transition from whatever the
-     current state is to `unauthenticated'. Alternately, the local party
-     may break the Telnet connection instead.
-
-The above model explains how each party should handle the authentication
-and authorization information exchanged during the lifetime of a Telnet
-connection. It is deliberately fuzzy as to what constitutes internal
-processes (such as "authorizing") and what is meant by "resources" or
-"end-system" (such as whether an end-system is strictly a single entity
-and communications path to the local party, or multiples of each, etc).
-
-Here's a state transition diagram, as per [RFC2360]:
-
-             0       1          2        3            4
-Events     | unauth   auth'ing  auth'ed   authorizing   trans-ready
------------+--------------------------------------------------------
-auth-needed| sap/1    sap/1     sap/1     sap/1        der,sap/1
-auth-accept| -       ain/2     -        -            -
-auth-bad   | -       0         wa/0     wa,der/0     der,sap/1
-authz-start| szp/3    -         szp/3     -            -
-data-rcvd  | szp/3    qd/1      szp/3     qd/3         pd/4
-authz-ok   | -       -         -        4            -
-authz-bad  | -       -         -        der/2        wa,der,szp/3
-
-Action | Description
--------+--------------------------------------------
-sap    | start authentication process
-der    | deallocate end-system resources
-ain    | authorize if needed
-szp    | start authorization process
-qd     | queue incoming data
-pd     | process data
-wa     | wipe authorization info
-
-Event       |    Description
--------------+---------------------------------------------------
-auth-needed  | authentication deemed needed by local party
-auth-accept  | remote party's authentication creds accepted
-auth-bad     | remote party's authentication creds rejected or expired
-authz-start  | local or remote party starts authorization proceedings
-data-rcvd    | data destined for end-system received from remote party
-authz-ok     | authorization and resource allocation succeeded
-authz-bad    | authorization or resource allocation failed or expired
-
-4.1    Authentication of the Server by the Client
-
-A secure connection requires that the client be able to authenticate the
-identity of the server.  How the authentication is performed depends 
-upon the TLS cipher agreed upon during the negotiation.  As of this
-writing there are three categories of cipher suites supported by TLS:
-ciphers supporting X.509 certificates (PKI), non-PKI ciphers, and 
-anonymous ciphers.  The following sections detail how Server authentication
-should be performed by the client for each cipher category.
-
-4.1.1  PKI-based Authentication via TLS handshake
-
-When a PKI based cipher is negotiated during the TLS negotiation, the
-server will deliver an X.509 certificate to the client.  Before the 
-certificate MAY be used to determine the identity of the server, the
-certifiicate MUST be validated as per RFC 2459.
-
-Once validated the identity of the server is confirmed by matching the DNS 
-name used to access the host with the name stored in the certificate.  If the 
-certificate includes the `subjectAltName' extension and it contains a 
-`dNSName' object, then the client MUST use this name as the identity of the 
-server.  Otherwise, the (most specific) commonName field in the Subject field 
-if the certificate MUST be used. Note that although the commonName field 
-technique is currently in wide use, it is deprecated and Certification 
-Authorities are encourage to use the dnsName instead.
-
-Matching is performed using the matching rules specified by [RFC 2459].  If 
-more than one identity of a given type is present in the certificate (e.g., 
-more than one dnsName name, a match in any one of the set is considered 
-acceptable.)  Names may contain the wildcard character '*' which is considered 
-to match any single domain name component or component fragment. E.g., 
-"*.a.com" matches "foo.a.com" but not "bar.foo.a.com.  "f*.com" matches 
-"foo.com" but not "bar.com".
-
-In some cases, an IP address is used to access the host instead of a DNS name. 
- In these cases, a 'subjectAltName' object of type 'iPAddress' MUST be present 
-in the certificate and MUST exactly match the IP address provided by the end 
-user.
-
-If the hostname does not match the identity in the certificate, user oriented 
-clients MUST either notify the user (clients MAY give the user the opportunity 
-to continue with the connection in any case) or terminate the connection with 
-a bad certificate error.  Automated clients MUST log the error to an 
-appropriate audit log (if available) and SHOULD terminate the connection (with 
-a bad certificate error.)  Automated clients MAY provide a configuration 
-setting that disables this check, but MUST provide a setting which enables it.
-
-4.1.2  Non-PKI based authentication via TLS handshake
-
-As of this writing TLS only supports one class of non-PKI cipher suites 
-which are based on Kerberos 5.  Regardless, any non-PKI cipher suite
-incorporated into TLS will provide for mutual authentication.  Authentication
-of the server is therefore implied by a successful TLS credential exchange.
-
-4.1.3  Authentication by Telnet AUTH option (RFC 2941)
-
-If the TLS exchange used an anonymous cipher such as Anonymous-Diffie-
-Hellman (ADH) or if the X.509 certificate could not be validated, then
-the session MUST be protected from a man in the middle attack.  This can
-be accomplished by using a Telnet AUTH [AUTH] method that provides for
-mutual authentication(*) of the client and server; and which allows the
-TLS Finished messages sent by the client and the server to be verified.
-A failure to successfully perform a mutual authentication with Finished
-message verification via Telnet AUTH MUST result in termination of the
-connection by both the client and the server.
-
-(*) The Telnet AUTH option supports both unilateral and mutual authentication
-methods.  The distinction being that mutual authentication methods confirm
-the identity of both parties at the end of the negotiation.  A unilateral
-authentication method cannot be used to verify the contents of the TLS client
-and server finished messages.  It is worth noting that TLS usually 
-authenticates the server to the client; whereas, Telnet AUTH usually 
-authenticates the client to the server when unilateral methods are used.
-
-4.2    Authentication of the Client by the Server
-
-After TLS has been successfully negotiated the server may not have the
-client's identity (verified or not) since the client is not required to
-provide credentials during the TLS exchange.  Even when the client does
-provide credentials during the TLS exchange, the server may have a policy
-that prevents their use.  Therefore, the server may not have enough
-confidence in the client to move the connection to the authenticated state.
-
-If further client, server or client-server authentication is going to
-occur after TLS has been negotiated, it MUST occur before any
-non-authentication-related Telnet interactions take place on the link
-after TLS starts. When the first non-authentication-related Telnet
-interaction is received by either participant, then the receiving
-participant MAY drop the connection due to dissatisfaction with the
-level of authentication.
-
-If the server wishes to request a client certificate after TLS is
-initially started (presumably with no client certificate requested), it
-may do so. However, the server MUST make such a request immediately
-after the initial TLS handshake is complete.
-
-No TLS negotiation outcome, however trustworthy, will by itself provide
-the server with the authorization identity if that is different from the
-authentication identity of the client.
-
-The following subsections detail how the client can provide the server
-with authentication and authorization credentials.
-
-4.2.1   PKI-based Authentication via TLS handshake
-
-PKI-based authentication is used by the client transmitting an X.509
-certificate to the host during the TLS handshake.  There is no standard
-mechanism defined for how a client certificate should be mapped to a
-authorization identity (userid).  There are several methods currently
-in wide practice.  A telnet server compliant with this document may
-implement zero, one or more than one of them.
-
-The first method is to use information stored within the certificate
-to determine the authorization identity.  If the certificate contains
-an Common Name object then portions of it can be used as the
-authorization identity.  If the Common Name contains an UID member, 
-then it can be used directly.  If the Common Name contains an Email
-member, then it can be used if the specified domain matches the domain
-of the telnet server.
-
-The second method is to use the entire Subject Name as a entry to 
-lookup in a directory.  The directory provides a mapping between the 
-subject name and the authorization identity.
-
-The third method is to use the entire certificate as a entry to lookup
-in a directory with the directory providing a mapping between the 
-certificate and the authorization identity.
-
-The first method is only practical if the certificates are being 
-issued by certificate authority managed by the same organization as
-the server performing the authorization.
-
-The second and third methods can be used with certificates issued
-by public certificate authorities provided the certificates are 
-delivered to the organization performing the authorization in advance
-via an authenticated method.  The second and third methods have the
-added benefit that the certificates, if issued by the authorizing
-organization, do not require that any personal information about the
-subject be included in the certificate.  The Subject line could be
-filled only with gibberish to establish its uniqueness in the
-directory.
-
-4.2.2   Non-PKI Authentication via TLS handshake
-
-TLS supports non-PKI authentication methods which can be used for
-securely establishing authentication identities.  As of this writing,
-TLS supports only one non-PKI authentication method, Kerberos 5.
-However, it is not unlikely that other authentication methods might be
-incorporated into TLS ciphers in the future.
-
-4.2.3   Telnet AUTH option
-
-The Telnet AUTH option implements a variety of authentication methods
-which can be used to establish authentication and authorization 
-identities.  Some methods (e.g., KERBEROS_IV and KERBEROS_V) allow
-separate authentication and authorization identities to be provided.
-Details on the use of the Telnet AUTH option and its authentication
-methods can be found in RFC1416 (about to be obsoleted) and its related
-documents.  For a current list of Telnet AUTH methods see IANA.
-
-4.2.4   Traditional Username and Password
-
-When all else fails the authorization identity may be provided over
-the secure TLS connection in the form of a username and password.
-
-The Username MAY be transmitted to the host via the Telnet New 
-Environment option's USER variable.
-
-
-5    Security
-
-Security is discussed throughout this document. Most of this document
-concerns itself with wire protocols and security frameworks. But in this
-section, client and server implementation security issues are in focus.
-
-5.1   PKI-based certificate processing
-
-A complete discussion of the proper methods for verifying X.509 certificates
-and their associated certificate chains is beyond the scope of this 
-document.  The reader is advised to refer to the RFCs issued by the PKIX
-Working Group.  However, the verification of a certificate MUST include,
-but isn't limited to, the verification of the signature certificate
-chain to the point where the a signature in that chain uses a known good
-signing certificate in the local key chain. The verification
-SHOULD then continue with a check to see if the fully qualified host name
-which the client connected to appears anywhere in the server's
-certificate subject (DN). 
-
-If the certificate cannot be verified then either:
-
-   o the end user MUST see a display of the server's certificate and be
-     asked if he/she is willing to proceed with the session; or,
-
-   o the end user MUST NOT see a display of server's certificate, but the
-     certificate details are logged on whatever media is used to log
-     other session details. This option may be preferred to the first
-     option in environments where the end-user cannot be expected to make
-     an informed decision about whether a mismatch is harmful. The
-     connection MUST be closed automatically by the client UNLESS the
-     client has been configured to explicitly allow all mismatches.
-
-   o the connection MUST be closed on the user's behalf, and an error
-     describing the mismatch logged to stable storage.
-
-If the client side of the service is not interactive with a human
-end-user, the Telnet connection SHOULD be dropped if this host check
-fails.
-
-5.2   Client and Server authentication of anonymous-TLS connections
-
-When authentication is performed after the establishment of a TLS session
-which uses an anonymous cipher, it is imperative that the authentication
-method protect against a man in the middle attack by verifying the
-contents of the client's and server's TLS finished messages.  Without
-the verification of both the client and server's TLS finished messages
-it is impossible to confirm that there is not a man in the middle 
-listening and perhaps changing all the data transmitted on the 
-connection.  
-
-Verification of the TLS finished messages can be performed as part 
-of a Telnet AUTH option mutual authentication exchange (when using the
-ENCRYPT_START_TLS flag.) This can be done at the same time the 
-verification of the authentication-type-pair is performed.
-
-5.3    Display of security levels
-
-The Telnet client and server MAY, during the TLS protocol negotiation
-phase, choose to use a weak cipher suite due to policy, law or even
-convenience. It is, however, important that the choice of weak cipher
-suite be noted as being commonly known to be vulnerable to attack. In
-particular, both server and client software should note the choice of
-weak cipher-suites in the following ways:
-
-   o If the Telnet endpoint is communicating with a human end-user, the
-     user-interface SHOULD display the choice of weak cipher-suite and
-     the fact that such a cipher-suite may compromise security.
-
-   o The Telnet endpoints SHOULD log the exact choice of cipher-suite as
-     part of whatever logging/accounting mechanism normally used.
-
-5.4    Trust Relationships and Implications
-
-Authentication and authorization of the remote Telnet party is useful,
-but can present dangers to the authorizing party even if the connection
-between the client and server is protected by TLS using strong
-encryption and mutual authentication. This is because there are some
-trust-relationships assumed by one or both parties:
-
-   o Each side assumes that the authentication and authentication details
-     proferred by the remote party stay constant until explicitly changed
-     (or until the TLS session is ended).
-
-   o More stringently, each side trusts the other to send a timely
-     notification if authentication or authorization details of the other
-     party's end system(s) have changed.
-
-Either of these assumptions about trust may be false if an intruder has
-breached communications between a client or server and its respective
-end system. And either may be false if a component is badly implemented
-or configured. Implementers should take care in program construction to
-avoid invalidating these trust relationships, and should document to
-configuring-users the proper ways to configure the software to avoid
-invalidation of these relationships.
-
-5.5  Telnet negotation handling
-
-There are two aspects to Telnet negotiation handling that affect the
-security of the connection.  First, given the asynchronous nature
-of Telnet option negotiations it is possible for a telnet client or
-server to allow private data to be transmitted over a non-secure 
-link.  It is especially important that implementors of this telnet
-option ensure that no telnet option subnegotiations other than those
-related to authentication and establishment of security take place over
-an insecure connection.
-
-The second item is related to the most common error when implementing
-a telnet protocol state machine.  Most telnet implementations do not
-check to ensure that the peer responds to all outstanding requests
-to change states: WILL, DO, WONT, DONT.  It is important that all 
-telnet implementations ensure that requests for state changes are
-responded to.
-
-
-6    TLS Variants and Options
-
-TLS has different versions and different cipher suites that can be
-supported by client or server implementations. The following
-subsections detail what TLS extensions and options are mandatory. The
-subsections also address how TLS variations can be accommodated.
-
-6.1    Support of previous versions of TLS
-
-TLS has its roots in SSL 2.0 and SSL 3.0. Server and client
-implementations may wish to support for SSL 3.0 as a fallback in case TLS
-1.0 or higher is not supported. This is permissible; however, client
-implementations which negotiate SSL3.0 MUST still follow the rules in
-Section 5.3 concerning disclosure to the end-user of transport-level
-security characteristics.
-
-Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; it
-is detailed in [TLS].  SSL 2.0 MUST NOT be negotiated.
-
-6.2    Using Kerberos V5 with TLS
-
-If the client and server are both amenable to using Kerberos V5, then
-using non-PKI authentication techniques within the confines of TLS may
-be acceptable (see [TLSKERB]). Note that clients and servers are under
-no obligation to support anything but the cipher-suite(s) mandated in
-[TLS]. However, if implementations do implement the KRB5 authentication
-as a part of TLS ciphersuite, then these implementations SHOULD support
-at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite.
-
-7    Protocol Examples
-
-The following sections provide skeletal examples of how Telnet clients
-and servers can negotiate TLS.
-
-7.1    Successful TLS negotiation
-
-The following protocol exchange is the typical sequence that starts TLS:
-
-// typical successful opening exchange
-  S: IAC DO START_TLS
-  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
-  S: IAC SB START_TLS FOLLOWS IAC SE
-// server now readies input stream for non-Telnet, TLS-level negotiation
-  C: [starts TLS-level negotiations with a ClientHello]
-  [TLS transport-level negotiation ensues]
-  [TLS transport-level negotiation completes with a Finished exchanged]
-// either side now able to send further Telnet data or commands
-
-7.2    Successful TLS negotiation, variation
-
-The following protocol exchange is the typical sequence that starts TLS,
-but with the twist that the (TN3270E) server is willing but not
-aggressive about doing TLS; the client strongly desires doing TLS.
-
-// typical successful opening exchange
-  S: IAC DO TN3270E
-  C: IAC WILL START_TLS IAC
-  S: IAC DO START_TLS
-  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
-  S: IAC SB START_TLS FOLLOWS IAC SE
-// server now readies input stream for non-Telnet, TLS-level negotiation
-  C: [starts TLS-level negotiations with a ClientHello]
-  [TLS transport-level negotiation ensues]
-  [TLS transport-level negotiation completes with a Finished
-                 exchanged]
-// note that server retries negotiation of TN3270E after TLS
-// is done.
-  S: IAC DO TN3270E
-  C: IAC WILL TN3270E
-// TN3270E dialog continues....
-
-7.3    Unsuccessful TLS negotiation
-
-This example assumes that the server does not wish to allow the Telnet
-session to proceed without TLS security; however, the client's version
-of TLS does not interoperate with the server's.
-
-//typical unsuccessful opening exchange
-  S: IAC DO START_TLS
-  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
-  S: IAC SB START_TLS FOLLOWS IAC SE
-// server now readies input stream for non-Telnet, TLS-level negotiation
-  C: [starts TLS-level negotiations with a ClientHello]
-  [TLS transport-level negotiation ensues]
-  [TLS transport-level negotiation fails with server sending
-               ErrorAlert message]
-  S: [TCP level disconnect]
-//  server (or both) initiate TCP session disconnection
-
-This example assumes that the server wants to do TLS, but is willing to
-allow the session to proceed without TLS security; however, the client's
-version of TLS does not interoperate with the server's.
-
-//typical unsuccessful opening exchange
-  S: IAC DO START_TLS
-  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
-  S: IAC SB START_TLS FOLLOWS IAC SE
-// server now readies input stream for non-Telnet, TLS-level negotiation
-  C: [starts TLS-level negotiations with a ClientHello]
-  [TLS transport-level negotiation ensues]
-  [TLS transport-level negotiation fails with server sending
-               ErrorAlert message]
-  S: [TCP level disconnect]
-// session is dropped
-
-7.4    Authentication via Kerberos 4 after TLS negotiation
-
-Here's an implementation example of using Kerberos 4 to authenticate the
-client after encrypting the session with TLS. Note the following
-details:
-
-   o The client strictly enforces a security policy of proposing Telnet
-     AUTH first, but accepting TLS. This has the effect of producing a
-     rather verbose pre-TLS negotiation sequence; however, the
-     end-result is correct. A more efficient pre-TLS sequence can be
-     obtained by changing the client security policy to be the same as the
-     server's for this connection (and implementing policy-aware
-     negotiation code in the Telnet part of the client).
-
-     A similar efficient result can be obtained even in the absence of a
-     clear client security policy if the client has cached server
-     security preferences from a previous Telnet session to the same
-     server.
-
-   o The server strictly enforces a security policy of proposing TLS
-     first, but falling back to Telnet AUTH.
-
-  C: IAC WILL AUTHENTICATION
-  C: IAC WILL NAWS
-  C: IAC WILL TERMINAL-TYPE
-  C: IAC WILL NEW-ENVIRONMENT
-  S: IAC DO START_TLS
-  C: IAC WILL START_TLS
-  C: IAC SB START_TLS FOLLOWS IAC SE
-  S: IAC DO AUTHENTICATION
-  S: IAC DO NAWS
-  S: IAC WILL SUPPRESS-GO-AHEAD
-  S: IAC DO SUPPRESS-GO-AHEAD
-  S: IAC WILL ECHO
-  S: IAC DO TERMINAL-TYPE
-  S: IAC DO NEW-ENVIRONMENT
-  S: IAC SB AUTHENTICATION SEND
-    KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ
-    KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL
-    KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY
-    SSL CLIENT_TO_SERVER|ONE_WAY   IAC SE
-  S: IAC SB TERMINAL-TYPE SEND  IAC SE
-  S: IAC SB NEW-ENVIRONMENT SEND  IAC SE
-  S: IAC SB START_TLS FOLLOWS  IAC SE
-  [TLS - handshake starting]
-  [TLS - OK]
-  C: IAC WILL AUTHENTICATION
-  C: IAC WILL NAWS
-  C: IAC WILL TERMINAL-TYPE
-  C: IAC WILL NEW-ENVIRONMENT
-  <wait for outstanding negotiations>
-  S: IAC DO AUTHENTICATION
-  S: IAC DO NAWS
-  S: IAC WILL SUPPRESS-GO-AHEAD
-  C: IAC DO SUPPRESS-GO-AHEAD
-  S: IAC DO SUPPRESS-GO-AHEAD
-  C: IAC WILL SUPPRESS-GO-AHEAD
-  S: IAC WILL ECHO
-  C: IAC DO ECHO
-  S: IAC DO TERMINAL-TYPE
-  S: IAC DO NEW-ENVIRONMENT
-  S: IAC SB AUTHENTICATION SEND
-    KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL
-    KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY   IAC SE
-  C: IAC SB AUTHENTICATION NAME jaltman IAC SE
-  C: IAC SB AUTHENTICATION IS
-    KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL AUTH
-    04 07 0B "CC.COLUMBIA.EDU" 00 "8(" 0D 9E 9F AB A0 "L" 15 8F A6
-    ED "x" 19 F8 0C "wa" CA "z`" 1A E2 B8 "Y" B0 8E "KkK" C6 AA "<" FF
-    FF 98 89 "|" 90 AC DF 13 "2" FC 8E 97 F7 BD AE "e" 07 82 "n" 19 "v"
-    7F 10 C1 12 B0 C6 "|" FA BB "s1Y" FF FF 10 B5 14 B3 "(" BC 86 "`"
-    D2 "z" AB "Qp" C4 "7" AB "]8" 8A 83 B7 "j" E6 "IK" DE "|YIVN"
-    IAC SE
-  S: IAC SB TERMINAL-TYPE SEND  IAC SE
-  S: IAC SB NEW-ENVIRONMENT SEND  IAC SE
-  S: IAC SB AUTHENTICATION REPLY
-   KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL ACCEPT  IAC SE
-  C: IAC SB AUTHENTICATION IS
-   KERBEROS_V4 CLIENT|MUTUAL CHALLENGE "[" BE B7 96 "j" 92 09 "~" IAC SE
-  S: IAC SB AUTHENTICATION REPLY
-   KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL RESPONSE "df" B0 D6 "vR_/"  IAC SE
-  C: IAC SB TERMINAL-TYPE IS VT320 IAC SE
-  C: IAC SB NEW-ENVIRONMENT IS VAR USER VALUE jaltman VAR SYSTEMTYPE \\
-           VALUE WIN32 IAC SE
-  C: IAC SB NAWS 162 49 IAC SE
-
-Here are several things to note about the above example:
-
-   o After TLS is successfully negotiated, all non-TLS Telnet settings
-     are forgotten and must be renegotiated.
-
-   o After TLS is successfully negotiated, the server offers all
-     authentication types that are appropriate for a session using TLS.
-     Note that the server, post TLS-negotiation, isn't offering Telnet
-     ENCRYPT or AUTH SSL, since (a) it's useless to encrypt twice, and 
-     (b) TLS and/or SSL can be applied only once to a Telnet session.
-
-8  References
-
-[ANBF]       D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
-             Specifications: ABNF", RFC2235, November 1997.
-
-[AUTH]       T.Ts'o, Ed,. J. Altman, "Telnet Authentication Option",
-             RFC2941, September 2000.
-
-[ENCRYPT]    T.Ts'o, "Telnet Encryption Option", RFC2946, September 2000.
-
-[KEYWORDS]   Bradner, S. "Key words for use in RFCs to Indicate
-             Requirement Levels", RFC2119, March 1997.
-
-[RFC927]     Brian A. Anderson. "TACACS User Identification Telnet
-             Option", RFC927, December 1984
-
-[RFC2360]    G. Scott, Editor. "Guide for Internet Standard Writers",
-             RFC2360, June 1998.
-
-[RFC2459]    Housley, R., Ford, W., Polk, W. and D.Solo, "Internet 
-             Public Key Infrastructure: Part I: X.509 Certificate and
-             CRL Profile", RFC2459, January 1999.
-
-[TELNET]     J. Postel, J. Reynolds. "Telnet Protocol Specifications",
-             RFC854, May 1983.
-
-[TLS]        Tim Dierks, C. Allen. "The TLS Protocol", RFC2246, January
-             1999.
-
-[TLSKERB]    Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher
-             Suites to Transport Layer Security (TLS)", RFC2712, October
-             1999.
-
-9   Authors
-
-  Michael Boe                                  Jeffrey Altman
-  Cisco Systems Inc.                           Columbia University
-  170 West Tasman Drive                        612 West 115th Street
-  San Jose CA 95134 USA                        New York NY 10025 USA
-
-  Email: mboe@cisco.com                        jaltman@columbia.edu
-
-10  Mailing list
-
-  General Discussion:tn3270e@list.nih.gov
-  To Subscribe: listserv@list.nih.gov
-  In Body: sub tn3270e <first_name>
-  Archive: listserv@list.nih.gov 
-
-  Associated list: telnet-wg@bsdi.com
-
-Full Copyright Statement
-
-Copyright (c) The Internet Society (1998, 2000). 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 develop- ing 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.
-
-
-                  Jeffrey Altman * Sr.Software Designer
-                 The Kermit Project * Columbia University
-               612 West 115th St * New York, NY * 10025 * USA
-     http://www.kermit-project.org/ * kermit-support@kermit-project.org
-
-