idnits 2.17.1 draft-altman-telnet-starttls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1162. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 1068 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 499 has weird spacing: '... unauth auth...' -- 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 (December 15, 2006) is 6341 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: 'RFC927' is defined on line 1105, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2235 (ref. 'ABNF') -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) -- No information found for draft-altman-tls-channel-bindings-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TLS-CB' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jeffrey Altman 2 INTERNET-DRAFT draft-altman-telnet-starttls-02.txt 3 Expires: 16 July 2007 4 December 15, 2006 6 Telnet START-TLS Option 8 Status of this memo 10 By submitting this Internet-Draft, each author represents that 11 any applicable patent or other IPR claims of which he or she is 12 aware have been or will be disclosed, and any of which he or she 13 becomes aware will be disclosed, in accordance with Section 6 of 14 BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on 15 December 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2006). 38 Abstract 40 Telnet service has long been a standard Internet protocol. However, a 41 standard way of ensuring privacy and integrity of Telnet sessions has 42 been lacking. This document proposes a standard method for Telnet 43 servers and clients to use the Transport Layer Security (TLS) protocol. 44 It describes how two Telnet participants can decide whether or not to 45 attempt TLS negotiation, and how the two participants should process 46 authentication credentials exchanged as a part of TLS startup. 48 Contents 50 1 Introduction 52 2 Command Names and Codes (assigned by IANA) 54 3 Command Meanings 56 3.1 Usage of commands and interactions with other Telnet options 58 3.2 TLS Negotiation Failure 60 4 Authentication and Authorization 62 4.1 Authentication of the Client by the Server 64 4.1.1 PKI Server Authentication via TLS handshake 66 4.1.2 Non-PKI Server Authentication via TLS handshake 68 4.1.3 Telnet AUTH option 70 4.1.4 Username and Password 72 4.2 Authentication of the Server by the Client 74 4.2.1 PKI-based Authentication via TLS handshake 76 4.2.2 Non-PKI based authentication via TLS handshake 78 4.2.3 Authentication by Telnet AUTH option 80 5 Security Considerations 82 5.1 PKI-based certificate processing . . . 84 5.2 Client and Server authentication of anonymous TLS 85 connections 87 5.3 Display of security levels . . . . . . 89 5.4 Trust Relationships and Implications . . . . 91 5.5 Telnet negotation handling 93 6 TLS Variants and Options 95 6.1 Support of previous versions of TLS . . . . 97 6.2 Using Kerberos V5 with TLS . . . . . . 99 6.3 TLS Channel Bindings for use with TELNET AUTH mechanisms 101 7 Protocol Examples 103 7.1 Successful TLS negotiation . . . . . . 105 7.2 Successful TLS negotiation, variation . . . . 107 7.3 Unsuccessful TLS negotiation . . . . . . 109 7.4 Authentication via Telnet Auth Kerberos 5 after TLS 110 negotiation 112 8 IANA Considerations 114 9 Normative References 116 10 Authors 118 11 Credits 119 1 Introduction 121 This document describes the Telnet START_TLS option. It allows TLS 122 to be activated at the beginning of a Telnet connection, using the IANA 123 assigned "telnet" port (IANA tcp\23), which can be used to provide 124 authentication and confidentiality. This document also defines a set 125 of advisory security policy response codes for use when negotiating TLS 126 from within an existing Telnet session. 128 This specification addresses the interaction between the Telnet 129 client and server that requires private communications while 130 acknowledging it may only protect a portion of the total end-user to 131 application path. Specifically, it is often true that the Telnet server 132 does not reside on the target machine (it does not have access to a 133 list of identities which are allowed to access to that application- 134 server), and it is often true (e.g. 3270 access) that the telnet server 135 can not even identify that portion of the emulation stream which 136 contains user identification/password information. Additionally, it may 137 be the case that the Telnet client is not co-resident with the end user 138 and that it also may be unable to identify that portion of the data 139 stream that deals with user identity. This document assumes that there 140 is a trust relationship and appropriate protection to support that 141 relationship between the Telnet Server and the ultimate application 142 engine such that data on this path is protected and that the 143 application will authenticate the end user via the emulation stream as 144 well as use this channel to control access to information. It is 145 further assumed that the path between the end user and the client is 146 protected. 148 In order for the Telnet portion of the overall path between the 149 user and the application-server to be considered secure, the Telnet 150 data stream must be authenticated and provide confidentiality and integrity 151 protection. This is accomplished by establishing a shared secret 152 between the client and server. This shared secret is used to encrypt 153 the flow of data and (just as important) require the client to verify 154 that it is talking to correct server (the one that the application- 155 server trusts rather than an unintended man-in-the-middle) with the 156 knowledge that the emulation stream itself will be used by the 157 application-server to verify the identity of the end-user. Rather than 158 create a new proprietary protocol which accomplishes these goals this 159 document defines the use of an existing IETF protocol, Transport Layer 160 Security (TLS). 162 The Telnet [TELNET] application protocol can certainly benefit from the 163 use of TLS. Since 1992 Telnet has supported over a dozen forms of 164 end user authentication and encryption via the AUTH and ENCRYPT 165 options. Since 1995, predecessors to TLS have been used to provide 166 privacy and integrity protection to Telnet data streams via the 167 undocumented Telnet AUTH SSL option and via the dedicated IANA assigned 168 port assignment ("telnets" tcp\992). TLS offers a broad range of 169 security levels that allow sites to proceed at an "evolutionary" pace 170 in deploying authentication, authorization and confidentiality 171 policies, databases and distribution methods. 173 This document describes how TLS can be used to provide the following: 175 o creation and refresh of a shared secret; 177 o negotiation and execution of data encryption and optional 178 compressesion; 180 o primary negotiation of authentication; and, if chosen 182 o execution of public-key or symmetric-key based authentication. 184 TLS at most offers only authentication of the peers conducting the TLS 185 dialog. In particular, it does not support the client providing 186 different credentials for authorization than were presented for 187 authentication. After the establishment of peer-to-peer trust using 188 TLS, other forms of end user authentication including Telnet AUTH may 189 be used to provide credentials for use in determining end user 190 authorization. 192 Traditional Telnet servers have operated without such early 193 presentation of authorization credentials for many reasons (most of 194 which are historical). However, recent developments in Telnet server 195 technology make it advantageous for the Telnet server to know the 196 authorized capabilities of the remote client before choosing a 197 communications link (be it `pty' or SNA LU) and link-characteristics to 198 the host system (be that "upstream" link local or remote to the server). 199 Thus, we expect to see the use of client authorization to become an 200 important element of the Telnet evolution. Such authorization methods 201 may require certificates presented by the client via TLS, or by the use 202 of Telnet AUTH option, or some other as yet-to-be-standardized method. 204 Conventions Used in this Document 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 207 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 208 "OPTIONAL" in this document are to be interpreted as described in 209 RFC 2119. [KEYWORDS]. 211 Formal syntax is defined using Augmented BNF for Syntax 212 Specifications [ABNF]. 214 In examples, "C:" and "S:" indicate lines sent by the the client and 215 server, respectively. 217 2 Command Names and Codes (assigned by IANA) 219 START_TLS 46 (decimal) 221 FOLLOWS 1 (decimal) 223 3 Command Meanings 225 This document makes reference to a "server" and a "client". For the 226 purposes of this document, the "server" is the side of the 227 connection that did the passive TCP open (TCP LISTEN state), and the 228 "client" is the side of the connection that did the active open. 230 IAC DONT START_TLS 232 The sender is either not a server or is not interested in 233 negotiating a TLS connection. 235 IAC WONT START_TLS 237 The sender is either not a client or is not interested in 238 negotiating a TLS connection. 240 IAC DO START_TLS 242 The server side of the connection sends this command to indicate 243 a desire to negotiate a TLS connection. This command MUST NOT 244 be sent by the client. If this command is received by the server, 245 it MUST be refused with IAC WONT START_TLS. 247 IAC WILL START_TLS 249 The client side of the connection sends this command to indicate 250 a desire to negotiate a TLS connection. This command MUST NOT 251 be sent by the server. If this command is received by the client, 252 it MUST be refused with IAC DONT START_TLS. 254 IAC SB START_TLS FOLLOWS IAC SE 256 The FOLLOWS sub-command is sent to indicate that the next byte of 257 data received after this command MUST be a TLS negotiation as 258 described in [TLS]. This sub-command is sent by both the client 259 and the server. After this sub-command has been sent, the sender 260 MUST NOT respond to nor initiate any additional telnet commands or 261 sub-commands. When this sub-command has been sent and received 262 the TLS negotiation will commence. When sent by a client this 263 sub-command will be followed by a TLS ClientHello. When sent by a 264 server this sub-command will be followed by a TLS ServerHello. 266 3.1 Usage of commands and interactions with other Telnet options 268 The START_TLS option is an asymmetric option, with the server side 269 allowed to send IAC DO START_TLS and the client allowed to send 270 IAC WILL START_TLS. Sub-commands are used to synchronize the link 271 in preparation for negotiating TLS. This synchronization takes 272 the form of a three-way handshake: 274 1. As per normal Telnet option processing rules, the client MUST 275 respond to the server's IAC DO START_TLS with either IAC WONT 276 START_TLS or IAC WILL START_TLS (if it hasn't already done 277 so). Once the client has sent IAC WILL START_TLS and received 278 IAC DO START_TLS, it MUST immediately send a FOLLOWS sub-command 279 (IAC SB START_TLS FOLLOWS IAC SE) to indicate it is ready to begin 280 a TLS negotiation. Once the FOLLOWS sub-command has been sent, 281 the client MUST ignore all telnet negotiations except for the 282 FOLLOWS sub-command. When the FOLLOWS sub-command has been 283 received the client MUST halt use of the telnet protocol, reset 284 the telnet state machine and begin a TLS negotiation by sending a 285 ClientHello message. 287 2. If the client initiates by sending IAC WILL START_TLS, the server 288 MUST respond with either IAC DO START_TLS or IAC DONT START_TLS. 290 3. The server SHOULD NOT send additional Telnet data or commands 291 after sending IAC DO START_TLS except in response to client Telnet 292 options received until after it receives either a negative 293 response from the client (IAC WONT START_TLS) or a successful 294 negotiation of TLS has occurred. If the client's START_TLS option 295 response is negative, the server is free to send additional Telnet 296 data or commands. If the client's response is affirmative (IAC 297 WILL START_TLS), then the server MUST send the FOLLOWS sub-command 298 (IAC SB START_TLS FOLLOWS IAC SE) and await the FOLLOWS sub- 299 command from the client. When the FOLLOWS sub-command has been 300 sent and received the server MUST halt use of the Telnet protocol, 301 reset the telnet state machine, and begin a TLS negotiation by 302 sending a TLS ServerHello message. 304 4. If both START_TLS and AUTH [AUTH] are offered, START_TLS SHOULD be 305 sent first and MUST take precedence if both are mutually negotiated. 306 AUTH MAY be renegotiated after successful establishment of the TLS 307 session if end-user authentication via a supported method is 308 desired. 310 5. If a TLS session has been established, the ENCRYPT [ENCRYPT] option 311 MUST NOT be negotiated in either direction. 313 6. When the FOLLOWS sub-command has been sent and received the Telnet 314 state machine is reset. This means that the state of all telnet 315 options is reset to the WONT/DONT state and any data received via 316 subcommands is forgotten. After a sucessful TLS negotiation the 317 Telnet negotiations will be restarted as if a new connection had 318 just been established with one exception. Since TLS is already in 319 use, the START_TLS option MUST NOT be negotiated. 321 3.2 TLS Negotiation Failure 323 The behavior regarding TLS negotiation failure is covered in [TLS], and 324 does not indicate that the TCP connection be broken; the semantics are 325 that TLS is finished and all state variables cleaned up. The TCP 326 connection may be retained. 328 However, it's not clear that either side can detect when the last of 329 the TLS data has arrived. So if TLS negotiation fails, the TCP 330 connection SHOULD be reset and the client MAY reconnect. To avoid 331 infinite loops of TLS negotiation failures, the client MUST remember to 332 not negotiate START_TLS if reconnecting due to a TLS negotiation failure 333 (if allowed by policy.) 335 4 Telnet Authentication and Authorization 337 Telnet servers and clients can be implemented in a variety of ways that 338 impact how clients and servers authenticate and authorize each other. 339 However, most (if not all) the implementations can be abstracted via 340 the following four communicating processes: 342 SES Server End System. This is an application or machine to which 343 client desires a connection. Though not illustrated here, a single 344 Telnet connection between client and server could have multiple 345 SES terminations. 347 Server The Telnet server. 349 Client The Telnet client, which may or may not be co-located with the 350 CES. The Telnet client in fact be a gateway or proxy for 351 downstream clients; it's immaterial. 353 CES Client End System. The system communicating with the Telnet 354 Client. There may be more than one actual CES communicating to a 355 single Telnet Client instance; this is also immaterial with respect 356 to Client and Server sucessfully exchanging authentication and 357 authorization details. However, see Section 5.4 for a discussion 358 on trust implications. 360 What is of interest here is how the Client and Server can exchange 361 authentication and authorization details such that these components can 362 direct Telnet session traffic to authorized End Systems in a reliable, 363 trustworthy fashion. 365 What is beyond the scope of this specification are several related 366 topics, including: 368 o How the Server and SES are connected, and how they exchange data 369 or information regarding authorization or authentication (if any). 371 o How the Client and CES are connected, and how they exchange data 372 or information regarding authorization or authentication (if any). 374 System-to-system communications using the Telnet protocol have 375 traditionally used no authentication techniques at the Telnet level. 376 More recent techniques have used Telnet to transport authentication 377 exchanges [AUTH]. In none of these systems, however, is a remote 378 system allowed to assume more than one identity once the Telnet 379 preamble negotiation is over and the remote party is connected to the 380 application-endpoint. The reason for this is that the local party must 381 in some way inform the end-system of the remote party's identity (and 382 perhaps authorization). This process must take place before the remote 383 party starts communicating with the end-system. At that point it's too 384 late to change what access a client may have to an server end-system: 385 that end-system has been selected, resources have been allocated and 386 capability restrictions set. 388 This process of authentication, authorization and resource allocation 389 can be modeled by the following simple set of states and transitions: 391 `unauthenticated' The local party has not received any credentials 392 offered by the remote party. A new Telnet connection starts in 393 this state. 395 The `authenticating' state will be entered from this state if the 396 local party initiates the authentication process of the peer. The 397 Telnet START_TLS negotiation is considered an initiation of the 398 authentication process. 400 The `authorizing' state will be entered from this state either if 401 the local party decides to begin authorization and resource 402 allocation procedures unilaterally, or if the local party has 403 received data from the remote party destined for local end-system. 405 `authenticating' The local party has received at least some of the 406 credentials needed to authenticate its peer, but has not finished 407 the process. 409 The `authenticated' state will be entered from this state if the 410 local party is satisfied with the credentials proferred by the 411 client. 413 The `unauthenticated' state will be entered from this state if the 414 local party cannot verify the credentials proffered by the client 415 or if the client has not proffered any credentials. Alternately, 416 the local party may terminate the Telnet connection instead of 417 returning it to the `unauthenticated' state. 419 `authenticated' The local party has authenticated its peer, but has 420 not yet authorized the client to connect to any end-system 421 resources. 423 The `authenticating' state will be entered from this state if the 424 local party decides that further authentication of the client is 425 warranted. 427 The `authorizing' state will be entered from this state if the 428 local party either initiates authorization dialog with the client 429 (or engages in some process to authorize and allocate resources on 430 behalf of the client), or has received data from the remote party 431 destined for a local end-system. 433 `authorizing' The local party is in the process of authorizing its 434 peer to use end-system resources, or may be in the process of 435 allocating or reserving those resources. 437 The `transfer-ready' state will be entered when the local party is 438 ready to allow data to be passed between the local end-system and 439 remote peer. 441 The `authenticated' state will be entered if the local party 442 determines that the current authorization does not allow any 443 access to a local end-system. If the remote peer is not currently 444 authenticated, then the `unauthenticated' state will be entered 445 instead. 447 `transfer-ready' The party may pass data between the local end- 448 system to its peer. 450 The `authorizing' state will be entered if the local party (perhaps 451 due to a request by the remote peer) deallocates the communications 452 resources to the local-end system. Alternately, the local party may 453 enter the `authenticated' or the `unauthenticated' state. 455 In addition to the "orderly" state transitions noted above, some 456 extraordinary transitions may also occur: 458 1. The absence of a guarantee on the integrity of the data stream 459 between the two Telnet parties also removes the guarantee that the 460 remote peer is who the authentication credentials say the peer is. 461 Thus, upon being notified that the Telnet session is no longer 462 using an integrity layer, the local party must at least deallocate 463 all resources associated with a Telnet connection which would not 464 have been allocable had the remote party never authenticated 465 itself. 467 In practice, this deallocation-of-resources restriction is hard to 468 interpret consistently by both Telnet endpoints. Therefore, both 469 parties MUST return to the initial Telnet state after negotiation 470 of TLS. That is, it is as if the Telnet session had just started. 472 This means that the states may transition from whatever the current 473 state is to `unauthenticated'. Alternately, the local party may 474 break the Telnet connection instead. 476 2. If the local party is notified at any point during the Telnet 477 connection that the remote party's authorizations have been 478 reduced or revoked, then the local party must treat the remote 479 party as being unauthenticated. The local party must deallocate 480 all resources associated with a Telnet connection which would not 481 have been allocable had the remote party never authenticated 482 itself. 484 This too may mean that the states may transition from whatever the 485 current state is to `unauthenticated'. Alternately, the local 486 party may break the Telnet connection instead. 488 The above model explains how each party should handle the 489 authentication and authorization information exchanged during the 490 lifetime of a Telnet connection. It is deliberately fuzzy as to what 491 constitutes internal processes (such as "authorizing") and what is 492 meant by "resources" or "end-system" (such as whether an end-system is 493 strictly a single entity and communications path to the local party, or 494 multiples of each, etc). 496 Here's a state transition diagram, as per [RFC2360]: 498 0 1 2 3 4 499 Events | unauth auth'ing auth'ed authorizing trans-ready 500 -----------+-------------------------------------------------------- 501 auth-needed| sap/1 sap/1 sap/1 sap/1 der,sap/1 502 auth-accept| - ain/2 - - - 503 auth-bad | - 0 wa/0 wa,der/0 der,sap/1 504 authz-start| szp/3 - szp/3 - - 505 data-rcvd | szp/3 qd/1 szp/3 qd/3 pd/4 506 authz-ok | - - - 4 - 507 authz-bad | - - - der/2 wa,der,szp/3 509 Action | Description 510 -------+-------------------------------------------- 511 sap | start authentication process 512 der | deallocate end-system resources 513 ain | authorize if needed 514 szp | start authorization process 515 qd | queue incoming data 516 pd | process data 517 wa | wipe authorization info 519 Event | Description 520 -------------+--------------------------------------------------- 521 auth-needed | authentication deemed needed by local party 522 auth-accept | remote party's authentication creds accepted 523 auth-bad | remote party's authentication creds rejected or expired 524 authz-start | local or remote party starts authorization proceedings 525 data-rcvd | data destined for end-system received from remote party 526 authz-ok | authorization and resource allocation succeeded 527 authz-bad | authorization or resource allocation failed or expired 529 4.1 Authentication of the Server by the Client 531 A secure connection requires that the client authenticate the identity 532 of the server. How the authentication is performed depends upon the TLS 533 ciphersuite agreed upon during the negotiation. As of this writing there are 534 three categories of ciphersuites supported by TLS: ciphersuites supporting 535 X.509 certificates (PKI), non-PKI ciphersuites, and anonymous ciphersuites. 536 The following sections detail how Server authentication should be performed 537 by the client for each ciphersuite category. 539 4.1.1 PKI-based Server Authentication via TLS handshake 541 When a PKI based ciphersuite is negotiated during the TLS negotiation, the 542 server will deliver an X.509 certificate to the client. Before the 543 certificate MAY be used to determine the identity of the server, the 544 certificate MUST be validated as per [RFC3280]. 546 Once validated the identity of the server is confirmed by matching the 547 DNS name used to access the host with the name stored in the 548 certificate. If the certificate includes the `subjectAltName' 549 extension and it contains a `dNSName' object, then the client MUST use 550 this name as the identity of the server. Otherwise, the (most 551 specific) commonName field in the Subject field if the certificate MUST 552 be used. Note that although the commonName field technique is currently 553 in wide use, it is deprecated and Certification Authorities are 554 encourage to use the dnsName instead. Another possibility is that the 555 Subject Name field can consist of Domain Component assertions. For example, 556 "dc=com, dc=example, dc=hostname". Matching is performed using the 557 matching rules specified by [RFC3280]. 559 In some cases, an IP address is used to access the host instead of 560 a DNS name. In these cases, a 'subjectAltName' object of type 561 'iPAddress' MUST be present in the certificate and MUST exactly match 562 the IP address provided by the end user. 564 If the hostname does not match the identity in the certificate, user 565 oriented clients MUST either notify the user (clients MAY give the user 566 the opportunity to continue with the connection in any case) or 567 terminate the connection with a bad certificate error. Automated 568 clients MUST log the error to an appropriate audit log (if available) 569 and SHOULD terminate the connection (with a bad certificate error.) 570 Automated clients MAY provide a configuration setting that disables 571 this check, but MUST provide a setting which enables it. 573 4.1.2 Non-PKI Server Authentication via TLS handshake 575 Non-PKI ciphersuites such as Kerberos v5 [TLSKERB] and Pre-Shared Keys 576 [TLSPSK] provide for server authentication. Refer to the appropriate 577 RFC for details. 579 4.1.3 Server Authentication by Telnet AUTH option [AUTH] 581 If the TLS exchange used an anonymous ciphersuite such as Anonymous-Diffie- 582 Hellman (ADH) or if the X.509 certificate could not be validated, then 583 the session MUST be protected from a man-in-the-middle attack. This 584 can be accomplished by using a Telnet AUTH [AUTH] method that provides 585 for mutual authentication(*) of the client and server; and which allows 586 the TLS Channel Binding data [TLS-CB] to be verified. A failure to 587 successfully perform a mutual authentication with TLS Channel Binding 588 verification via Telnet AUTH MUST result in termination of the connection 589 by both the client and the server. 591 (*) The Telnet AUTH option supports both unilateral and mutual 592 authentication methods. The distinction being that mutual 593 authentication methods confirm the identity of both parties at the end 594 of the negotiation. A unilateral authentication method cannot be used 595 to verify the contents of the TLS client and server finished messages. 596 It is worth noting that TLS usually authenticates the server to the 597 client; whereas, Telnet AUTH usually authenticates the client to the 598 server when unilateral methods are used. 600 4.2 Authentication of the Client by the Server 602 After TLS has been successfully negotiated the server may not have the 603 client's identity (verified or not) since the client is not required to 604 provide credentials during the TLS exchange. Even when the client does 605 provide credentials during the TLS exchange, the server may have a 606 policy that prevents their use. Therefore, the server may not have 607 enough confidence in the client to move the connection to the 608 authenticated state. 610 If further client, server or client-server authentication is going to 611 occur post-TLS establishment, it MUST occur before any 612 non-authentication-related Telnet options are negotiated or data 613 is transmitted. When the first non-authentication-related Telnet 614 interaction is received by either participant, then the receiving 615 participant MAY drop the connection due to dissatisfaction with the 616 level of authentication. 618 If the server wishes to request a client certificate after TLS is 619 initially started (presumably with no client certificate requested), it 620 may do so. However, the server MUST make such a request immediately 621 after the initial TLS handshake is complete. 623 No TLS negotiation outcome, however trustworthy, will by itself provide 624 the server with the authorization identity if that is different from 625 the authentication identity of the client. 627 The following subsections detail how the client can provide the server 628 with authentication and authorization credentials. 630 4.2.1 PKI-based Authentication via TLS handshake 632 PKI-based authentication is used by the client transmitting an X.509 633 certificate to the host during the TLS handshake. There is no standard 634 mechanism defined for how a client certificate should be mapped to a 635 authorization identity (userid). There are several methods currently 636 in wide practice. A telnet server compliant with this document may 637 implement zero, one or more than one of them. 639 The first method is to use information stored within the certificate 640 to determine the authorization identity. If the certificate contains 641 an Common Name object then portions of it can be used as the 642 authorization identity. If the Common Name contains an UID member, 643 then it can be used directly. If the Common Name contains an Email 644 member, then it can be used if the specified domain matches the domain 645 of the telnet server. 647 The second method is to use the entire Subject Name as a entry to 648 lookup in a directory. The directory provides a mapping between the 649 subject name and the authorization identity. 651 The third method is to use the entire certificate or the entire 652 distinguished name as a entry to lookup in a directory with the 653 directory providing a mapping between the certificate and the 654 authorization identity. 656 The first method is only practical if the certificates are being 657 issued by certification authority managed by the same organization as 658 the server performing the authorization. 660 The second and third methods can be used with certificates issued 661 by public certification authorities provided the certificates are 662 delivered to the organization performing the authorization in advance 663 via an authenticated method. The second and third methods have the 664 added benefit that the certificates, if issued by the authorizing 665 organization, do not require that any personal information about the 666 subject be included in the certificate. The Common Name field could be 667 filled only with gibberish to establish its uniqueness in the 668 directory. 670 4.2.2 Non-PKI Authentication via TLS handshake 672 TLS supports non-PKI authentication methods which can be used for 673 securely establishing authentication identities. 675 4.2.3 Telnet AUTH option 677 The Telnet AUTH option implements a variety of authentication methods 678 which can be used to establish authentication and authorization 679 identities. Some methods (e.g., KERBEROS_IV and KERBEROS_V) allow 680 separate authentication and authorization identities to be provided. 681 Details on the use of the Telnet AUTH option and its authentication 682 methods can be found in [AUTH] and its related documents. For a 683 current list of Telnet AUTH methods see [IANA]. 685 4.2.4 Username and Password 687 When there is no other method of client authentication available 688 transmitting the username and password over a connection protected 689 by TLS is far superior to sending them in the clear. 691 The Username MAY be transmitted to the host via the Telnet New 692 Environment option's USER variable. 694 5 Security Considerations 696 Security is discussed throughout this document. Most of this document 697 concerns itself with wire protocols and security frameworks. But in 698 this section, client and server implementation security issues are in 699 focus. 701 5.1 PKI-based certificate processing 703 A complete discussion of the proper methods for verifying X.509 704 certificates and their associated certificate chains is beyond the 705 scope of this document. The reader is advised to refer to the RFCs 706 issued by the PKIX Working Group. However, the verification of a 707 certificate MUST include, but isn't limited to, the verification of the 708 signature certificate chain up to the trust anchor. The verification 709 SHOULD then continue with a check to see if the fully qualified host 710 name which the client connected to appears anywhere in the server's 711 certificate subject (DN). 713 If the certificate cannot be verified then either: 715 o the end user MUST see a display of the server's certificate and be 716 asked if he/she is willing to proceed with the session; or, 718 o the end user MUST NOT see a display of server's certificate, but 719 the certificate details are logged on whatever media is used to 720 log other session details. This option may be preferred to the 721 first option in environments where the end-user cannot be expected 722 to make an informed decision about whether a mismatch is harmful. 723 The connection MUST be closed automatically by the client UNLESS 724 the client has been configured to explicitly allow all mismatches. 726 o the connection MUST be closed on the user's behalf, and an error 727 describing the mismatch logged to stable storage. 729 If the client side of the service is not interactive with a human 730 end-user, the Telnet connection SHOULD be dropped if this host check 731 fails. 733 5.2 Client and Server authentication of anonymous-TLS connections 735 When authentication is performed after the establishment of a TLS 736 session which uses an anonymous ciphersuite, it is imperative that the 737 authentication method protect against a man-in-the-middle attack by 738 verifying the contents of the client's and server's TLS finished 739 messages. Without the verification of both the client and server's TLS 740 finished messages it is impossible to confirm that there is not a man- 741 in-the-middle listening and perhaps changing all the data transmitted 742 on the connection. 744 Verification of the TLS finished messages can be performed as part 745 of a Telnet AUTH option mutual authentication exchange (when using the 746 ENCRYPT_START_TLS flag.) This can be done at the same time the 747 verification of the authentication-type-pair is performed. 749 5.3 Display of security levels 751 The Telnet client and server MAY, during the TLS protocol negotiation 752 phase, choose to use a weak ciphersuite due to policy, law or even 753 convenience. It is, however, important that the choice of weak cipher- 754 suite be noted as being commonly known to be vulnerable to attack. In 755 particular, both server and client software should note the choice of 756 weak ciphersuites in the following ways: 758 o If the Telnet endpoint is communicating with a human end-user, the 759 user-interface SHOULD display the choice of weak ciphersuite and 760 the fact that such a ciphersuite may compromise security. 762 o The Telnet endpoints SHOULD log the exact choice of ciphersuite 763 as part of whatever logging/accounting mechanism normally used. 765 5.4 Trust Relationships and Implications 767 Authentication and authorization of the remote Telnet party is useful, 768 but can present dangers to the authorizing party even if the connection 769 between the client and server is protected by TLS using strong 770 encryption and mutual authentication. This is because there are some 771 trust-relationships assumed by one or both parties: 773 o Each side assumes that the authentication and authentication 774 details proferred by the remote party stay constant until 775 explicitly changed (or until the TLS session is ended). 777 o More stringently, each side trusts the other to send a timely 778 notification if authentication or authorization details of the 779 other party's end system(s) have changed. 781 Either of these assumptions about trust may be false if an intruder has 782 breached communications between a client or server and its respective 783 end system. And either may be false if a component is badly implemented 784 or configured. Implementers should take care in program construction to 785 avoid invalidating these trust relationships, and should document to 786 configuring-users the proper ways to configure the software to avoid 787 invalidation of these relationships. 789 5.5 Telnet negotation handling 791 There are two aspects to Telnet negotiation handling that affect the 792 security of the connection. First, given the asynchronous nature 793 of Telnet option negotiations it is possible for a telnet client or 794 server to allow private data to be transmitted over a non-secure 795 link. It is especially important that implementors of this telnet 796 option ensure that no telnet option sub-negotiations other than those 797 related to authentication and establishment of security take place over 798 an insecure connection. 800 The second item is related to the most common error when implementing 801 a telnet protocol state machine. Most telnet implementations do not 802 check to ensure that the peer responds to all outstanding requests 803 to change states: WILL, DO, WONT, DONT. It is important that all 804 telnet implementations ensure that requests for state changes are 805 responded to. 807 6 TLS Variants and Options 809 TLS has different versions and different ciphersuites that can be 810 supported by client or server implementations. The following 811 subsections detail what TLS extensions and options are mandatory. The 812 subsections also address how TLS variations can be accommodated. 814 6.1 Support of previous versions of TLS 816 TLS has its roots in SSL 2.0 and SSL 3.0. Server and client 817 implementations may wish to support for SSL 3.0 as a fallback in case 818 TLS 1.0 or higher is not supported. This is permissible; however, 819 client implementations which negotiate SSL3.0 MUST still follow the 820 rules in Section 5.3 concerning disclosure to the end-user of 821 transport-level security characteristics. 823 Negotiating the use of SSL 3.0 is done as part of the TLS negotiation; 824 it is detailed in [TLS]. SSL 2.0 MUST NOT be negotiated. 826 6.2 Using Kerberos V5 with TLS 828 If the client and server are both amenable to using Kerberos V5, then 829 using non-PKI authentication techniques within the confines of TLS may 830 be acceptable (see [TLSKERB]). Note that clients and servers are under 831 no obligation to support anything but the ciphersuite(s) mandated in 832 [TLS]. However, if implementations do implement the KRB5 authentication 833 as a part of TLS ciphersuite, then these implementations SHOULD support 834 at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite. 836 Kerberos V5 can also be securely negotiated using TELNET AUTH KRB5 after 837 START_TLS negotiation has completed. This is the preferred method of 838 combining TLS and Kerberos V5 authentication. [AUTH-KRB5] 840 6.3 TLS Channel Bindings for use with TELNET AUTH mechanisms 842 When the Telnet AUTH option is negotiated over TLS, the authentication 843 option SHOULD verify the TLS channel bindings data [TLS-CB]. Doing so 844 provides a strong cryptographic binding between the client 845 authentication and the underlying TLS session. 847 7 Protocol Examples 849 The following sections provide skeletal examples of how Telnet clients 850 and servers can negotiate TLS. 852 7.1 Successful TLS negotiation 854 The following protocol exchange is the typical sequence that starts TLS: 856 // typical successful opening exchange 857 S: IAC DO START_TLS 858 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 859 S: IAC SB START_TLS FOLLOWS IAC SE 860 // server now readies input stream for non-Telnet, TLS-level negotiation 861 C: [starts TLS-level negotiations with a ClientHello] 862 [TLS transport-level negotiation ensues] 863 [TLS transport-level negotiation completes with a Finished exchanged] 864 // either side now able to send further Telnet data or commands 866 7.2 Successful TLS negotiation, variation 868 The following protocol exchange is the typical sequence that starts TLS, 869 but with the twist that the (TN3270E) server is willing but not 870 aggressive about doing TLS; the client strongly desires doing TLS. 872 // typical successful opening exchange 873 S: IAC DO TN3270E 874 C: IAC WILL START_TLS IAC 875 S: IAC DO START_TLS 876 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 877 S: IAC SB START_TLS FOLLOWS IAC SE 878 // server now readies input stream for non-Telnet, TLS-level negotiation 879 C: [starts TLS-level negotiations with a ClientHello] 880 [TLS transport-level negotiation ensues] 881 [TLS transport-level negotiation completes with a Finished 882 exchanged] 883 // note that server retries negotiation of TN3270E after TLS 884 // is done. 885 S: IAC DO TN3270E 886 C: IAC WILL TN3270E 887 // TN3270E dialog continues.... 889 7.3 Unsuccessful TLS negotiation 891 This example assumes that the server does not wish to allow the Telnet 892 session to proceed without TLS security; however, the client's version 893 of TLS does not interoperate with the server's. 895 //typical unsuccessful opening exchange 896 S: IAC DO START_TLS 897 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 898 S: IAC SB START_TLS FOLLOWS IAC SE 899 // server now readies input stream for non-Telnet, TLS-level negotiation 900 C: [starts TLS-level negotiations with a ClientHello] 901 [TLS transport-level negotiation ensues] 902 [TLS transport-level negotiation fails with server sending 903 ErrorAlert message] 904 S: [TCP level disconnect] 905 // server (or both) initiate TCP session disconnection 907 This example assumes that the server wants to do TLS, but is willing to 908 allow the session to proceed without TLS security; however, the client's 909 version of TLS does not interoperate with the server's. 911 //typical unsuccessful opening exchange 912 S: IAC DO START_TLS 913 C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE 914 S: IAC SB START_TLS FOLLOWS IAC SE 915 // server now readies input stream for non-Telnet, TLS-level negotiation 916 C: [starts TLS-level negotiations with a ClientHello] 917 [TLS transport-level negotiation ensues] 918 [TLS transport-level negotiation fails with server sending 919 ErrorAlert message] 920 S: [TCP level disconnect] 921 // session is dropped 923 7.4 Authentication via Kerberos 5 after TLS negotiation 925 Here's an implementation example of using Kerberos 5 to authenticate the 926 client after encrypting the session with TLS. Note the following 927 details: 929 o The client strictly enforces a security policy of proposing Telnet 930 AUTH first, but accepting TLS. This has the effect of producing a 931 rather verbose pre-TLS negotiation sequence; however, the 932 end-result is correct. A more efficient pre-TLS sequence can be 933 obtained by changing the client security policy to be the same as 934 the server's for this connection (and implementing policy-aware 935 negotiation code in the Telnet part of the client). 937 A similar efficient result can be obtained even in the absence of a 938 clear client security policy if the client has cached server 939 security preferences from a previous Telnet session to the same 940 server. 942 o The server strictly enforces a security policy of proposing TLS 943 first, but falling back to Telnet AUTH. 945 C: IAC WILL AUTHENTICATION 946 C: IAC WILL NAWS 947 C: IAC WILL TERMINAL-TYPE 948 C: IAC WILL NEW-ENVIRONMENT 949 S: IAC DO START_TLS 950 C: IAC WILL START_TLS 951 C: IAC SB START_TLS FOLLOWS IAC SE 952 S: IAC DO AUTHENTICATION 953 S: IAC DO NAWS 954 S: IAC WILL SUPPRESS-GO-AHEAD 955 S: IAC DO SUPPRESS-GO-AHEAD 956 S: IAC WILL ECHO 957 S: IAC DO TERMINAL-TYPE 958 S: IAC DO NEW-ENVIRONMENT 959 S: IAC SB AUTHENTICATION SEND 960 KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ 961 KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL 962 KERBEROS_V5 CLIENT_TO_SERVER|ONE_WAY 963 SSL CLIENT_TO_SERVER|ONE_WAY IAC SE 964 S: IAC SB TERMINAL-TYPE SEND IAC SE 965 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 966 S: IAC SB START_TLS FOLLOWS IAC SE 967 [TLS - handshake starting] 968 [TLS - OK] 969 C: IAC WILL AUTHENTICATION 970 C: IAC WILL NAWS 971 C: IAC WILL TERMINAL-TYPE 972 C: IAC WILL NEW-ENVIRONMENT 973 974 S: IAC DO AUTHENTICATION 975 S: IAC DO NAWS 976 S: IAC WILL SUPPRESS-GO-AHEAD 977 C: IAC DO SUPPRESS-GO-AHEAD 978 S: IAC DO SUPPRESS-GO-AHEAD 979 C: IAC WILL SUPPRESS-GO-AHEAD 980 S: IAC WILL ECHO 981 C: IAC DO ECHO 982 S: IAC DO TERMINAL-TYPE 983 S: IAC DO NEW-ENVIRONMENT 984 S: IAC SB AUTHENTICATION SEND 985 KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL 986 KERBEROS_V5 CLIENT_TO_SERVER|ONE_WAY 987 IAC SE 988 C: IAC SB AUTHENTICATION NAME jaltman IAC SE 989 C: IAC SB AUTHENTICATION IS 990 KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL AUTH 991 6e 82 01 d4 30 82 01 d0 | a0 03 02 01 05 a1 03 02 992 01 0e a2 07 03 05 00 20 | 00 00 00 a3 82 01 18 61 993 82 01 14 30 82 01 10 a0 | 03 02 01 05 a1 10 1b 0e 994 41 54 48 45 4e 41 2e 4d | 49 54 2e 45 44 55 a2 29 995 30 27 a0 03 02 01 03 a1 | 20 30 1e 1b 04 68 6f 73 996 74 1b 16 61 6c 6c 2d 6e | 69 67 68 74 2d 74 6f 6f 997 6c 2e 6d 69 74 2e 65 64 | 75 a3 81 cb 30 81 c8 a0 998 03 02 01 01 a1 03 02 01 | 10 a2 81 bb 04 81 b8 92 999 25 23 ce 7a 7d dc bf 7d | 7a 53 07 17 55 3a 55 ef 1000 2b d5 44 7f bd f2 8e a5 | 13 69 ee e2 72 e2 10 9a 1001 a4 cf cb 55 3e 4a db d9 | 10 37 f4 50 be 6f 91 29 1002 c4 ef fe 77 ba ae b9 b7 | 5e e1 1c ed ff ff b8 f6 1003 b3 00 2d d9 83 1c 42 08 | bc 8b 14 aa de fa 46 39 1004 db 02 ed 21 79 66 4e 5d | 8a d6 f6 5a 66 10 82 00 1005 06 f4 cd b7 0e d4 57 99 | 89 81 f8 dc 4b 64 60 90 1006 75 66 d3 c9 74 27 ea 75 | d5 57 7a 7b 29 ad e1 de 1007 58 23 42 d8 09 f8 14 b7 | a4 67 8b 1c 86 e7 be 6f 1008 d8 69 66 d1 ab 8e 62 cc | a5 ee 43 02 7e 0c 16 c5 1009 ad 29 30 25 bc 26 98 0a | f1 3e c9 e8 14 7e 84 4e 1010 06 66 2c 0c f2 37 ee da | a4 81 9e 30 81 9b a0 03 1011 02 01 01 a2 81 93 04 81 | 90 3e d1 48 2b a3 e2 27 1012 90 48 35 93 d2 48 6a 80 | 6d 59 cd ab bb 94 23 99 1013 4c e8 02 e2 77 0e 39 e9 | e9 35 86 48 68 1b f2 94 1014 03 45 66 6f f2 e1 b0 f0 | 7f 78 ae ef 78 75 a8 e5 1015 03 47 ef 6a 08 b5 10 48 | 2a 3e f4 a4 dd 56 f9 5e 1016 03 4c a0 09 92 9f 22 3d | d5 5d 22 4b 9d ef e8 de 1017 cd 27 71 5b a2 4d 48 d3 | 85 73 0b 82 e5 22 52 4b 1018 b5 aa aa 6c bf aa 79 d2 | 9a b4 c2 48 3a 31 04 44 1019 bb d7 14 b3 2c f3 00 70 | be 04 a2 95 30 bb c2 dc 1020 a2 93 62 89 45 b2 64 bb | 8e 1021 IAC SE 1022 S: IAC SB TERMINAL-TYPE SEND IAC SE 1023 S: IAC SB NEW-ENVIRONMENT SEND IAC SE 1024 S: IAC SB AUTHENTICATION REPLY 1025 KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL RESPONSE 1026 6f 59 30 57 a0 03 02 01 | 05 a1 03 02 01 0f a2 4b 1027 30 49 a0 03 02 01 01 a2 | 42 04 40 29 56 c7 c0 87 1028 17 49 e4 87 02 d4 e1 ce | 34 de 78 a6 ae a8 cd f4 1029 b9 12 c4 88 29 93 f3 21 | f9 69 4e 65 73 fa 3a 6f 1030 70 fd 6e 18 bb 73 22 25 | d7 3b 1b e1 20 6c 45 d7 1031 6f 35 e3 3b 84 41 db 9b | 19 a4 44 1032 IAC SE 1033 S: IAC SB AUTHENTICATION REPLY 1034 KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL ACCEPT "jaltman@ATHENA.MIT.EDU" 1035 IAC SE 1036 C: IAC SB TERMINAL-TYPE IS VT320 IAC SE 1037 C: IAC SB NEW-ENVIRONMENT IS VAR USER VALUE jaltman VAR SYSTEMTYPE \\ 1038 VALUE WIN32 IAC SE 1039 C: IAC SB NAWS 162 49 IAC SE 1041 Here are several things to note about the above example: 1043 o After TLS is successfully negotiated, all non-TLS Telnet settings 1044 are forgotten and must be renegotiated. 1046 o After TLS is successfully negotiated, the server offers all 1047 authentication types that are appropriate for a session using TLS. 1048 Note that the server, post TLS-negotiation, isn't offering Telnet 1049 ENCRYPT or AUTH SSL, since (a) it's useless to encrypt twice, and 1050 (b) TLS and/or SSL can be applied only once to a Telnet session. 1052 8. IANA Considerations 1054 The IANA will update the Telnet Prootcol registry to reflect the 1055 contents of this document. In particular, IANA will document the 1056 START_TLS option number and the FOLLOWS sub-option. 1058 9. Normative References 1060 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 1061 Specifications: ABNF", RFC2235, November 1997. 1063 [AUTH] J. Altman, "Telnet Authentication Option", 1064 successor to RFC2941. 1065 draft-altman-telnet-rfc2941bis 1067 [AUTH-KRB5] J. Altman, "Telnet Authentication: Kerberos Version 5" 1068 successor to RFC2942 1069 draft-altman-telnet-rfc2942bis 1071 [ENCRYPT] T.Ts'o, "Telnet Encryption Option", RFC2946, 1072 September 2000. 1074 [IANA] IANA Assigned Telnet Options 1075 http://www.iana.org/assignments/telnet-options 1077 [KEYWORDS] Bradner, S. "Key words for use in RFCs to Indicate 1078 Requirement Levels", RFC2119, March 1997. 1080 [RFC2360] G. Scott, Editor. "Guide for Internet Standard Writers", 1081 RFC2360, June 1998. 1083 [RFC3280] Housley, R., Ford, W., Polk, W. and D.Solo, "Internet 1084 Public Key Infrastructure: Part I: X.509 Certificate and 1085 CRL Profile", RFC3280, April 2002. 1087 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specifications", 1088 RFC854, May 1983. 1090 [TLS] Tim Dierks, C. Allen. "The TLS Protocol Version 1.1", 1091 RFC4346, April 2006. 1093 [TLS-CB] J. Altman, N. Williams. "TLS Channel Bindings", 1094 draft-altman-tls-channel-bindings-XX.txt 1096 [TLSKERB] Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher 1097 Suites to Transport Layer Security (TLS)", RFC2712, October 1098 1999. 1100 [TLSPSK] Eronen, P. and H. Tschofenig. "Pre-Shared Key Ciphersuites 1101 for Transport Layer Security (TLS)", RFC4279, December 2005. 1103 10. Informational references 1105 [RFC927] Brian A. Anderson. "TACACS User Identification Telnet 1106 Option", RFC927, December 1984 1108 11. Editor 1110 Jeffrey Altman 1111 Secure Endpoints Inc 1112 255 W 94th ST 1113 New York NY 10025 USA 1115 jaltman@secure-endpoints.com 1117 12. Credits 1119 This document was originally the product of the TN3270WG and was 1120 co-authored by Michael Boe. The TN3270WG closed before this document 1121 could be submitted to the IESG. Russ Housley and Eric Rescorla provided 1122 significant feedback during its initial publication. 1124 Full Copyright Statement 1126 Copyright (C) The IETF Trust (2006). 1128 This document is subject to the rights, licenses and restrictions 1129 contained in BCP 78, and except as set forth therein, the authors 1130 retain all their rights. 1132 This document and the information contained herein are provided on an 1133 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1134 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1135 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1136 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1137 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1138 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1140 Intellectual Property 1142 The IETF takes no position regarding the validity or scope of any 1143 Intellectual Property Rights or other rights that might be claimed to 1144 pertain to the implementation or use of the technology described in 1145 this document or the extent to which any license under such rights 1146 might or might not be available; nor does it represent that it has 1147 made any independent effort to identify any such rights. Information 1148 on the procedures with respect to rights in RFC documents can be 1149 found in BCP 78 and BCP 79. 1151 Copies of IPR disclosures made to the IETF Secretariat and any 1152 assurances of licenses to be made available, or the result of an 1153 attempt made to obtain a general license or permission for the use of 1154 such proprietary rights by implementers or users of this 1155 specification can be obtained from the IETF on-line IPR repository at 1156 http://www.ietf.org/ipr. 1158 The IETF invites any interested party to bring to its attention any 1159 copyrights, patents or patent applications, or other proprietary 1160 rights that may cover technology that may be required to implement 1161 this standard. Please address the information to the IETF at 1162 ietf-ipr@ietf.org. 1164 Acknowledgment 1166 Funding for the RFC Editor function is provided by the IETF 1167 Administrative Support Activity (IASA).