idnits 2.17.1 draft-ietf-tn3270e-telnet-tls-03.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 1084 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 91 instances of too long lines in the document, the longest one being 3 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 563 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 (March 2001) is 8436 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 1017, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 1020, but no explicit reference was found in the text == Unused Reference: 'RFC927' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'RFC2360' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'TELNET' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'TLSKERB' is defined on line 1035, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2235 (ref. 'ANBF') ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 2 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-03.txt Cisco Systems 3 expires March 2001 4 October, 1999 6 TLS-based Telnet Security 8 Status of this memo 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 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 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Copyright Notice 27 Copyright (C) The Internet Society (1998, 1999). All Rights Reserved. 29 Abstract 30 Telnet service has long been a standard Internet protocol. However, a 31 standard way of ensuring privacy and integrity of Telnet sessions has 32 been lacking. This document proposes a standard method for Telnet 34 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 35 1999 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 -02 Draft 42 o Clarify server actions in response to client initiating the TLS 43 negotiation. 45 o Replace the parochial term "mainframe" with "application-server." 47 o Nuke explicit references to RFC1416, since there's a new RFC in the 48 works for this and the reference isn't normative anyway. 50 o Use dNSName language similar to that used in the most recent HTTP TLS 51 draft. 53 o Delete beginning paragraph describing server-authentication in TLS. 54 Unclear and possibly wrong. 56 o Delete explicit references to SASL, since we don't actually describe 57 ways of using SASL. 59 o Add section describing interaction between AUTH and STARTTLS option 60 negotiations. 62 Changes since -01 Draft 63 o Drop possibility of a continuing a Telnet session if the TLS 64 negotiation fails. 66 o Assert that server sending DO STARTTLS must be willing to negotiate 67 a TLS session 69 o Change SHOULD to MUST with respect to a server requesting a client 70 certificate. 72 o Add paragraph on commonName to section on check of X.509 73 certificate. 75 o Sharpen language concerning notification of possible 76 server-certificate mismatch. 78 o drop place-holder section on Kerberos 5 security; replace with 79 section on non-PKI-based authentication (after TLS negotiation). 81 Michael Boe [Page 82 2] 84 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 85 1999 86 o Prohibit fallback to SSL 2.0. 88 o Give more details about how authentication-after-TLS-negotiation 89 can be achieved. 91 o Simplify post-TLS Telnet negotiation state-assumptions by resetting 92 them to initial-state. 94 Changes since -00 Draft 95 o Add local authentication/authorization operational model. 97 o Change behavior of Telnet machine to reset at start of TLS 98 negotiation. 100 o Insert narrative questioning the utility of allowing continuation of 101 Telnet session after TLS has ended. 103 o change examples to reflect the above changes. 105 o Fix several typos. 107 Michael Boe [Page 108 3] 110 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 111 1999 112 Contents 114 1 Introduction 115 6 116 2 Telnet STARTTLS Option and Subnegotiation 117 8 119 2.1 Abnormal Negotiation Failure . . . . . . 120 9 122 2.2 Assigned Values for STARTTLS Negotiation . . . . 123 9 124 3 Telnet Authentication and Authorization 125 10 126 4 TLS, Authentication and Authorization 127 11 129 4.1 Authentication of the remote party . . . . 130 14 132 4.2 PKI-based Authentication and certificate extensions 133 15 135 4.3 Pre-TLS Authentication . . . . . . . 136 15 137 5 Security 138 16 140 5.1 Authentication of the Server by the Client . . . 141 16 143 5.1.1 PKI-based certificate processing . . . 144 16 146 5.2 Non-PKI-based Authentication of client or server . 147 17 149 5.3 Display of security levels . . . . . . 150 17 152 5.4 Trust Relationships and Implications . . . . 153 17 154 6 TLS Variants and Options 155 18 157 6.1 Support of previous versions of TLS . . . . 158 18 160 6.2 Using Kerberos V5 with TLS . . . . . . 161 18 162 7 Protocol Examples 163 19 165 Michael Boe [Page 166 4] 168 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 169 1999 170 7.1 Successful TLS negotiation . . . . . . 171 19 173 7.2 Successful TLS negotiation, variation . . . . 174 19 176 7.3 Unsuccessful TLS negotiation . . . . . . 177 20 179 7.4 Authentication via Kerberos 4 after TLS negotiation 180 21 182 Michael Boe [Page 183 5] 185 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 186 1999 187 1 Introduction 188 We are interested in addressing the interaction between the Telnet 189 client and server that will support this secure requirement with the 190 knowledge that this is only a portion of the total end-user to 191 application path. Specifically, it is often true that the Telnet server 192 does not reside on the target machine (it does not have access to a list 193 of identities which are allowed to access to that application-server), 194 and it is often true (e.g. 3270 access) that the TN server can not even 195 identify that portion of the emulation stream which contains user 196 identification/password information. Additionally, it may be the case 197 that the Telnet client is not co-resident with the end user and that it 198 also may be unable to identify that portion of the data stream that deals 199 with user identity. We make the assumption here that there is a trust 200 relationship and appropriate protection to support that relationship 201 between the TN Server and the ultimate application engine such that data 202 on this path is protected and that the application will authenticate the 203 end user via the emulation stream as well as use this to control access 204 to information. We further make the assumption that the path between the 205 end user and the client is protected. 207 To hold up the Telnet part of the overall secure path between the user 208 and the application-server, the Telnet data stream must appear 209 unintelligible to a third party. This is done by creating a shared 210 secret between the client and server. This shared secret is used to 211 encrypt the flow of data and (just as important) require the client to 212 verify that it is talking to correct server (the one that the 213 application-server trusts rather than an unintended man-in-the-middle) 214 with the knowledge that the emulation stream itself will be used by the 215 application-server to verify the identity of the end-user. Rather than 216 create a specialized new protocol which accomplishes these goals we 217 instead have chosen to use existing protocols with certain constraints. 219 One such existing protocol is the TLS protocol (formerly known as SSL). 220 And the Telnet [TELNET ] application protocol can certainly benefit from 221 the use of TLS. Other security mechanisms have been used in Telnet via 222 the AUTH and ENCRYPT options, but TLS offers a broad range of security 223 levels that allow sites to proceed at an "evolutionary" pace in 224 deploying authentication, authorization and confidentiality policies, 225 databases and distribution methods. 227 TLS is used to provide the following: 229 o creation and refresh of a shared secret; 231 o negotiation and execution of data encryption and optional 233 Michael Boe [Page 234 6] 236 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 237 1999 238 compressesion; 240 o primary negotiation of authentication; and, if chosen 242 o execution of public-key or symmetric-key based authentication. 244 TLS at most offers only authentication of the peers conducting the TLS 245 dialog. In particular, it does not offer the possibility of the client 246 providing separate credentials for authorization than were presented for 247 authentication. It is expect that other RFCs will be produced describing 248 how other authentication mechanisms can be used in conjunction with TLS. 250 Traditional Telnet servers have operated without such early presentation 251 of authorization credentials for many reasons (most of which are 252 historical). However, recent developments in Telnet server technology 253 make it advantageous for the Telnet server to know the authorized 254 capabilities of the remote client before choosing a communications link 255 (be it `pty' or SNA LU) and link-characteristics to the host system (be 256 that "upstream" link local or remote to the server). Thus, we expect to 257 see the use of client authorization to become an important element of the 258 telnet evolution. Such authorization methods may require certificates 259 presented by the client via TLS, or by the use of Telnet AUTH option, or 260 some other as yet unstandardized method. 262 This document defines extensions to Telnet which allow TLS to be 263 activated early in the lifetime of the Telnet connection. It defines a 264 set of advisory security-policy response codes for use when negotiating 265 TLS over Telnet. 267 Conventions Used in this Document 268 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 269 "MAY" in this document are to be interpreted as described in [KEYWORDS ]. 271 Formal syntax is defined using ABNF [ANBF ]. 273 In examples, "C:" and "S:" indicate lines sent by the the client and 274 server, respectively. 276 Michael Boe [Page 277 7] 279 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 280 1999 281 2 Telnet STARTTLS Option and Subnegotiation 282 The STARTTLS option is an asymmetric option, with only the server side 283 being able to send IAC DO STARTTLS. The client may initiate by sending 284 IAC WILL STARTTLS. There are some more rules due to the need to clear the 285 link of data (or to synchronize the link). This synchronization takes 286 the form of a three-way handshake: 288 1. As per normal Telnet option processing rules, the client MUST 289 respond to the server's IAC DO STARTTLS with either IAC WONT 290 STARTTLS or IAC WILL STARTTLS (if it hasn't already done so). An 291 affirmative response MUST be followed immediately by IAC SB STARTTLS 292 FOLLOWS IAC SE. If the client sends the affirmative response, it 293 must then not initiate any further Telnet options or subnegotiations 294 except for the STARTTLS subnegotiation until after the TLS 295 negotiation has completed. 297 2. If the client initiates by sending IAC WILL STARTTLS, the server 298 SHOULD send the IAC DO STARTTLS as soon as practical. 300 3. The server SHOULD NOT send any more Telnet data or commands after 301 sending IAC DO STARTTLS except in response to client Telnet options 302 received until after it receives either a negative response from the 303 client (IAC WONT STARTTLS) or the affirmative (both IAC WILL 304 STARTTLS and followed eventually by IAC SB STARTTLS FOLLOWS IAC SE). 305 If the client's STARTTLS option response is negative, the server is 306 free to again send Telnet data or commands. If the client's response 307 is affirmative, then the server MUST send only IAC SB STARTTLS 308 FOLLOWS IAC SE. If the server sends IAC SB STARTTLS FOLLOWS IAC SE, 309 then the server MUST also arrange at this time, for the normal Telnet 310 byte-stuff/destuff processing to be turned off for the duration of 311 the TLS negotiation. 313 4. If both STARTTLS and AUTH are offered, STARTTLS MUST be sent first 314 and take precedence if both are agreed to. AUTH may be renegotiated 315 after successful establishment of the TLS session if end-user 316 authentication is desired. 318 5. The client, upon receipt of the server's IAC SB STARTTLS FOLLOWS IAC 319 SE, MUST also arrange for normal Telnet byte-stuff/destuff 320 processing to be turned off for the duration of the TLS negotiation. 321 It MUST then enter into TLS negotiation by sending the TLS 322 ClientHello message. 324 Here's a breakdown of the Telnet command phrases defined in this 325 document: 327 Michael Boe [Page 328 8] 330 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 331 1999 332 S: IAC DO STARTTLS-- Sent only by server. Indicates that server strongly 333 desires that the client enter into TLS negotiations. 335 C: IAC WILL STARTTLS-- Sent only by client. Indicates that client 336 strongly desires that the server enter into TLS negotiations. 338 S: IAC DONT STARTTLS-- Sent only by the server. Indicates that the 339 server is not willing to enter into TLS negotations. 341 C: IAC WONT STARTTLS-- Sent only by the client. Indicates that the 342 client is not willing to enter into TLS negotiations. 344 C: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the client, this 345 indicates that the client is preparing for TLS negotiations, and 346 that the next thing sent by the client will be the TLS ClientHello. 347 Also indicates that the client has reset its Telnet state. 349 S: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the server, this 350 indicates that the server has prepared to receive the TLS 351 ClientHello from the client. Also indicates that the server has 352 reset its Telnet state. 354 2.1 Abnormal Negotiation Failure 356 The behavior regarding TLS negotiation failure is covered in [TLS ], and 357 does not indicate that the TCP connection be broken; the semantics are 358 that TLS is finished and all state variables cleaned up. The TCP 359 connection may be retained. 361 However, it's not clear that either side can detect when the last of the 362 TLS data has arrived. So if TLS negotiation fails, the TCP connection 363 SHOULD be reset and the client MAY reconnect. To avoid infinite loops of 364 TLS negotiation failures, the client MUST remember to not negotiate TLS 365 upon reconnecting after a TLS negotiation failure. 367 2.2 Assigned Values for STARTTLS Negotiation 369 The assigned value of the Telnet STARTTLS option octet is 46. The 370 assigned value of the FOLLOWS subnegotiation octet is 1. In ABNF, this 371 is: 373 STARTTLS = %d46 374 FOLLOWS = %d1 376 Michael Boe [Page 377 9] 379 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 380 1999 381 3 Telnet Authentication and Authorization 382 Telnet servers and clients can be implemented in a variety of ways that 383 impact how clients and servers authenticate and authorize each other. 384 However, most (if not all) the implementations can be abstracted via the 385 following four communicating processes: 387 SES Server End System. This is an application or machine to which client 388 desires a connection. Though not illustrated here, a single Telnet 389 connection between client and server could have multiple SES 390 terminations. 392 Server The Telnet server. 394 Client The Telnet client, which may or may not be co-located with the 395 CES. The Telnet client in fact be a gateway or proxy for downstream 396 clients; it's immaterial. 398 CES Client End System. The system communicating with the Telnet Client. 399 There may be more than one actual CES communicating to a single 400 Telnet Client instance; this is also immaterial to how Client and 401 Server can sucessfully exchange authentication and authorization 402 details. However, see Section 5.4 for a discussion on trust 403 implications. 405 What is of interest here is how the Client and Server can exchange 406 authentication and authorization details such that these components can 407 direct Telnet session traffic to authorized End Systems in a reliable, 408 trustworthy fashion. 410 What is beyond the scope of this specification are several related 411 topics, including: 413 o How the Server and SES are connected, and how they exchange data or 414 information regarding authorization or authentication (if any). 416 o How the Client and CES are connected, and how they exchange data or 417 information regarding authorization or authentication (if any). 418 Michael Boe [Page 419 10] 421 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 422 1999 423 4 TLS, Authentication and Authorization 424 System-to-system communications using the Telnet protocol have 425 traditionally used no authentication techniques at the Telnet level. 426 More recent techniques have used Telnet to transport authentication 427 exchanges (e.g.[TLSKERB ] or Telnet AUTH). In none of these systems, 428 however, is a remote system allowed to assume more than one identity once 429 the Telnet preamble negotiation is over and the remote is connected to 430 the application-endpoint. The reason for this is that the local party 431 must in some way inform the end-system of the remote party's identity 432 (and perhaps authorization). This process must take place before the 433 remote party starts communicating with the end-system. At that point 434 it's too late to change what access a client may have to an server 435 end-system: that end-system has been selected, resources have been 436 allocated and capability restrictions set. 438 [Author's note: I dislike providing state models of how local systems 439 should behave in relation to a wire protocol; it seems to me that such 440 models often do more harm than good when describing a wire protocol. The 441 model often misrepresents reality, and/or makes unnecessarily limiting 442 assumptions about implementation behavior. However, the alternative 443 methods of explanation seemed even less useful in this case....] 445 This process of authentication, authorization and resource allocation 446 can be modeled (one hopes!) by the following simple set of states and 447 transitions: 449 `unauthenticated' The local party has not received any credentials 450 offered by the remote. A new Telnet connection starts in this state. 452 The `authenticating' state will be entered from this state if the 453 local party initiates the authentication process of the peer. The 454 Telnet STARTTLS negotiation is considered an initiation of the 455 authentication process. 457 The `authorizing' state will be entered from this state either if 458 the local party decides to begin authorization and resource 459 allocation procedures unilaterally...or if the local party has 460 received data from the remote party destined for local end-system. 462 `authenticating' The local party has received at least some of the 463 credentials needed to authenticate its peer, but has not finished 464 the process. 466 The `authenticated' state will be entered from this state if the 467 local party is satisfied with the credentials proferred by the 468 client. 470 Michael Boe [Page 471 11] 473 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 474 1999 475 The `unauthenticated' state will be entered from this state if the 476 local party cannot verify the credentials proffered by the client or 477 if the client has not proffered any credentials. Alternately, the 478 local party may terminate the Telnet connection instead of returning 479 it to the `unauthenticated' state. 481 `authenticated' The local party has authenticated its peer, but has not 482 yet authorized the client to connect to any end-system resources. 484 The `authenticating' state will be entered from this state if the 485 local party decides that further authentication of the client is 486 warranted. 488 The `authorizing' state will be entered from this state if the local 489 party either initiates authorization dialog with the client (or 490 engages in some process to authorize and allocate resources on 491 behalf of the client), or has received data from the remote party 492 destined for a local end-system. 494 `authorizing' The local party is in the process of authorizing its peer 495 to use end-system resources, or may be in the process of allocating 496 or reserving those resources. 498 The `transfer-ready' state will be entered when the local party is 499 ready to allow data to be passed between the local end-system and 500 remote peer. 502 The `authenticated' state will be entered if the local party 503 determines that the current authorization does not allow any access 504 to a local end-system. If the remote peer is not currently 505 authenticated, then the `unauthenticated' state will be entered 506 instead. 508 `transfer-ready' The party may pass data between the local end-system to 509 its peer. 511 The `authorizing' state will be entered if the local party (perhaps 512 due to a request by the remote peer) deallocates the communications 513 resources to the local-end system. Alternately, the local party may 514 enter the `authenticated' or the `unauthenticated' state. 516 In addition to the "orderly" state transitions noted above, some 517 extraordinary transitions may also occur: 519 1. The absence of a guarantee on the integrity of the data stream 520 between the two Telnet parties also removes the guarantee that the 521 remote peer is who the authentication credentials say the peer is. 522 Thus, upon being notified that the Telnet session is no longer using 523 an integrity layer, the local party must at least deallocate all 525 Michael Boe [Page 526 12] 528 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 529 1999 530 resources associated with a Telnet connection which would not have 531 been allocable had the remote party never authenticated itself. 533 In practice, this deallocation-of-resources restriction is hard to 534 interpret consistently by both Telnet endpoints. Therefore, both 535 parties MUST return to the initial Telnet state after negotiation of 536 TLS. That is, it is as if the Telnet session had just started. 538 This means that the states may transition from whatever the current 539 state is to `unauthenticated'. Alternately, the local party may 540 break the Telnet connection instead. 542 2. If the local party is notified at any point during the Telnet 543 connection that the remote party's authorizations have been reduced 544 or revoked, then the local party must treat the remote party as being 545 unauthenticated. The local party must deallocate all resources 546 associated with a Telnet connection which would not have been 547 allocable had the remote party never authenticated itself. 549 This too may mean that the states may transition from whatever the 550 current state is to `unauthenticated'. Alternately, the local party 551 may break the Telnet connection instead. 553 The above model explains how each party should handle the authentication 554 and authorization information exchanged during the lifetime of a Telnet 555 connection. It is deliberately fuzzy as to what constitutes internal 556 processes (such as "authorizing") and what is meant by "resources" or 557 "end-system" (such as whether an end-system is strictly a single entity 558 and communications path to the local party, or multiples of each, etc). 560 Here's a state transition diagram, as per [RFC2360 ]: 562 0 1 2 3 4 563 Events | unauth auth'ing auth'ed authorizing trans-ready 564 -----------+-------------------------------------------------------- 565 auth-needed| sap/1 sap/1 sap/1 sap/1 der,sap/1 566 auth-accept| - ain/2 - - - 567 auth-bad | - 0 wa/0 wa,der/0 der,sap/1 568 authz-start| szp/3 - szp/3 - - 569 data-rcvd | szp/3 qd/1 szp/3 qd/3 pd/4 570 authz-ok | - - - 4 - 571 authz-bad | - - - der/2 wa,der,szp/3 573 Action | Description 574 -------+-------------------------------------------- 576 Michael Boe [Page 577 13] 579 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 580 1999 581 sap | start authentication process 582 der | deallocate end-system resources 583 ain | authorize if needed 584 szp | start authorization process 585 qd | queue incoming data 586 pd | process data 587 wa | wipe authorization info 589 Event | Description 590 -------------+--------------------------------------------------- 591 auth-needed | authentication deemed needed by local party 592 auth-accept | remote party's authentication creds accepted 593 auth-bad | remote party's authentication creds rejected or expired 594 authz-start | local or remote party starts authorization proceedings 595 data-rcvd | data destined for end-system received from remote party 596 authz-ok | authorization and resource allocation succeeded 597 authz-bad | authorization or resource allocation failed or expired 599 4.1 Authentication of the remote party 601 If TLS has been successfully negotiated, the client will have the 602 server's certificate. This indicates that the server's identity can be 603 verified. Client implementations MUST always verify the server identity 604 as part of TLS processing and fail the connection if such verification 605 fails, unless Telnet AUTH will be used to perform mutual authentication 606 and verification of the session key. See Section 5.1 for a general 607 discussion of the server authentication apropos Telnet clients. 609 The server, however, may not have the client's identity (verified or 610 not). This is because the client need not provide a certificate during 611 the TLS exchange. Or it may be server site policy not to use the identity 612 so provided. In any case, the server may not have enough confidence in 613 the client to move the connection to the authenticated state. 615 If further client, server or client-server authentication is going to 616 occur after TLS has been negotiated, it MUST occur before any 617 non-authentication-related Telnet interactions take place on the link 618 after TLS starts. When the first non-authentication-related Telnet 619 interaction is received by either participant, then the receiving 620 participant MAY drop the connection due to dissatisfaction with the 621 level of authentication. 623 If the server wishes to request a client certificate after TLS is 625 Michael Boe [Page 626 14] 628 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 629 1999 630 initially started (presumably with no client certificate requested), it 631 may do so. However, the server MUST make such a request immediately 632 after the initial TLS handshake is complete. 634 No TLS negotiation outcome, however trustworthy, will by itself provide 635 the server with the authorization identity if that is different from the 636 authentication identity of the client. 638 The following subsections detail how the client can provide the server 639 with authentication and authorization credentials separate to the TLS 640 mechanism. 642 4.2 PKI-based Authentication and certificate extensions 644 When PKI authentication is used no special X.509 certificate extensions 645 will be require but a client or server may choose to support an extension 646 if found. For example, they may use a contained certificate revocation 647 URL extension if provided. The intent is to allow sharing of 648 certificates with other services on the same host, for example, a Telnet 649 server might use the same certificate to identify itself that a 650 co-located WEB server uses. The method of sharing certificates is 651 outside the scope of this document. 653 An X.509 certificate received by a client may include the 654 `subjectAltName' extension. If this extension is present and contains a 655 `dNSName' object, then the client MUST be used as the identity. 656 Otherwise, the (most specific) Common Name field in the Subject field fo 657 the certificate MUST be used. Note that the Common Name field technique 658 is currently used, it is deprecated. 660 If the subjectAltName extension is not present, then the client may use 661 the commonName field as long as the contents of the field are interpreted 662 as fully qualified domain names. 664 4.3 Pre-TLS Authentication 666 It could be that the server had moved the Telnet connection to the 667 authenticated state sometime previous to the negotiation of TLS. If this 668 is the case, then the server MUST NOT use the credentials proffered by 669 the client during the TLS negotiations for authorization of that client. 670 The server should, of course, verify the client's TLS-proffered 671 credentials. 673 Michael Boe [Page 674 15] 676 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 677 1999 678 Note that such an authenticated state could not have resulted from 679 previous data exchanged on this Telnet session, and must have been 680 authenticated via some other means. 682 5 Security 683 Security is discussed throughout this document. Most of this document 684 concerns itself with wire protocols and security frameworks. But in this 685 section, client and server implementation security issues are in focus. 687 5.1 Authentication of the Server by the Client 689 How the client can verify the server's proferred identity varies 690 according to the key-exchange algorithm used in the selected TLS 691 cipher-suite. However, it's important for the client to follow good 692 security practice in verifying the proffered identity of the server. 694 5.1.1 PKI-based certificate processing 696 The verification of the server's certificate by the client MUST include, 697 but isn't limited to, the verification of the signature certificate 698 chain to the point where the a signature in that chain uses a known good 699 signing certificate in the clients local key chain. The verification 700 SHOULD then continue with a check to see if the fully qualified host name 701 which the client connected to appears anywhere in the server's 702 certificate subject (DN). If no match is found then either: 704 o the end user MUST see a display of the server's certificate and be 705 asked if he/she is willing to proceed with the session; or, 707 o the end user MUST NOT see a display of server's certificate, but the 708 certificate details are logged on whatever media is used to log 709 other session details. This option may be preferred to the first 710 option in environments where the end-user cannot be expected to make 711 an informed decision about whether a mismatch is harmful. The 712 connection MUST be closed automatically by the client UNLESS the 713 client has been configured to explicitly allow all mismatches. 715 o the connection MUST be closed on the user's behalf, and an error 716 describing the mismatch logged to stable storage. 718 Michael Boe [Page 719 16] 721 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 722 1999 723 If the client side of the service is not interactive with a human 724 end-user, the Telnet connection SHOULD be dropped if this host check 725 fails. 727 5.2 Non-PKI-based Authentication of client or server 729 Authentication of the client (or further mutual authentication between 730 client and server) can be accomplished via non-PKI means, too. 731 Implementors should be careful to remember that authentication must 732 occur after successful TLS session negotiation where the shared secret 733 is verified. Further, the timing of the authentication MUST be as per 734 Section 4. 736 Practically speaking, this means that non-TLS authentication MUST 737 immediately follow the TLS negotiation. See 7.4 for an example of how 738 this can work. 740 5.3 Display of security levels 742 The Telnet client and server MAY, during the TLS protocol negotiation 743 phase, choose to use a weak cipher suite due to policy, law or even 744 convenience. It is, however, important that the choice of weak cipher 745 suite be noted as being commonly known to be vulnerable to attack. In 746 particular, both server and client software should note the choice of 747 weak cipher-suites in the following ways: 749 o If the Telnet endpoint is communicating with a human end-user, the 750 user-interface SHOULD display the choice of weak cipher-suite and 751 the fact that such a cipher-suite may compromise security. 753 o The Telnet endpoints SHOULD log the exact choice of cipher-suite as 754 part of whatever logging/accounting mechanism normally used. 756 5.4 Trust Relationships and Implications 758 Authentication and authorization of the remote Telnet party is useful, 759 but can present dangers to the authorizing party even if the connection 760 between the client and server is protected by TLS using strong 761 encryption and mutual authentication. This is because there are some 762 trust-relationships assumed by one or both parties: 764 Michael Boe [Page 765 17] 767 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 768 1999 769 o Each side assumes that the authentication and authentication details 770 proferred by the remote party stay constant until explicitly changed 771 (or until the TLS session is ended). 773 o More stringently, each side trusts the other to send a timely 774 notification if authentication or authorization details of the other 775 party's end system(s) have changed. 777 Either of these assumptions about trust may be false if an intruder has 778 breached communications between a client or server and its respective 779 end system. And either may be false if a component is badly implemented 780 or configured. Implementers should take care in program construction to 781 avoid invalidating these trust relationships, and should document to 782 configuring-users the proper ways to configure the software to avoid 783 invalidation of these relationships. 785 6 TLS Variants and Options 786 TLS has different versions and different cipher suites that can be 787 supported by client or server implementations. The following 788 subsections detail what TLS extensions and options are mandatory. The 789 subsections also address how TLS variations can be accommodated. 791 6.1 Support of previous versions of TLS 793 TLS has its roots in SSL 2.0 and SSL 3.0. Server and client 794 implementations may wish to support for SSL 3.0 as a fallback in case TLS 795 3.1 or higher is not supported. This is permissible; however, client 796 implementations which negotiate SSL3.0 MUST still follow the rules in 797 Section 5.3 concerning disclosure to the end-user of transport-level 798 security characteristics. 800 Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; it 801 is detailed in [TLS ]. Negotiating SSL 2.0 MUST NOT be attempted. 803 6.2 Using Kerberos V5 with TLS 805 If the client and server are both amenable to using Kerberos V5, then 806 using non-PKI authentication techniques within the confines of TLS may 808 Michael Boe [Page 809 18] 811 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 812 1999 813 be acceptable (see [TLSKERB ]). Note that clients and servers are under 814 no obligation to support anything but the cipher-suite(s) mandated in 815 [TLS ]. However, if implementations do implement the KRB5 authentication 816 as a part of TLS ciphersuite, then these implementations SHOULD support 817 at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite. 819 7 Protocol Examples 820 The following sections provide skeletal examples of how Telnet clients 821 and servers can negotiate TLS. 823 7.1 Successful TLS negotiation 825 The following protocol exchange is the typical sequence that starts TLS: 827 // typical successful opening exchange 828 S: IAC DO STARTTLS 829 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 830 S: IAC SB STARTTLS FOLLOWS IAC SE 831 // server now readies input stream for non-Telnet, TLS-level negotiation 832 C: [starts TLS-level negotiations with a ClientHello] 833 [TLS transport-level negotiation ensues] 834 [TLS transport-level negotiation completes with a Finished exchanged] 835 // either side now able to send further Telnet data or commands 837 7.2 Successful TLS negotiation, variation 839 The following protocol exchange is the typical sequence that starts TLS, 840 but with the twist that the (TN3270E) server is willing but not 841 aggressive about doing TLS; the client strongly desires doing TLS. 843 // typical successful opening exchange 844 S: IAC DO TN3270E 845 C: IAC WILL STARTTLS IAC 846 S: IAC DO STARTTLS 847 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 848 S: IAC SB STARTTLS FOLLOWS IAC SE 850 Michael Boe [Page 851 19] 853 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 854 1999 855 // server now readies input stream for non-Telnet, TLS-level negotiation 856 C: [starts TLS-level negotiations with a ClientHello] 857 [TLS transport-level negotiation ensues] 858 [TLS transport-level negotiation completes with a Finished 859 exchanged] 860 // note that server retries negotiation of TN3270E after TLS 861 // is done. 862 S: IAC DO TN3270E 863 C: IAC WILL TN3270E 864 // TN3270E dialog continues.... 866 7.3 Unsuccessful TLS negotiation 868 This example assumes that the server does not wish to allow the Telnet 869 session to proceed without TLS security; however, the client's version 870 of TLS does not interoperate with the server's. 872 //typical unsuccessful opening exchange 873 S: IAC DO STARTTLS 874 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 875 S: IAC SB STARTTLS FOLLOWS IAC SE 876 // server now readies input stream for non-Telnet, TLS-level negotiation 877 C: [starts TLS-level negotiations with a ClientHello] 878 [TLS transport-level negotiation ensues] 879 [TLS transport-level negotiation fails with server sending 880 ErrorAlert message] 881 S: [TCP level disconnect] 882 // server (or both) initiate TCP session disconnection 884 This example assumes that the server wants to do TLS, but is willing to 885 allow the session to proceed without TLS security; however, the client's 886 version of TLS does not interoperate with the server's. 888 //typical unsuccessful opening exchange 889 S: IAC DO STARTTLS 890 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 891 S: IAC SB STARTTLS 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 897 Michael Boe [Page 898 20] 900 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 901 1999 902 ErrorAlert message] 903 S: [TCP level disconnect] 904 // session is dropped 906 7.4 Authentication via Kerberos 4 after TLS negotiation 908 Here's an implementation example of using Kerberos 4 to authenticate the 909 client after encrypting the session with TLS. Note the following 910 details: 912 o The client strictly enforces a security policy of proposing Telnet 913 AUTH first, but accepting TLS. This has the effect of producing a 914 rather verbose pre-TLS negotiation sequence; however, the 915 end-result is correct. A more efficient pre-TLS sequence can be 916 obtained by changing the client security policy to be the same as the 917 server's for this connection (and implementing policy-aware 918 negotiation code in the Telnet part of the client). 920 A similar efficient result can be obtained even in the absence of a 921 clear client security policy if the client has cached server 922 security preferences from a previous Telnet session to the same 923 server. 925 o The server strictly enforces a security policy of proposing TLS 926 first, but falling back to Telnet AUTH. 928 C: IAC WILL AUTHENTICATION 929 C: IAC WILL NAWS 930 C: IAC WILL TERMINAL-TYPE 931 C: IAC WILL NEW-ENVIRONMENT 932 S: IAC DO STARTTLS 933 C: IAC WILL STARTTLS 934 C: IAC SB STARTTLS FOLLOWS IAC SE 935 S: IAC DO AUTHENTICATION 936 S: IAC DO NAWS 937 S: IAC WILL SUPPRESS-GO-AHEAD 938 S: IAC DO SUPPRESS-GO-AHEAD 939 S: IAC WILL ECHO 940 S: IAC DO TERMINAL-TYPE 941 S: IAC DO NEW-ENVIRONMENT 942 S: IAC SB AUTHENTICATION SEND 943 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ 944 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 946 Michael Boe [Page 947 21] 949 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 950 1999 951 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY 952 SSL CLIENT_TO_SERVER|ONE_WAY IAC SE 953 S: IAC SB TERMINAL-TYPE SEND IAC SE 954 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 955 S: IAC SB STARTTLS FOLLOWS IAC SE 956 [TLS - handshake starting] 957 [TLS - OK] 958 C: IAC WILL AUTHENTICATION 959 C: IAC WILL NAWS 960 C: IAC WILL TERMINAL-TYPE 961 C: IAC WILL NEW-ENVIRONMENT 962 963 S: IAC DO AUTHENTICATION 964 S: IAC DO NAWS 965 S: IAC WILL SUPPRESS-GO-AHEAD 966 C: IAC DO SUPPRESS-GO-AHEAD 967 S: IAC DO SUPPRESS-GO-AHEAD 968 C: IAC WILL SUPPRESS-GO-AHEAD 969 S: IAC WILL ECHO 970 C: IAC DO ECHO 971 S: IAC DO TERMINAL-TYPE 972 S: IAC DO NEW-ENVIRONMENT 973 S: IAC SB AUTHENTICATION SEND 974 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 975 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY IAC SE 976 C: IAC SB AUTHENTICATION NAME jaltman IAC SE 977 C: IAC SB AUTHENTICATION IS 978 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL AUTH 979 04 07 0B "CC.COLUMBIA.EDU" 00 "8(" 0D 9E 9F AB A0 "L" 15 8F A6 980 ED "x" 19 F8 0C "wa" CA "z`" 1A E2 B8 "Y" B0 8E "KkK" C6 AA "<" FF 981 FF 98 89 "|" 90 AC DF 13 "2" FC 8E 97 F7 BD AE "e" 07 82 "n" 19 "v" 982 7F 10 C1 12 B0 C6 "|" FA BB "s1Y" FF FF 10 B5 14 B3 "(" BC 86 "`" 983 D2 "z" AB "Qp" C4 "7" AB "]8" 8A 83 B7 "j" E6 "IK" DE "|YIVN" 984 IAC SE 985 S: IAC SB TERMINAL-TYPE SEND IAC SE 986 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 987 S: IAC SB AUTHENTICATION REPLY 988 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL ACCEPT IAC SE 989 C: IAC SB AUTHENTICATION IS 990 KERBEROS_V4 CLIENT|MUTUAL CHALLENGE "[" BE B7 96 "j" 92 09 "~" IAC SE 991 S: IAC SB AUTHENTICATION REPLY 992 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL RESPONSE "df" B0 D6 "vR_/" IAC SE 993 994 C: IAC SB TERMINAL-TYPE IS VT320 IAC SE 995 C: IAC SB NEW-ENVIRONMENT IS VAR USER VALUE jaltman VAR SYSTEMTYPE \\ 996 VALUE WIN32 IAC SE 997 C: IAC SB NAWS 162 49 IAC SE 999 Michael Boe [Page 1000 22] 1002 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 1003 1999 1004 Here are several things to note about the above example: 1006 o After TLS is successfully negotiated, all non-TLS Telnet settings 1007 are forgotten and must be renegotiated. 1009 o After TLS is successfully negotiated, the server offers all 1010 authentication types that are appropriate for a session using TLS. 1011 Note that the server, post TLS-negotiation, isn't offering Telnet 1012 ENCRYPT or AUTH SSL, since (a) it's useless and perhaps dangerous to 1013 encrypt twice, and (b) TLS and/or SSL can be applied only once to a 1014 Telnet session. 1016 References 1017 [ANBF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 1018 Specifications: ABNF", RFC2235, November 1997. 1020 [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate 1021 Requirement Levels", RFC2119, March 1997. 1023 [RFC927] Brian A. Anderson. "TACACS User Identification Telnet 1024 Option", RFC927, December 1984 1026 [RFC2360] G. Scott, Editor. "Guide for Internet Standard Writers", 1027 RFC2360, June 1998. 1029 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specifications", 1030 RFC854, May 1983. 1032 [TLS] Tim Dierks, C. Allen. "The TLS Protocol", RFC2246, January 1033 1999. 1035 [TLSKERB] Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher 1036 Suites to Transport Layer Security (TLS)", RFC2712, October 1037 1999. 1039 Author's Address 1040 Michael Boe 1041 Cisco Systems Inc. 1042 170 West Tasman Drive 1043 San Jose, CA 95134 1045 Email: Michael Boe 1047 Michael Boe [Page 1048 23] 1050 I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security October, 1051 1999 1052 Full Copyright Statement 1053 Copyright (c) The Internet Society (1998, 1999). 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 Michael Boe [Page 1083 24]