idnits 2.17.1 draft-ietf-tn3270e-telnet-tls-05.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 976 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 71 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 568 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 (April 2001) is 8412 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ABNF' is mentioned on line 290, but not defined == Missing Reference: 'RFC 2459' is mentioned on line 624, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Unused Reference: 'ANBF' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC927' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 1100, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2235 (ref. 'ANBF') ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 10 errors (**), 0 flaws (~~), 9 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-05.txt Jeffrey Altman 3 expires April 2001 4 October 24, 2000 6 TLS-based Telnet Security 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that the other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced or obsoleted by other documents at any time. 18 Its is inappropriate to use Internet-Drafts as reference material or to 19 cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (1998 - 2000). All Rights Reserved. 31 Abstract 33 Telnet service has long been a standard Internet protocol. However, a 34 standard way of ensuring privacy and integrity of Telnet sessions has 35 been lacking. This document proposes a standard method for Telnet 36 servers and clients to use the Transport Layer Security (TLS) protocol. 37 It describes how two Telnet participants can decide whether or not to 38 attempt TLS negotiation, and how the two participants should process 39 authentication credentials exchanged as a part of TLS startup. 41 Changes since -04 Draft 43 Incorporated changes submitted by Eric Rescorla and Russ Housley. 44 Mostly minor in nature except for an expansion of the text in 45 section 4.1.1 on how certificate verification should be performed. 46 This section was taken almost verbatim from RFC 2818. 48 Minor changes include: 50 . change MUST to SHOULD in section 3.2 52 . clarification to reference to Kerberos cipher suites in 4.1.1 54 . expansion of discussion on mutual authentication via Telnet 55 AUTH in section 4.1.3. 57 . both client and server should shutdown connection upon error 58 detection in section 4.1.3 60 . correction to name of PKIX Working Group in section 5.1 62 . expansion of discussion of finished message discussion in 5.2. 64 . TLS 3.1 replaced by TLS 1.0 in section 6.1 66 . removal of "dangerous to encrypt twice" comment from 7.0 68 . expansion of references. 70 Changes since -03 Draft 72 Major changes to sections describing authentication of clients 73 and servers. 75 Changes since -02 Draft 77 o Clarify server actions in response to client initiating the TLS 78 negotiation. 80 o Replace the parochial term "mainframe" with "application-server." 82 o Nuke explicit references to RFC1416, since there's a new RFC in the 83 works for this and the reference isn't normative anyway. 85 o Use dNSName language similar to that used in the most recent HTTP TLS 86 draft. 88 o Delete beginning paragraph describing server-authentication in TLS. 89 Unclear and possibly wrong. 91 o Delete explicit references to SASL, since we don't actually describe 92 ways of using SASL. 94 o Add section describing interaction between AUTH and STARTTLS option 95 negotiations. 97 Changes since -01 Draft 98 o Drop possibility of a continuing a Telnet session if the TLS 99 negotiation fails. 101 o Assert that server sending DO STARTTLS must be willing to negotiate 102 a TLS session 104 o Change SHOULD to MUST with respect to a server requesting a client 105 certificate. 107 o Add paragraph on commonName to section on check of X.509 108 certificate. 110 o Sharpen language concerning notification of possible 111 server-certificate mismatch. 113 o drop place-holder section on Kerberos 5 security; replace with 114 section on non-PKI-based authentication (after TLS negotiation). 116 o Prohibit fallback to SSL 2.0. 118 o Give more details about how authentication-after-TLS-negotiation 119 can be achieved. 121 o Simplify post-TLS Telnet negotiation state-assumptions by resetting 122 them to initial-state. 124 Changes since -00 Draft 125 o Add local authentication/authorization operational model. 127 o Change behavior of Telnet machine to reset at start of TLS 128 negotiation. 130 o Insert narrative questioning the utility of allowing continuation of 131 Telnet session after TLS has ended. 133 o change examples to reflect the above changes. 135 o Fix several typos. 137 Contents 139 1 Introduction 141 2 Command Names and Codes (assigned by IANA) 143 3 Command Meanings 145 3.1 Usage of commands and interactions with other Telnet options 147 3.2 TLS Negotiation Failure 149 4 Authentication and Authorization 151 4.1 Authentication of the Client by the Server 153 4.1.1 PKI-based Authentication via TLS handshake 155 4.1.2 Non-PKI Authentication via TLS handshake 157 4.1.3 Telnet AUTH option 159 4.1.4 Traditional Username and Password 161 4.2 Authentication of the Server by the Client 163 4.2.1 PKI-based Authentication via TLS handshake 165 4.2.2 Non-PKI based authentication via TLS handshake 167 4.2.3 Authentication by Telnet AUTH option 169 5 Security 171 5.1 PKI-based certificate processing . . . 173 5.2 Client and Server authentication of anonymous TLS connections 175 5.3 Display of security levels . . . . . . 177 5.4 Trust Relationships and Implications . . . . 179 5.5 Telnet negotation handling 181 6 TLS Variants and Options 183 6.1 Support of previous versions of TLS . . . . 185 6.2 Using Kerberos V5 with TLS . . . . . . 187 7 Protocol Examples 189 7.1 Successful TLS negotiation . . . . . . 191 7.2 Successful TLS negotiation, variation . . . . 193 7.3 Unsuccessful TLS negotiation . . . . . . 195 7.4 Authentication via Telnet Auth Kerberos 4 after TLS negotiation 197 8 References 199 9 Authors 200 1 Introduction 202 This document describes the START_TLS Telnet option. It allows TLS 203 to be activated at the beginning of a Telnet connection to provide 204 authentication and confidentiality of the Telnet session. This document 205 also defines a set of advisory security policy response codes for use 206 when negotiating TLS from within Telnet. 208 We are interested in addressing the interaction between the Telnet 209 client and server that will support this secure requirement with the 210 knowledge that this is only a portion of the total end-user to 211 application path. Specifically, it is often true that the Telnet server 212 does not reside on the target machine (it does not have access to a list 213 of identities which are allowed to access to that application-server), 214 and it is often true (e.g. 3270 access) that the telnet server can not 215 even identify that portion of the emulation stream which contains user 216 identification/password information. Additionally, it may be the case 217 that the Telnet client is not co-resident with the end user and that it 218 also may be unable to identify that portion of the data stream that deals 219 with user identity. We make the assumption here that there is a trust 220 relationship and appropriate protection to support that relationship 221 between the Telnet Server and the ultimate application engine such that 222 data on this path is protected and that the application will authenticate 223 the end user via the emulation stream as well as use this to control 224 access to information. We further make the assumption that the path 225 between the end user and the client is protected. 227 To hold up the Telnet part of the overall secure path between the user 228 and the application-server, the Telnet data stream must appear 229 unintelligible to a third party. This is done by creating a shared 230 secret between the client and server. This shared secret is used to 231 encrypt the flow of data and (just as important) require the client to 232 verify that it is talking to correct server (the one that the 233 application-server trusts rather than an unintended man-in-the-middle) 234 with the knowledge that the emulation stream itself will be used by the 235 application-server to verify the identity of the end-user. Rather than 236 create a specialized new protocol which accomplishes these goals we 237 instead have chosen to use an existing IETF protocol, Transport Layer 238 Security (TLS) (formerly known as Secure Sockets Layer (SSL)). 240 The Telnet [TELNET] application protocol can certainly benefit from the 241 use of TLS. Since 1992 Telnet has supported over a dozen forms of 242 end user authentication and DES encryption via the AUTH and ENCRYPT 243 options. Since 1995, TLS (as SSL) has been used to provide privacy and 244 integrity protection to Telnet data streams via Telnet AUTH and via 245 dedicated IANA assigned port numbers (telnets 992). TLS offers a broad 246 range of security levels that allow sites to proceed at an "evolutionary" 247 pace in deploying authentication, authorization and confidentiality 248 policies, databases and distribution methods. 250 This document describes how TLS can be used to provide the following: 252 o creation and refresh of a shared secret; 254 o negotiation and execution of data encryption and optional 255 compressesion; 257 o primary negotiation of authentication; and, if chosen 259 o execution of public-key or symmetric-key based authentication. 261 TLS at most offers only authentication of the peers conducting the TLS 262 dialog. In particular, it does not offer the possibility of the client 263 providing separate credentials for authorization than were presented for 264 authentication. After the establishment of peer to peer trust based 265 on TLS, other forms of end user authentication including Telnet AUTH 266 may be used to provide credentials for use in determining end user 267 authorization. 269 Traditional Telnet servers have operated without such early presentation 270 of authorization credentials for many reasons (most of which are 271 historical). However, recent developments in Telnet server technology 272 make it advantageous for the Telnet server to know the authorized 273 capabilities of the remote client before choosing a communications link 274 (be it `pty' or SNA LU) and link-characteristics to the host system (be 275 that "upstream" link local or remote to the server). Thus, we expect to 276 see the use of client authorization to become an important element of the 277 Telnet evolution. Such authorization methods may require certificates 278 presented by the client via TLS, or by the use of Telnet AUTH option, or 279 some other as yet unstandardized method. 281 This document describes the START_TLS telnet option which allows TLS to 282 be activated at the beginning of a Telnet connection using the standard 283 "telnet" port (IANA tcp\23). It also defines a set of advisory security- 284 policy response codes for use when negotiating TLS over Telnet. 286 Conventions Used in this Document 287 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 288 "MAY" in this document are to be interpreted as described in [KEYWORDS]. 290 Formal syntax is defined using ABNF [ABNF]. 292 In examples, "C:" and "S:" indicate lines sent by the the client and 293 server, respectively. 295 2 Command Names and Codes (assigned by IANA) 297 START_TLS 46 (decimal) 299 FOLLOWS 1 (decimal) 301 3 Command Meanings 303 This document makes reference to a "server" and a "client". For the 304 purposes of this document, the "server" is the side of the connection 305 that did the passive TCP open (TCP LISTEN state), and the "client" is 306 the side of the connection that did the active open. 308 IAC DONT START_TLS 310 The sender is either not a server or is not interested in 311 negotiating a TLS connection. 313 IAC WONT START_TLS 315 The sender is either not a client or is not interested in 316 negotiating a TLS connection. 318 IAC DO START_TLS 320 The server side of the connection sends this command to indicate 321 a desire to negotiate a TLS connection. This command MUST NOT 322 be sent by the client and if received by the server MUST be refused 323 with IAC WONT START_TLS. 325 IAC WILL START_TLS 327 The client side of the connection sends this command to indicate 328 a desire to negotiate a TLS connection. This command MUST NOT 329 be sent by the server and if received by the client MUST be refused 330 with IAC DONT START_TLS. 332 IAC SB START_TLS FOLLOWS IAC SE 334 The FOLLOWS sub-command when sent indicates that the next byte of 335 data received after this command MUST be a TLS negotiation as 336 described in [TLS]. This sub-command is sent by both the client and 337 the server. After this sub-command has been sent, the sender MUST NOT 338 respond to nor initiate any additional telnet commands or 339 sub-commands. When this sub-command has been sent and received the 340 TLS negotiation will commence. When sent by a client this sub- 341 command will be followed by a TLS ClientHello. When sent by a server 342 this sub-command will be followed by a TLS ServerHello. 344 3.1 Usage of commands and interactions with other Telnet options 346 The START_TLS option is an asymmetric option, with the server side 347 allowed to send IAC DO START_TLS and the client allowed to send 348 IAC WILL START_TLS. Sub-commands are used to synchronize the link 349 in preparation for negotiating TLS. This synchronization takes 350 the form of a three-way handshake: 352 1. As per normal Telnet option processing rules, the client MUST 353 respond to the server's IAC DO START_TLS with either IAC WONT 354 START_TLS or IAC WILL START_TLS (if it hasn't already done so). 355 Once the client has sent IAC WILL START_TLS and received 356 IAC DO START_TLS, it MUST immediately send a FOLLOWS sub-command 357 (IAC SB START_TLS FOLLOWS IAC SE) to indicate it is ready to begin 358 a TLS negotiation. Once the FOLLOWS sub-command has been sent, the 359 client MUST ignore all telnet negotiations except for the FOLLOWS 360 sub-command. When the FOLLOWS sub-command has been received the 361 client MUST halt use of the telnet protocol, reset the telnet state 362 machine and begin a TLS negotiation by sending a ClientHello message. 364 2. If the client initiates by sending IAC WILL START_TLS, the server 365 MUST respond with either IAC DO START_TLS or IAC DONT START_TLS. 367 3. The server SHOULD NOT send additional Telnet data or commands after 368 sending IAC DO START_TLS except in response to client Telnet options 369 received until after it receives either a negative response from the 370 client (IAC WONT START_TLS) or a successful negotiation of TLS has 371 occurred. If the client's START_TLS option response is negative, the 372 server is free to send additional Telnet data or commands. If the 373 client's response is affirmative (IAC WILL START_TLS), then the server 374 MUST send the FOLLOWS sub-command (IAC SB START_TLS FOLLOWS IAC SE) 375 and await the FOLLOWS sub-command from the client. When the FOLLOWS 376 sub-command has been sent and received the server MUST halt use of the 377 telnet protocol, reset the telnet state machine, and begin a TLS 378 negotiation by sending a TLS ServerHello message. 380 4. If both START_TLS and AUTH [AUTH] are offered, START_TLS SHOULD be sent 381 first and MUST take precedence if both are agreed to. AUTH MAY be 382 renegotiated after successful establishment of the TLS session if 383 end-user authentication via a supported method is desired. 385 5. If a TLS session has been established, the ENCRYPT [ENCRYPT] option 386 MUST NOT be negotiated in either direction. 388 6. When the FOLLOWS sub-command has been sent and received the Telnet 389 state machine is reset. This means that the state of all telnet 390 options is reset to the WONT/DONT state and any data received via 391 subcommands is forgotten. After a sucessful TLS negotiation the 392 Telnet negotiations will be restarted as if a new connection had 393 just been established with one exception. Since TLS is already in 394 use, the START_TLS option MUST NOT be negotiated. 396 3.2 TLS Negotiation Failure 398 The behavior regarding TLS negotiation failure is covered in [TLS], and 399 does not indicate that the TCP connection be broken; the semantics are 400 that TLS is finished and all state variables cleaned up. The TCP connection 401 may be retained. 403 However, it's not clear that either side can detect when the last of the 404 TLS data has arrived. So if TLS negotiation fails, the TCP connection 405 SHOULD be reset and the client MAY reconnect. To avoid infinite loops of 406 TLS negotiation failures, the client MUST remember to not negotiate 407 START_TLS if reconnecting due to a TLS negotiation failure. 409 4 Telnet Authentication and Authorization 411 Telnet servers and clients can be implemented in a variety of ways that 412 impact how clients and servers authenticate and authorize each other. 413 However, most (if not all) the implementations can be abstracted via the 414 following four communicating processes: 416 SES Server End System. This is an application or machine to which client 417 desires a connection. Though not illustrated here, a single Telnet 418 connection between client and server could have multiple SES 419 terminations. 421 Server The Telnet server. 423 Client The Telnet client, which may or may not be co-located with the 424 CES. The Telnet client in fact be a gateway or proxy for downstream 425 clients; it's immaterial. 427 CES Client End System. The system communicating with the Telnet Client. 428 There may be more than one actual CES communicating to a single 429 Telnet Client instance; this is also immaterial to how Client and 430 Server can sucessfully exchange authentication and authorization 431 details. However, see Section 5.4 for a discussion on trust 432 implications. 434 What is of interest here is how the Client and Server can exchange 435 authentication and authorization details such that these components can 436 direct Telnet session traffic to authorized End Systems in a reliable, 437 trustworthy fashion. 439 What is beyond the scope of this specification are several related 440 topics, including: 442 o How the Server and SES are connected, and how they exchange data or 443 information regarding authorization or authentication (if any). 445 o How the Client and CES are connected, and how they exchange data or 446 information regarding authorization or authentication (if any). 448 System-to-system communications using the Telnet protocol have 449 traditionally used no authentication techniques at the Telnet level. 450 More recent techniques have used Telnet to transport authentication 451 exchanges (RFC 2941). In none of these systems, however, is a remote system 452 allowed to assume more than one identity once the Telnet preamble 453 negotiation is over and the remote is connected to the application- 454 endpoint. The reason for this is that the local party must in some way 455 inform the end-system of the remote party's identity (and perhaps 456 authorization). This process must take place before the remote party 457 starts communicating with the end-system. At that point it's too late 458 to change what access a client may have to an server end-system: that 459 end-system has been selected, resources have been allocated and 460 capability restrictions set. 462 This process of authentication, authorization and resource allocation 463 can be modeled by the following simple set of states and transitions: 465 `unauthenticated' The local party has not received any credentials 466 offered by the remote. A new Telnet connection starts in this state. 468 The `authenticating' state will be entered from this state if the 469 local party initiates the authentication process of the peer. The 470 Telnet START_TLS negotiation is considered an initiation of the 471 authentication process. 473 The `authorizing' state will be entered from this state either if 474 the local party decides to begin authorization and resource 475 allocation procedures unilaterally...or if the local party has 476 received data from the remote party destined for local end-system. 478 `authenticating' The local party has received at least some of the 479 credentials needed to authenticate its peer, but has not finished 480 the process. 482 The `authenticated' state will be entered from this state if the 483 local party is satisfied with the credentials proferred by the 484 client. 486 The `unauthenticated' state will be entered from this state if the 487 local party cannot verify the credentials proffered by the client or 488 if the client has not proffered any credentials. Alternately, the 489 local party may terminate the Telnet connection instead of returning 490 it to the `unauthenticated' state. 492 `authenticated' The local party has authenticated its peer, but has not 493 yet authorized the client to connect to any end-system resources. 495 The `authenticating' state will be entered from this state if the 496 local party decides that further authentication of the client is 497 warranted. 499 The `authorizing' state will be entered from this state if the local 500 party either initiates authorization dialog with the client (or 501 engages in some process to authorize and allocate resources on 502 behalf of the client), or has received data from the remote party 503 destined for a local end-system. 505 `authorizing' The local party is in the process of authorizing its peer 506 to use end-system resources, or may be in the process of allocating 507 or reserving those resources. 509 The `transfer-ready' state will be entered when the local party is 510 ready to allow data to be passed between the local end-system and 511 remote peer. 513 The `authenticated' state will be entered if the local party 514 determines that the current authorization does not allow any access 515 to a local end-system. If the remote peer is not currently 516 authenticated, then the `unauthenticated' state will be entered 517 instead. 519 `transfer-ready' The party may pass data between the local end-system to 520 its peer. 522 The `authorizing' state will be entered if the local party (perhaps 523 due to a request by the remote peer) deallocates the communications 524 resources to the local-end system. Alternately, the local party may 525 enter the `authenticated' or the `unauthenticated' state. 527 In addition to the "orderly" state transitions noted above, some 528 extraordinary transitions may also occur: 530 1. The absence of a guarantee on the integrity of the data stream 531 between the two Telnet parties also removes the guarantee that the 532 remote peer is who the authentication credentials say the peer is. 533 Thus, upon being notified that the Telnet session is no longer using 534 an integrity layer, the local party must at least deallocate all 535 resources associated with a Telnet connection which would not have 536 been allocable had the remote party never authenticated itself. 538 In practice, this deallocation-of-resources restriction is hard to 539 interpret consistently by both Telnet endpoints. Therefore, both 540 parties MUST return to the initial Telnet state after negotiation of 541 TLS. That is, it is as if the Telnet session had just started. 543 This means that the states may transition from whatever the current 544 state is to `unauthenticated'. Alternately, the local party may 545 break the Telnet connection instead. 547 2. If the local party is notified at any point during the Telnet 548 connection that the remote party's authorizations have been reduced 549 or revoked, then the local party must treat the remote party as being 550 unauthenticated. The local party must deallocate all resources 551 associated with a Telnet connection which would not have been 552 allocable had the remote party never authenticated itself. 554 This too may mean that the states may transition from whatever the 555 current state is to `unauthenticated'. Alternately, the local party 556 may break the Telnet connection instead. 558 The above model explains how each party should handle the authentication 559 and authorization information exchanged during the lifetime of a Telnet 560 connection. It is deliberately fuzzy as to what constitutes internal 561 processes (such as "authorizing") and what is meant by "resources" or 562 "end-system" (such as whether an end-system is strictly a single entity 563 and communications path to the local party, or multiples of each, etc). 565 Here's a state transition diagram, as per [RFC2360]: 567 0 1 2 3 4 568 Events | unauth auth'ing auth'ed authorizing trans-ready 569 -----------+-------------------------------------------------------- 570 auth-needed| sap/1 sap/1 sap/1 sap/1 der,sap/1 571 auth-accept| - ain/2 - - - 572 auth-bad | - 0 wa/0 wa,der/0 der,sap/1 573 authz-start| szp/3 - szp/3 - - 574 data-rcvd | szp/3 qd/1 szp/3 qd/3 pd/4 575 authz-ok | - - - 4 - 576 authz-bad | - - - der/2 wa,der,szp/3 578 Action | Description 579 -------+-------------------------------------------- 580 sap | start authentication process 581 der | deallocate end-system resources 582 ain | authorize if needed 583 szp | start authorization process 584 qd | queue incoming data 585 pd | process data 586 wa | wipe authorization info 588 Event | Description 589 -------------+--------------------------------------------------- 590 auth-needed | authentication deemed needed by local party 591 auth-accept | remote party's authentication creds accepted 592 auth-bad | remote party's authentication creds rejected or expired 593 authz-start | local or remote party starts authorization proceedings 594 data-rcvd | data destined for end-system received from remote party 595 authz-ok | authorization and resource allocation succeeded 596 authz-bad | authorization or resource allocation failed or expired 598 4.1 Authentication of the Server by the Client 600 A secure connection requires that the client be able to authenticate the 601 identity of the server. How the authentication is performed depends 602 upon the TLS cipher agreed upon during the negotiation. As of this 603 writing there are three categories of cipher suites supported by TLS: 604 ciphers supporting X.509 certificates (PKI), non-PKI ciphers, and 605 anonymous ciphers. The following sections detail how Server authentication 606 should be performed by the client for each cipher category. 608 4.1.1 PKI-based Authentication via TLS handshake 610 When a PKI based cipher is negotiated during the TLS negotiation, the 611 server will deliver an X.509 certificate to the client. Before the 612 certificate MAY be used to determine the identity of the server, the 613 certifiicate MUST be validated as per RFC 2459. 615 Once validated the identity of the server is confirmed by matching the DNS 616 name used to access the host with the name stored in the certificate. If the 617 certificate includes the `subjectAltName' extension and it contains a 618 `dNSName' object, then the client MUST use this name as the identity of the 619 server. Otherwise, the (most specific) commonName field in the Subject field 620 if the certificate MUST be used. Note that although the commonName field 621 technique is currently in wide use, it is deprecated and Certification 622 Authorities are encourage to use the dnsName instead. 624 Matching is performed using the matching rules specified by [RFC 2459]. If 625 more than one identity of a given type is present in the certificate (e.g., 626 more than one dnsName name, a match in any one of the set is considered 627 acceptable.) Names may contain the wildcard character '*' which is considered 628 to match any single domain name component or component fragment. E.g., 629 "*.a.com" matches "foo.a.com" but not "bar.foo.a.com. "f*.com" matches 630 "foo.com" but not "bar.com". 632 In some cases, an IP address is used to access the host instead of a DNS name. 633 In these cases, a 'subjectAltName' object of type 'iPAddress' MUST be present 634 in the certificate and MUST exactly match the IP address provided by the end 635 user. 637 If the hostname does not match the identity in the certificate, user oriented 638 clients MUST either notify the user (clients MAY give the user the opportunity 639 to continue with the connection in any case) or terminate the connection with 640 a bad certificate error. Automated clients MUST log the error to an 641 appropriate audit log (if available) and SHOULD terminate the connection (with 642 a bad certificate error.) Automated clients MAY provide a configuration 643 setting that disables this check, but MUST provide a setting which enables it. 645 4.1.2 Non-PKI based authentication via TLS handshake 647 As of this writing TLS only supports one class of non-PKI cipher suites 648 which are based on Kerberos 5. Regardless, any non-PKI cipher suite 649 incorporated into TLS will provide for mutual authentication. Authentication 650 of the server is therefore implied by a successful TLS credential exchange. 652 4.1.3 Authentication by Telnet AUTH option (RFC 2941) 654 If the TLS exchange used an anonymous cipher such as Anonymous-Diffie- 655 Hellman (ADH) or if the X.509 certificate could not be validated, then 656 the session MUST be protected from a man in the middle attack. This can 657 be accomplished by using a Telnet AUTH [AUTH] method that provides for 658 mutual authentication(*) of the client and server; and which allows the 659 TLS Finished messages sent by the client and the server to be verified. 660 A failure to successfully perform a mutual authentication with Finished 661 message verification via Telnet AUTH MUST result in termination of the 662 connection by both the client and the server. 664 (*) The Telnet AUTH option supports both unilateral and mutual authentication 665 methods. The distinction being that mutual authentication methods confirm 666 the identity of both parties at the end of the negotiation. A unilateral 667 authentication method cannot be used to verify the contents of the TLS client 668 and server finished messages. It is worth noting that TLS usually 669 authenticates the server to the client; whereas, Telnet AUTH usually 670 authenticates the client to the server when unilateral methods are used. 672 4.2 Authentication of the Client by the Server 674 After TLS has been successfully negotiated the server may not have the 675 client's identity (verified or not) since the client is not required to 676 provide credentials during the TLS exchange. Even when the client does 677 provide credentials during the TLS exchange, the server may have a policy 678 that prevents their use. Therefore, the server may not have enough 679 confidence in the client to move the connection to the authenticated state. 681 If further client, server or client-server authentication is going to 682 occur after TLS has been negotiated, it MUST occur before any 683 non-authentication-related Telnet interactions take place on the link 684 after TLS starts. When the first non-authentication-related Telnet 685 interaction is received by either participant, then the receiving 686 participant MAY drop the connection due to dissatisfaction with the 687 level of authentication. 689 If the server wishes to request a client certificate after TLS is 690 initially started (presumably with no client certificate requested), it 691 may do so. However, the server MUST make such a request immediately 692 after the initial TLS handshake is complete. 694 No TLS negotiation outcome, however trustworthy, will by itself provide 695 the server with the authorization identity if that is different from the 696 authentication identity of the client. 698 The following subsections detail how the client can provide the server 699 with authentication and authorization credentials. 701 4.2.1 PKI-based Authentication via TLS handshake 703 PKI-based authentication is used by the client transmitting an X.509 704 certificate to the host during the TLS handshake. There is no standard 705 mechanism defined for how a client certificate should be mapped to a 706 authorization identity (userid). There are several methods currently 707 in wide practice. A telnet server compliant with this document may 708 implement zero, one or more than one of them. 710 The first method is to use information stored within the certificate 711 to determine the authorization identity. If the certificate contains 712 an Common Name object then portions of it can be used as the 713 authorization identity. If the Common Name contains an UID member, 714 then it can be used directly. If the Common Name contains an Email 715 member, then it can be used if the specified domain matches the domain 716 of the telnet server. 718 The second method is to use the entire Subject Name as a entry to 719 lookup in a directory. The directory provides a mapping between the 720 subject name and the authorization identity. 722 The third method is to use the entire certificate as a entry to lookup 723 in a directory with the directory providing a mapping between the 724 certificate and the authorization identity. 726 The first method is only practical if the certificates are being 727 issued by certificate authority managed by the same organization as 728 the server performing the authorization. 730 The second and third methods can be used with certificates issued 731 by public certificate authorities provided the certificates are 732 delivered to the organization performing the authorization in advance 733 via an authenticated method. The second and third methods have the 734 added benefit that the certificates, if issued by the authorizing 735 organization, do not require that any personal information about the 736 subject be included in the certificate. The Subject line could be 737 filled only with gibberish to establish its uniqueness in the 738 directory. 740 4.2.2 Non-PKI Authentication via TLS handshake 742 TLS supports non-PKI authentication methods which can be used for 743 securely establishing authentication identities. As of this writing, 744 TLS supports only one non-PKI authentication method, Kerberos 5. 745 However, it is not unlikely that other authentication methods might be 746 incorporated into TLS ciphers in the future. 748 4.2.3 Telnet AUTH option 750 The Telnet AUTH option implements a variety of authentication methods 751 which can be used to establish authentication and authorization 752 identities. Some methods (e.g., KERBEROS_IV and KERBEROS_V) allow 753 separate authentication and authorization identities to be provided. 754 Details on the use of the Telnet AUTH option and its authentication 755 methods can be found in RFC1416 (about to be obsoleted) and its related 756 documents. For a current list of Telnet AUTH methods see IANA. 758 4.2.4 Traditional Username and Password 760 When all else fails the authorization identity may be provided over 761 the secure TLS connection in the form of a username and password. 763 The Username MAY be transmitted to the host via the Telnet New 764 Environment option's USER variable. 766 5 Security 768 Security is discussed throughout this document. Most of this document 769 concerns itself with wire protocols and security frameworks. But in this 770 section, client and server implementation security issues are in focus. 772 5.1 PKI-based certificate processing 774 A complete discussion of the proper methods for verifying X.509 certificates 775 and their associated certificate chains is beyond the scope of this 776 document. The reader is advised to refer to the RFCs issued by the PKIX 777 Working Group. However, the verification of a certificate MUST include, 778 but isn't limited to, the verification of the signature certificate 779 chain to the point where the a signature in that chain uses a known good 780 signing certificate in the local key chain. The verification 781 SHOULD then continue with a check to see if the fully qualified host name 782 which the client connected to appears anywhere in the server's 783 certificate subject (DN). 785 If the certificate cannot be verified then either: 787 o the end user MUST see a display of the server's certificate and be 788 asked if he/she is willing to proceed with the session; or, 790 o the end user MUST NOT see a display of server's certificate, but the 791 certificate details are logged on whatever media is used to log 792 other session details. This option may be preferred to the first 793 option in environments where the end-user cannot be expected to make 794 an informed decision about whether a mismatch is harmful. The 795 connection MUST be closed automatically by the client UNLESS the 796 client has been configured to explicitly allow all mismatches. 798 o the connection MUST be closed on the user's behalf, and an error 799 describing the mismatch logged to stable storage. 801 If the client side of the service is not interactive with a human 802 end-user, the Telnet connection SHOULD be dropped if this host check 803 fails. 805 5.2 Client and Server authentication of anonymous-TLS connections 807 When authentication is performed after the establishment of a TLS session 808 which uses an anonymous cipher, it is imperative that the authentication 809 method protect against a man in the middle attack by verifying the 810 contents of the client's and server's TLS finished messages. Without 811 the verification of both the client and server's TLS finished messages 812 it is impossible to confirm that there is not a man in the middle 813 listening and perhaps changing all the data transmitted on the 814 connection. 816 Verification of the TLS finished messages can be performed as part 817 of a Telnet AUTH option mutual authentication exchange (when using the 818 ENCRYPT_START_TLS flag.) This can be done at the same time the 819 verification of the authentication-type-pair is performed. 821 5.3 Display of security levels 823 The Telnet client and server MAY, during the TLS protocol negotiation 824 phase, choose to use a weak cipher suite due to policy, law or even 825 convenience. It is, however, important that the choice of weak cipher 826 suite be noted as being commonly known to be vulnerable to attack. In 827 particular, both server and client software should note the choice of 828 weak cipher-suites in the following ways: 830 o If the Telnet endpoint is communicating with a human end-user, the 831 user-interface SHOULD display the choice of weak cipher-suite and 832 the fact that such a cipher-suite may compromise security. 834 o The Telnet endpoints SHOULD log the exact choice of cipher-suite as 835 part of whatever logging/accounting mechanism normally used. 837 5.4 Trust Relationships and Implications 839 Authentication and authorization of the remote Telnet party is useful, 840 but can present dangers to the authorizing party even if the connection 841 between the client and server is protected by TLS using strong 842 encryption and mutual authentication. This is because there are some 843 trust-relationships assumed by one or both parties: 845 o Each side assumes that the authentication and authentication details 846 proferred by the remote party stay constant until explicitly changed 847 (or until the TLS session is ended). 849 o More stringently, each side trusts the other to send a timely 850 notification if authentication or authorization details of the other 851 party's end system(s) have changed. 853 Either of these assumptions about trust may be false if an intruder has 854 breached communications between a client or server and its respective 855 end system. And either may be false if a component is badly implemented 856 or configured. Implementers should take care in program construction to 857 avoid invalidating these trust relationships, and should document to 858 configuring-users the proper ways to configure the software to avoid 859 invalidation of these relationships. 861 5.5 Telnet negotation handling 863 There are two aspects to Telnet negotiation handling that affect the 864 security of the connection. First, given the asynchronous nature 865 of Telnet option negotiations it is possible for a telnet client or 866 server to allow private data to be transmitted over a non-secure 867 link. It is especially important that implementors of this telnet 868 option ensure that no telnet option subnegotiations other than those 869 related to authentication and establishment of security take place over 870 an insecure connection. 872 The second item is related to the most common error when implementing 873 a telnet protocol state machine. Most telnet implementations do not 874 check to ensure that the peer responds to all outstanding requests 875 to change states: WILL, DO, WONT, DONT. It is important that all 876 telnet implementations ensure that requests for state changes are 877 responded to. 879 6 TLS Variants and Options 881 TLS has different versions and different cipher suites that can be 882 supported by client or server implementations. The following 883 subsections detail what TLS extensions and options are mandatory. The 884 subsections also address how TLS variations can be accommodated. 886 6.1 Support of previous versions of TLS 888 TLS has its roots in SSL 2.0 and SSL 3.0. Server and client 889 implementations may wish to support for SSL 3.0 as a fallback in case TLS 890 1.0 or higher is not supported. This is permissible; however, client 891 implementations which negotiate SSL3.0 MUST still follow the rules in 892 Section 5.3 concerning disclosure to the end-user of transport-level 893 security characteristics. 895 Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; it 896 is detailed in [TLS]. SSL 2.0 MUST NOT be negotiated. 898 6.2 Using Kerberos V5 with TLS 900 If the client and server are both amenable to using Kerberos V5, then 901 using non-PKI authentication techniques within the confines of TLS may 902 be acceptable (see [TLSKERB]). Note that clients and servers are under 903 no obligation to support anything but the cipher-suite(s) mandated in 904 [TLS]. However, if implementations do implement the KRB5 authentication 905 as a part of TLS ciphersuite, then these implementations SHOULD support 906 at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite. 908 7 Protocol Examples 910 The following sections provide skeletal examples of how Telnet clients 911 and servers can negotiate TLS. 913 7.1 Successful TLS negotiation 915 The following protocol exchange is the typical sequence that starts TLS: 917 // typical successful opening exchange 918 S: IAC DO START_TLS 919 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 920 S: IAC SB START_TLS FOLLOWS IAC SE 921 // server now readies input stream for non-Telnet, TLS-level negotiation 922 C: [starts TLS-level negotiations with a ClientHello] 923 [TLS transport-level negotiation ensues] 924 [TLS transport-level negotiation completes with a Finished exchanged] 925 // either side now able to send further Telnet data or commands 927 7.2 Successful TLS negotiation, variation 929 The following protocol exchange is the typical sequence that starts TLS, 930 but with the twist that the (TN3270E) server is willing but not 931 aggressive about doing TLS; the client strongly desires doing TLS. 933 // typical successful opening exchange 934 S: IAC DO TN3270E 935 C: IAC WILL START_TLS IAC 936 S: IAC DO START_TLS 937 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 938 S: IAC SB START_TLS FOLLOWS IAC SE 939 // server now readies input stream for non-Telnet, TLS-level negotiation 940 C: [starts TLS-level negotiations with a ClientHello] 941 [TLS transport-level negotiation ensues] 942 [TLS transport-level negotiation completes with a Finished 943 exchanged] 944 // note that server retries negotiation of TN3270E after TLS 945 // is done. 946 S: IAC DO TN3270E 947 C: IAC WILL TN3270E 948 // TN3270E dialog continues.... 950 7.3 Unsuccessful TLS negotiation 952 This example assumes that the server does not wish to allow the Telnet 953 session to proceed without TLS security; however, the client's version 954 of TLS does not interoperate with the server's. 956 //typical unsuccessful opening exchange 957 S: IAC DO START_TLS 958 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 959 S: IAC SB START_TLS FOLLOWS IAC SE 960 // server now readies input stream for non-Telnet, TLS-level negotiation 961 C: [starts TLS-level negotiations with a ClientHello] 962 [TLS transport-level negotiation ensues] 963 [TLS transport-level negotiation fails with server sending 964 ErrorAlert message] 965 S: [TCP level disconnect] 966 // server (or both) initiate TCP session disconnection 968 This example assumes that the server wants to do TLS, but is willing to 969 allow the session to proceed without TLS security; however, the client's 970 version of TLS does not interoperate with the server's. 972 //typical unsuccessful opening exchange 973 S: IAC DO START_TLS 974 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 975 S: IAC SB START_TLS FOLLOWS IAC SE 976 // server now readies input stream for non-Telnet, TLS-level negotiation 977 C: [starts TLS-level negotiations with a ClientHello] 978 [TLS transport-level negotiation ensues] 979 [TLS transport-level negotiation fails with server sending 980 ErrorAlert message] 981 S: [TCP level disconnect] 982 // session is dropped 984 7.4 Authentication via Kerberos 4 after TLS negotiation 986 Here's an implementation example of using Kerberos 4 to authenticate the 987 client after encrypting the session with TLS. Note the following 988 details: 990 o The client strictly enforces a security policy of proposing Telnet 991 AUTH first, but accepting TLS. This has the effect of producing a 992 rather verbose pre-TLS negotiation sequence; however, the 993 end-result is correct. A more efficient pre-TLS sequence can be 994 obtained by changing the client security policy to be the same as the 995 server's for this connection (and implementing policy-aware 996 negotiation code in the Telnet part of the client). 998 A similar efficient result can be obtained even in the absence of a 999 clear client security policy if the client has cached server 1000 security preferences from a previous Telnet session to the same 1001 server. 1003 o The server strictly enforces a security policy of proposing TLS 1004 first, but falling back to Telnet AUTH. 1006 C: IAC WILL AUTHENTICATION 1007 C: IAC WILL NAWS 1008 C: IAC WILL TERMINAL-TYPE 1009 C: IAC WILL NEW-ENVIRONMENT 1010 S: IAC DO START_TLS 1011 C: IAC WILL START_TLS 1012 C: IAC SB START_TLS FOLLOWS IAC SE 1013 S: IAC DO AUTHENTICATION 1014 S: IAC DO NAWS 1015 S: IAC WILL SUPPRESS-GO-AHEAD 1016 S: IAC DO SUPPRESS-GO-AHEAD 1017 S: IAC WILL ECHO 1018 S: IAC DO TERMINAL-TYPE 1019 S: IAC DO NEW-ENVIRONMENT 1020 S: IAC SB AUTHENTICATION SEND 1021 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ 1022 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 1023 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY 1024 SSL CLIENT_TO_SERVER|ONE_WAY IAC SE 1025 S: IAC SB TERMINAL-TYPE SEND IAC SE 1026 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 1027 S: IAC SB START_TLS FOLLOWS IAC SE 1028 [TLS - handshake starting] 1029 [TLS - OK] 1030 C: IAC WILL AUTHENTICATION 1031 C: IAC WILL NAWS 1032 C: IAC WILL TERMINAL-TYPE 1033 C: IAC WILL NEW-ENVIRONMENT 1034 1035 S: IAC DO AUTHENTICATION 1036 S: IAC DO NAWS 1037 S: IAC WILL SUPPRESS-GO-AHEAD 1038 C: IAC DO SUPPRESS-GO-AHEAD 1039 S: IAC DO SUPPRESS-GO-AHEAD 1040 C: IAC WILL SUPPRESS-GO-AHEAD 1041 S: IAC WILL ECHO 1042 C: IAC DO ECHO 1043 S: IAC DO TERMINAL-TYPE 1044 S: IAC DO NEW-ENVIRONMENT 1045 S: IAC SB AUTHENTICATION SEND 1046 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL 1047 KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY IAC SE 1048 C: IAC SB AUTHENTICATION NAME jaltman IAC SE 1049 C: IAC SB AUTHENTICATION IS 1050 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL AUTH 1051 04 07 0B "CC.COLUMBIA.EDU" 00 "8(" 0D 9E 9F AB A0 "L" 15 8F A6 1052 ED "x" 19 F8 0C "wa" CA "z`" 1A E2 B8 "Y" B0 8E "KkK" C6 AA "<" FF 1053 FF 98 89 "|" 90 AC DF 13 "2" FC 8E 97 F7 BD AE "e" 07 82 "n" 19 "v" 1054 7F 10 C1 12 B0 C6 "|" FA BB "s1Y" FF FF 10 B5 14 B3 "(" BC 86 "`" 1055 D2 "z" AB "Qp" C4 "7" AB "]8" 8A 83 B7 "j" E6 "IK" DE "|YIVN" 1056 IAC SE 1057 S: IAC SB TERMINAL-TYPE SEND IAC SE 1058 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 1059 S: IAC SB AUTHENTICATION REPLY 1060 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL ACCEPT IAC SE 1061 C: IAC SB AUTHENTICATION IS 1062 KERBEROS_V4 CLIENT|MUTUAL CHALLENGE "[" BE B7 96 "j" 92 09 "~" IAC SE 1063 S: IAC SB AUTHENTICATION REPLY 1064 KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL RESPONSE "df" B0 D6 "vR_/" IAC SE 1065 C: IAC SB TERMINAL-TYPE IS VT320 IAC SE 1066 C: IAC SB NEW-ENVIRONMENT IS VAR USER VALUE jaltman VAR SYSTEMTYPE \\ 1067 VALUE WIN32 IAC SE 1068 C: IAC SB NAWS 162 49 IAC SE 1070 Here are several things to note about the above example: 1072 o After TLS is successfully negotiated, all non-TLS Telnet settings 1073 are forgotten and must be renegotiated. 1075 o After TLS is successfully negotiated, the server offers all 1076 authentication types that are appropriate for a session using TLS. 1077 Note that the server, post TLS-negotiation, isn't offering Telnet 1078 ENCRYPT or AUTH SSL, since (a) it's useless to encrypt twice, and 1079 (b) TLS and/or SSL can be applied only once to a Telnet session. 1081 8 References 1083 [ANBF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 1084 Specifications: ABNF", RFC2235, November 1997. 1086 [AUTH] T.Ts'o, Ed,. J. Altman, "Telnet Authentication Option", 1087 RFC2941, September 2000. 1089 [ENCRYPT] T.Ts'o, "Telnet Encryption Option", RFC2946, September 2000. 1091 [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate 1092 Requirement Levels", RFC2119, March 1997. 1094 [RFC927] Brian A. Anderson. "TACACS User Identification Telnet 1095 Option", RFC927, December 1984 1097 [RFC2360] G. Scott, Editor. "Guide for Internet Standard Writers", 1098 RFC2360, June 1998. 1100 [RFC2459] Housley, R., Ford, W., Polk, W. and D.Solo, "Internet 1101 Public Key Infrastructure: Part I: X.509 Certificate and 1102 CRL Profile", RFC2459, January 1999. 1104 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specifications", 1105 RFC854, May 1983. 1107 [TLS] Tim Dierks, C. Allen. "The TLS Protocol", RFC2246, January 1108 1999. 1110 [TLSKERB] Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher 1111 Suites to Transport Layer Security (TLS)", RFC2712, October 1112 1999. 1114 9 Authors 1116 Michael Boe Jeffrey Altman 1117 Cisco Systems Inc. Columbia University 1118 170 West Tasman Drive 612 West 115th Street 1119 San Jose CA 95134 USA New York NY 10025 USA 1121 Email: mboe@cisco.com jaltman@columbia.edu 1123 10 Mailing list 1125 General Discussion:tn3270e@list.nih.gov 1126 To Subscribe: listserv@list.nih.gov 1127 In Body: sub tn3270e 1128 Archive: listserv@list.nih.gov 1130 Associated list: telnet-wg@bsdi.com 1132 Full Copyright Statement 1134 Copyright (c) The Internet Society (1998, 2000). All Rights Reserved. 1136 This document and translations of it may be copied and furnished to 1137 others, and derivative works that comment on or otherwise explain it or 1138 assist in its implementation may be prepared, copied, published and 1139 distributed, in whole or in part, without restriction of any kind, 1140 provided that the above copyright notice and this paragraph are included 1141 on all such copies and derivative works. However, this document itself 1142 may not be modified in any way, such as by removing the copyright notice 1143 or references to the Internet Society or other Internet organizations, 1144 except as needed for the purpose of develop- ing Internet standards in 1145 which case the procedures for copyrights defined in the Internet 1146 Standards process must be followed, or as required to translate it into 1147 languages other than English. 1149 The limited permissions granted above are perpetual and will not be 1150 revoked by the Internet Society or its successors or assigns. 1152 This document and the information contained herein is provided on an "AS 1153 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1154 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1155 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1156 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1157 FITNESS FOR A PARTICULAR PURPOSE. 1159 Acknowledgement 1160 Funding for the RFC Editor function is currently provided by the 1161 Internet Society. 1163 Jeffrey Altman * Sr.Software Designer 1164 The Kermit Project * Columbia University 1165 612 West 115th St * New York, NY * 10025 * USA 1166 http://www.kermit-project.org/ * kermit-support@kermit-project.org