idnits 2.17.1 draft-altman-telnet-rfc2941bis-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 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 781. 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 791 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 6340 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) -- Looks like a reference, but probably isn't: '4' on line 713 == Unused Reference: 'RFC 854' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC 2941' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC 2434' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 695, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 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-rfc2941bis-02.txt 3 Expires: 16 July 2007 4 December 15, 2006 6 Telnet Authentication 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 16 July 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2006). 38 Abstract 40 This document describes the authentication option to the Telnet 41 protocol, RFC 854, as a generic method for negotiating an authentication 42 type and mode including whether encryption should be used and if 43 credentials should be forwarded. While this document summarizes 44 currently utilized commands and types it does not define a specific 45 authentication type. Separate documents are to be published defining 46 each authentication type. 48 This document updates a previous specification of the Telnet 49 authentication option, RFC 2941, to allow the AUTHENTICATION 50 option to be used in conjunction with the START_TLS option, RFC XXXX. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 55 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 56 "OPTIONAL" in this document are to be interpreted as described in 57 RFC 2119. 59 1. Introduction 61 This document describes the authentication option to the Telnet 62 protocol, RFC 854, as a generic method for negotiating an authentication 63 type and mode including whether encryption should be used and if 64 credentials should be forwarded. While this document summarizes 65 currently utilized commands and types it does not define a specific 66 authentication type. Separate documents are to be published defining 67 each authentication type. 69 This document updates a previous specification of the telnet 70 authentication option, RFC 2941, to allow the AUTHENTICATION 71 option to be used in conjunction with the START_TLS option, RFC XXXX. 73 This document consolidates and expands the security considerations 74 section. 76 2. Command Names and Codes 78 AUTHENTICATION 37 80 Authentication Commands 81 IS 0 82 SEND 1 83 REPLY 2 84 NAME 3 86 Authentication Types 87 NULL 0 88 KERBEROS_V4 1 89 KERBEROS_V5 2 90 SPX* 3 91 MINK* 4 92 SRP 5 93 RSA*[also used by SRA*] 6 94 SSL* 7 95 [unassigned] 8 96 [unassigned] 9 97 LOKI* 10 98 SSA* 11 99 KEA_SJ 12 100 KEA_SJ_INTEG 13 101 DSS 14 102 NTLM* 15 104 Authentication types followed by (*) were never submitted to the 105 IETF for consideration as an Internet standard. 107 Modifiers 108 AUTH_WHO_MASK 1 109 AUTH_CLIENT_TO_SERVER 0 110 AUTH_SERVER_TO_CLIENT 1 112 AUTH_HOW_MASK 2 113 AUTH_HOW_ONE_WAY 0 114 AUTH_HOW_MUTUAL 2 116 ENCRYPT_MASK 20 117 ENCRYPT_OFF 0 118 ENCRYPT_USING_TELOPT 4 119 ENCRYPT_AFTER_EXCHANGE 16 120 ENCRYPT_START_TLS 20 122 INI_CRED_FWD_MASK 8 123 INI_CRED_FWD_OFF 0 124 INI_CRED_FWD_ON 8 126 3. Command Meanings 128 This document makes reference to a "server" and a "client". For the 129 purposes of this document, the "server" is the side of the connection 130 that performed the passive TCP open (TCP LISTEN state), and the 131 "client" is the side of the connection that performed the active TCP 132 open. 134 IAC WILL AUTHENTICATION 136 The client side of the connection sends this command to indicate 137 that it is willing to send and receive authentication information. 139 IAC DO AUTHENTICATION 141 The servers side of the connection sends this command to indicate 142 that it is willing to send and receive authentication information. 144 IAC WONT AUTHENTICATION 146 The client side of the connection sends this command to indicate 147 that it refuses to send or receive authentication information; the 148 server side must send this command if it receives a DO 149 AUTHENTICATION command. 151 IAC DONT AUTHENTICATION 153 The server side of the connection sends this command to indicate 154 that it refuses to send or receive authentication information; the 155 client side must send this command if it receives a WILL 156 AUTHENTICATION command. 158 IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE 160 The sender of this command (the server) requests that the remote 161 side send authentication information for one of the authentication 162 types listed in "authentication-type-pair-list". The 163 "authentication-type-pair-list" is an ordered list of 164 "authentication-type" pairs. Only the server side (DO 165 AUTHENTICATION) is allowed to send this. 167 IAC SB AUTHENTICATION IS authentication-type-pair IAC SE 169 The sender of this command (the client) is sending the 170 authentication information for authentication type 171 "authentication-type-pair". Only the client side (WILL 172 AUTHENTICATION) is allowed to send this. 174 IAC SB AUTHENTICATION REPLY authentication-type-pair IAC 175 SE 177 The sender of this command (the server) is sending a reply to the 178 the authentication information received in a previous IS command. 179 Only the server side (DO AUTHENTICATION) is allowed to send this. 181 IAC SB AUTHENTICATION NAME remote-user IAC SE 183 This optional command is sent to specify the account name on the 184 remote host that the user wishes to be authorized to use. Note 185 that authentication may succeed, and the authorization to use a 186 particular account may still fail. Some authentication mechanisms 187 may ignore this command. (See Security Considerations.) 189 The "authentication-type-pair" is two octets, the first is the 190 authentication type, and the second is a modifier to the type. The 191 authentication type may or may not include built-in encryption. For 192 instance, when the Kerberos 5 authentication type is negotiated 193 encryption must be negotiated with either the Telnet START_TLS or 194 ENCRYPT options [RFC 2946]. However, the SSL and KEA_SJ authentication 195 types provide an encrypted channel as part of a successful Telnet AUTH 196 option negotiation. 198 There are currently five one bit fields defined in the modifier. The 199 first two of these bits are processed as a pair, the AUTH_WHO_MASK 200 bit and the AUTH_HOW_MASK bit. There are four possible combinations 201 of these two bits: 203 AUTH_CLIENT_TO_SERVER 204 AUTH_HOW_ONE_WAY 206 The client will send authentication information about the local 207 user to the server. If the negotiation is successful, the 208 server will have authenticated the user on the client side of 209 the connection. 211 AUTH_SERVER_TO_CLIENT 212 AUTH_HOW_ONE_WAY 214 The server will authenticate itself to the client. If the 215 negotiation is successful, the client will know that it is 216 connected to the server that it wants to be connected to. 218 AUTH_CLIENT_TO_SERVER 219 AUTH_HOW_MUTUAL 221 The client will send authentication information about the local 222 user to the server, and then the server will authenticate 223 itself to the client. If the negotiation is successful, the 224 server will have authenticated the user on the client side of 225 the connection, and the client will know that it is connected 226 to the server that it wants to be connected to. 228 AUTH_SERVER_TO_CLIENT 229 AUTH_HOW_MUTUAL 231 The server will authenticate itself to the client, and then the 232 client will authenticate itself to the server. If the 233 negotiation is successful, the client will know that it is 234 connected to the server that it wants to be connected to, and 235 the server will know that the client is who it claims to be. 237 The third and fifth bits in the modifier are the ENCRYPT_MASK 238 bits. These bits are used to determine if and how encryption 239 should be enabled. Of the four possible combinations only three 240 are currently defined: 242 ENCRYPT_OFF 244 Encryption will not be used for this session. TELOPT 245 ENCRYPT SHOULD NOT be negotiated. This mode MUST be used 246 with all AUTH types that do not provide a shared secret to 247 be used as a session key. 249 ENCRYPT_USING_TELOPT 251 Encryption will be negotiated via the use of TELOPT ENCRYPT. 252 Immediately after authentication has completed TELOPT 253 ENCRYPT MUST be negotiated in both directions. This is 254 required to occur before credentials forwarding; other 255 telnet options are negotiated; or any user data is 256 transmitted. A failure to successfully negotiate TELOPT 257 ENCRYPT in either direction MUST result in immediate session 258 termination. 260 ENCRYPT_AFTER_EXCHANGE 262 Encryption will be activated in both directions immediately 263 after the successful exchange of the shared secret to be 264 used as the session key. The encryption algorithm to be 265 used MUST be implied by the AUTH type. 267 ENCRYPT_START_TLS 269 Encryption is provided by TLS which MUST have been 270 negotiated prior to use of this flag. If TLS has not been 271 previous negotiated, authentication-type-pairs including 272 this flag MUST NOT be offered by the server and MUST NOT be 273 accepted by the client. Authentication methods that support 274 this option MUST verify the TLS Channel Binding data [RFC 4346] 275 as part of the authentication exchange. 277 The fourth bit field in the modifier is the INI_CRED_FWD_MASK bit. 278 This bit is either set to INI_CRED_FWD_ON or INI_CRED_FWD_OFF. 279 This bit is set by the client to advise the server to expect 280 forwarded credentials from the client. 282 INI_CRED_FWD_OFF 284 The client will not be forwarding credentials to the server. 285 This mode must be used if the selected authentication method 286 does not support credentials forwarding. 288 INI_CRED_FWD_ON 290 Once authentication, and perhaps encryption, completes, the 291 client will immediately forward authentication credentials 292 to the server. 294 The motivation for this advisory bit is that the server may wish 295 to wait until the forwarded credentials have been sent before 296 starting any operating system specific login procedures which may 297 depend on these credentials. Note that credentials forwarding may 298 not be supported by all authentication mechanisms. It is a 299 protocol error to set this bit if the underlying authentication 300 mechanism does not support credentials forwarding. 302 Credentials forwarding MUST NOT be performed if 303 AUTH_CLIENT_TO_SERVER|AUTH_HOW_ONE_WAY was used since the identity 304 of the server can not be assured. Credentials SHOULD NOT be 305 forwarded if the telnet connection is not protected using some 306 encryption or integrity protection services. 308 Note that older implementations of the telnet authentication 309 option will not understand the ENCRYPT_MASK and INI_CRED_FWD_MASK 310 bits. Hence any implementation wishing to offer these bits will 311 have to offer authentication type pairs with these bits both set 312 and not set if backwards compatibility is required. (See Security 313 Considerations.) 315 4. Default Specification 317 The default specification for this option is 319 WONT AUTHENTICATION DONT AUTHENTICATION 321 meaning there will not be any exchange of authentication information. 323 5. Motivation 325 One of the deficiencies of the Telnet protocol is that in order to 326 log into remote systems, users have to type their passwords, which 327 are passed in clear text through the network. If the connection 328 go through untrusted networks, there is the possibility that 329 passwords will be compromised by someone watching the packets while 330 in transit. 332 The purpose of the AUTHENTICATION option is to provide a framework 333 for the passing of authentication information through the TELNET 334 session, and a mechanism to enable encryption of the data stream as a 335 side effect of successful authentication or via subsequent use of the 336 telnet ENCRYPT option. This means that: 1) the users password will 337 not be sent in clear text across the network, 2) if the front end 338 telnet process has the appropriate authentication information, it can 339 automatically send the information, and the user will not have to 340 type any password. 3) once authentication has succeeded, the data 341 stream can be encrypted to provide protection against active attacks. 343 It is intended that the AUTHENTICATION option be general enough that 344 it can be used to pass information for any authentication and 345 encryption system. 347 6. Implementation Rules 349 WILL and DO are used only at the beginning of the connection to 350 obtain and grant permission for future negotiations. 352 The authentication is only negotiated in one direction; the server 353 must send the "DO", and the client must send the "WILL". This 354 restriction is due to the nature of authentication; there are three 355 possible cases; server authenticates client, client authenticates 356 server, and server and client authenticate each other. By only 357 negotiating the option in one direction, and then determining which 358 of the three cases is being used via the suboption, potential 359 ambiguity is removed. If the server receives a "DO", it must respond 360 with a "WONT". If the client receives a "WILL", it must respond with 361 a "DONT". 363 Once the two hosts have exchanged a DO and a WILL, the server is free 364 to request authentication information. In the request, a list of 365 supported authentication types is sent. Only the server may send 366 requests ("IAC SB AUTHENTICATION SEND authentication-type-pair-list 367 IAC SE"). Only the client may transmit authentication information 368 via the "IAC SB AUTHENTICATION IS authentication-type ... IAC SE" 369 command. Only the server may send replies ("IAC SB AUTHENTICATION 370 REPLY authentication-type ... IAC SE"). As many IS and REPLY 371 suboptions may be exchanged as are needed for the particular 372 authentication scheme chosen. 374 If the client does not support any of the authentication types listed 375 in the authentication-type-pair-list, a type of NULL should be used 376 to indicate this in the IS reply. Note that if the client responds 377 with a type of NULL, the server may choose to close the connection. 379 When the server has concluded that authentication cannot be 380 negotiated with the client it should send IAC DONT AUTH to the 381 client. 383 The order of the authentication types MUST be ordered to indicate a 384 preference for different authentication types, the first type being 385 the most preferred, and the last type the least preferred. 387 As long as the server is WILL AUTH it may request authentication 388 information at any time. This is done by sending a new list of 389 supported authentication types. Requesting authentication 390 information may be done as a way of verifying the validity of the 391 client's credentials after an extended period of time or to negotiate 392 a new session key for use during encryption. 394 7. Integration with TELNET START_TLS option 396 The Telnet START_TLS option [RFC XXXX] enables the Telnet client and 397 server to negotiate the use of the TLS protocol to secure the 398 connection. TLS is most frequently used with X.509 server-side 399 certificates [RFC 3280]. When properly verified by the client the TLS 400 session provides strong encryption and protects against a wide range 401 of passive and active attacks. When certificates are not used or not 402 verified by the client, the session (although encrypted) is susceptible 403 to man-in-the-middle attacks. These attacks can be detected by 404 verifying the TLS Channel Binding data [RFC 4346] during the Telnet 405 AUTHENTICATION protocol exchange. The method for performing this 406 verification is authentication type specific. 408 8. User Interface 410 Normally protocol specifications do not address user interface 411 specifications. However, due to the fact that the user will probably 412 want to be able to configure the authentication and 413 encryption and know whether or not the negotiations succeeded, some 414 guidance needs to be given to implementors to provide some minimum 415 level of user control. 417 The user of the client MUST be able to specify whether or not 418 authentication is to be used, and whether or not encryption is to 419 used if the authentication succeeds. There SHOULD be at least four 420 settings, REQUIRE, PROMPT, WARN and DISABLE. Setting the 421 authentication switch to REQUIRE means that if the authentication 422 fails, then an appropriate error message must be displayed and the 423 TELNET connection must be terminated. Setting the authentication 424 switch to PROMPT means that if the authentication fails, then an 425 appropriate error message must be displayed and the user must be 426 prompted for confirmation before continuing the TELNET session. 427 Setting the authentication switch to WARN means that if the 428 authentication fails, then an appropriate error message must be 429 displayed before continuing the TELNET session. Setting the 430 authentication switch to DISABLE means that authentication will not 431 be attempted. The encryption switch SHOULD have the same settings as 432 the authentication switch; however its settings are only used when 433 authentication succeeds. The default setting for both switches 434 should be WARN. Both of these switches may be implemented as a 435 single switch, though having them separate gives more control to 436 the user. 438 The server MUST provide the system administrator the ability to 439 specify whether or not authentication is required and which 440 authentication type pairs should be offered to the client and 441 in what order of preference. 443 9. Security Considerations 445 This memo describes a general framework for adding authentication and 446 encryption to the telnet protocol. The actual authentication 447 mechanism is described in the authentication suboption 448 specifications, and the security of the authentication option is 449 dependent on the strengths and weaknesses of the authentication 450 suboption. 452 The ability to negotiate a common authentication mechanism between 453 client and server is a feature of the authentication option that 454 should be used with caution. When the negotiation is performed, no 455 authentication has yet occurred. Therefore each system has no way of 456 knowing whether or not it is connected to the intended system. An 457 intruder could attempt to negotiate the use of an authentication 458 system which is either weak, or already compromised by the intruder. 460 It should be noted that the negotiation of the authentication 461 type pair is not protected, thus allowing an attacker to force the 462 result of the authentication to the weakest mutually acceptable 463 method. (For example, even if both sides of the negotiation can 464 accept a "strong" mechanism and a "40-bit" mechanism, an attacker 465 could force selection of the "40-bit" mechanism.) An implementation 466 should therefore only accept an authentication mechanism to be 467 negotiated if it is willing to trust the resulting channel as being 468 secure. 470 If the START_TLS option has not been negotiated and the 471 authentication type requires that encryption be enabled as a separate 472 optional negotiation there will be a window of vulnerability from the 473 completion of the AUTH option until the successful negotiation to 474 activiate bidirectional encryption. During this window an active 475 attack may be successfully implemented. An active attack is one 476 where the underlying TCP stream can be modified or taken over by the 477 active attacker. 479 The active attack can be prevented if the server only offers 480 authentication type pairs that include the ENCRYPT_USING_TELOPT or 481 ENCRYPT_START_TLS bits set in the ENCRYPT_MASK field, since both 482 parties will agree that an encryption capability must be successfully 483 negotiated. When the ENCRYPT_USING_TELOPT bit is negotiated, the 484 ENCRYPT option MUST be negotiated immediately following the 485 successful completion of the AUTH option. 487 Authentication types that link the enabling of encryption as a side 488 effect of successful authentication are not vulnerable to this active 489 attack. The ENCRYPT_AFTER_EXCHANGE bit allows these authentication 490 types to optionally negotiate the activation of encryption. 492 Another opportunity for active attacks is presented when encryption 493 may be turned on and off without re-authentication. Once encryption 494 is disabled, an attacker may hijack the telnet stream, and interfere 495 with attempts to restart encryption. Therefore, a client SHOULD NOT 496 support the ability to turn off encryption. Once encryption is 497 disabled, if an attempt to re-enable encryption fails, the client 498 MUST terminate the telnet connection. 500 It is important that in all cases the authentication type pair be 501 integrity protected at the end of the authentication exchange. This 502 must be specified for each authentication type to ensure that the 503 result of the telnet authentication option negotiation is agreed to 504 by both the client and the server. To prevent downgrade attacks 505 authentication type suboptions SHOULD (if possible) include either 506 the entire auth-type pair list; or all of the telnet authentication 507 negotiation exchanges in the integrity checksum. 509 Each side MUST verify the consistency of the auth-type-pairs in each 510 message received. Any variation in the auth-type-pair MUST be 511 treated as a fatal protocol error. 513 It should also be noted that the transmission of the username in 514 the IAC SB AUTHENTICATION NAME name IAC SE message is not protected. 515 Implementations should verify the value by a secure method before 516 using this untrusted value when there is a possibility of a man-in- 517 the-middle attack. One method of verifying this value is for the 518 server to request the USER using the NEW ENVIRONMENT option after 519 mutual authentication has been established [RFC 1572]. 521 10. Example 523 The following is an example of use of the option: 525 Client Server 526 IAC DO AUTHENTICATION 527 IAC WILL AUTHENTICATION 528 [ The server is now free to request authentication information. ] 529 IAC SB AUTHENTICATION SEND 530 KERBEROS_V5 CLIENT|MUTUAL 531 KERBEROS_V5 CLIENT|ONE_WAY IAC 532 SE 533 [ The server has requested mutual Kerberos authentication, but is 534 willing to do just one-way Kerberos authentication. The client 535 will now respond with the name of the user that it wants to log 536 in as, and the Kerberos ticket. ] 537 IAC SB AUTHENTICATION NAME "joe" 538 IAC SE 539 IAC SB AUTHENTICATION IS 540 KERBEROS_V5 CLIENT|MUTUAL AUTH 4 541 7 1 67 82 65 89 46 67 7 9 77 0 542 48 24 49 244 109 240 50 208 43 543 35 25 116 104 44 167 21 201 224 544 229 145 20 2 244 213 220 33 134 545 148 4 251 249 233 229 152 77 2 546 109 130 231 33 146 190 248 1 9 547 31 95 94 15 120 224 0 225 76 205 548 70 136 245 190 199 147 155 13 549 IAC SE 550 [ The server responds with an ACCEPT command to state that the 551 authentication was successful. ] 552 IAC SB AUTHENTICATION REPLY 553 KERBEROS_V5 CLIENT|MUTUAL ACCEPT 554 IAC SE 555 [ Next, the client sends across a CHALLENGE to verify that it is 556 really talking to the right server. ] 557 IAC SB AUTHENTICATION IS 558 KERBEROS_V5 CLIENT|MUTUAL 559 CHALLENGE xx xx xx xx xx xx xx 560 xx IAC SE 561 [ Lastly, the server sends across a RESPONSE to prove that it 562 really is the right server. ] 564 IAC SB AUTHENTICATION REPLY 565 KERBEROS_V5 CLIENT|MUTUAL 566 RESPONSE yy yy yy yy yy yy yy yy 567 IAC SE 569 The following is an example of use of the option with encryption 570 negotiated via telnet ENCRYPT: 572 Client Server 573 IAC DO AUTHENTICATION 574 IAC WILL AUTHENTICATION 575 [ The server is now free to request authentication information. ] 576 IAC SB AUTHENTICATION SEND 577 KERBEROS_V5 578 CLIENT|MUTUAL|ENCRYPT_USING_TELOPT 579 KERBEROS_V5 CLIENT|ONE_WAY IAC 580 SE 581 [ The server has requested mutual Kerberos authentication, but is 582 willing to do just one-way Kerberos authentication. In both 583 cases it is willing to encrypt the data stream. The client 584 will now respond with the name of the user that it wants to log 585 in as, and the Kerberos ticket. ] 586 IAC SB AUTHENTICATION NAME "joe" 587 IAC SE 588 IAC SB AUTHENTICATION IS 589 KERBEROS_V5 590 CLIENT|MUTUAL|ENCRYPT_USING_TELOPT 591 AUTH 4 7 1 67 82 65 89 46 67 7 9 592 77 0 48 24 49 244 109 240 50 208 593 43 35 25 116 104 44 167 21 201 594 224 229 145 20 2 244 213 220 33 595 134 148 4 251 249 233 229 152 77 596 2 109 130 231 33 146 190 248 1 9 597 31 95 94 15 120 224 0 225 76 205 598 70 136 245 190 199 147 155 13 599 IAC SE 600 [ The server responds with an ACCEPT command to state that the 601 authentication was successful. ] 602 IAC SB AUTHENTICATION REPLY 603 KERBEROS_V5 604 CLIENT|MUTUAL|ENCRYPT_USING_TELOPT 605 ACCEPT IAC SE 606 [ Next, the client sends across a CHALLENGE to verify that it is 607 really talking to the right server. ] 608 IAC SB AUTHENTICATION IS 609 KERBEROS_V5 610 CLIENT|MUTUAL|ENCRYPT_USING_TELOPT 611 CHALLENGE xx xx xx xx xx xx xx 612 xx IAC SE 613 [ The server sends across a RESPONSE to prove that it really is 614 the right server. ] 615 IAC SB AUTHENTICATION REPLY 616 KERBEROS_V5 617 CLIENT|MUTUAL|ENCRYPT_USING_TELOPT 618 RESPONSE yy yy yy yy yy yy yy yy 619 IAC SE 620 [ At this point, the client and server begin to negotiate the 621 telnet ENCRYPT option in each direction for a secure channel. 622 If the option fails in either direction for any reason the 623 connection must be immediately terminated. ] 625 The following is an example of use of the option with integrated 626 encryption: 628 Client Server 629 IAC DO AUTHENTICATION 630 IAC WILL AUTHENTICATION 631 [ The server is now free to request authentication information. ] 632 IAC SB AUTHENTICATION SEND 633 KEA_SJ 634 CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE 635 IAC SE 636 [ The server has requested mutual KEA authentication with 637 SKIPJACK encryption. The client will now respond with the name 638 of the user that it wants to log in as and the KEA cert. ] 639 IAC SB AUTHENTICATION NAME "joe" 640 IAC SE IAC SB AUTHENTICATION IS 641 KEA_SJ 642 CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE 643 '1' CertA||Ra IAC SE 644 [ The server responds with its KEA Cert. ] 645 IAC SB AUTHENTICATION REPLY 646 KEA_SJ 647 CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE 648 '2' 649 CertB||Rb||IVb||Encrypt(NonceB) 650 IAC SE 651 [ Next, the client sends across a CHALLENGE to verify that it is 652 really talking to the right server. ] 653 IAC SB AUTHENTICATION IS KEA_SJ 654 CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE 655 '3' IVa||Encrypt( NonceB xor 656 0x0C18 || NonceA ) IAC SE 658 [ At this point, the client begins to encrypt the outgoing data 659 stream, and the server, after receiving this command, begins to 660 decrypt the incoming data stream. Lastly, the server sends 661 across a RESPONSE to prove that it really is the right server. ] 662 IAC SB AUTHENTICATION REPLY 663 KEA_SJ 664 CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE 665 '4' Encrypt( NonceA xor 0x0C18 ) 666 IAC SE 667 [ At this point, the server begins to encrypt its outgoing data 668 stream, and the client, after receiving this command, begins to 669 decrypt its incoming data stream. ] 671 It is expected that any implementation that supports the Telnet 672 AUTHENTICATION option will support all of this specification. 674 11. Normative References 676 [RFC 854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", 677 STD 8, RFC 854, May 1983. 679 [RFC 2941] T'so, T. and Altman, J., "Telnet Authentication Option", 680 RFC 2941, September 2000. 682 [RFC 2946] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, 683 September 2000. 685 [RFC 2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 686 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 687 October 1998. 689 [RFC XXXX] Altman, J., "Telnet START_TLS Option", 690 draft-altman-telnet-starttls 692 [RFC 1572] Alexander, S., "Telnet Environment Option", RFC 1572, 693 January 1994 695 [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate 696 Requirement Levels", RFC2119, March 1997. 698 [RFC 4346] Dierks, T. and E. Rescorla. "The Transport Layer Security 699 (TLS) Protocol Version 1.1.", RFC4346, April 2006. 701 [RFC 3280] Housley, R., Polk, W., Ford, W., and Solo, D. 702 "Internet X.509 Publick Key Infrastructure Certificiate and 703 Certificate Revocation List (CRL) Profile", RFC3280, 704 April 2002 706 12. IANA Considerations 708 The IANA will maintain a registry of Telnet Authentication Option 709 mechanism values. 711 Following historical practice, future authentication type numbers 712 and authentication modifiers will be assigned by the IANA under a 713 First Come First Served policy as outlined by RFC 2434 [4]. 714 Despite the fact that authentication type numbers are allocated 715 out of an 8-bit number space (as are most values in the telnet 716 specification) it is not anticipated that the number space is or 717 will become in danger of being exhausted. However, if this 718 should become an issue, when over 50% of the number space becomes 719 allocated, the IANA shall refer allocation requests to either the 720 IESG or a designated expert for approval. IANA is instructed not 721 to issue new suboption values without submission of documentation 722 of their use. 724 13. Acknowledgements 726 RFC 2941 from which this document was derived was edited by Theodore 727 Ts'o and Jeffrey Altman. 729 Many people have worked on this document over the span of many years. 730 Dave Borman was a document editor and author of much of the original 731 text. Other folks who have contributed ideas and suggestions to this 732 text include: David Carrel, Jeff Schiller, and Richard Basch. 734 14. Editor 736 Jeffrey Altman 737 Secure Endpoints Inc 738 255 W 94th ST 739 New York NY 10025 USA 741 jaltman@secure-endpoints.com 743 Full Copyright Statement 745 Copyright (C) The IETF Trust (2006). 747 This document is subject to the rights, licenses and restrictions 748 contained in BCP 78, and except as set forth therein, the authors 749 retain all their rights. 751 This document and the information contained herein are provided on an 752 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 753 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 754 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 755 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 756 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 757 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 759 Intellectual Property 761 The IETF takes no position regarding the validity or scope of any 762 Intellectual Property Rights or other rights that might be claimed to 763 pertain to the implementation or use of the technology described in 764 this document or the extent to which any license under such rights 765 might or might not be available; nor does it represent that it has 766 made any independent effort to identify any such rights. Information 767 on the procedures with respect to rights in RFC documents can be 768 found in BCP 78 and BCP 79. 770 Copies of IPR disclosures made to the IETF Secretariat and any 771 assurances of licenses to be made available, or the result of an 772 attempt made to obtain a general license or permission for the use of 773 such proprietary rights by implementers or users of this 774 specification can be obtained from the IETF on-line IPR repository at 775 http://www.ietf.org/ipr. 777 The IETF invites any interested party to bring to its attention any 778 copyrights, patents or patent applications, or other proprietary 779 rights that may cover technology that may be required to implement 780 this standard. Please address the information to the IETF at 781 ietf-ipr@ietf.org. 783 Acknowledgment 785 Funding for the RFC Editor function is provided by the IETF 786 Administrative Support Activity (IASA).