Internet Engineering Task Force Michael Boe INTERNET-DRAFT draft-ietf-telnet-tls-00 Cisco Systems expires July 1998 December, 1997 TLS-based Telnet Security Status of this memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Cost), or ftp.isi.edu (US West Coast). 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. I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 Changes since last Draft The first draft was really just writing down what's been done in one working Telnet implementation where TLS is used: the SSLeay SSLTelnet package. This seems as good a starting point as any. Reviewers had the following comments concerning the content of that draft: *separate port: Why not just do a separate port implementation? At the Washington D.C. meeting, it was made clear that specifying a separate port implementation would be met with a distinct lack of enthusiasm on the part of the IESG. So the separate port is still absent. *no RFC1416: Why do the RFC1416 song and dance when the RFC1416 model doesn't fit with this? John Hind points out that one could want to negotiate Kerberos on top of TLS. Chris Newman takes this a step further and points out that TLS is not really doing the same thing as RFC1416; TLS is providing transport encryption and optional authentication; RFC1416 appears to be providing authentication and sometimes encryption. I've scuttled the use of RFC1416 to negotiate TLS. Instead, TLS is negotiated via a IAC DO STARTTLS option. This breaks SSLeay implementations. *0xff processing: We may need to explicitly disable Telnet 0xff processing during TLS negotiation. I'm not sure what to think of this. My hope is that by accepting the IAC DO STARTTLS option, normal Telnet 0xff processing is suspended until TLS negotiation has completed (successfully or not). If someone think this won't work (due to lack of synchronicity at the end TLS negotiations), please let me know. Intent of Draft I'm hoping this draft provides some focus on the following issues: o how client and server can achieve TLS/SSL-based Telnet connections. o how TLS can co-exist on the same server (or client) program with other authentication techniques. This is an interesting problem, since it turns out I can't talk about some of these techniques Michael Boe [Page 2] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 because RFC1416 is Experimental, and normative references need to be Standards. So I'm having to hack the text to refer to these techniques generically and not specifically. I may be able to get away with using RFC1416 as an example but pointing that it's just that: an example. o the limitations (futility?) of attempting to ``negotiate'' TLS at the Telnet level. I did not include descriptive narrative showing how things could be implemented. Although this is a ``good'' thing in general with RFCs, it makes initial understanding a bit harder. So please question the draft if something appears pointless or obscure. One thing I have not addressed is the minimum set of cipher-suites that must be supported by all clients and servers. The IETF looks like it is settling on TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, which is the suite of DSS certificates and triple-DES and SHA MAC. This is not what comes standard with Netscape SSL 3.0...but then, supposedly SSL is just a fallback in case one of the implementations is not compliant with this spec :-). The reference to SASL in this draft is purely placeholder for future work. I don't envision this SASL ``protocol exchange'' that will provide authorization identity as being very complicated. I'm thinking it will be very simple--maybe a pair of exchanges between client and server sent immediately after the TLS negotation. 1 Introduction 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 mainframe), and it is often true (e.g. 3270 access) that the TN 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 TN Server and the ultimate application engine such that data on this path is protected and further that the application will authenticate the end user via the emulation stream as well as use this to Michael Boe [Page 3] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 control access to information. We further make the assumption that the path between the end user and the client is protected. To hold up our Telnet part of the overall secure path between the user and the mainframe we need to make the Telnet data stream unobservable to a third party. We do this by creating a shared secret between the client and server which 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 mainframe trusts rather than an unintended man-in-the-middle) with the knowledge that the emulation stream itself will be used by the mainframe 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 existing protocols with certain constraints. The TLS protocol (formerly known as SSL) can shield a connection from tampering and eavesdropping. One protocol which can benefit from the security TLS offers is Telnet [TELNET ]. Although other security mechanisms have been used with Telnet (e.g. KERBEROS [RFC1416 ]), 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. TLS is 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. Since both encryption and authentication is always needed for a secure channel that meets the requirements of these emulation types, we can use the anonymous authentication negotiation option of TLS as an indication that the client wants to negotiate some non-TLS-based authentication exchange. Note that as per usual TLS rules, the client must always authenticate the server's credentials. 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. It is expect that other RFCs will be produced describing how other authentication mechanisms can be used in conjunction with TLS. Michael Boe [Page 4] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 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 SASL or RFC1416, or some other as yet unknown method. This document defines extensions to Telnet which allow TLS to be activated early in the lifetime of the Telnet connection. It defines a set of advisory security-policy response codes for use when negotiating TLS over Telnet. 2 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 [ANBF ]. In examples, "C:" and "S:" indicate lines sent by the the client and server, respectively. 3 Telnet STARTTLS Option The STARTTLS option is an asymmetric option, with only the server side being able to send IAC DO STARTTLS. The client may initiate by sending IAC WILL STARTTLS. There are some more rules due to the need to clear the link of data (or to ``synchronize'' the link). 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 STARTTLS with either IAC WONT STARTTLS or IAC WILL STARTTLS (if it hasn't already done so). An affirmative response MUST be followed eventually by IAC SB STARTTLS FOLLOWS IAC SE. If the client sends the affirmative response, it must then not initiate any further Telnet options or subnegotiations except for the STARTTLS subnegotiation until after the TLS Michael Boe [Page 5] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 negotiation has completed. 2. The server SHOULD NOT send any more Telnet data or commands after sending IAC DO STARTTLS except in response to client Telnet options received until after it receives either a negative response from the client (IAC WONT STARTTLS) or the affirmative (both IAC WILL STARTTLS and followed eventually by IAC SB STARTTLS FOLLOWS IAC SE). If the client's STARTTLS option response is negative, the server is free to again send Telnet data or commands. If the client's response is affirmative, then the server MUST send only IAC SB STARTTLS FOLLOWS IAC SE. If the server sends IAC SB STARTTLS FOLLOWS IAC SE, then the server MUST also arrange at this time, for the normal Telnet byte-stuff/destuff processing to be turned off for the duration of the TLS negotiation. 3. The client, upon receipt of the server's IAC SB STARTTLS FOLLOWS IAC SE, MUST also arrange for normal Telnet byte-stuff/destuff processing to be turned off for the duration of the TLS negotiation. It MUST then enter into TLS negotiation by sending the TLS ClientHello message. Here's a breakdown of the Telnet command phrases defined in this document: S: IAC DO STARTTLS-- Sent only by server. Indicates that server strongly desires that the client enter into TLS negotiations. C: IAC WILL STARTTLS-- Sent only by client. Indicates that client strongly desires that the server enter into TLS negotiations. S: IAC DONT STARTTLS-- Sent only by the server. Indicates that the server is not willing to enter into TLS negotations. C: IAC WONT STARTTLS-- Sent only by the client. Indicates that the client is not willing to enter into TLS negotiations. C: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the client, this indicates that the client is preparing for TLS negotiations, and that the next thing sent by the client will be the TLS ClientHello. S: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the server, this indicates that the server has prepared to receive the TLS ClientHello from the client. Michael Boe [Page 6] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 3.1 Abnormal Negotiation Failure The behavior regarding TLS negotiation failure is covered in [TLS ]. The TLS spec recommends that the TCP connection be dropped where negotiation failure is due to insufficient security, inability to verify a certificate, handshake failure, etc. This appears not to indicate that the TCP connection be broken; the semantics are that TLS is finished and all state variables cleaned up. If this happens, the two sides may continue the Telnet connection. Here's how: o The side which received the TLS ErrorAlert message speaks first; o The first speaker can send any Telnet data or commands; o Neither side SHOULD attempt to issue another STARTTLS during the lifetime of the Telnet session. 4 TLS, Authentication and Authorization If TLS has been successfully negotiated, the client will have the server's certificate. This indicates that the server's identity can be verified. Client implementations MUST always verify the server identity as part of TLS processing and fail the connection if such verification fails. See Section /refsec:servauth for details of the mechanics of server authentication. The server, however, may not have the client's identity (verified or not). This is because the client need not provide a certificate during the TLS exchange. Or it may be server site policy not to use the identity so provided. In any case, the server may not have enough confidence in the client to move the connection to the ``authenticated'' state. On the other hand, the server MAY elect to use the client's TLS-proffered credentials as the basis for authentication. If the server is satisfied with the credentials, it MUST move the connection to the ``authenticated'' state before it processes any further Telnet data or commands from the client. Once the connection has been moved to the authenticated state, the server MUST NOT initiate further authentication-related Telnet exchanges with the client after moving the Telnet connection to the Michael Boe [Page 7] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 authenticated state. And the server MUST NOT accept further attempts by the client to proffer authentication details. [Author's note: this has some interesting implications. It appears that it's very important for the client to pick a TLS authentication mechanism that has the best chance in resulting in the authorizations wanted by that client. That's because the server will very probably prefer TLS-provided authentication over post-TLS-negotiation authentication. Are people happy with this?] 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. This specification recognizes Telnet AUTHENTICATE and TUID options and subsequent subnegotiations as being valid authentication-related Telnet interactions (for more information on these to options, see [RFC1416 ] and [RFC927 ] respectively). [Note that this specification does not rely on TUID or AUTHENTICATE Telnet options in any way.] Further Telnet options and subnegotiations may be added to this list by registering them with IANA as being authentication-related Telnet options. 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. [author's note: Probably a few error-conditions ala ACAP/POP3/IMAP authentication are in order so that the spurned participant has something useful to display/log other than "session disconnected." Comments?] And 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. See [SASL ] for why this might be a desirable function to have with proxy clients, etc. How such authorization is done is outside the scope of this document. The following subsections detail how the client can provide the server with authentication and authorization credentials separate to the TLS mechanism. 4.1 PKI-based Authentication and certificate extensions When PKI authentication is used no special X.509 certificate extensions will be require but a client or server may choose to support an extension if found. For example, they may use a contained certificate revocation Michael Boe [Page 8] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 URL extension if provided. The intent is to allow sharing of certificates with other services on the same host, for example, a Telnet server might use the same certificate to identify itself that a co-located WEB server uses. The method of sharing certificates is outside the scope of this document. 4.2 Pre-TLS Authentication It could be that the server had moved the Telnet connection to the authenticated state sometime previous to the negotiation of TLS. If this is the case, then the server MUST NOT use the credentials proffered by the client during the TLS negotiations for authorization of that client. The server should, of course, verify the client's TLS-proffered credentials. [Author's note: I've deleted the sections on RFC1416 and SASL. RFC1416 is an Experimental RFC, and I don't want people to think that this document relies on an experimental RFC (which would prevent this document from being approved). And the use of SASL should be a completely separate effort from the one this document describes.] 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 Authentication of the Server by the Client How the client can verify the server's proferred identity varies according to the key-exchange algorithm used in the selected TLS cipher-suite. However, it's important for the client to follow good security practice in verifying the proffered identity of the server. 5.1.1 PKI-based certificate processing When PKI authentication is used no special X.509 certificate extensions will be required but a client or server may choose to support an extension if found. For example, they may use a contained certificate revocation URL extension if provided. The intent is to allow sharing of Michael Boe [Page 9] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 certificates with other services on the same host, for example, a Telnet server might use the same certificate to identify itself that a co-located WEB server uses. The method of sharing certificates is not a topic of this document. The verification of the server's certificate by the client 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 clients 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 no match is found then the end user should see a display of the servers certificate and be asked if he/she is willing to proceed with the session. [question: do certs always get signed with the DNS domain-name? Further, will all clients that implement TLS also be forced to use DNS? If not, how would the client end up knowing the DNS name of the host? Another question: suppose the FQDN of the server comes back as a subdomain of the name on the cert. Is this ok? What are the pros and cons of this?] 5.1.2 Kerberos V5 server verification [Nothing here yet. Just a placeholder to show everybody that PKI-based authentication is not the only game in town.] 5.2 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. Michael Boe [Page 10] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 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 3.1 or higher is not supported. This is permissible; however, client implementations which negotiate SSL3.0 MUST still follow the rules in Section 5.2 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 ]. Negotiating SSL 2.0 is not recommended. 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 Michael Boe [Page 11] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 S: IAC DO STARTTLS C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE S: IAC SB STARTTLS 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 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 STARTTLS IAC C: IAC WONT TN3270E S: IAC DO STARTTLS C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE S: IAC SB STARTTLS 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.2 Unsuccessful TLS negotiation This example assumes that the server does not wish to allow the Telnet session to procede without TLS security; however, the client's version of TLS does not interoperate with server's. //typical unsuccessful opening exchange S: IAC DO STARTTLS C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE S: IAC SB STARTTLS FOLLOWS IAC SE // server now readies input stream for non-Telnet, TLS-level negotiation C: [starts TLS-level negotiations with a ClientHello] Michael Boe [Page 12] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 [TLS transport-level negotiation ensues] [TLS transport-level negotiation fails with server sending ErrorAlert message] C: IAC DO TERMINAL-TYPE S: IAC WONT TERMINAL-TYPE 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 procede without TLS security; however, the client's version of TLS does not interoperate with server's. //typical unsuccessful opening exchange S: IAC DO STARTTLS C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE S: IAC SB STARTTLS 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] C: IAC DO TERMINAL-TYPE S: IAC WILL TERMINAL-TYPE // regular Telnet dialog ensues References [ANBF] D. Crocker, Ed., P. Overell, ``Augmented BNF for Syntax Specifications: ABNF'', RFC2235, November 1997. [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 [RFC1416] D. Borman, Editor. ``Telnet Authentication Option'', RFC1416, February 1993. [SASL] Myers, J. ``Simple Authentication and Security Layer (SASL)'', RFC2222, October 1997. [TELNET] J. Postel, J. Reynolds. ``Telnet Protocol Specifications'', RFC854, May 1983. [TLS] Tim Dierks. ``The TLS Protocol'', Internet Draft, November 1997. Michael Boe [Page 13] I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 [TLSKERB] Ari Medvinsky, Matthew Hur. ``Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)'', Internet Draft, July 1997. Author's Address Michael Boe Cisco Systems Inc. 1264 5th Avenue San Francisco, CA 94122-2649 Email: Michael Boe Michael Boe [Page 14]