idnits 2.17.1 draft-ietf-tn3270e-telnet-tls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-telnet-tls-00', but the file name used is 'draft-ietf-tn3270e-telnet-tls-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 11) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 40 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1998) is 9414 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ANBF' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC927' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC1416' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'SASL' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'TELNET' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'TLSKERB' is defined on line 587, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2235 (ref. 'ANBF') ** Obsolete normative reference: RFC 1416 (Obsoleted by RFC 2941) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSKERB' Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Michael Boe 2 INTERNET-DRAFT draft-ietf-telnet-tls-00 Cisco Systems 3 expires July 1998 4 December, 1997 6 TLS-based Telnet Security 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that the other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced or obsoleted by other documents at any time. 17 Its is inappropriate to use Internet-Drafts as reference material or to 18 cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Cost), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 Telnet service has long been a standard Internet protocol. However, a 29 standard way of ensuring privacy and integrity of Telnet sessions has 30 been lacking. This document proposes a standard method for Telnet 31 servers and clients to use the Transport Layer Security (TLS) protocol. 32 It describes how two Telnet participants can decide whether or not to 33 attempt TLS negotiation, and how the two participants should process 34 authentication credentials exchanged as a part of TLS startup. 36 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 38 Changes since last Draft 40 The first draft was really just writing down what's been done in one 41 working Telnet implementation where TLS is used: the SSLeay SSLTelnet 42 package. This seems as good a starting point as any. Reviewers had the 43 following comments concerning the content of that draft: 45 *separate port: Why not just do a separate port implementation? 47 At the Washington D.C. meeting, it was made clear that specifying a 48 separate port implementation would be met with a distinct lack of 49 enthusiasm on the part of the IESG. So the separate port is still 50 absent. 52 *no RFC1416: Why do the RFC1416 song and dance when the RFC1416 model 53 doesn't fit with this? 55 John Hind points out that one could want to negotiate Kerberos on top 56 of TLS. Chris Newman takes this a step further and points out that 57 TLS is not really doing the same thing as RFC1416; TLS is providing 58 transport encryption and optional authentication; RFC1416 appears 59 to be providing authentication and sometimes encryption. I've 60 scuttled the use of RFC1416 to negotiate TLS. Instead, TLS is 61 negotiated via a IAC DO STARTTLS option. This breaks SSLeay 62 implementations. 64 *0xff processing: We may need to explicitly disable Telnet 0xff 65 processing during TLS negotiation. 67 I'm not sure what to think of this. My hope is that by accepting the 68 IAC DO STARTTLS option, normal Telnet 0xff processing is suspended 69 until TLS negotiation has completed (successfully or not). If 70 someone think this won't work (due to lack of synchronicity at the 71 end TLS negotiations), please let me know. 73 Intent of Draft 75 I'm hoping this draft provides some focus on the following issues: 77 o how client and server can achieve TLS/SSL-based Telnet connections. 79 o how TLS can co-exist on the same server (or client) program with 80 other authentication techniques. This is an interesting problem, 81 since it turns out I can't talk about some of these techniques 83 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 85 because RFC1416 is Experimental, and normative references need to be 86 Standards. So I'm having to hack the text to refer to these 87 techniques generically and not specifically. I may be able to get 88 away with using RFC1416 as an example but pointing that it's just 89 that: an example. 91 o the limitations (futility?) of attempting to ``negotiate'' TLS at 92 the Telnet level. 94 I did not include descriptive narrative showing how things could be 95 implemented. Although this is a ``good'' thing in general with RFCs, it 96 makes initial understanding a bit harder. So please question the draft 97 if something appears pointless or obscure. 99 One thing I have not addressed is the minimum set of cipher-suites that 100 must be supported by all clients and servers. The IETF looks like it is 101 settling on TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, which is the suite of DSS 102 certificates and triple-DES and SHA MAC. This is not what comes standard 103 with Netscape SSL 3.0...but then, supposedly SSL is just a fallback in 104 case one of the implementations is not compliant with this spec :-). 106 The reference to SASL in this draft is purely placeholder for future 107 work. I don't envision this SASL ``protocol exchange'' that will provide 108 authorization identity as being very complicated. I'm thinking it will 109 be very simple--maybe a pair of exchanges between client and server sent 110 immediately after the TLS negotation. 112 1 Introduction 114 We are interested in addressing the interaction between the Telnet 115 client and server that will support this secure requirement with the 116 knowledge that this is only a portion of the total end-user to 117 application path. Specifically it is often true that the Telnet server 118 does not reside on the target machine (it does not have access to a list 119 of identities which are allowed to access to that mainframe), and it is 120 often true (e.g. 3270 access) that the TN server can not even identify 121 that portion of the emulation stream which contains user 122 identification/password information. Additionally it may be the case 123 that the Telnet client is not co-resident with the end user and that it 124 also may be unable to identify that portion of the data stream that deals 125 with user identity. We make the assumption here that there is a trust 126 relationship and appropriate protection to support that relationship 127 between the TN Server and the ultimate application engine such that data 128 on this path is protected and further that the application will 129 authenticate the end user via the emulation stream as well as use this to 130 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 132 control access to information. We further make the assumption that the 133 path between the end user and the client is protected. 135 To hold up our Telnet part of the overall secure path between the user 136 and the mainframe we need to make the Telnet data stream unobservable to 137 a third party. We do this by creating a shared secret between the client 138 and server which is used to encrypt the flow of data and (just as 139 important) require the client to verify that it is talking to correct 140 server (the one that the mainframe trusts rather than an unintended 141 man-in-the-middle) with the knowledge that the emulation stream itself 142 will be used by the mainframe to verify the identity of the end-user. 143 Rather than create a specialized new protocol which accomplishes these 144 goals we instead have chosen to use existing protocols with certain 145 constraints. 147 The TLS protocol (formerly known as SSL) can shield a connection from 148 tampering and eavesdropping. One protocol which can benefit from the 149 security TLS offers is Telnet [TELNET ]. Although other security 150 mechanisms have been used with Telnet (e.g. KERBEROS [RFC1416 ]), TLS 151 offers a broad range of security levels that allow sites to proceed at an 152 "evolutionary" pace in deploying authentication, authorization and 153 confidentiality policies, databases and distribution methods. 155 TLS is used to provide the following: 157 o creation and refresh of a shared secret; 159 o negotiation and execution of data encryption and optional 160 compressesion; 162 o primary negotiation of authentication; and, if chosen 164 o execution of public-key or symmetric-key based authentication. 166 Since both encryption and authentication is always needed for a secure 167 channel that meets the requirements of these emulation types, we can use 168 the anonymous authentication negotiation option of TLS as an indication 169 that the client wants to negotiate some non-TLS-based authentication 170 exchange. Note that as per usual TLS rules, the client must always 171 authenticate the server's credentials. 173 TLS at most offers only authentication of the peers conducting the TLS 174 dialog. In particular, it does not offer the possibility of the client 175 providing separate credentials for authorization than were presented for 176 authentication. It is expect that other RFCs will be produced describing 177 how other authentication mechanisms can be used in conjunction with TLS. 179 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 181 Traditional Telnet servers have operated without such early presentation 182 of authorization credentials for many reasons (most of which are 183 historical). However, recent developments in Telnet server technology 184 make it advantageous for the Telnet server to know the authorized 185 capabilities of the remote client before choosing a communications link 186 (be it `pty' or SNA LU) and link-characteristics to the host system (be 187 that ``upstream'' link local or remote to the server). Thus, we expect 188 to see the use of client authorization to become an important element of 189 the telnet evolution. Such authorization methods may require 190 certificates presented by the client via TLS, or by the use of SASL or 191 RFC1416, or some other as yet unknown method. 193 This document defines extensions to Telnet which allow TLS to be 194 activated early in the lifetime of the Telnet connection. It defines a 195 set of advisory security-policy response codes for use when negotiating 196 TLS over Telnet. 198 2 Conventions Used in this Document 200 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 201 "MAY" in this document are to be interpreted as described in [KEYWORDS ]. 203 Formal syntax is defined using ABNF [ANBF ]. 205 In examples, "C:" and "S:" indicate lines sent by the the client and 206 server, respectively. 208 3 Telnet STARTTLS Option 210 The STARTTLS option is an asymmetric option, with only the server side 211 being able to send IAC DO STARTTLS. The client may initiate by sending 212 IAC WILL STARTTLS. There are some more rules due to the need to clear the 213 link of data (or to ``synchronize'' the link). This synchronization 214 takes the form of a three-way handshake: 216 1. As per normal Telnet option processing rules, the client MUST 217 respond to the server's IAC DO STARTTLS with either IAC WONT 218 STARTTLS or IAC WILL STARTTLS (if it hasn't already done so). An 219 affirmative response MUST be followed eventually by IAC SB STARTTLS 220 FOLLOWS IAC SE. If the client sends the affirmative response, it 221 must then not initiate any further Telnet options or subnegotiations 222 except for the STARTTLS subnegotiation until after the TLS 224 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 226 negotiation has completed. 228 2. The server SHOULD NOT send any more Telnet data or commands after 229 sending IAC DO STARTTLS except in response to client Telnet options 230 received until after it receives either a negative response from the 231 client (IAC WONT STARTTLS) or the affirmative (both IAC WILL 232 STARTTLS and followed eventually by IAC SB STARTTLS FOLLOWS IAC SE). 233 If the client's STARTTLS option response is negative, the server is 234 free to again send Telnet data or commands. If the client's response 235 is affirmative, then the server MUST send only IAC SB STARTTLS 236 FOLLOWS IAC SE. If the server sends IAC SB STARTTLS FOLLOWS IAC SE, 237 then the server MUST also arrange at this time, for the normal Telnet 238 byte-stuff/destuff processing to be turned off for the duration of 239 the TLS negotiation. 241 3. The client, upon receipt of the server's IAC SB STARTTLS FOLLOWS IAC 242 SE, MUST also arrange for normal Telnet byte-stuff/destuff 243 processing to be turned off for the duration of the TLS negotiation. 244 It MUST then enter into TLS negotiation by sending the TLS 245 ClientHello message. 247 Here's a breakdown of the Telnet command phrases defined in this 248 document: 250 S: IAC DO STARTTLS-- Sent only by server. Indicates that server strongly 251 desires that the client enter into TLS negotiations. 253 C: IAC WILL STARTTLS-- Sent only by client. Indicates that client 254 strongly desires that the server enter into TLS negotiations. 256 S: IAC DONT STARTTLS-- Sent only by the server. Indicates that the 257 server is not willing to enter into TLS negotations. 259 C: IAC WONT STARTTLS-- Sent only by the client. Indicates that the 260 client is not willing to enter into TLS negotiations. 262 C: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the client, this 263 indicates that the client is preparing for TLS negotiations, and 264 that the next thing sent by the client will be the TLS ClientHello. 266 S: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the server, this 267 indicates that the server has prepared to receive the TLS 268 ClientHello from the client. 270 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 272 3.1 Abnormal Negotiation Failure 274 The behavior regarding TLS negotiation failure is covered in [TLS ]. The 275 TLS spec recommends that the TCP connection be dropped where negotiation 276 failure is due to insufficient security, inability to verify a 277 certificate, handshake failure, etc. This appears not to indicate that 278 the TCP connection be broken; the semantics are that TLS is finished and 279 all state variables cleaned up. 281 If this happens, the two sides may continue the Telnet connection. 282 Here's how: 284 o The side which received the TLS ErrorAlert message speaks first; 286 o The first speaker can send any Telnet data or commands; 288 o Neither side SHOULD attempt to issue another STARTTLS during the 289 lifetime of the Telnet session. 291 4 TLS, Authentication and Authorization 293 If TLS has been successfully negotiated, the client will have the 294 server's certificate. This indicates that the server's identity can be 295 verified. Client implementations MUST always verify the server identity 296 as part of TLS processing and fail the connection if such verification 297 fails. See Section /refsec:servauth for details of the mechanics of 298 server authentication. 300 The server, however, may not have the client's identity (verified or 301 not). This is because the client need not provide a certificate during 302 the TLS exchange. Or it may be server site policy not to use the identity 303 so provided. In any case, the server may not have enough confidence in 304 the client to move the connection to the ``authenticated'' state. 306 On the other hand, the server MAY elect to use the client's TLS-proffered 307 credentials as the basis for authentication. If the server is satisfied 308 with the credentials, it MUST move the connection to the 309 ``authenticated'' state before it processes any further Telnet data or 310 commands from the client. 312 Once the connection has been moved to the authenticated state, the 313 server MUST NOT initiate further authentication-related Telnet 314 exchanges with the client after moving the Telnet connection to the 315 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 317 authenticated state. And the server MUST NOT accept further attempts by 318 the client to proffer authentication details. 320 [Author's note: this has some interesting implications. It appears that 321 it's very important for the client to pick a TLS authentication 322 mechanism that has the best chance in resulting in the authorizations 323 wanted by that client. That's because the server will very probably 324 prefer TLS-provided authentication over post-TLS-negotiation 325 authentication. Are people happy with this?] 327 If further client, server or client-server authentication is going to 328 occur after TLS has been negotiated, it MUST occur before any 329 non-authentication-related Telnet interactions take place on the link 330 after TLS starts. This specification recognizes Telnet AUTHENTICATE and 331 TUID options and subsequent subnegotiations as being valid 332 authentication-related Telnet interactions (for more information on 333 these to options, see [RFC1416 ] and [RFC927 ] respectively). [Note that 334 this specification does not rely on TUID or AUTHENTICATE Telnet options 335 in any way.] Further Telnet options and subnegotiations may be added to 336 this list by registering them with IANA as being authentication-related 337 Telnet options. When the first non-authentication-related Telnet 338 interaction is received by either participant, then the receiving 339 participant MAY drop the connection due to dissatisfaction with the 340 level of authentication. 342 [author's note: Probably a few error-conditions ala ACAP/POP3/IMAP 343 authentication are in order so that the spurned participant has 344 something useful to display/log other than "session disconnected." 345 Comments?] 347 And no TLS negotiation outcome, however trustworthy, will by itself 348 provide the server with the authorization identity if that is different 349 from the authentication identity of the client. See [SASL ] for why this 350 might be a desirable function to have with proxy clients, etc. How such 351 authorization is done is outside the scope of this document. 353 The following subsections detail how the client can provide the server 354 with authentication and authorization credentials separate to the TLS 355 mechanism. 357 4.1 PKI-based Authentication and certificate extensions 359 When PKI authentication is used no special X.509 certificate extensions 360 will be require but a client or server may choose to support an extension 361 if found. For example, they may use a contained certificate revocation 362 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 364 URL extension if provided. The intent is to allow sharing of 365 certificates with other services on the same host, for example, a Telnet 366 server might use the same certificate to identify itself that a 367 co-located WEB server uses. The method of sharing certificates is 368 outside the scope of this document. 370 4.2 Pre-TLS Authentication 372 It could be that the server had moved the Telnet connection to the 373 authenticated state sometime previous to the negotiation of TLS. If this 374 is the case, then the server MUST NOT use the credentials proffered by 375 the client during the TLS negotiations for authorization of that client. 376 The server should, of course, verify the client's TLS-proffered 377 credentials. 379 [Author's note: I've deleted the sections on RFC1416 and SASL. RFC1416 380 is an Experimental RFC, and I don't want people to think that this 381 document relies on an experimental RFC (which would prevent this 382 document from being approved). And the use of SASL should be a 383 completely separate effort from the one this document describes.] 385 5 Security 387 Security is discussed throughout this document. Most of this document 388 concerns itself with wire protocols and security frameworks. But in this 389 section, client and server implementation security issues are in focus. 391 5.1 Authentication of the Server by the Client 393 How the client can verify the server's proferred identity varies 394 according to the key-exchange algorithm used in the selected TLS 395 cipher-suite. However, it's important for the client to follow good 396 security practice in verifying the proffered identity of the server. 398 5.1.1 PKI-based certificate processing 400 When PKI authentication is used no special X.509 certificate extensions 401 will be required but a client or server may choose to support an 402 extension if found. For example, they may use a contained certificate 403 revocation URL extension if provided. The intent is to allow sharing of 404 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 406 certificates with other services on the same host, for example, a Telnet 407 server might use the same certificate to identify itself that a 408 co-located WEB server uses. The method of sharing certificates is not a 409 topic of this document. 411 The verification of the server's certificate by the client MUST include, 412 but isn't limited to, the verification of the signature certificate 413 chain to the point where the a signature in that chain uses a known good 414 signing certificate in the clients local key chain. The verification 415 SHOULD then continue with a check to see if the fully qualified host name 416 which the client connected to appears anywhere in the server's 417 certificate subject (DN). If no match is found then the end user should 418 see a display of the servers certificate and be asked if he/she is 419 willing to proceed with the session. 421 [question: do certs always get signed with the DNS domain-name? Further, 422 will all clients that implement TLS also be forced to use DNS? If not, 423 how would the client end up knowing the DNS name of the host? Another 424 question: suppose the FQDN of the server comes back as a subdomain of the 425 name on the cert. Is this ok? What are the pros and cons of this?] 427 5.1.2 Kerberos V5 server verification 429 [Nothing here yet. Just a placeholder to show everybody that PKI-based 430 authentication is not the only game in town.] 432 5.2 Display of security levels 434 The Telnet client and server MAY, during the TLS protocol negotiation 435 phase, choose to use a weak cipher suite due to policy, law or even 436 convenience. It is, however, important that the choice of weak cipher 437 suite be noted as being commonly known to be vulnerable to attack. In 438 particular, both server and client software should note the choice of 439 weak cipher-suites in the following ways: 441 o If the Telnet endpoint is communicating with a human end-user, the 442 user-interface SHOULD display the choice of weak cipher-suite and 443 the fact that such a cipher-suite may compromise security. 445 o The Telnet endpoints SHOULD log the exact choice of cipher-suite as 446 part of whatever logging/accounting mechanism normally used. 448 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 450 6 TLS Variants and Options 452 TLS has different versions and different cipher suites that can be 453 supported by client or server implementations. The following 454 subsections detail what TLS extensions and options are mandatory. The 455 subsections also address how TLS variations can be accommodated. 457 6.1 Support of previous versions of TLS 459 TLS has its roots in SSL 2.0 and SSL 3.0. Server and client 460 implementations may wish to support for SSL 3.0 as a fallback in case TLS 461 3.1 or higher is not supported. This is permissible; however, client 462 implementations which negotiate SSL3.0 MUST still follow the rules in 463 Section 5.2 concerning disclosure to the end-user of transport-level 464 security characteristics. 466 Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; it 467 is detailed in [TLS ]. Negotiating SSL 2.0 is not recommended. 469 6.2 Using Kerberos V5 with TLS 471 If the client and server are both amenable to using Kerberos V5, then 472 using non-PKI authentication techniques within the confines of TLS may 473 be acceptable (see [TLSKERB ]). Note that clients and servers are under 474 no obligation to support anything but the cipher-suite(s) mandated in 475 [TLS ]. However, if implementations do implement the KRB5 authentication 476 as a part of TLS ciphersuite, then these implementations SHOULD support 477 at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite. 479 7 Protocol Examples 481 The following sections provide skeletal examples of how Telnet clients 482 and servers can negotiate TLS. 484 7.1 Successful TLS negotiation 486 The following protocol exchange is the typical sequence that starts TLS: 488 // typical successful opening exchange 489 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 491 S: IAC DO STARTTLS 492 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 493 S: IAC SB STARTTLS FOLLOWS IAC SE 494 // server now readies input stream for non-Telnet, TLS-level negotiation 495 C: [starts TLS-level negotiations with a ClientHello] 496 [TLS transport-level negotiation ensues] 497 [TLS transport-level negotiation completes with a Finished exchanged] 498 // either side now able to send further Telnet data or commands 500 The following protocol exchange is the typical sequence that starts TLS, 501 but with the twist that the (TN3270E) server is willing but not 502 aggressive about doing TLS; the client strongly desires doing TLS. 504 // typical successful opening exchange 505 S: IAC DO TN3270E 506 C: IAC WILL STARTTLS IAC 507 C: IAC WONT TN3270E 508 S: IAC DO STARTTLS 509 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 510 S: IAC SB STARTTLS FOLLOWS IAC SE 511 // server now readies input stream for non-Telnet, TLS-level negotiation 512 C: [starts TLS-level negotiations with a ClientHello] 513 [TLS transport-level negotiation ensues] 514 [TLS transport-level negotiation completes with a Finished 515 exchanged] 516 // note that server retries negotiation of TN3270E after TLS 517 // is done. 518 S: IAC DO TN3270E 519 C: IAC WILL TN3270E 520 // TN3270E dialog continues.... 522 7.2 Unsuccessful TLS negotiation 524 This example assumes that the server does not wish to allow the Telnet 525 session to procede without TLS security; however, the client's version 526 of TLS does not interoperate with server's. 528 //typical unsuccessful opening exchange 529 S: IAC DO STARTTLS 530 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 531 S: IAC SB STARTTLS FOLLOWS IAC SE 532 // server now readies input stream for non-Telnet, TLS-level negotiation 533 C: [starts TLS-level negotiations with a ClientHello] 535 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 537 [TLS transport-level negotiation ensues] 538 [TLS transport-level negotiation fails with server sending 539 ErrorAlert message] 540 C: IAC DO TERMINAL-TYPE 541 S: IAC WONT TERMINAL-TYPE 542 S: [TCP level disconnect] 543 // server (or both) initiate TCP session disconnection 545 This example assumes that the server wants to do TLS, but is willing to 546 allow the session to procede without TLS security; however, the client's 547 version of TLS does not interoperate with server's. 549 //typical unsuccessful opening exchange 550 S: IAC DO STARTTLS 551 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 552 S: IAC SB STARTTLS FOLLOWS IAC SE 553 // server now readies input stream for non-Telnet, TLS-level negotiation 554 C: [starts TLS-level negotiations with a ClientHello] 555 [TLS transport-level negotiation ensues] 556 [TLS transport-level negotiation fails with server sending 557 ErrorAlert message] 558 C: IAC DO TERMINAL-TYPE 559 S: IAC WILL TERMINAL-TYPE 560 // regular Telnet dialog ensues 562 References 564 [ANBF] D. Crocker, Ed., P. Overell, ``Augmented BNF for Syntax 565 Specifications: ABNF'', RFC2235, November 1997. 567 [KEYWORDS] Bradner, S. ``Key words for use in RFCs to Indicate 568 Requirement Levels'', RFC2119, March 1997. 570 [RFC927] Brian A. Anderson. ``TACACS User Identification Telnet 571 Option'', RFC927, December 1984 573 [RFC1416] D. Borman, Editor. ``Telnet Authentication Option'', 574 RFC1416, February 1993. 576 [SASL] Myers, J. ``Simple Authentication and Security Layer 577 (SASL)'', RFC2222, October 1997. 579 [TELNET] J. Postel, J. Reynolds. ``Telnet Protocol Specifications'', 580 RFC854, May 1983. 582 [TLS] Tim Dierks. ``The TLS Protocol'', Internet Draft, November 583 1997. 585 I-D draft-ietf-telnet-tls-00 TLS-based Telnet Security December, 1997 587 [TLSKERB] Ari Medvinsky, Matthew Hur. ``Addition of Kerberos Cipher 588 Suites to Transport Layer Security (TLS)'', Internet Draft, 589 July 1997. 591 Author's Address 593 Michael Boe 594 Cisco Systems Inc. 595 1264 5th Avenue 596 San Francisco, CA 94122-2649 598 Email: Michael Boe