idnits 2.17.1 draft-ietf-tn3270e-telnet-tls-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-telnet-tls-01', but the file name used is 'draft-ietf-tn3270e-telnet-tls-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 6) being 65 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 61 instances of too long lines in the document, the longest one being 8 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 474 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). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 1999) is 9196 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 776, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC927' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC1416' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'SASL' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'RFC2360' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'TELNET' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'TLSKERB' is defined on line 802, but no explicit reference was found in the text == Unused Reference: 'TLSHTTP' is defined on line 806, 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: 12 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Michael Boe 3 INTERNET-DRAFT draft-ietf-telnet-tls-01 Cisco Systems 4 expires February 1999 5 September, 1998 7 TLS-based Telnet Security 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that the other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced or obsoleted by other documents at any time. 18 Its is inappropriate to use Internet-Drafts as reference material or to 19 cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Cost), or 25 ftp.isi.edu (US West Coast). 27 Copyright Notice 29 Copyright (C) The Internet Society (1998). All Rights Reserved. 31 Abstract 33 Telnet service has long been a standard Internet protocol. However, a 34 standard way of ensuring privacy and integrity of Telnet sessions has 35 been lacking. This document proposes a standard method for Telnet 36 servers and clients to use the Transport Layer Security (TLS) protocol. 38 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 40 It describes how two Telnet participants can decide whether or not to 41 attempt TLS negotiation, and how the two participants should process 42 authentication credentials exchanged as a part of TLS startup. 44 Changes since -00 Draft 46 o Add local authentication/authorization operational model. 48 o Change behavior of Telnet machine to reset at start of TLS 49 negotiation. 51 o Insert narrative questioning the utility of allowing continuation of 52 Telnet session after TLS has ended. 54 o change examples to reflect the above changes. 56 o Fix several typos. 58 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 60 Contents 62 1 Introduction 5 64 2 Telnet STARTTLS Option and Subnegotiation 7 66 2.1 Abnormal Negotiation Failure . . . . . . 8 68 2.2 Assigned Values for STARTTLS Negotiation . . . . 8 70 3 Telnet Authentication and Authorization 9 72 4 TLS, Authentication and Authorization 10 74 4.1 Authentication of the remote party . . . . . 13 76 4.2 PKI-based Authentication and certificate extensions . . . 14 78 4.3 Pre-TLS Authentication . . . . . . . . 14 80 5 Security 14 82 5.1 Authentication of the Server by the Client . . . . 15 84 5.1.1 PKI-based certificate processing . . . . 15 86 5.1.2 Kerberos V5 server verification . . . . . 15 88 5.2 Display of security levels . . . . . . . 15 90 5.3 Trust Relationships and Implications . . . . . 16 92 6 TLS Variants and Options 16 94 6.1 Support of previous versions of TLS . . . . . 17 96 6.2 Using Kerberos V5 with TLS . . . . . . 17 98 7 Protocol Examples 17 100 7.1 Successful TLS negotiation . . . . . . 17 102 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 104 7.2 Successful TLS negotiation, variation . . . . 18 106 7.3 Unsuccessful TLS negotiation . . . . . . 18 108 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 110 1 Introduction 112 We are interested in addressing the interaction between the Telnet 113 client and server that will support this secure requirement with the 114 knowledge that this is only a portion of the total end-user to 115 application path. Specifically, it is often true that the Telnet server 116 does not reside on the target machine (it does not have access to a list 117 of identities which are allowed to access to that mainframe), and it is 118 often true (e.g. 3270 access) that the TN server can not even identify 119 that portion of the emulation stream which contains user 120 identification/password information. Additionally, it may be the case 121 that the Telnet client is not co-resident with the end user and that it 122 also may be unable to identify that portion of the data stream that deals 123 with user identity. We make the assumption here that there is a trust 124 relationship and appropriate protection to support that relationship 125 between the TN Server and the ultimate application engine such that data 126 on this path is protected and that the application will authenticate the 127 end user via the emulation stream as well as use this to control access 128 to information. We further make the assumption that the path between the 129 end user and the client is protected. 131 To hold up the Telnet part of the overall secure path between the user 132 and the mainframe, the Telnet data stream must appear unintelligible to 133 a third party. This is done by creating a shared secret between the 134 client and server. This shared secret is used to encrypt the flow of data 135 and (just as important) require the client to verify that it is talking 136 to correct server (the one that the mainframe trusts rather than an 137 unintended man-in-the-middle) with the knowledge that the emulation 138 stream itself will be used by the mainframe to verify the identity of the 139 end-user. Rather than create a specialized new protocol which 140 accomplishes these goals we instead have chosen to use existing 141 protocols with certain constraints. 143 One such existing protocol is the TLS protocol (formerly known as SSL). 144 And the Telnet [TELNET ] application protocol can certainly benefit from 145 the use of TLS. Other security mechanisms have been used with Telnet 146 (e.g. KERBEROS [RFC1416 ]), but TLS offers a broad range of security 147 levels that allow sites to proceed at an "evolutionary" pace in 148 deploying authentication, authorization and confidentiality policies, 149 databases and distribution methods. 151 TLS is used to provide the following: 153 o creation and refresh of a shared secret; 155 o negotiation and execution of data encryption and optional 157 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 159 compressesion; 161 o primary negotiation of authentication; and, if chosen 163 o execution of public-key or symmetric-key based authentication. 165 Since both encryption and authentication is always needed for a secure 166 channel that meets the requirements of these emulation types, we can use 167 the anonymous authentication negotiation option of TLS as an indication 168 that the client wants to negotiate some non-TLS-based authentication 169 exchange. Note that as per usual TLS rules, the client must always 170 authenticate the server's credentials. 172 TLS at most offers only authentication of the peers conducting the TLS 173 dialog. In particular, it does not offer the possibility of the client 174 providing separate credentials for authorization than were presented for 175 authentication. It is expect that other RFCs will be produced describing 176 how other authentication mechanisms can be used in conjunction with TLS. 178 Traditional Telnet servers have operated without such early presentation 179 of authorization credentials for many reasons (most of which are 180 historical). However, recent developments in Telnet server technology 181 make it advantageous for the Telnet server to know the authorized 182 capabilities of the remote client before choosing a communications link 183 (be it `pty' or SNA LU) and link-characteristics to the host system (be 184 that "upstream" link local or remote to the server). Thus, we expect to 185 see the use of client authorization to become an important element of the 186 telnet evolution. Such authorization methods may require certificates 187 presented by the client via TLS, or by the use of SASL or RFC1416, or 188 some other as yet unstandardized method. 190 This document defines extensions to Telnet which allow TLS to be 191 activated early in the lifetime of the Telnet connection. It defines a 192 set of advisory security-policy response codes for use when negotiating 193 TLS over Telnet. 195 Conventions Used in this Document 197 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 198 "MAY" in this document are to be interpreted as described in [KEYWORDS ]. 200 Formal syntax is defined using ABNF [ANBF ]. 202 In examples, "C:" and "S:" indicate lines sent by the the client and 203 server, respectively. 205 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 207 2 Telnet STARTTLS Option and Subnegotiation 209 The STARTTLS option is an asymmetric option, with only the server side 210 being able to send IAC DO STARTTLS. The client may initiate by sending 211 IAC WILL STARTTLS. There are some more rules due to the need to clear the 212 link of data (or to synchronize the link). This synchronization takes 213 the form of a three-way handshake: 215 1. As per normal Telnet option processing rules, the client MUST 216 respond to the server's IAC DO STARTTLS with either IAC WONT 217 STARTTLS or IAC WILL STARTTLS (if it hasn't already done so). An 218 affirmative response MUST be followed eventually by IAC SB STARTTLS 219 FOLLOWS IAC SE. If the client sends the affirmative response, it 220 must then not initiate any further Telnet options or subnegotiations 221 except for the STARTTLS subnegotiation until after the TLS 222 negotiation has completed. 224 2. The server SHOULD NOT send any more Telnet data or commands after 225 sending IAC DO STARTTLS except in response to client Telnet options 226 received until after it receives either a negative response from the 227 client (IAC WONT STARTTLS) or the affirmative (both IAC WILL 228 STARTTLS and followed eventually by IAC SB STARTTLS FOLLOWS IAC SE). 229 If the client's STARTTLS option response is negative, the server is 230 free to again send Telnet data or commands. If the client's response 231 is affirmative, then the server MUST send only IAC SB STARTTLS 232 FOLLOWS IAC SE. If the server sends IAC SB STARTTLS FOLLOWS IAC SE, 233 then the server MUST also arrange at this time, for the normal Telnet 234 byte-stuff/destuff processing to be turned off for the duration of 235 the TLS negotiation. 237 3. The client, upon receipt of the server's IAC SB STARTTLS FOLLOWS IAC 238 SE, MUST also arrange for normal Telnet byte-stuff/destuff 239 processing to be turned off for the duration of the TLS negotiation. 240 It MUST then enter into TLS negotiation by sending the TLS 241 ClientHello message. 243 Here's a breakdown of the Telnet command phrases defined in this 244 document: 246 S: IAC DO STARTTLS-- Sent only by server. Indicates that server strongly 247 desires that the client enter into TLS negotiations. 249 C: IAC WILL STARTTLS-- Sent only by client. Indicates that client 250 strongly desires that the server enter into TLS negotiations. 252 S: IAC DONT STARTTLS-- Sent only by the server. Indicates that the 253 server is not willing to enter into TLS negotations. 255 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 257 C: IAC WONT STARTTLS-- Sent only by the client. Indicates that the 258 client is not willing to enter into TLS negotiations. 260 C: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the client, this 261 indicates that the client is preparing for TLS negotiations, and 262 that the next thing sent by the client will be the TLS ClientHello. 263 Also indicates that the client has reset its Telnet state. 265 S: IAC SB STARTTLS FOLLOWS IAC SE-- When sent by the server, this 266 indicates that the server has prepared to receive the TLS 267 ClientHello from the client. Also indicates that the server has 268 reset its Telnet state. 270 2.1 Abnormal Negotiation Failure 272 The behavior regarding TLS negotiation failure is covered in [TLS ], and 273 does not indicate that the TCP connection be broken; the semantics are 274 that TLS is finished and all state variables cleaned up. The TCP 275 connection may be retained. 277 If this happens, the two sides may continue the Telnet connection. 278 Here's how: 280 o The side which received the TLS ErrorAlert message speaks first; 282 o The first speaker can send any Telnet data or commands; 284 o Neither side SHOULD attempt to issue another STARTTLS during the 285 lifetime of the Telnet session. 287 [Author's question: Is it possible that TLS data could still be on the 288 wire if the negotiation fails? If so, then this continuation of session 289 is not possible, since unintended data could be injected into the 290 stream.] 292 2.2 Assigned Values for STARTTLS Negotiation 294 The assigned value of the Telnet STARTTLS option octet is 46. The 295 assigned value of the FOLLOWS subnegotiation octet is 1. In ABNF, this 296 is: 298 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 300 STARTTLS = %d46 301 FOLLOWS = %d1 303 3 Telnet Authentication and Authorization 305 Telnet servers and clients can be implemented in a variety of ways that 306 impact how clients and servers authenticate and authorize each other. 307 However, most (if not all) the implementations can be abstracted via the 308 following four communicating processes: 310 SES Server End System. This is an application or machine to which client 311 desires a connection. Though not illustrated here, a single Telnet 312 connection between client and server could have multiple SES 313 terminations. 315 Server The Telnet server. 317 Client The Telnet client, which may or may not be co-located with the 318 CES. The Telnet client in fact be a gateway or proxy for downstream 319 clients; it's immaterial. 321 CES Client End System. The system communicating with the Telnet Client. 322 There may be more than one actual CES communicating to a single 323 Telnet Client instance; this is also immaterial to how Client and 324 Server can sucessfully exchange authentication and authorization 325 details. However, see Section 5.3 for a discussion on trust 326 implications. 328 What is of interest here is how the Client and Server can exchange 329 authentication and authorization details such that these components can 330 direct Telnet session traffic to authorized End Systems in a reliable, 331 trustworthy fashion. 333 What is beyond the scope of this specification are several related 334 topics, including: 336 o How the Server and SES are connected, and how they exchange data or 337 information regarding authorization or authentication (if any). 339 o How the Client and CES are connected, and how they exchange data or 340 information regarding authorization or authentication (if any). 342 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 344 4 TLS, Authentication and Authorization 346 System-to-system communications using the Telnet protocol have 347 traditionally used no authentication techniques at the Telnet level. 348 More recent techniques have used Telnet to transport authentication 349 exchanges (e.g.[TLSKERB ]). In none of these systems, however, is a 350 remote system allowed to assume more than one identity once the Telnet 351 preamble negotiation is over and the remote is connected to the 352 application-endpoint. The reason for this is that the local party must 353 in some way inform the end-system of the remote party's identity (and 354 perhaps authorization). This process must take place before the remote 355 party starts communicating with the end-system. At that point it's too 356 late to change what access a client may have to an server end-system: 357 that end-system has been selected, resources have been allocated and 358 capability restrictions set. 360 [Author's note: I dislike providing state models of how local systems 361 should behave in relation to a wire protocol; it seems to me that such 362 models often do more harm than good when describing a wire protocol. The 363 model often misrepresents reality, and/or makes unnecessarily limiting 364 assumptions about implementation behavior. However, the alternative 365 methods of explanation seemed even less useful in this case....] 367 This process of authentication, authorization and resource allocation 368 can be modeled (one hopes!) by the following simple set of states and 369 transitions: 371 `unauthenticated' The local party has not received any credentials 372 offered by the remote. A new Telnet connection starts in this state. 374 The `authenticating' state will be entered from this state if the 375 local party initiates the authentication process of the peer. The 376 Telnet STARTTLS negotiation is considered an initiation of the 377 authentication process. 379 The `authorizing' state will be entered from this state either if 380 the local party decides to begin authorizatin and resource 381 allocation procedures unilaterally...or if the local party has 382 received data from the remote party destined for local end-system. 384 `authenticating' The local party has received at least some of the 385 credentials needed to authenticate its peer, but has not finished 386 the process. 388 The `authenticated' state will be entered from this state if the 389 local party is satisfied with the credentials proferred by the 390 client. 392 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 394 The `unauthenticated' state will be entered from this state if the 395 local party cannot verify the credentials proffered by the client or 396 if the client has not proffered any credentials. Alternately, the 397 local party may terminate the Telnet connection instead of returning 398 it to the `unauthenticated' state. 400 `authenticated' The local party has authenticated its peer, but has not 401 yet authorized the client to connect to any end-system resources. 403 The `authenticating' state will be entered from this state if the 404 local party decides that further authentication of the client is 405 warranted. 407 The `authorizing' state will be entered from this state if the local 408 party either initiates authorization dialog with the client (or 409 engages in some process to authorize and allocate resources on 410 behalf of the client), or has received data from the remote party 411 destined for a local end-system. 413 `authorizing' The local party is in the process of authorizing its peer 414 to use end-system resources, or may be in the process of allocating 415 or reserving those resources. 417 The `transfer-ready' state will be entered when the local party is 418 ready to allow data to be passed between the local end-system and 419 remote peer. 421 The `authenticated' state will be entered if the local party 422 determines that the current authorization does not allow any access 423 to a local end-system. If the remote peer is not currently 424 authenticated, then the `unauthenticated' state will be entered 425 instead. 427 `transfer-ready' The party may pass data between the local end-system to 428 its peer. 430 The `authorizing' state will be entered if the local party (perhaps 431 due to a request by the remote peer) deallocates the communications 432 resources to the local-end system. Alternately, the local party may 433 enter the `authenticated' or the `unauthenticated' state. 435 In addition to the "orderly" state transitions noted above, some 436 extraordinary transitions may also occur: 438 1. The absence of a guarantee on the integrity of the data stream 439 between the two Telnet parties also removes the guarantee that the 440 remote peer is who the authentication credentials say the peer is. 441 Thus, upon being notified that the Telnet session is no longer using 442 an integrity layer, the local party must deallocate all resources 444 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 446 associated with a Telnet connection which would not have been 447 allocable had the remote party never authenticated itself. 449 This may mean that the states may transition from whatever the 450 current state is to `unauthenticated'. Alternately, the local party 451 may break the Telnet connection instead. 453 2. If the local party is notified at any point during the Telnet 454 connection that the remote party's authorizations have been reduced 455 or revoked, then the local party must treat the remote party as being 456 unauthenticated. The local party must deallocate all resources 457 associated with a Telnet connection which would not have been 458 allocable had the remote party never authenticated itself. 460 This too may mean that the states may transition from whatever the 461 current state is to `unauthenticated'. Alternately, the local party 462 may break the Telnet connection instead. 464 The above model explains how each party should handle the authentication 465 and authorization information exchanged during the lifetime of a Telnet 466 connection. It is deliberately fuzzy as to what constitutes internal 467 processes (such as "authorizing") and what is meant by "resources" or 468 "end-system" (such as whether an end-system is strictly a single entity 469 and communications path to the local party, or multiples of each, etc). 471 Here's a state transition diagram, as per [RFC2360 ]: 473 0 1 2 3 4 474 Events | unauth auth'ing auth'ed authorizing trans-ready 475 -----------+-------------------------------------------------------- 476 auth-needed| sap/1 sap/1 sap/1 sap/1 der,sap/1 477 auth-accept| - ain/2 - - - 478 auth-bad | - 0 wa/0 wa,der/0 der,sap/1 479 authz-start| szp/3 - szp/3 - - 480 data-rcvd | szp/3 qd/1 szp/3 qd/3 pd/4 481 authz-ok | - - - 4 - 482 authz-bad | - - - der/2 wa,der,szp/3 484 Action | Description 485 -------+-------------------------------------------- 486 sap | start authentication process 487 der | deallocate end-system resources 488 ain | authorize if needed 489 szp | start authorization process 490 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 492 qd | queue incoming data 493 pd | process data 494 wa | wipe authorization info 496 Event | Description 497 -------------+--------------------------------------------------- 498 auth-needed | authentication deemed needed by local party 499 auth-accept | remote party's authentication creds accepted 500 auth-bad | remote party's authentication creds rejected or expired 501 authz-start | local or remote party starts authorization proceedings 502 data-rcvd | data destined for end-system received from remote party 503 authz-ok | authorization and resource allocation succeeded 504 authz-bad | authorization or resource allocation failed or expired 506 4.1 Authentication of the remote party 508 If TLS has been successfully negotiated, the client will have the 509 server's certificate. This indicates that the server's identity can be 510 verified. Client implementations MUST always verify the server identity 511 as part of TLS processing and fail the connection if such verification 512 fails. See Section 5.1 for a general discussion of the server 513 authentication apropos Telnet clients. 515 The server, however, may not have the client's identity (verified or 516 not). This is because the client need not provide a certificate during 517 the TLS exchange. Or it may be server site policy not to use the identity 518 so provided. In any case, the server may not have enough confidence in 519 the client to move the connection to the authenticated state. 521 If further client, server or client-server authentication is going to 522 occur after TLS has been negotiated, it MUST occur before any 523 non-authentication-related Telnet interactions take place on the link 524 after TLS starts. When the first non-authentication-related Telnet 525 interaction is received by either participant, then the receiving 526 participant MAY drop the connection due to dissatisfaction with the 527 level of authentication. 529 If the server wishes to request a client certificate after TLS is 530 initially started (presumably with no client certificate requested), it 531 may do so. However, the server SHOULD make such a request immediately 532 after the initial TLS handshake is complete. 534 No TLS negotiation outcome, however trustworthy, will by itself provide 535 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 537 the server with the authorization identity if that is different from the 538 authentication identity of the client. See [SASL ] for why this might be 539 a desirable function to have with proxy clients, etc. How such 540 authorization is done is outside the scope of this document. 542 The following subsections detail how the client can provide the server 543 with authentication and authorization credentials separate to the TLS 544 mechanism. 546 4.2 PKI-based Authentication and certificate extensions 548 When PKI authentication is used no special X.509 certificate extensions 549 will be require but a client or server may choose to support an extension 550 if found. For example, they may use a contained certificate revocation 551 URL extension if provided. The intent is to allow sharing of 552 certificates with other services on the same host, for example, a Telnet 553 server might use the same certificate to identify itself that a 554 co-located WEB server uses. The method of sharing certificates is 555 outside the scope of this document. 557 An X.509 certificate received by a client may include the 558 `subjectAltName' extension. If this extension is present and contains a 559 `dNSName' object, then the client MUST check the hostname used to 560 connect to the host against the dNSName found in the certificate. The 561 method used is outlined in [TLSHTTP ]. 563 4.3 Pre-TLS Authentication 565 It could be that the server had moved the Telnet connection to the 566 authenticated state sometime previous to the negotiation of TLS. If this 567 is the case, then the server MUST NOT use the credentials proffered by 568 the client during the TLS negotiations for authorization of that client. 569 The server should, of course, verify the client's TLS-proffered 570 credentials. 572 5 Security 574 Security is discussed throughout this document. Most of this document 575 concerns itself with wire protocols and security frameworks. But in this 576 section, client and server implementation security issues are in focus. 578 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 580 5.1 Authentication of the Server by the Client 582 How the client can verify the server's proferred identity varies 583 according to the key-exchange algorithm used in the selected TLS 584 cipher-suite. However, it's important for the client to follow good 585 security practice in verifying the proffered identity of the server. 587 5.1.1 PKI-based certificate processing 589 When PKI authentication is used no special X.509 certificate extensions 590 will be required but a client or server may choose to support an 591 extension if found. For example, they may use a contained certificate 592 revocation URL extension if provided. The intent is to allow sharing of 593 certificates with other services on the same host, for example, a Telnet 594 server might use the same certificate to identify itself that a 595 co-located WEB server uses. The method of sharing certificates is not a 596 topic of this document. 598 The verification of the server's certificate by the client MUST include, 599 but isn't limited to, the verification of the signature certificate 600 chain to the point where the a signature in that chain uses a known good 601 signing certificate in the clients local key chain. The verification 602 SHOULD then continue with a check to see if the fully qualified host name 603 which the client connected to appears anywhere in the server's 604 certificate subject (DN). If no match is found then the end user should 605 see a display of the servers certificate and be asked if he/she is 606 willing to proceed with the session. If the client side of the service is 607 not interactive with a human end-user, the Telnet connection SHOULD be 608 dropped if this host check fails. 610 5.1.2 Kerberos V5 server verification 612 [Nothing here yet. Just a placeholder to show everybody that PKI-based 613 authentication is not the only game in town.] 615 5.2 Display of security levels 617 The Telnet client and server MAY, during the TLS protocol negotiation 618 phase, choose to use a weak cipher suite due to policy, law or even 619 convenience. It is, however, important that the choice of weak cipher 620 suite be noted as being commonly known to be vulnerable to attack. In 621 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 623 particular, both server and client software should note the choice of 624 weak cipher-suites in the following ways: 626 o If the Telnet endpoint is communicating with a human end-user, the 627 user-interface SHOULD display the choice of weak cipher-suite and 628 the fact that such a cipher-suite may compromise security. 630 o The Telnet endpoints SHOULD log the exact choice of cipher-suite as 631 part of whatever logging/accounting mechanism normally used. 633 5.3 Trust Relationships and Implications 635 Authentication and authorization of the remote Telnet party is useful, 636 but can present dangers to the authorizing party even if the connection 637 between the client and server is protected by TLS using strong 638 encryption and mutual authentication. This is because there are some 639 trust-relationships assumed by one or both parties: 641 o Each side assumes that the authentication and authentication details 642 proferred by the remote party stay constant until explicitly changed 643 (or until the TLS session is ended). 645 o More stringently, each side trusts the other to send a timely 646 notification if authentication or authorization details of the other 647 party's end system(s) have changed. 649 Either of these trust relationships may be false if an intruder has 650 breached communications between a client or server and its respective 651 end system. And either may be false if a component is badly implemented 652 or configured. Implementers should take care in program construction to 653 avoid invalidating these trust relationships, and should document to 654 configuring-users the proper ways to configure the software to avoid 655 invalidation of these relationships. 657 6 TLS Variants and Options 659 TLS has different versions and different cipher suites that can be 660 supported by client or server implementations. The following 661 subsections detail what TLS extensions and options are mandatory. The 662 subsections also address how TLS variations can be accommodated. 664 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 666 6.1 Support of previous versions of TLS 668 TLS has its roots in SSL 2.0 and SSL 3.0. Server and client 669 implementations may wish to support for SSL 3.0 as a fallback in case TLS 670 3.1 or higher is not supported. This is permissible; however, client 671 implementations which negotiate SSL3.0 MUST still follow the rules in 672 Section 5.2 concerning disclosure to the end-user of transport-level 673 security characteristics. 675 Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; it 676 is detailed in [TLS ]. Negotiating SSL 2.0 is not recommended. 678 6.2 Using Kerberos V5 with TLS 680 If the client and server are both amenable to using Kerberos V5, then 681 using non-PKI authentication techniques within the confines of TLS may 682 be acceptable (see [TLSKERB ]). Note that clients and servers are under 683 no obligation to support anything but the cipher-suite(s) mandated in 684 [TLS ]. However, if implementations do implement the KRB5 authentication 685 as a part of TLS ciphersuite, then these implementations SHOULD support 686 at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite. 688 7 Protocol Examples 690 The following sections provide skeletal examples of how Telnet clients 691 and servers can negotiate TLS. 693 7.1 Successful TLS negotiation 695 The following protocol exchange is the typical sequence that starts TLS: 697 // typical successful opening exchange 698 S: IAC DO STARTTLS 699 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 700 S: IAC SB STARTTLS FOLLOWS IAC SE 701 // server now readies input stream for non-Telnet, TLS-level negotiation 702 C: [starts TLS-level negotiations with a ClientHello] 703 [TLS transport-level negotiation ensues] 705 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 707 [TLS transport-level negotiation completes with a Finished exchanged] 708 // either side now able to send further Telnet data or commands 710 7.2 Successful TLS negotiation, variation 712 The following protocol exchange is the typical sequence that starts TLS, 713 but with the twist that the (TN3270E) server is willing but not 714 aggressive about doing TLS; the client strongly desires doing TLS. 716 // typical successful opening exchange 717 S: IAC DO TN3270E 718 C: IAC WILL STARTTLS IAC 719 S: IAC DO STARTTLS 720 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 721 S: IAC SB STARTTLS FOLLOWS IAC SE 722 // server now readies input stream for non-Telnet, TLS-level negotiation 723 C: [starts TLS-level negotiations with a ClientHello] 724 [TLS transport-level negotiation ensues] 725 [TLS transport-level negotiation completes with a Finished 726 exchanged] 727 // note that server retries negotiation of TN3270E after TLS 728 // is done. 729 S: IAC DO TN3270E 730 C: IAC WILL TN3270E 731 // TN3270E dialog continues.... 733 7.3 Unsuccessful TLS negotiation 735 This example assumes that the server does not wish to allow the Telnet 736 session to procede without TLS security; however, the client's version 737 of TLS does not interoperate with server's. 739 //typical unsuccessful opening exchange 740 S: IAC DO STARTTLS 741 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 742 S: IAC SB STARTTLS FOLLOWS IAC SE 743 // server now readies input stream for non-Telnet, TLS-level negotiation 744 C: [starts TLS-level negotiations with a ClientHello] 745 [TLS transport-level negotiation ensues] 746 [TLS transport-level negotiation fails with server sending 748 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 750 ErrorAlert message] 751 C: IAC DO TERMINAL-TYPE 752 S: IAC WONT TERMINAL-TYPE 753 S: [TCP level disconnect] 754 // server (or both) initiate TCP session disconnection 756 This example assumes that the server wants to do TLS, but is willing to 757 allow the session to procede without TLS security; however, the client's 758 version of TLS does not interoperate with server's. 760 //typical unsuccessful opening exchange 761 S: IAC DO STARTTLS 762 C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE 763 S: IAC SB STARTTLS FOLLOWS IAC SE 764 // server now readies input stream for non-Telnet, TLS-level negotiation 765 C: [starts TLS-level negotiations with a ClientHello] 766 [TLS transport-level negotiation ensues] 767 [TLS transport-level negotiation fails with server sending 768 ErrorAlert message] 769 C: IAC DO TERMINAL-TYPE 770 S: IAC WILL TERMINAL-TYPE 771 // regular Telnet dialog ensues 773 References 774 ---------- 776 [ANBF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 777 Specifications: ABNF", RFC2235, November 1997. 779 [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate 780 Requirement Levels", RFC2119, March 1997. 782 [RFC927] Brian A. Anderson. "TACACS User Identification Telnet 783 Option", RFC927, December 1984 785 [RFC1416] D. Borman, Editor. "Telnet Authentication Option", RFC1416, 786 February 1993. 788 [SASL] Myers, J. "Simple Authentication and Security Layer (SASL)", 789 RFC2222, October 1997. 791 [RFC2360] G. Scott, Editor. "Guide for Internet Standard Writers", 792 RFC2360, June 1998. 794 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specifications", 795 RFC854, May 1983. 797 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 799 [TLS] Tim Dierks. "The TLS Protocol", Internet Draft, November 800 1997. 802 [TLSKERB] Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher 803 Suites to Transport Layer Security (TLS)", Internet Draft, 804 July 1997. 806 [TLSHTTP] E. Rescorla. "HTTP Over TLS", Internet Draft 807 , March 1998. 809 Author's Address 810 ---------------- 812 Michael Boe 813 Cisco Systems Inc. 814 1264 5th Avenue 815 San Francisco, CA 94122-2649 817 Email: Michael Boe 819 Full Copyright Statement 821 Copyright (c) The Internet Society (1998). All Rights Reserved. 823 This document and translations of it may be copied and furnished to 824 others, and derivative works that comment on or otherwise explain it or 825 assist in its implementation may be prepared, copied, published and 826 distributed, in whole or in part, without restriction of any kind, 827 provided that the above copyright notice and this paragraph are included 828 on all such copies and derivative works. However, this document itself 829 may not be modified in any way, such as by removing the copyright notice 830 or references to the Internet Society or other Internet organizations, 831 except as needed for the purpose of develop- ing Internet standards in 832 which case the procedures for copyrights defined in the Internet 833 Standards process must be followed, or as required to translate it into 834 languages other than English. 836 The limited permissions granted above are perpetual and will not be 837 revoked by the Internet Society or its successors or assigns. 839 This document and the information contained herein is provided on an "AS 840 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 841 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 842 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 843 I-D draft-ietf-telnet-tls-01 TLS-based Telnet Security September, 1998 845 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 846 FITNESS FOR A PARTICULAR PURPOSE. 848 Expiration of Draft 850 This draft expires at the end of February, 1999.