idnits 2.17.1 draft-ietf-tn3270e-telnet-tls-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 925 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 55 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 533 has weird spacing: '... unauth auth...' == 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). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8562 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) == Missing Reference: 'ABNF' is mentioned on line 255, but not defined == Unused Reference: 'ANBF' is defined on line 1016, but no explicit reference was found in the text == Unused Reference: 'RFC927' is defined on line 1026, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2235 (ref. 'ANBF') -- Possible downref: Non-RFC (?) normative reference: ref. 'AUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ENCRYPT' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 4 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-tn3270e-telnet-tls-04.txt Jeffrey Altman 3 expires November 2000 4 May 22, 2000 6 TLS-based Telnet Security 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that the other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced or obsoleted by other documents at any time. 18 Its is inappropriate to use Internet-Drafts as reference material or to 19 cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (1998, 1999). All Rights Reserved. 31 Abstract 33 Telnet service has long been a standard Internet protocol. However, a 34 standard way of ensuring privacy and integrity of Telnet sessions has 35 been lacking. This document proposes a standard method for Telnet 36 servers and clients to use the Transport Layer Security (TLS) protocol. 37 It describes how two Telnet participants can decide whether or not to 38 attempt TLS negotiation, and how the two participants should process 39 authentication credentials exchanged as a part of TLS startup. 41 Changes since -03 Draft 43 Major changes to sections describing authentication of clients 44 and servers. 46 Changes since -02 Draft 48 o Clarify server actions in response to client initiating the TLS 49 negotiation. 51 o Replace the parochial term "mainframe" with "application-server." 53 o Nuke explicit references to RFC1416, since there's a new RFC in the 54 works for this and the reference isn't normative anyway. 56 o Use dNSName language similar to that used in the most recent HTTP TLS 57 draft. 59 o Delete beginning paragraph describing server-authentication in TLS. 60 Unclear and possibly wrong. 62 o Delete explicit references to SASL, since we don't actually describe 63 ways of using SASL. 65 o Add section describing interaction between AUTH and STARTTLS option 66 negotiations. 68 Changes since -01 Draft 69 o Drop possibility of a continuing a Telnet session if the TLS 70 negotiation fails. 72 o Assert that server sending DO STARTTLS must be willing to negotiate 73 a TLS session 75 o Change SHOULD to MUST with respect to a server requesting a client 76 certificate. 78 o Add paragraph on commonName to section on check of X.509 79 certificate. 81 o Sharpen language concerning notification of possible 82 server-certificate mismatch. 84 o drop place-holder section on Kerberos 5 security; replace with 85 section on non-PKI-based authentication (after TLS negotiation). 87 o Prohibit fallback to SSL 2.0. 89 o Give more details about how authentication-after-TLS-negotiation 90 can be achieved. 92 o Simplify post-TLS Telnet negotiation state-assumptions by resetting 93 them to initial-state. 95 Changes since -00 Draft 96 o Add local authentication/authorization operational model. 98 o Change behavior of Telnet machine to reset at start of TLS 99 negotiation. 101 o Insert narrative questioning the utility of allowing continuation of 102 Telnet session after TLS has ended. 104 o change examples to reflect the above changes. 106 o Fix several typos. 108 Contents 110 1 Introduction 112 2 Command Names and Codes (assigned by IANA) 114 3 Command Meanings 116 3.1 Usage of commands and interactions with other Telnet options 118 3.2 TLS Negotiation Failure 120 4 Authentication and Authorization 122 4.1 Authentication of the Client by the Server 124 4.1.1 PKI-based Authentication via TLS handshake 126 4.1.2 Non-PKI Authentication via TLS handshake 128 4.1.3 Telnet AUTH option 130 4.1.4 Traditional Username and Password 132 4.2 Authentication of the Server by the Client 134 4.2.1 PKI-based Authentication via TLS handshake 136 4.2.2 Non-PKI based authentication via TLS handshake 138 4.2.3 Authentication by Telnet AUTH option 140 5 Security 142 5.1 PKI-based certificate processing . . . 144 5.2 Client and Server authentication of anonymous TLS connections 146 5.3 Display of security levels . . . . . . 148 5.4 Trust Relationships and Implications . . . . 150 5.5 Telnet negotation handling 152 6 TLS Variants and Options 154 6.1 Support of previous versions of TLS . . . . 156 6.2 Using Kerberos V5 with TLS . . . . . . 158 7 Protocol Examples 160 7.1 Successful TLS negotiation . . . . . . 162 7.2 Successful TLS negotiation, variation . . . . 164 7.3 Unsuccessful TLS negotiation . . . . . . 166 7.4 Authentication via Telnet Auth Kerberos 4 after TLS negotiation 168 8 References 170 9 Authors 171 1 Introduction 173 We are interested in addressing the interaction between the Telnet 174 client and server that will support this secure requirement with the 175 knowledge that this is only a portion of the total end-user to 176 application path. Specifically, it is often true that the Telnet server 177 does not reside on the target machine (it does not have access to a list 178 of identities which are allowed to access to that application-server), 179 and it is often true (e.g. 3270 access) that the telnet server can not 180 even identify that portion of the emulation stream which contains user 181 identification/password information. Additionally, it may be the case 182 that the Telnet client is not co-resident with the end user and that it 183 also may be unable to identify that portion of the data stream that deals 184 with user identity. We make the assumption here that there is a trust 185 relationship and appropriate protection to support that relationship 186 between the Telnet Server and the ultimate application engine such that 187 data on this path is protected and that the application will authenticate 188 the end user via the emulation stream as well as use this to control 189 access to information. We further make the assumption that the path 190 between the end user and the client is protected. 192 To hold up the Telnet part of the overall secure path between the user 193 and the application-server, the Telnet data stream must appear 194 unintelligible to a third party. This is done by creating a shared 195 secret between the client and server. This shared secret is used to 196 encrypt the flow of data and (just as important) require the client to 197 verify that it is talking to correct server (the one that the 198 application-server trusts rather than an unintended man-in-the-middle) 199 with the knowledge that the emulation stream itself will be used by the 200 application-server to verify the identity of the end-user. Rather than 201 create a specialized new protocol which accomplishes these goals we 202 instead have chosen to use an existing IETF protocol, Transport Layer 203 Security (TLS) (formerly known as Secure Sockets Layer (SSL)). 205 The Telnet [TELNET] application protocol can certainly benefit from the 206 use of TLS. Since 1992 Telnet has supported over a dozen forms of 207 end user authentication and DES encryption via the AUTH and ENCRYPT 208 options. Since 1995, TLS (as SSL) has been used to provide privacy and 209 integrity protection to Telnet data streams via Telnet AUTH and via 210 dedicated IANA assigned port numbers (telnets 992). TLS offers a broad 211 range of security levels that allow sites to proceed at an "evolutionary" 212 pace in deploying authentication, authorization and confidentiality 213 policies, databases and distribution methods. 215 This document describes how TLS can be used to provide the following: 217 o creation and refresh of a shared secret; 219 o negotiation and execution of data encryption and optional 220 compressesion; 222 o primary negotiation of authentication; and, if chosen 224 o execution of public-key or symmetric-key based authentication. 226 TLS at most offers only authentication of the peers conducting the TLS 227 dialog. In particular, it does not offer the possibility of the client 228 providing separate credentials for authorization than were presented for 229 authentication. After the establishment of peer to peer trust based 230 on TLS, other forms of end user authentication including Telnet AUTH 231 may be used to provide credentials for use in determining end user 232 authorization. 234 Traditional Telnet servers have operated without such early presentation 235 of authorization credentials for many reasons (most of which are 236 historical). However, recent developments in Telnet server technology 237 make it advantageous for the Telnet server to know the authorized 238 capabilities of the remote client before choosing a communications link 239 (be it `pty' or SNA LU) and link-characteristics to the host system (be 240 that "upstream" link local or remote to the server). Thus, we expect to 241 see the use of client authorization to become an important element of the 242 Telnet evolution. Such authorization methods may require certificates 243 presented by the client via TLS, or by the use of Telnet AUTH option, or 244 some other as yet unstandardized method. 246 This document describes the START_TLS telnet option which allows TLS to 247 be activated at the beginning of a Telnet connection using the standard 248 "telnet" port (IANA tcp\23). It also defines a set of advisory security- 249 policy response codes for use when negotiating TLS over Telnet. 251 Conventions Used in this Document 252 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 253 "MAY" in this document are to be interpreted as described in [KEYWORDS]. 255 Formal syntax is defined using ABNF [ABNF]. 257 In examples, "C:" and "S:" indicate lines sent by the the client and 258 server, respectively. 260 2 Command Names and Codes (assigned by IANA) 262 START_TLS 46 (decimal) 264 FOLLOWS 1 (decimal) 266 3 Command Meanings 268 This document makes reference to a "server" and a "client". For the 269 purposes of this document, the "server" is the side of the connection 270 that did the passive TCP open (TCP LISTEN state), and the "client" is 271 the side of the connection that did the active open. 273 IAC DONT START_TLS 275 The sender is either not a server or is not interested in 276 negotiating a TLS connection. 278 IAC WONT START_TLS 280 The sender is either not a client or is not interested in 281 negotiating a TLS connection. 283 IAC DO START_TLS 285 The server side of the connection sends this command to indicate 286 a desire to negotiate a TLS connection. This command MUST NOT 287 be sent by the client and if received by the server MUST be refused 288 with IAC WONT START_TLS. 290 IAC WILL START_TLS 292 The client side of the connection sends this command to indicate 293 a desire to negotiate a TLS connection. This command MUST NOT 294 be sent by the server and if received by the client MUST be refused 295 with IAC DONT START_TLS. 297 IAC SB START_TLS FOLLOWS IAC SE 299 The FOLLOWS sub-command when sent indicates that the next byte of 300 data received after this command MUST be a TLS negotiation as 301 described in [TLS]. This sub-command is sent by both the client and 302 the server. After this sub-command has been sent, the sender MUST NOT 303 respond to nor initiate any additional telnet commands or 304 sub-commands. When this sub-command has been sent and received the 305 TLS negotiation will commence. When sent by a client this sub- 306 command will be followed by a TLS ClientHello. When sent by a server 307 this sub-command will be followed by a TLS ServerHello. 309 3.1 Usage of commands and interactions with other Telnet options 311 The START_TLS option is an asymmetric option, with the server side 312 allowed to send IAC DO START_TLS and the client allowed to send 313 IAC WILL START_TLS. Sub-commands are used to synchronize the link 314 in preparation for negotiating TLS. This synchronization takes 315 the form of a three-way handshake: 317 1. As per normal Telnet option processing rules, the client MUST 318 respond to the server's IAC DO START_TLS with either IAC WONT 319 START_TLS or IAC WILL START_TLS (if it hasn't already done so). 320 Once the client has sent IAC WILL START_TLS and received 321 IAC DO START_TLS, it MUST immediately send a FOLLOWS sub-command 322 (IAC SB START_TLS FOLLOWS IAC SE) to indicate it is ready to begin 323 a TLS negotiation. Once the FOLLOWS sub-command has been sent, the 324 client MUST ignore all telnet negotiations except for the FOLLOWS 325 sub-command. When the FOLLOWS sub-command has been received the 326 client MUST halt use of the telnet protocol, reset the telnet state 327 machine and begin a TLS negotiation by sending a ClientHello message. 329 2. If the client initiates by sending IAC WILL START_TLS, the server 330 MUST respond with either IAC DO START_TLS or IAC DONT START_TLS. 332 3. The server SHOULD NOT send additional Telnet data or commands after 333 sending IAC DO START_TLS except in response to client Telnet options 334 received until after it receives either a negative response from the 335 client (IAC WONT START_TLS) or a successful negotiation of TLS has 336 occurred. If the client's START_TLS option response is negative, the 337 server is free to send additional Telnet data or commands. If the 338 client's response is affirmative (IAC WILL START_TLS), then the server 339 MUST send the FOLLOWS sub-command (IAC SB START_TLS FOLLOWS IAC SE) 340 and await the FOLLOWS sub-command from the client. When the FOLLOWS 341 sub-command has been sent and received the server MUST halt use of the 342 telnet protocol, reset the telnet state machine, and begin a TLS 343 negotiation by sending a TLS ServerHello message. 345 4. If both START_TLS and AUTH [AUTH] are offered, START_TLS SHOULD be sent 346 first and MUST take precedence if both are agreed to. AUTH MAY be 347 renegotiated after successful establishment of the TLS session if 348 end-user authentication via a supported method is desired. 350 5. If a TLS session has been established, the ENCRYPT [ENCRYPT] option 351 MUST NOT be negotiated in either direction. 353 6. When the FOLLOWS sub-command has been sent and received the Telnet 354 state machine is reset. This means that the state of all telnet 355 options is reset to the WONT/DONT state and any data received via 356 subcommands is forgotten. After a sucessful TLS negotiation the 357 Telnet negotiations will be restarted as if a new connection had 358 just been established with one exception. Since TLS is already in 359 use, the START_TLS option MUST NOT be negotiated. 361 3.2 TLS Negotiation Failure 363 The behavior regarding TLS negotiation failure is covered in [TLS], and 364 does not indicate that the TCP connection be broken; the semantics are 365 that TLS is finished and all state variables cleaned up. The TCP connection 366 may be retained. 368 However, it's not clear that either side can detect when the last of the 369 TLS data has arrived. So if TLS negotiation fails, the TCP connection 370 SHOULD be reset and the client MAY reconnect. To avoid infinite loops of 371 TLS negotiation failures, the client MUST remember to not negotiate 372 START_TLS if reconnecting due to a TLS negotiation failure. 374 4 Telnet Authentication and Authorization 376 Telnet servers and clients can be implemented in a variety of ways that 377 impact how clients and servers authenticate and authorize each other. 378 However, most (if not all) the implementations can be abstracted via the 379 following four communicating processes: 381 SES Server End System. This is an application or machine to which client 382 desires a connection. Though not illustrated here, a single Telnet 383 connection between client and server could have multiple SES 384 terminations. 386 Server The Telnet server. 388 Client The Telnet client, which may or may not be co-located with the 389 CES. The Telnet client in fact be a gateway or proxy for downstream 390 clients; it's immaterial. 392 CES Client End System. The system communicating with the Telnet Client. 393 There may be more than one actual CES communicating to a single 394 Telnet Client instance; this is also immaterial to how Client and 395 Server can sucessfully exchange authentication and authorization 396 details. However, see Section 5.4 for a discussion on trust 397 implications. 399 What is of interest here is how the Client and Server can exchange 400 authentication and authorization details such that these components can 401 direct Telnet session traffic to authorized End Systems in a reliable, 402 trustworthy fashion. 404 What is beyond the scope of this specification are several related 405 topics, including: 407 o How the Server and SES are connected, and how they exchange data or 408 information regarding authorization or authentication (if any). 410 o How the Client and CES are connected, and how they exchange data or 411 information regarding authorization or authentication (if any). 413 System-to-system communications using the Telnet protocol have 414 traditionally used no authentication techniques at the Telnet level. 415 More recent techniques have used Telnet to transport authentication 416 exchanges. In none of these systems, however, is a remote system 417 allowed to assume more than one identity once the Telnet preamble 418 negotiation is over and the remote is connected to the application- 419 endpoint. The reason for this is that the local party must in some way 420 inform the end-system of the remote party's identity (and perhaps 421 authorization). This process must take place before the remote party 422 starts communicating with the end-system. At that point it's too late 423 to change what access a client may have to an server end-system: that 424 end-system has been selected, resources have been allocated and 425 capability restrictions set. 427 This process of authentication, authorization and resource allocation 428 can be modeled by the following simple set of states and transitions: 430 `unauthenticated' The local party has not received any credentials 431 offered by the remote. A new Telnet connection starts in this state. 433 The `authenticating' state will be entered from this state if the 434 local party initiates the authentication process of the peer. The 435 Telnet START_TLS negotiation is considered an initiation of the 436 authentication process. 438 The `authorizing' state will be entered from this state either if 439 the local party decides to begin authorization and resource 440 allocation procedures unilaterally...or if the local party has 441 received data from the remote party destined for local end-system. 443 `authenticating' The local party has received at least some of the 444 credentials needed to authenticate its peer, but has not finished 445 the process. 447 The `authenticated' state will be entered from this state if the 448 local party is satisfied with the credentials proferred by the 449 client. 451 The `unauthenticated' state will be entered from this state if the 452 local party cannot verify the credentials proffered by the client or 453 if the client has not proffered any credentials. Alternately, the 454 local party may terminate the Telnet connection instead of returning 455 it to the `unauthenticated' state. 457 `authenticated' The local party has authenticated its peer, but has not 458 yet authorized the client to connect to any end-system resources. 460 The `authenticating' state will be entered from this state if the 461 local party decides that further authentication of the client is 462 warranted. 464 The `authorizing' state will be entered from this state if the local 465 party either initiates authorization dialog with the client (or 466 engages in some process to authorize and allocate resources on 467 behalf of the client), or has received data from the remote party 468 destined for a local end-system. 470 `authorizing' The local party is in the process of authorizing its peer 471 to use end-system resources, or may be in the process of allocating 472 or reserving those resources. 474 The `transfer-ready' state will be entered when the local party is 475 ready to allow data to be passed between the local end-system and 476 remote peer. 478 The `authenticated' state will be entered if the local party 479 determines that the current authorization does not allow any access 480 to a local end-system. If the remote peer is not currently 481 authenticated, then the `unauthenticated' state will be entered 482 instead. 484 `transfer-ready' The party may pass data between the local end-system to 485 its peer. 487 The `authorizing' state will be entered if the local party (perhaps 488 due to a request by the remote peer) deallocates the communications 489 resources to the local-end system. Alternately, the local party may 490 enter the `authenticated' or the `unauthenticated' state. 492 In addition to the "orderly" state transitions noted above, some 493 extraordinary transitions may also occur: 495 1. The absence of a guarantee on the integrity of the data stream 496 between the two Telnet parties also removes the guarantee that the 497 remote peer is who the authentication credentials say the peer is. 498 Thus, upon being notified that the Telnet session is no longer using 499 an integrity layer, the local party must at least deallocate all 500 resources associated with a Telnet connection which would not have 501 been allocable had the remote party never authenticated itself. 503 In practice, this deallocation-of-resources restriction is hard to 504 interpret consistently by both Telnet endpoints. Therefore, both 505 parties MUST return to the initial Telnet state after negotiation of 506 TLS. That is, it is as if the Telnet session had just started. 508 This means that the states may transition from whatever the current 509 state is to `unauthenticated'. Alternately, the local party may 510 break the Telnet connection instead. 512 2. If the local party is notified at any point during the Telnet 513 connection that the remote party's authorizations have been reduced 514 or revoked, then the local party must treat the remote party as being 515 unauthenticated. The local party must deallocate all resources 516 associated with a Telnet connection which would not have been 517 allocable had the remote party never authenticated itself. 519 This too may mean that the states may transition from whatever the 520 current state is to `unauthenticated'. Alternately, the local party 521 may break the Telnet connection instead. 523 The above model explains how each party should handle the authentication 524 and authorization information exchanged during the lifetime of a Telnet 525 connection. It is deliberately fuzzy as to what constitutes internal 526 processes (such as "authorizing") and what is meant by "resources" or 527 "end-system" (such as whether an end-system is strictly a single entity 528 and communications path to the local party, or multiples of each, etc). 530 Here's a state transition diagram, as per [RFC2360]: 532 0 1 2 3 4 533 Events | unauth auth'ing auth'ed authorizing trans-ready 534 -----------+-------------------------------------------------------- 535 auth-needed| sap/1 sap/1 sap/1 sap/1 der,sap/1 536 auth-accept| - ain/2 - - - 537 auth-bad | - 0 wa/0 wa,der/0 der,sap/1 538 authz-start| szp/3 - szp/3 - - 539 data-rcvd | szp/3 qd/1 szp/3 qd/3 pd/4 540 authz-ok | - - - 4 - 541 authz-bad | - - - der/2 wa,der,szp/3 543 Action | Description 544 -------+-------------------------------------------- 545 sap | start authentication process 546 der | deallocate end-system resources 547 ain | authorize if needed 548 szp | start authorization process 549 qd | queue incoming data 550 pd | process data 551 wa | wipe authorization info 553 Event | Description 554 -------------+--------------------------------------------------- 555 auth-needed | authentication deemed needed by local party 556 auth-accept | remote party's authentication creds accepted 557 auth-bad | remote party's authentication creds rejected or expired 558 authz-start | local or remote party starts authorization proceedings 559 data-rcvd | data destined for end-system received from remote party 560 authz-ok | authorization and resource allocation succeeded 561 authz-bad | authorization or resource allocation failed or expired 563 4.1 Authentication of the Server by the Client 565 A secure connection requires that the client be able to authenticate the 566 identity of the server. How the authentication is performed depends 567 upon the TLS cipher agreed upon during the negotiation. As of this 568 writing there are three categories of cipher suites supported by TLS: 569 ciphers supporting X.509 certificates (PKI), non-PKI ciphers, and 570 anonymous ciphers. The following sections detail how Server authentication 571 should be performed by the client for each cipher category. 573 4.1.1 PKI-based Authentication via TLS handshake 575 When a PKI based cipher is negotiated during the TLS negotiation, the 576 server will deliver an X.509 certificate to the client. Before the 577 certificate MAY be used to determine the identity of the server, the 578 certifiicate MUST be validated as per RFC 2459. 580 Once validated the identity of the server is confirmed by matching the DNS 581 name used to access the host with the name stored in the certificate. If 582 the certificate includes the `subjectAltName' extension and it contains a 583 `dNSName' object, then the client MUST use this name as the identity of the 584 server. Otherwise, the (most specific) commonName field in the Subject 585 field if the certificate MUST be used. Note that although the commonName 586 field technique is currently in wide use, it is deprecated. The 587 commonName field may only be used as long as the contents of the field 588 are interpreted as fully qualified domain names. 590 4.1.2 Non-PKI based authentication via TLS handshake 592 As of this writing TLS only supports one non-PKI cipher suite which 593 is based on Kerberos 5. Regardless, any non-PKI cipher suite incorporated 594 into TLS will provide for mutual authentication. Authentication of the 595 server is therefore implied by a successful TLS credential exchange. 597 4.1.3 Authentication by Telnet AUTH option 599 If the TLS exchange used an anonymous cipher such as Anonymous-Diffie- 600 Hellman (ADH) or if the X.509 certificate could not be validated, then 601 the session MUST be protected from a man in the middle attack. This can 602 be accomplished by using a Telnet AUTH [AUTH] method that provides for 603 mutual authentication of the client and server; and which allows the 604 TLS Finished messages sent by the client and the server to be verified. 605 A failure to successfully perform a mutual authentication with Finished 606 message verification via Telnet AUTH MUST result in termination of the 607 connection by the client. 609 4.2 Authentication of the Client by the Server 611 After TLS has been successfully negotiated the server may not have the 612 client's identity (verified or not) since the client is not required to 613 provide credentials during the TLS exchange. Even when the client does 614 provide credentials during the TLS exchange, the server may have a policy 615 that prevents their use. Therefore, the server may not have enough 616 confidence in the client to move the connection to the authenticated state. 618 If further client, server or client-server authentication is going to 619 occur after TLS has been negotiated, it MUST occur before any 620 non-authentication-related Telnet interactions take place on the link 621 after TLS starts. When the first non-authentication-related Telnet 622 interaction is received by either participant, then the receiving 623 participant MAY drop the connection due to dissatisfaction with the 624 level of authentication. 626 If the server wishes to request a client certificate after TLS is 627 initially started (presumably with no client certificate requested), it 628 may do so. However, the server MUST make such a request immediately 629 after the initial TLS handshake is complete. 631 No TLS negotiation outcome, however trustworthy, will by itself provide 632 the server with the authorization identity if that is different from the 633 authentication identity of the client. 635 The following subsections detail how the client can provide the server 636 with authentication and authorization credentials. 638 4.2.1 PKI-based Authentication via TLS handshake 640 PKI-based authentication is used by the client transmitting an X.509 641 certificate to the host during the TLS handshake. There is no standard 642 mechanism defined for how a client certificate should be mapped to a 643 authorization identity (userid). There are several methods currently 644 in wide practice. A telnet server compliant with this document may 645 implement zero, one or more than one of them. 647 The first method is to use information stored within the certificate 648 to determine the authorization identity. If the certificate contains 649 an Common Name object then portions of it can be used as the 650 authorization identity. If the Common Name contains an UID member, 651 then it can be used directly. If the Common Name contains an Email 652 member, then it can be used if the specified domain matches the domain 653 of the telnet server. 655 The second method is to use the entire Subject Name as a entry to 656 lookup in a directory. The directory provides a mapping between the 657 subject name and the authorization identity. 659 The third method is to use the entire certificate as a entry to lookup 660 in a directory with the directory providing a mapping between the 661 certificate and the authorization identity. 663 The first method is only practical if the certificates are being 664 issued by certificate authority managed by the same organization as 665 the server performing the authorization. 667 The second and third methods can be used with certificates issued 668 by public certificate authorities provided the certificates are 669 delivered to the organization performing the authorization in advance 670 via an authenticated method. The second and third methods have the 671 added benefit that the certificates, if issued by the authorizing 672 organization, do not require that any personal information about the 673 subject be included in the certificate. The Subject line could be 674 filled only with gibberish to establish its uniqueness in the 675 directory. 677 4.2.2 Non-PKI Authentication via TLS handshake 679 TLS supports non-PKI authentication methods which can be used for 680 securely establishing authentication identities. As of this writing, 681 TLS supports only one non-PKI authentication method, Kerberos 5. 682 However, it is not unlikely that other authentication methods might be 683 incorporated into TLS ciphers in the future. 685 4.2.3 Telnet AUTH option 687 The Telnet AUTH option implements a variety of authentication methods 688 which can be used to establish authentication and authorization 689 identities. Some methods (e.g., KERBEROS_IV and KERBEROS_V) allow 690 separate authentication and authorization identities to be provided. 691 Details on the use of the Telnet AUTH option and its authentication 692 methods can be found in RFC1416 (about to be obsoleted) and its related 693 documents. For a current list of Telnet AUTH methods see IANA. 695 4.2.4 Traditional Username and Password 697 When all else fails the authorization identity may be provided over 698 the secure TLS connection in the form of a username and password. 700 The Username MAY be transmitted to the host via the Telnet New 701 Environment option's USER variable. 703 5 Security 705 Security is discussed throughout this document. Most of this document 706 concerns itself with wire protocols and security frameworks. But in this 707 section, client and server implementation security issues are in focus. 709 5.1 PKI-based certificate processing 711 A complete discussion of the proper methods for verifying X.509 certificates 712 and their associated certificate chains is beyond the scope of this 713 document. The reader is advised to refer to the RFCs issued by the PKI 714 working group. However, the verification of a certificate MUST include, 715 but isn't limited to, the verification of the signature certificate 716 chain to the point where the a signature in that chain uses a known good 717 signing certificate in the local key chain. The verification 718 SHOULD then continue with a check to see if the fully qualified host name 719 which the client connected to appears anywhere in the server's 720 certificate subject (DN). 722 If the certificate cannot be verified then either: 724 o the end user MUST see a display of the server's certificate and be 725 asked if he/she is willing to proceed with the session; or, 727 o the end user MUST NOT see a display of server's certificate, but the 728 certificate details are logged on whatever media is used to log 729 other session details. This option may be preferred to the first 730 option in environments where the end-user cannot be expected to make 731 an informed decision about whether a mismatch is harmful. The 732 connection MUST be closed automatically by the client UNLESS the 733 client has been configured to explicitly allow all mismatches. 735 o the connection MUST be closed on the user's behalf, and an error 736 describing the mismatch logged to stable storage. 738 If the client side of the service is not interactive with a human 739 end-user, the Telnet connection SHOULD be dropped if this host check 740 fails. 742 5.2 Client and Server authentication of anonymous-TLS connections 744 When authentication is performed after the establishment of a TLS session 745 which uses an anonymous cipher, it is imperative that the authentication 746 method protect against a man in the middle attack by verifying the 747 contents of the client's and server's TLS finished messages. Without 748 the verification of both the client and server's TLS finished messages 749 it is impossible to confirm that there is not a man in the middle 750 listening and perhaps changing all the data transmitted on the 751 connection. 753 5.3 Display of security levels 755 The Telnet client and server MAY, during the TLS protocol negotiation 756 phase, choose to use a weak cipher suite due to policy, law or even 757 convenience. It is, however, important that the choice of weak cipher 758 suite be noted as being commonly known to be vulnerable to attack. In 759 particular, both server and client software should note the choice of 760 weak cipher-suites in the following ways: 762 o If the Telnet endpoint is communicating with a human end-user, the 763 user-interface SHOULD display the choice of weak cipher-suite and 764 the fact that such a cipher-suite may compromise security. 766 o The Telnet endpoints SHOULD log the exact choice of cipher-suite as 767 part of whatever logging/accounting mechanism normally used. 769 5.4 Trust Relationships and Implications 771 Authentication and authorization of the remote Telnet party is useful, 772 but can present dangers to the authorizing party even if the connection 773 between the client and server is protected by TLS using strong 774 encryption and mutual authentication. This is because there are some 775 trust-relationships assumed by one or both parties: 777 o Each side assumes that the authentication and authentication details 778 proferred by the remote party stay constant until explicitly changed 779 (or until the TLS session is ended). 781 o More stringently, each side trusts the other to send a timely 782 notification if authentication or authorization details of the other 783 party's end system(s) have changed. 785 Either of these assumptions about trust may be false if an intruder has 786 breached communications between a client or server and its respective 787 end system. And either may be false if a component is badly implemented 788 or configured. Implementers should take care in program construction to 789 avoid invalidating these trust relationships, and should document to 790 configuring-users the proper ways to configure the software to avoid 791 invalidation of these relationships. 793 5.5 Telnet negotation handling 795 There are two aspects to Telnet negotiation handling that affect the 796 security of the connection. First, given the asynchronous nature 797 of Telnet option negotiations it is possible for a telnet client or 798 server to allow private data to be transmitted over a non-secure 799 link. It is especially important that implementors of this telnet 800 option ensure that no telnet option subnegotiations other than those 801 related to authentication and establishment of security take place over 802 an insecure connection. 804 The second item is related to the most common error when implementing 805 a telnet protocol state machine. Most telnet implementations do not 806 check to ensure that the peer responds to all outstanding requests 807 to change states: WILL, DO, WONT, DONT. It is important that all 808 telnet implementations ensure that requests for state changes are 809 responded to. 811 6 TLS Variants and Options 813 TLS has different versions and different cipher suites that can be 814 supported by client or server implementations. The following 815 subsections detail what TLS extensions and options are mandatory. The 816 subsections also address how TLS variations can be accommodated. 818 6.1 Support of previous versions of TLS 820 TLS has its roots in SSL 2.0 and SSL 3.0. Server and client 821 implementations may wish to support for SSL 3.0 as a fallback in case TLS 822 3.1 or higher is not supported. This is permissible; however, client 823 implementations which negotiate SSL3.0 MUST still follow the rules in 824 Section 5.3 concerning disclosure to the end-user of transport-level 825 security characteristics. 827 Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; it 828 is detailed in [TLS]. SSL 2.0 MUST NOT be negotiated. 830 6.2 Using Kerberos V5 with TLS 832 If the client and server are both amenable to using Kerberos V5, then 833 using non-PKI authentication techniques within the confines of TLS may 834 be acceptable (see [TLSKERB]). Note that clients and servers are under 835 no obligation to support anything but the cipher-suite(s) mandated in 836 [TLS]. However, if implementations do implement the KRB5 authentication 837 as a part of TLS ciphersuite, then these implementations SHOULD support 838 at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite. 840 7 Protocol Examples 842 The following sections provide skeletal examples of how Telnet clients 843 and servers can negotiate TLS. 845 7.1 Successful TLS negotiation 847 The following protocol exchange is the typical sequence that starts TLS: 849 // typical successful opening exchange 850 S: IAC DO START_TLS 851 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 852 S: IAC SB START_TLS FOLLOWS IAC SE 853 // server now readies input stream for non-Telnet, TLS-level negotiation 854 C: [starts TLS-level negotiations with a ClientHello] 855 [TLS transport-level negotiation ensues] 856 [TLS transport-level negotiation completes with a Finished exchanged] 857 // either side now able to send further Telnet data or commands 859 7.2 Successful TLS negotiation, variation 861 The following protocol exchange is the typical sequence that starts TLS, 862 but with the twist that the (TN3270E) server is willing but not 863 aggressive about doing TLS; the client strongly desires doing TLS. 865 // typical successful opening exchange 866 S: IAC DO TN3270E 867 C: IAC WILL START_TLS IAC 868 S: IAC DO START_TLS 869 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 870 S: IAC SB START_TLS FOLLOWS IAC SE 871 // server now readies input stream for non-Telnet, TLS-level negotiation 872 C: [starts TLS-level negotiations with a ClientHello] 873 [TLS transport-level negotiation ensues] 874 [TLS transport-level negotiation completes with a Finished 875 exchanged] 876 // note that server retries negotiation of TN3270E after TLS 877 // is done. 878 S: IAC DO TN3270E 879 C: IAC WILL TN3270E 880 // TN3270E dialog continues.... 882 7.3 Unsuccessful TLS negotiation 884 This example assumes that the server does not wish to allow the Telnet 885 session to proceed without TLS security; however, the client's version 886 of TLS does not interoperate with the server's. 888 //typical unsuccessful opening exchange 889 S: IAC DO START_TLS 890 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 891 S: IAC SB START_TLS FOLLOWS IAC SE 892 // server now readies input stream for non-Telnet, TLS-level negotiation 893 C: [starts TLS-level negotiations with a ClientHello] 894 [TLS transport-level negotiation ensues] 895 [TLS transport-level negotiation fails with server sending 896 ErrorAlert message] 897 S: [TCP level disconnect] 898 // server (or both) initiate TCP session disconnection 900 This example assumes that the server wants to do TLS, but is willing to 901 allow the session to proceed without TLS security; however, the client's 902 version of TLS does not interoperate with the server's. 904 //typical unsuccessful opening exchange 905 S: IAC DO START_TLS 906 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 907 S: IAC SB START_TLS FOLLOWS IAC SE 908 // server now readies input stream for non-Telnet, TLS-level negotiation 909 C: [starts TLS-level negotiations with a ClientHello] 910 [TLS transport-level negotiation ensues] 911 [TLS transport-level negotiation fails with server sending 912 ErrorAlert message] 913 S: [TCP level disconnect] 914 // session is dropped 916 7.4 Authentication via Kerberos 4 after TLS negotiation 918 Here's an implementation example of using Kerberos 4 to authenticate the 919 client after encrypting the session with TLS. Note the following 920 details: 922 o The client strictly enforces a security policy of proposing Telnet 923 AUTH first, but accepting TLS. This has the effect of producing a 924 rather verbose pre-TLS negotiation sequence; however, the 925 end-result is correct. A more efficient pre-TLS sequence can be 926 obtained by changing the client security policy to be the same as the 927 server's for this connection (and implementing policy-aware 928 negotiation code in the Telnet part of the client). 930 A similar efficient result can be obtained even in the absence of a 931 clear client security policy if the client has cached server 932 security preferences from a previous Telnet session to the same 933 server. 935 o The server strictly enforces a security policy of proposing TLS 936 first, but falling back to Telnet AUTH. 938 C: IAC WILL AUTHENTICATION 939 C: IAC WILL NAWS 940 C: IAC WILL TERMINAL-TYPE 941 C: IAC WILL NEW-ENVIRONMENT 942 S: IAC DO START_TLS 943 C: IAC WILL START_TLS 944 C: IAC SB START_TLS FOLLOWS IAC SE 945 S: IAC DO AUTHENTICATION 946 S: IAC DO NAWS 947 S: IAC WILL SUPPRESS-GO-AHEAD 948 S: IAC DO SUPPRESS-GO-AHEAD 949 S: IAC WILL ECHO 950 S: IAC DO TERMINAL-TYPE 951 S: IAC DO NEW-ENVIRONMENT 952 S: IAC SB AUTHENTICATION SEND 953 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ 954 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 955 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY 956 SSL CLIENT_TO_SERVER|ONE_WAY IAC SE 957 S: IAC SB TERMINAL-TYPE SEND IAC SE 958 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 959 S: IAC SB START_TLS FOLLOWS IAC SE 960 [TLS - handshake starting] 961 [TLS - OK] 962 C: IAC WILL AUTHENTICATION 963 C: IAC WILL NAWS 964 C: IAC WILL TERMINAL-TYPE 965 C: IAC WILL NEW-ENVIRONMENT 966 967 S: IAC DO AUTHENTICATION 968 S: IAC DO NAWS 969 S: IAC WILL SUPPRESS-GO-AHEAD 970 C: IAC DO SUPPRESS-GO-AHEAD 971 S: IAC DO SUPPRESS-GO-AHEAD 972 C: IAC WILL SUPPRESS-GO-AHEAD 973 S: IAC WILL ECHO 974 C: IAC DO ECHO 975 S: IAC DO TERMINAL-TYPE 976 S: IAC DO NEW-ENVIRONMENT 977 S: IAC SB AUTHENTICATION SEND 978 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 979 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY IAC SE 980 C: IAC SB AUTHENTICATION NAME jaltman IAC SE 981 C: IAC SB AUTHENTICATION IS 982 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL AUTH 983 04 07 0B "CC.COLUMBIA.EDU" 00 "8(" 0D 9E 9F AB A0 "L" 15 8F A6 984 ED "x" 19 F8 0C "wa" CA "z`" 1A E2 B8 "Y" B0 8E "KkK" C6 AA "<" FF 985 FF 98 89 "|" 90 AC DF 13 "2" FC 8E 97 F7 BD AE "e" 07 82 "n" 19 "v" 986 7F 10 C1 12 B0 C6 "|" FA BB "s1Y" FF FF 10 B5 14 B3 "(" BC 86 "`" 987 D2 "z" AB "Qp" C4 "7" AB "]8" 8A 83 B7 "j" E6 "IK" DE "|YIVN" 988 IAC SE 989 S: IAC SB TERMINAL-TYPE SEND IAC SE 990 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 991 S: IAC SB AUTHENTICATION REPLY 992 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL ACCEPT IAC SE 993 C: IAC SB AUTHENTICATION IS 994 KERBEROS_V4 CLIENT|MUTUAL CHALLENGE "[" BE B7 96 "j" 92 09 "~" IAC SE 995 S: IAC SB AUTHENTICATION REPLY 996 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL RESPONSE "df" B0 D6 "vR_/" IAC SE 997 C: IAC SB TERMINAL-TYPE IS VT320 IAC SE 998 C: IAC SB NEW-ENVIRONMENT IS VAR USER VALUE jaltman VAR SYSTEMTYPE \\ 999 VALUE WIN32 IAC SE 1000 C: IAC SB NAWS 162 49 IAC SE 1002 Here are several things to note about the above example: 1004 o After TLS is successfully negotiated, all non-TLS Telnet settings 1005 are forgotten and must be renegotiated. 1007 o After TLS is successfully negotiated, the server offers all 1008 authentication types that are appropriate for a session using TLS. 1009 Note that the server, post TLS-negotiation, isn't offering Telnet 1010 ENCRYPT or AUTH SSL, since (a) it's useless and perhaps dangerous to 1011 encrypt twice, and (b) TLS and/or SSL can be applied only once to a 1012 Telnet session. 1014 8 References 1016 [ANBF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 1017 Specifications: ABNF", RFC2235, November 1997. 1019 [AUTH] Internet-Draft .... 1021 [ENCRYPT] Internet-Draft .... 1023 [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate 1024 Requirement Levels", RFC2119, March 1997. 1026 [RFC927] Brian A. Anderson. "TACACS User Identification Telnet 1027 Option", RFC927, December 1984 1029 [RFC2360] G. Scott, Editor. "Guide for Internet Standard Writers", 1030 RFC2360, June 1998. 1032 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specifications", 1033 RFC854, May 1983. 1035 [TLS] Tim Dierks, C. Allen. "The TLS Protocol", RFC2246, January 1036 1999. 1038 [TLSKERB] Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher 1039 Suites to Transport Layer Security (TLS)", RFC2712, October 1040 1999. 1042 9 Authors 1044 Michael Boe Jeffrey Altman 1045 Cisco Systems Inc. Columbia University 1046 170 West Tasman Drive 612 West 115th Street 1047 San Jose CA 95134 USA New York NY 10025 USA 1049 Email: mboe@cisco.com jaltman@columbia.edu 1051 Full Copyright Statement 1053 Copyright (c) The Internet Society (1998, 2000). All Rights Reserved. 1055 This document and translations of it may be copied and furnished to 1056 others, and derivative works that comment on or otherwise explain it or 1057 assist in its implementation may be prepared, copied, published and 1058 distributed, in whole or in part, without restriction of any kind, 1059 provided that the above copyright notice and this paragraph are included 1060 on all such copies and derivative works. However, this document itself 1061 may not be modified in any way, such as by removing the copyright notice 1062 or references to the Internet Society or other Internet organizations, 1063 except as needed for the purpose of develop- ing Internet standards in 1064 which case the procedures for copyrights defined in the Internet 1065 Standards process must be followed, or as required to translate it into 1066 languages other than English. 1068 The limited permissions granted above are perpetual and will not be 1069 revoked by the Internet Society or its successors or assigns. 1071 This document and the information contained herein is provided on an "AS 1072 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1073 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1074 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1075 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1076 FITNESS FOR A PARTICULAR PURPOSE. 1078 Acknowledgement 1079 Funding for the RFC Editor function is currently provided by the 1080 Internet Society. 1082 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 1083 The Kermit Project * Columbia University 1084 612 West 115th St #716 * New York, NY * 10025 1085 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org