Internet Engineering Task Force Jeffrey Altman INTERNET-DRAFT draft-altman-telnet-starttls-02.txt Expires: 16 July 2007 December 15, 2006 Telnet START-TLS Option Status of this memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on 15 December 2007. Copyright Notice Copyright (C) The IETF Trust (2006). 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. 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 Server Authentication via TLS handshake 4.1.2 Non-PKI Server Authentication via TLS handshake 4.1.3 Telnet AUTH option 4.1.4 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 Considerations 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 . . . . . . 6.3 TLS Channel Bindings for use with TELNET AUTH mechanisms 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 5 after TLS negotiation 8 IANA Considerations 9 Normative References 10 Authors 11 Credits 1 Introduction This document describes the Telnet START_TLS option. It allows TLS to be activated at the beginning of a Telnet connection, using the IANA assigned "telnet" port (IANA tcp\23), which can be used to provide authentication and confidentiality. This document also defines a set of advisory security policy response codes for use when negotiating TLS from within an existing Telnet session. This specification addresses the interaction between the Telnet client and server that requires private communications while acknowledging it may only protect 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. This document assumes 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 channel to control access to information. It is further assumed that the path between the end user and the client is protected. In order for the Telnet portion of the overall path between the user and the application-server to be considered secure, the Telnet data stream must be authenticated and provide confidentiality and integrity protection. This is accomplished by establishing 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 new proprietary protocol which accomplishes these goals this document defines the use of an existing IETF protocol, Transport Layer Security (TLS). 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 encryption via the AUTH and ENCRYPT options. Since 1995, predecessors to TLS have been used to provide privacy and integrity protection to Telnet data streams via the undocumented Telnet AUTH SSL option and via the dedicated IANA assigned port assignment ("telnets" tcp\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 support the client providing different credentials for authorization than were presented for authentication. After the establishment of peer-to-peer trust using 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-to-be-standardized method. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [KEYWORDS]. Formal syntax is defined using Augmented BNF for Syntax Specifications [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. If this command is received by the server, it 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. If this command is received by the client, it MUST be refused with IAC DONT START_TLS. IAC SB START_TLS FOLLOWS IAC SE The FOLLOWS sub-command is sent to indicate 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 mutually negotiated. 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 (if allowed by policy.) 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 with respect to Client and Server sucessfully exchanging 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 [AUTH]. 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 party 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 party. 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 authenticate the identity of the server. How the authentication is performed depends upon the TLS ciphersuite agreed upon during the negotiation. As of this writing there are three categories of ciphersuites supported by TLS: ciphersuites supporting X.509 certificates (PKI), non-PKI ciphersuites, and anonymous ciphersuites. The following sections detail how Server authentication should be performed by the client for each ciphersuite category. 4.1.1 PKI-based Server Authentication via TLS handshake When a PKI based ciphersuite 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 certificate MUST be validated as per [RFC3280]. 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. Another possibility is that the Subject Name field can consist of Domain Component assertions. For example, "dc=com, dc=example, dc=hostname". Matching is performed using the matching rules specified by [RFC3280]. 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 Server Authentication via TLS handshake Non-PKI ciphersuites such as Kerberos v5 [TLSKERB] and Pre-Shared Keys [TLSPSK] provide for server authentication. Refer to the appropriate RFC for details. 4.1.3 Server Authentication by Telnet AUTH option [AUTH] If the TLS exchange used an anonymous ciphersuite 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 Channel Binding data [TLS-CB] to be verified. A failure to successfully perform a mutual authentication with TLS Channel Binding 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 post-TLS establishment, it MUST occur before any non-authentication-related Telnet options are negotiated or data is transmitted. 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 or the entire distinguished name 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 certification 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 certification 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 Common Name field 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. 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 [AUTH] and its related documents. For a current list of Telnet AUTH methods see [IANA]. 4.2.4 Username and Password When there is no other method of client authentication available transmitting the username and password over a connection protected by TLS is far superior to sending them in the clear. The Username MAY be transmitted to the host via the Telnet New Environment option's USER variable. 5 Security Considerations 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 up to the trust anchor. 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 ciphersuite, 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 ciphersuite 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 ciphersuites 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 ciphersuite and the fact that such a ciphersuite may compromise security. o The Telnet endpoints SHOULD log the exact choice of ciphersuite 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 sub-negotiations 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 ciphersuites 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 ciphersuite(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. Kerberos V5 can also be securely negotiated using TELNET AUTH KRB5 after START_TLS negotiation has completed. This is the preferred method of combining TLS and Kerberos V5 authentication. [AUTH-KRB5] 6.3 TLS Channel Bindings for use with TELNET AUTH mechanisms When the Telnet AUTH option is negotiated over TLS, the authentication option SHOULD verify the TLS channel bindings data [TLS-CB]. Doing so provides a strong cryptographic binding between the client authentication and the underlying TLS session. 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 5 after TLS negotiation Here's an implementation example of using Kerberos 5 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_V5 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL KERBEROS_V5 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_V5 CLIENT_TO_SERVER|MUTUAL KERBEROS_V5 CLIENT_TO_SERVER|ONE_WAY IAC SE C: IAC SB AUTHENTICATION NAME jaltman IAC SE C: IAC SB AUTHENTICATION IS KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL AUTH 6e 82 01 d4 30 82 01 d0 | a0 03 02 01 05 a1 03 02 01 0e a2 07 03 05 00 20 | 00 00 00 a3 82 01 18 61 82 01 14 30 82 01 10 a0 | 03 02 01 05 a1 10 1b 0e 41 54 48 45 4e 41 2e 4d | 49 54 2e 45 44 55 a2 29 30 27 a0 03 02 01 03 a1 | 20 30 1e 1b 04 68 6f 73 74 1b 16 61 6c 6c 2d 6e | 69 67 68 74 2d 74 6f 6f 6c 2e 6d 69 74 2e 65 64 | 75 a3 81 cb 30 81 c8 a0 03 02 01 01 a1 03 02 01 | 10 a2 81 bb 04 81 b8 92 25 23 ce 7a 7d dc bf 7d | 7a 53 07 17 55 3a 55 ef 2b d5 44 7f bd f2 8e a5 | 13 69 ee e2 72 e2 10 9a a4 cf cb 55 3e 4a db d9 | 10 37 f4 50 be 6f 91 29 c4 ef fe 77 ba ae b9 b7 | 5e e1 1c ed ff ff b8 f6 b3 00 2d d9 83 1c 42 08 | bc 8b 14 aa de fa 46 39 db 02 ed 21 79 66 4e 5d | 8a d6 f6 5a 66 10 82 00 06 f4 cd b7 0e d4 57 99 | 89 81 f8 dc 4b 64 60 90 75 66 d3 c9 74 27 ea 75 | d5 57 7a 7b 29 ad e1 de 58 23 42 d8 09 f8 14 b7 | a4 67 8b 1c 86 e7 be 6f d8 69 66 d1 ab 8e 62 cc | a5 ee 43 02 7e 0c 16 c5 ad 29 30 25 bc 26 98 0a | f1 3e c9 e8 14 7e 84 4e 06 66 2c 0c f2 37 ee da | a4 81 9e 30 81 9b a0 03 02 01 01 a2 81 93 04 81 | 90 3e d1 48 2b a3 e2 27 90 48 35 93 d2 48 6a 80 | 6d 59 cd ab bb 94 23 99 4c e8 02 e2 77 0e 39 e9 | e9 35 86 48 68 1b f2 94 03 45 66 6f f2 e1 b0 f0 | 7f 78 ae ef 78 75 a8 e5 03 47 ef 6a 08 b5 10 48 | 2a 3e f4 a4 dd 56 f9 5e 03 4c a0 09 92 9f 22 3d | d5 5d 22 4b 9d ef e8 de cd 27 71 5b a2 4d 48 d3 | 85 73 0b 82 e5 22 52 4b b5 aa aa 6c bf aa 79 d2 | 9a b4 c2 48 3a 31 04 44 bb d7 14 b3 2c f3 00 70 | be 04 a2 95 30 bb c2 dc a2 93 62 89 45 b2 64 bb | 8e IAC SE S: IAC SB TERMINAL-TYPE SEND IAC SE S: IAC SB NEW-ENVIRONMENT SEND IAC SE S: IAC SB AUTHENTICATION REPLY KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL RESPONSE 6f 59 30 57 a0 03 02 01 | 05 a1 03 02 01 0f a2 4b 30 49 a0 03 02 01 01 a2 | 42 04 40 29 56 c7 c0 87 17 49 e4 87 02 d4 e1 ce | 34 de 78 a6 ae a8 cd f4 b9 12 c4 88 29 93 f3 21 | f9 69 4e 65 73 fa 3a 6f 70 fd 6e 18 bb 73 22 25 | d7 3b 1b e1 20 6c 45 d7 6f 35 e3 3b 84 41 db 9b | 19 a4 44 IAC SE S: IAC SB AUTHENTICATION REPLY KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL ACCEPT "jaltman@ATHENA.MIT.EDU" 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. IANA Considerations The IANA will update the Telnet Prootcol registry to reflect the contents of this document. In particular, IANA will document the START_TLS option number and the FOLLOWS sub-option. 9. Normative References [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC2235, November 1997. [AUTH] J. Altman, "Telnet Authentication Option", successor to RFC2941. draft-altman-telnet-rfc2941bis [AUTH-KRB5] J. Altman, "Telnet Authentication: Kerberos Version 5" successor to RFC2942 draft-altman-telnet-rfc2942bis [ENCRYPT] T.Ts'o, "Telnet Encryption Option", RFC2946, September 2000. [IANA] IANA Assigned Telnet Options http://www.iana.org/assignments/telnet-options [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. [RFC2360] G. Scott, Editor. "Guide for Internet Standard Writers", RFC2360, June 1998. [RFC3280] Housley, R., Ford, W., Polk, W. and D.Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC3280, April 2002. [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specifications", RFC854, May 1983. [TLS] Tim Dierks, C. Allen. "The TLS Protocol Version 1.1", RFC4346, April 2006. [TLS-CB] J. Altman, N. Williams. "TLS Channel Bindings", draft-altman-tls-channel-bindings-XX.txt [TLSKERB] Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC2712, October 1999. [TLSPSK] Eronen, P. and H. Tschofenig. "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC4279, December 2005. 10. Informational references [RFC927] Brian A. Anderson. "TACACS User Identification Telnet Option", RFC927, December 1984 11. Editor Jeffrey Altman Secure Endpoints Inc 255 W 94th ST New York NY 10025 USA jaltman@secure-endpoints.com 12. Credits This document was originally the product of the TN3270WG and was co-authored by Michael Boe. The TN3270WG closed before this document could be submitted to the IESG. Russ Housley and Eric Rescorla provided significant feedback during its initial publication. Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
Datatracker
Report a datatracker bug
draft-altman-telnet-starttls-02
None
| Document | Document type |
Expired Internet-Draft
(individual in sec area)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author |
Jeffrey E. Altman
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | Proposed Standard | ||
| Other formats |