diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-ecc-01.txt | 1235 | ||||
| -rw-r--r-- | doc/protocol/draft-ietf-tn3270e-telnet-tls-05.txt | 1175 |
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 - - |