idnits 2.17.1 draft-ietf-tn3270e-telnet-tls-02.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 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 9 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 471 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 (January 2000) is 8868 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 888, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC927' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'RFC1416' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'SASL' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'RFC2360' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'TELNET' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'TLSKERB' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'TLSHTTP' is defined on line 917, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2235 (ref. 'ANBF') ** Obsolete normative reference: RFC 1416 (Obsoleted by RFC 2941) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSKERB' -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSHTTP' Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 5 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-02.txt Cisco Systems 3 expires January 2000 4 July, 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 33 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 34 servers and clients to use the Transport Layer Security (TLS) protocol. 35 It describes how two Telnet participants can decide whether or not to 36 attempt TLS negotiation, and how the two participants should process 37 authentication credentials exchanged as a part of TLS startup. 39 Changes since -01 Draft 40 o Drop possibility of a continuing a Telnet session if the TLS 41 negotiation fails. 43 o Assert that server sending DO STARTTLS must be willing to negotiate 44 a TLS session 46 o Change SHOULD to MUST with respect to a server requesting a client 47 certificate. 49 o Add paragraph on commonName to section on check of X.509 50 certificate. 52 o Sharpen language concerning notification of possible 53 server-certificate mismatch. 55 o drop place-holder section on Kerberos 5 security; replace with 56 section on non-PKI-based authentication (after TLS negotiation). 58 o Prohibit fallback to SSL 2.0. 60 o Give more details about how authentication-after-TLS-negotiation 61 can be achieved. 63 o Simplify post-TLS Telnet negotiation state-assumptions by resetting 64 them to initial-state. 66 Changes since -00 Draft 67 o Add local authentication/authorization operational model. 69 o Change behavior of Telnet machine to reset at start of TLS 70 negotiation. 72 o Insert narrative questioning the utility of allowing continuation of 73 Telnet session after TLS has ended. 75 o change examples to reflect the above changes. 77 o Fix several typos. 79 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 80 Contents 82 1 Introduction 5 83 2 Telnet STARTTLS Option and Subnegotiation 7 85 2.1 Abnormal Negotiation Failure . . . . . . 8 87 2.2 Assigned Values for STARTTLS Negotiation . . . 8 88 3 Telnet Authentication and Authorization 8 89 4 TLS, Authentication and Authorization 9 91 4.1 Authentication of the remote party . . . . 13 93 4.2 PKI-based Authentication and certificate extensions 14 95 4.3 Pre-TLS Authentication . . . . . . . 14 96 5 Security 15 98 5.1 Authentication of the Server by the Client . . . 15 100 5.1.1 PKI-based certificate processing . . . 15 102 5.2 Non-PKI-based Authentication of client or server . 16 104 5.3 Display of security levels . . . . . . 16 106 5.4 Trust Relationships and Implications . . . . 17 107 6 TLS Variants and Options 17 109 6.1 Support of previous versions of TLS . . . . 17 111 6.2 Using Kerberos V5 with TLS . . . . . . 18 112 7 Protocol Examples 18 113 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 114 7.1 Successful TLS negotiation . . . . . . 18 116 7.2 Successful TLS negotiation, variation . . . . 18 118 7.3 Unsuccessful TLS negotiation . . . . . . 19 120 7.4 Authentication via Kerberos 4 after TLS negotiation 20 122 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 123 1 Introduction 124 We are interested in addressing the interaction between the Telnet 125 client and server that will support this secure requirement with the 126 knowledge that this is only a portion of the total end-user to 127 application path. Specifically, it is often true that the Telnet server 128 does not reside on the target machine (it does not have access to a list 129 of identities which are allowed to access to that mainframe), and it is 130 often true (e.g. 3270 access) that the TN server can not even identify 131 that portion of the emulation stream which contains user 132 identification/password information. Additionally, it may be the case 133 that the Telnet client is not co-resident with the end user and that it 134 also may be unable to identify that portion of the data stream that deals 135 with user identity. We make the assumption here that there is a trust 136 relationship and appropriate protection to support that relationship 137 between the TN Server and the ultimate application engine such that data 138 on this path is protected and that the application will authenticate the 139 end user via the emulation stream as well as use this to control access 140 to information. We further make the assumption that the path between the 141 end user and the client is protected. 143 To hold up the Telnet part of the overall secure path between the user 144 and the mainframe, the Telnet data stream must appear unintelligible to 145 a third party. This is done by creating a shared secret between the 146 client and server. This shared secret is used to encrypt the flow of data 147 and (just as important) require the client to verify that it is talking 148 to correct server (the one that the mainframe trusts rather than an 149 unintended man-in-the-middle) with the knowledge that the emulation 150 stream itself will be used by the mainframe to verify the identity of the 151 end-user. Rather than create a specialized new protocol which 152 accomplishes these goals we instead have chosen to use existing 153 protocols with certain constraints. 155 One such existing protocol is the TLS protocol (formerly known as SSL). 156 And the Telnet [TELNET ] application protocol can certainly benefit from 157 the use of TLS. Other security mechanisms have been used with Telnet 158 (e.g. KERBEROS [RFC1416 ]), but TLS offers a broad range of security 159 levels that allow sites to proceed at an "evolutionary" pace in 160 deploying authentication, authorization and confidentiality policies, 161 databases and distribution methods. 163 TLS is used to provide the following: 165 o creation and refresh of a shared secret; 167 o negotiation and execution of data encryption and optional 169 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 170 compressesion; 172 o primary negotiation of authentication; and, if chosen 174 o execution of public-key or symmetric-key based authentication. 176 Since both encryption and authentication is always needed for a secure 177 channel that meets the requirements of these emulation types, we can use 178 the anonymous authentication negotiation option of TLS as an indication 179 that the client wants to negotiate some non-TLS-based authentication 180 exchange. Note that as per usual TLS rules, the client must always 181 authenticate the server's credentials. 183 TLS at most offers only authentication of the peers conducting the TLS 184 dialog. In particular, it does not offer the possibility of the client 185 providing separate credentials for authorization than were presented for 186 authentication. It is expect that other RFCs will be produced describing 187 how other authentication mechanisms can be used in conjunction with TLS. 189 Traditional Telnet servers have operated without such early presentation 190 of authorization credentials for many reasons (most of which are 191 historical). However, recent developments in Telnet server technology 192 make it advantageous for the Telnet server to know the authorized 193 capabilities of the remote client before choosing a communications link 194 (be it `pty' or SNA LU) and link-characteristics to the host system (be 195 that "upstream" link local or remote to the server). Thus, we expect to 196 see the use of client authorization to become an important element of the 197 telnet evolution. Such authorization methods may require certificates 198 presented by the client via TLS, or by the use of SASL or RFC1416, or 199 some other as yet unstandardized method. 201 This document defines extensions to Telnet which allow TLS to be 202 activated early in the lifetime of the Telnet connection. It defines a 203 set of advisory security-policy response codes for use when negotiating 204 TLS over Telnet. 206 Conventions Used in this Document 207 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 208 "MAY" in this document are to be interpreted as described in [KEYWORDS ]. 210 Formal syntax is defined using ABNF [ANBF ]. 212 In examples, "C:" and "S:" indicate lines sent by the the client and 213 server, respectively. 215 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 216 2 Telnet STARTTLS Option and Subnegotiation 217 The STARTTLS option is an asymmetric option, with only the server side 218 being able to send IAC DO STARTTLS. The client may initiate by sending 219 IAC WILL STARTTLS. There are some more rules due to the need to clear the 220 link of data (or to synchronize the link). This synchronization takes 221 the form of a three-way handshake: 223 1. As per normal Telnet option processing rules, the client MUST 224 respond to the server's IAC DO STARTTLS with either IAC WONT 225 STARTTLS or IAC WILL STARTTLS (if it hasn't already done so). An 226 affirmative response MUST be followed eventually by IAC SB STARTTLS 227 FOLLOWS IAC SE. If the client sends the affirmative response, it 228 must then not initiate any further Telnet options or subnegotiations 229 except for the STARTTLS subnegotiation until after the TLS 230 negotiation has completed. 232 2. The server SHOULD NOT send any more Telnet data or commands after 233 sending IAC DO STARTTLS except in response to client Telnet options 234 received until after it receives either a negative response from the 235 client (IAC WONT STARTTLS) or the affirmative (both IAC WILL 236 STARTTLS and followed eventually by IAC SB STARTTLS FOLLOWS IAC SE). 237 If the client's STARTTLS option response is negative, the server is 238 free to again send Telnet data or commands. If the client's response 239 is affirmative, then the server MUST send only IAC SB STARTTLS 240 FOLLOWS IAC SE. If the server sends IAC SB STARTTLS FOLLOWS IAC SE, 241 then the server MUST also arrange at this time, for the normal Telnet 242 byte-stuff/destuff processing to be turned off for the duration of 243 the TLS negotiation. 245 3. The client, upon receipt of the server's IAC SB STARTTLS FOLLOWS IAC 246 SE, MUST also arrange for normal Telnet byte-stuff/destuff 247 processing to be turned off for the duration of the TLS negotiation. 248 It MUST then enter into TLS negotiation by sending the TLS 249 ClientHello message. 251 Here's a breakdown of the Telnet command phrases defined in this 252 document: 254 S: IAC DO STARTTLS-- Sent only by server. Indicates that server strongly 255 desires that the client enter into TLS negotiations. 257 C: IAC WILL STARTTLS-- Sent only by client. Indicates that client 258 strongly desires that the server enter into TLS negotiations. 260 S: IAC DONT STARTTLS-- Sent only by the server. Indicates that the 261 server is not willing to enter into TLS negotations. 263 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 264 C: IAC WONT STARTTLS-- Sent only by the client. Indicates that the 265 client is not willing to enter into TLS negotiations. 267 C: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the client, this 268 indicates that the client is preparing for TLS negotiations, and 269 that the next thing sent by the client will be the TLS ClientHello. 270 Also indicates that the client has reset its Telnet state. 272 S: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the server, this 273 indicates that the server has prepared to receive the TLS 274 ClientHello from the client. Also indicates that the server has 275 reset its Telnet state. 277 2.1 Abnormal Negotiation Failure 279 The behavior regarding TLS negotiation failure is covered in [TLS ], and 280 does not indicate that the TCP connection be broken; the semantics are 281 that TLS is finished and all state variables cleaned up. The TCP 282 connection may be retained. 284 However, it's not clear that either side can detect when the last of the 285 TLS data has arrived. So if TLS negotiation fails, the TCP connection 286 SHOULD be reset and the client MAY reconnect. To avoid infinite loops of 287 TLS negotiation failures, the client MUST remember to not negotiate TLS 288 upon reconnecting after a TLS negotiation failure. 290 2.2 Assigned Values for STARTTLS Negotiation 292 The assigned value of the Telnet STARTTLS option octet is 46. The 293 assigned value of the FOLLOWS subnegotiation octet is 1. In ABNF, this 294 is: 296 STARTTLS = %d46 297 FOLLOWS = %d1 299 3 Telnet Authentication and Authorization 300 Telnet servers and clients can be implemented in a variety of ways that 301 impact how clients and servers authenticate and authorize each other. 303 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 304 However, most (if not all) the implementations can be abstracted via the 305 following four communicating processes: 307 SES Server End System. This is an application or machine to which client 308 desires a connection. Though not illustrated here, a single Telnet 309 connection between client and server could have multiple SES 310 terminations. 312 Server The Telnet server. 314 Client The Telnet client, which may or may not be co-located with the 315 CES. The Telnet client in fact be a gateway or proxy for downstream 316 clients; it's immaterial. 318 CES Client End System. The system communicating with the Telnet Client. 319 There may be more than one actual CES communicating to a single 320 Telnet Client instance; this is also immaterial to how Client and 321 Server can sucessfully exchange authentication and authorization 322 details. However, see Section 5.4 for a discussion on trust 323 implications. 325 What is of interest here is how the Client and Server can exchange 326 authentication and authorization details such that these components can 327 direct Telnet session traffic to authorized End Systems in a reliable, 328 trustworthy fashion. 330 What is beyond the scope of this specification are several related 331 topics, including: 333 o How the Server and SES are connected, and how they exchange data or 334 information regarding authorization or authentication (if any). 336 o How the Client and CES are connected, and how they exchange data or 337 information regarding authorization or authentication (if any). 339 4 TLS, Authentication and Authorization 340 System-to-system communications using the Telnet protocol have 341 traditionally used no authentication techniques at the Telnet level. 342 More recent techniques have used Telnet to transport authentication 343 exchanges (e.g.[TLSKERB ]). In none of these systems, however, is a 344 remote system allowed to assume more than one identity once the Telnet 345 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 346 preamble negotiation is over and the remote is connected to the 347 application-endpoint. The reason for this is that the local party must 348 in some way inform the end-system of the remote party's identity (and 349 perhaps authorization). This process must take place before the remote 350 party starts communicating with the end-system. At that point it's too 351 late to change what access a client may have to an server end-system: 352 that end-system has been selected, resources have been allocated and 353 capability restrictions set. 355 [Author's note: I dislike providing state models of how local systems 356 should behave in relation to a wire protocol; it seems to me that such 357 models often do more harm than good when describing a wire protocol. The 358 model often misrepresents reality, and/or makes unnecessarily limiting 359 assumptions about implementation behavior. However, the alternative 360 methods of explanation seemed even less useful in this case....] 362 This process of authentication, authorization and resource allocation 363 can be modeled (one hopes!) by the following simple set of states and 364 transitions: 366 `unauthenticated' The local party has not received any credentials 367 offered by the remote. A new Telnet connection starts in this state. 369 The `authenticating' state will be entered from this state if the 370 local party initiates the authentication process of the peer. The 371 Telnet STARTTLS negotiation is considered an initiation of the 372 authentication process. 374 The `authorizing' state will be entered from this state either if 375 the local party decides to begin authorization and resource 376 allocation procedures unilaterally...or if the local party has 377 received data from the remote party destined for local end-system. 379 `authenticating' The local party has received at least some of the 380 credentials needed to authenticate its peer, but has not finished 381 the process. 383 The `authenticated' state will be entered from this state if the 384 local party is satisfied with the credentials proferred by the 385 client. 387 The `unauthenticated' state will be entered from this state if the 388 local party cannot verify the credentials proffered by the client or 389 if the client has not proffered any credentials. Alternately, the 390 local party may terminate the Telnet connection instead of returning 391 it to the `unauthenticated' state. 393 `authenticated' The local party has authenticated its peer, but has not 394 yet authorized the client to connect to any end-system resources. 396 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 397 The `authenticating' state will be entered from this state if the 398 local party decides that further authentication of the client is 399 warranted. 401 The `authorizing' state will be entered from this state if the local 402 party either initiates authorization dialog with the client (or 403 engages in some process to authorize and allocate resources on 404 behalf of the client), or has received data from the remote party 405 destined for a local end-system. 407 `authorizing' The local party is in the process of authorizing its peer 408 to use end-system resources, or may be in the process of allocating 409 or reserving those resources. 411 The `transfer-ready' state will be entered when the local party is 412 ready to allow data to be passed between the local end-system and 413 remote peer. 415 The `authenticated' state will be entered if the local party 416 determines that the current authorization does not allow any access 417 to a local end-system. If the remote peer is not currently 418 authenticated, then the `unauthenticated' state will be entered 419 instead. 421 `transfer-ready' The party may pass data between the local end-system to 422 its peer. 424 The `authorizing' state will be entered if the local party (perhaps 425 due to a request by the remote peer) deallocates the communications 426 resources to the local-end system. Alternately, the local party may 427 enter the `authenticated' or the `unauthenticated' state. 429 In addition to the "orderly" state transitions noted above, some 430 extraordinary transitions may also occur: 432 1. The absence of a guarantee on the integrity of the data stream 433 between the two Telnet parties also removes the guarantee that the 434 remote peer is who the authentication credentials say the peer is. 435 Thus, upon being notified that the Telnet session is no longer using 436 an integrity layer, the local party must at least deallocate all 437 resources associated with a Telnet connection which would not have 438 been allocable had the remote party never authenticated itself. 440 In practice, this deallocation-of-resources restriction is hard to 441 interpret consistently by both Telnet endpoints. Therefore, both 442 parties MUST return to the initial Telnet state after negotiation of 443 TLS. That is, it is as if the Telnet session had just started. 445 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 446 This means that the states may transition from whatever the current 447 state is to `unauthenticated'. Alternately, the local party may 448 break the Telnet connection instead. 450 2. If the local party is notified at any point during the Telnet 451 connection that the remote party's authorizations have been reduced 452 or revoked, then the local party must treat the remote party as being 453 unauthenticated. The local party must deallocate all resources 454 associated with a Telnet connection which would not have been 455 allocable had the remote party never authenticated itself. 457 This too may mean that the states may transition from whatever the 458 current state is to `unauthenticated'. Alternately, the local party 459 may break the Telnet connection instead. 461 The above model explains how each party should handle the authentication 462 and authorization information exchanged during the lifetime of a Telnet 463 connection. It is deliberately fuzzy as to what constitutes internal 464 processes (such as "authorizing") and what is meant by "resources" or 465 "end-system" (such as whether an end-system is strictly a single entity 466 and communications path to the local party, or multiples of each, etc). 468 Here's a state transition diagram, as per [RFC2360 ]: 470 0 1 2 3 4 471 Events | unauth auth'ing auth'ed authorizing trans-ready 472 -----------+-------------------------------------------------------- 473 auth-needed| sap/1 sap/1 sap/1 sap/1 der,sap/1 474 auth-accept| - ain/2 - - - 475 auth-bad | - 0 wa/0 wa,der/0 der,sap/1 476 authz-start| szp/3 - szp/3 - - 477 data-rcvd | szp/3 qd/1 szp/3 qd/3 pd/4 478 authz-ok | - - - 4 - 479 authz-bad | - - - der/2 wa,der,szp/3 481 Action | Description 482 -------+-------------------------------------------- 483 sap | start authentication process 484 der | deallocate end-system resources 485 ain | authorize if needed 486 szp | start authorization process 487 qd | queue incoming data 488 pd | process data 489 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 490 wa | wipe authorization info 492 Event | Description 493 -------------+--------------------------------------------------- 494 auth-needed | authentication deemed needed by local party 495 auth-accept | remote party's authentication creds accepted 496 auth-bad | remote party's authentication creds rejected or expired 497 authz-start | local or remote party starts authorization proceedings 498 data-rcvd | data destined for end-system received from remote party 499 authz-ok | authorization and resource allocation succeeded 500 authz-bad | authorization or resource allocation failed or expired 502 4.1 Authentication of the remote party 504 If TLS has been successfully negotiated, the client will have the 505 server's certificate. This indicates that the server's identity can be 506 verified. Client implementations MUST always verify the server identity 507 as part of TLS processing and fail the connection if such verification 508 fails. See Section 5.1 for a general discussion of the server 509 authentication apropos Telnet clients. 511 The server, however, may not have the client's identity (verified or 512 not). This is because the client need not provide a certificate during 513 the TLS exchange. Or it may be server site policy not to use the identity 514 so provided. In any case, the server may not have enough confidence in 515 the client to move the connection to the authenticated state. 517 If further client, server or client-server authentication is going to 518 occur after TLS has been negotiated, it MUST occur before any 519 non-authentication-related Telnet interactions take place on the link 520 after TLS starts. When the first non-authentication-related Telnet 521 interaction is received by either participant, then the receiving 522 participant MAY drop the connection due to dissatisfaction with the 523 level of authentication. 525 If the server wishes to request a client certificate after TLS is 526 initially started (presumably with no client certificate requested), it 527 may do so. However, the server MUST make such a request immediately 528 after the initial TLS handshake is complete. 530 No TLS negotiation outcome, however trustworthy, will by itself provide 531 the server with the authorization identity if that is different from the 532 authentication identity of the client. See [SASL ] for why this might be 533 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 534 a desirable function to have with proxy clients, etc. How such 535 authorization is done is outside the scope of this document. 537 The following subsections detail how the client can provide the server 538 with authentication and authorization credentials separate to the TLS 539 mechanism. 541 4.2 PKI-based Authentication and certificate extensions 543 When PKI authentication is used no special X.509 certificate extensions 544 will be require but a client or server may choose to support an extension 545 if found. For example, they may use a contained certificate revocation 546 URL extension if provided. The intent is to allow sharing of 547 certificates with other services on the same host, for example, a Telnet 548 server might use the same certificate to identify itself that a 549 co-located WEB server uses. The method of sharing certificates is 550 outside the scope of this document. 552 An X.509 certificate received by a client may include the 553 `subjectAltName' extension. If this extension is present and contains a 554 `dNSName' object, then the client MUST check the hostname used to 555 connect to the host against the dNSName found in the certificate. The 556 method used is outlined in [TLSHTTP ]. 558 If the subjectAltName extension is not present, then the client may use 559 the commonName field as long as the contents of the field are interpreted 560 as fully qualified domain names. 562 4.3 Pre-TLS Authentication 564 It could be that the server had moved the Telnet connection to the 565 authenticated state sometime previous to the negotiation of TLS. If this 566 is the case, then the server MUST NOT use the credentials proffered by 567 the client during the TLS negotiations for authorization of that client. 568 The server should, of course, verify the client's TLS-proffered 569 credentials. 571 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 572 5 Security 573 Security is discussed throughout this document. Most of this document 574 concerns itself with wire protocols and security frameworks. But in this 575 section, client and server implementation security issues are in focus. 577 5.1 Authentication of the Server by the Client 579 How the client can verify the server's proferred identity varies 580 according to the key-exchange algorithm used in the selected TLS 581 cipher-suite. However, it's important for the client to follow good 582 security practice in verifying the proffered identity of the server. 584 5.1.1 PKI-based certificate processing 586 When PKI authentication is used no special X.509 certificate extensions 587 will be required but a client or server may choose to support an 588 extension if found. For example, they may use a contained certificate 589 revocation URL extension if provided. The intent is to allow sharing of 590 certificates with other services on the same host, for example, a Telnet 591 server might use the same certificate to identify itself that a 592 co-located WEB server uses. The method of sharing certificates is not a 593 topic of this document. 595 The verification of the server's certificate by the client MUST include, 596 but isn't limited to, the verification of the signature certificate 597 chain to the point where the a signature in that chain uses a known good 598 signing certificate in the clients local key chain. The verification 599 SHOULD then continue with a check to see if the fully qualified host name 600 which the client connected to appears anywhere in the server's 601 certificate subject (DN). If no match is found then either: 603 o the end user MUST see a display of the server's certificate and be 604 asked if he/she is willing to proceed with the session; or, 606 o the end user MUST NOT see a display of server's certificate, but the 607 certificate details are logged on whatever media is used to log 608 other session details. This option may be preferred to the first 609 option in environments where the end-user cannot be expected to make 610 an informed decision about whether a mismatch is harmful. The 612 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 613 connection MUST be closed automatically by the client UNLESS the 614 client has been configured to explicitly allow all mismatches. 616 o the connection MUST be closed on the user's behalf, and an error 617 describing the mismatch logged to stable storage. 619 If the client side of the service is not interactive with a human 620 end-user, the Telnet connection SHOULD be dropped if this host check 621 fails. 623 5.2 Non-PKI-based Authentication of client or server 625 Authentication of the client (or further mutual authentication between 626 client and server) can be accomplished via non-PKI means, too. 627 Implementors should be careful to remember that authentication must 628 occur after successful TLS session negotiation. Further, the timing of 629 the authentication MUST be as per Section 4. 631 Practically speaking, this means that non-TLS authentication should 632 immediately follow the TLS negotiation. See 7.4 for an example of how 633 this can work. 635 5.3 Display of security levels 637 The Telnet client and server MAY, during the TLS protocol negotiation 638 phase, choose to use a weak cipher suite due to policy, law or even 639 convenience. It is, however, important that the choice of weak cipher 640 suite be noted as being commonly known to be vulnerable to attack. In 641 particular, both server and client software should note the choice of 642 weak cipher-suites in the following ways: 644 o If the Telnet endpoint is communicating with a human end-user, the 645 user-interface SHOULD display the choice of weak cipher-suite and 646 the fact that such a cipher-suite may compromise security. 648 o The Telnet endpoints SHOULD log the exact choice of cipher-suite as 649 part of whatever logging/accounting mechanism normally used. 651 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 652 5.4 Trust Relationships and Implications 654 Authentication and authorization of the remote Telnet party is useful, 655 but can present dangers to the authorizing party even if the connection 656 between the client and server is protected by TLS using strong 657 encryption and mutual authentication. This is because there are some 658 trust-relationships assumed by one or both parties: 660 o Each side assumes that the authentication and authentication details 661 proferred by the remote party stay constant until explicitly changed 662 (or until the TLS session is ended). 664 o More stringently, each side trusts the other to send a timely 665 notification if authentication or authorization details of the other 666 party's end system(s) have changed. 668 Either of these trust relationships may be false if an intruder has 669 breached communications between a client or server and its respective 670 end system. And either may be false if a component is badly implemented 671 or configured. Implementers should take care in program construction to 672 avoid invalidating these trust relationships, and should document to 673 configuring-users the proper ways to configure the software to avoid 674 invalidation of these relationships. 676 6 TLS Variants and Options 677 TLS has different versions and different cipher suites that can be 678 supported by client or server implementations. The following 679 subsections detail what TLS extensions and options are mandatory. The 680 subsections also address how TLS variations can be accommodated. 682 6.1 Support of previous versions of TLS 684 TLS has its roots in SSL 2.0 and SSL 3.0. Server and client 685 implementations may wish to support for SSL 3.0 as a fallback in case TLS 686 3.1 or higher is not supported. This is permissible; however, client 687 implementations which negotiate SSL3.0 MUST still follow the rules in 688 Section 5.3 concerning disclosure to the end-user of transport-level 689 security characteristics. 691 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 692 Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; it 693 is detailed in [TLS ]. Negotiating SSL 2.0 is MUST NOT be attempted. 695 6.2 Using Kerberos V5 with TLS 697 If the client and server are both amenable to using Kerberos V5, then 698 using non-PKI authentication techniques within the confines of TLS may 699 be acceptable (see [TLSKERB ]). Note that clients and servers are under 700 no obligation to support anything but the cipher-suite(s) mandated in 701 [TLS ]. However, if implementations do implement the KRB5 authentication 702 as a part of TLS ciphersuite, then these implementations SHOULD support 703 at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite. 705 7 Protocol Examples 706 The following sections provide skeletal examples of how Telnet clients 707 and servers can negotiate TLS. 709 7.1 Successful TLS negotiation 711 The following protocol exchange is the typical sequence that starts TLS: 713 // typical successful opening exchange 714 S: IAC DO STARTTLS 715 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 716 S: IAC SB STARTTLS FOLLOWS IAC SE 717 // server now readies input stream for non-Telnet, TLS-level negotiation 718 C: [starts TLS-level negotiations with a ClientHello] 719 [TLS transport-level negotiation ensues] 720 [TLS transport-level negotiation completes with a Finished exchanged] 721 // either side now able to send further Telnet data or commands 723 7.2 Successful TLS negotiation, variation 725 The following protocol exchange is the typical sequence that starts TLS, 726 but with the twist that the (TN3270E) server is willing but not 727 aggressive about doing TLS; the client strongly desires doing TLS. 729 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 730 // typical successful opening exchange 731 S: IAC DO TN3270E 732 C: IAC WILL STARTTLS IAC 733 S: IAC DO STARTTLS 734 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 735 S: IAC SB STARTTLS FOLLOWS IAC SE 736 // server now readies input stream for non-Telnet, TLS-level negotiation 737 C: [starts TLS-level negotiations with a ClientHello] 738 [TLS transport-level negotiation ensues] 739 [TLS transport-level negotiation completes with a Finished 740 exchanged] 741 // note that server retries negotiation of TN3270E after TLS 742 // is done. 743 S: IAC DO TN3270E 744 C: IAC WILL TN3270E 745 // TN3270E dialog continues.... 747 7.3 Unsuccessful TLS negotiation 749 This example assumes that the server does not wish to allow the Telnet 750 session to proceed without TLS security; however, the client's version 751 of TLS does not interoperate with the server's. 753 //typical unsuccessful opening exchange 754 S: IAC DO STARTTLS 755 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 756 S: IAC SB STARTTLS FOLLOWS IAC SE 757 // server now readies input stream for non-Telnet, TLS-level negotiation 758 C: [starts TLS-level negotiations with a ClientHello] 759 [TLS transport-level negotiation ensues] 760 [TLS transport-level negotiation fails with server sending 761 ErrorAlert message] 762 C: IAC DO TERMINAL-TYPE 763 S: IAC WONT TERMINAL-TYPE 764 S: [TCP level disconnect] 765 // server (or both) initiate TCP session disconnection 767 This example assumes that the server wants to do TLS, but is willing to 768 allow the session to proceed without TLS security; however, the client's 769 version of TLS does not interoperate with the server's. 771 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 772 //typical unsuccessful opening exchange 773 S: IAC DO STARTTLS 774 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 775 S: IAC SB STARTTLS FOLLOWS IAC SE 776 // server now readies input stream for non-Telnet, TLS-level negotiation 777 C: [starts TLS-level negotiations with a ClientHello] 778 [TLS transport-level negotiation ensues] 779 [TLS transport-level negotiation fails with server sending 780 ErrorAlert message] 781 C: IAC DO TERMINAL-TYPE 782 S: IAC WILL TERMINAL-TYPE 783 // regular Telnet dialog ensues 785 7.4 Authentication via Kerberos 4 after TLS negotiation 787 Here's an implementation example of using Kerberos 4 to authenticate the 788 client after encrypting the session with TLS. Note the following 789 details: 791 o The client strictly enforces a security policy of proposing Telnet 792 AUTH first, but accepting TLS. This has the effect of producing a 793 rather verbose pre-TLS negotiation sequence; however, the 794 end-result is correct. A more efficient pre-TLS sequence can be 795 obtained by changing the client security policy to be the same as the 796 server's for this connection (and implementing policy-aware 797 negotiation code in the Telnet part of the client). 799 A similar efficient result can be obtained even in the absence of a 800 clear client security policy if the client has cached server 801 security preferences from a previous Telnet session to the same 802 server. 804 o The server strictly enforces a security policy of proposing TLS 805 first, but falling back to Telnet AUTH. 807 C: IAC WILL AUTHENTICATION 808 C: IAC WILL NAWS 809 C: IAC WILL TERMINAL-TYPE 810 C: IAC WILL NEW-ENVIRONMENT 811 S: IAC DO STARTTLS 812 C: IAC WILL STARTTLS 813 C: IAC SB STARTTLS FOLLOWS IAC SE 814 S: IAC DO AUTHENTICATION 816 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 817 S: IAC DO NAWS 818 S: IAC WILL SUPPRESS-GO-AHEAD 819 S: IAC DO SUPPRESS-GO-AHEAD 820 S: IAC WILL ECHO 821 S: IAC DO TERMINAL-TYPE 822 S: IAC DO NEW-ENVIRONMENT 823 S: IAC SB AUTHENTICATION SEND 824 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ 825 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 826 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY 827 SSL CLIENT_TO_SERVER|ONE_WAY IAC SE 828 S: IAC SB TERMINAL-TYPE SEND IAC SE 829 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 830 S: IAC SB STARTTLS FOLLOWS IAC SE 831 [TLS - handshake starting] 832 [TLS - OK] 833 C: IAC WILL AUTHENTICATION 834 C: IAC WILL NAWS 835 C: IAC WILL TERMINAL-TYPE 836 C: IAC WILL NEW-ENVIRONMENT 837 838 S: IAC DO AUTHENTICATION 839 S: IAC DO NAWS 840 S: IAC WILL SUPPRESS-GO-AHEAD 841 C: IAC DO SUPPRESS-GO-AHEAD 842 S: IAC DO SUPPRESS-GO-AHEAD 843 C: IAC WILL SUPPRESS-GO-AHEAD 844 S: IAC WILL ECHO 845 C: IAC DO ECHO 846 S: IAC DO TERMINAL-TYPE 847 S: IAC DO NEW-ENVIRONMENT 848 S: IAC SB AUTHENTICATION SEND 849 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 850 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY IAC SE 851 C: IAC SB AUTHENTICATION NAME jaltman IAC SE 852 C: IAC SB AUTHENTICATION IS 853 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL AUTH 854 04 07 0B "CC.COLUMBIA.EDU" 00 "8(" 0D 9E 9F AB A0 "L" 15 8F A6 855 ED "x" 19 F8 0C "wa" CA "z`" 1A E2 B8 "Y" B0 8E "KkK" C6 AA "<" FF 856 FF 98 89 "|" 90 AC DF 13 "2" FC 8E 97 F7 BD AE "e" 07 82 "n" 19 "v" 857 7F 10 C1 12 B0 C6 "|" FA BB "s1Y" FF FF 10 B5 14 B3 "(" BC 86 "`" 858 D2 "z" AB "Qp" C4 "7" AB "]8" 8A 83 B7 "j" E6 "IK" DE "|YIVN" 859 IAC SE 860 S: IAC SB TERMINAL-TYPE SEND IAC SE 861 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 862 S: IAC SB AUTHENTICATION REPLY 863 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL ACCEPT IAC SE 865 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 866 C: IAC SB AUTHENTICATION IS 867 KERBEROS_V4 CLIENT|MUTUAL CHALLENGE "[" BE B7 96 "j" 92 09 "~" IAC SE 868 S: IAC SB AUTHENTICATION REPLY 869 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL RESPONSE "df" B0 D6 "vR_/" IAC SE 870 871 C: IAC SB TERMINAL-TYPE IS VT320 IAC SE 872 C: IAC SB NEW-ENVIRONMENT IS USERAjaltmanSYSTEMTYPEAWIN32 IAC SE 873 C: IAC SB NAWS 162 49 IAC SE 875 Here are several things to note about the above example: 877 o After TLS is successfully negotiated, all non-TLS Telnet settings 878 are forgotten and must be renegotiated. 880 o After TLS is successfully negotiated, the server offers all 881 authentication types that are appropriate for a session using TLS. 882 Note that the server, post TLS-negotiation, isn't offering Telnet 883 ENCRYPT or AUTH SSL, since (a) it's useless and perhaps dangerous to 884 encrypt twice, and (b) TLS and/or SSL can be applied only once to a 885 Telnet session. 887 References 888 [ANBF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 889 Specifications: ABNF", RFC2235, November 1997. 891 [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate 892 Requirement Levels", RFC2119, March 1997. 894 [RFC927] Brian A. Anderson. "TACACS User Identification Telnet 895 Option", RFC927, December 1984 897 [RFC1416] D. Borman, Editor. "Telnet Authentication Option", RFC1416, 898 February 1993. 900 [SASL] Myers, J. "Simple Authentication and Security Layer (SASL)", 901 RFC2222, October 1997. 903 [RFC2360] G. Scott, Editor. "Guide for Internet Standard Writers", 904 RFC2360, June 1998. 906 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specifications", 907 RFC854, May 1983. 909 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 910 [TLS] Tim Dierks. "The TLS Protocol", Internet Draft, November 911 1997. 913 [TLSKERB] Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher 914 Suites to Transport Layer Security (TLS)", Internet Draft, 915 July 1997. 917 [TLSHTTP] E. Rescorla. "HTTP Over TLS", Internet Draft 918 , March 1998. 920 Author's Address 921 Michael Boe 922 Cisco Systems Inc. 923 170 West Tasman Drive 924 San Jose, CA 95134 926 Email: Michael Boe 928 Full Copyright Statement 929 Copyright (c) The Internet Society (1998, 1999). All Rights Reserved. 931 This document and translations of it may be copied and furnished to 932 others, and derivative works that comment on or otherwise explain it or 933 assist in its implementation may be prepared, copied, published and 934 distributed, in whole or in part, without restriction of any kind, 935 provided that the above copyright notice and this paragraph are included 936 on all such copies and derivative works. However, this document itself 937 may not be modified in any way, such as by removing the copyright notice 938 or references to the Internet Society or other Internet organizations, 939 except as needed for the purpose of develop- ing Internet standards in 940 which case the procedures for copyrights defined in the Internet 941 Standards process must be followed, or as required to translate it into 942 languages other than English. 944 The limited permissions granted above are perpetual and will not be 945 revoked by the Internet Society or its successors or assigns. 947 This document and the information contained herein is provided on an "AS 948 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 949 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 950 I-D draft-ietf-telnet-tls-02 TLS-based Telnet Security July, 1999 951 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 952 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 953 FITNESS FOR A PARTICULAR PURPOSE. 955 Acknowledgement 956 Funding for the RFC Editor function is currently provided by the 957 Internet Society.