idnits 2.17.00 (12 Aug 2021) /tmp/idnits38139/draft-galvin-telnet-authenc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 294: '... MUST send the "DO" and the client M...' RFC 2119 keyword, line 300: '...eceives a "DO", it MUST respond with a...' RFC 2119 keyword, line 301: '...eives a "WILL", it MUST respond with a...' RFC 2119 keyword, line 306: '...pes is sent. Only the server MAY send...' RFC 2119 keyword, line 308: '... Only the client MAY transmit authenti...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 1995) is 9800 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) ** Obsolete normative reference: RFC 1416 (ref. '1') (Obsoleted by RFC 2941) ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Experimental RFC: RFC 1411 (ref. '3') Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Galvin 2 INTERNET-DRAFT S. Murphy 3 draft-galvin-telnet-authenc-00.txt D. Balenson 4 TIS 5 July 1995 7 Telnet Authentication and Encryption Option 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It 18 is inappropriate to use Internet Drafts as reference material or to 19 cite them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 1id-abstracts.txt listing contained in one of the Internet Drafts 23 Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu 24 (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net 25 (Europe). 27 Abstract 29 One of the deficiences of the Telnet protocol is that in order to log 30 into remote systems users have to type their passwords, which are 31 passed in the clear through the network. This document specifies the 32 AUTH_ENCRYPT option, whose purpose is two-fold: to provide a 33 framework for the passing of authentication information through the 34 TELNET session and to provide a mechanism to enable encryption of the 35 data stream as a side effect of successful authentication. 37 Acknowledgements 39 This document represents a revision of RFC1416 [1] that has been 40 enhanced to include the optional encryption of the data stream. The 41 work of Dave Borman (Editor), Steve Alexander (Telnet working group 42 chair), and the Telnet working group in the preparation of that 43 document is gratefully acknowledged. Ted Ts'o deserves special 44 mention for keeping track of the details of this enhancement and 45 providing them to us so that this document could be prepared. 47 1. Introduction 49 One of the deficiences of the Telnet protocol is that in order to log 50 into remote systems users have to type their passwords, which are 51 passed in the clear through the network. If the connection goes 52 through untrusted networks, there is the possibility that an intruder 53 may eavesdrop on the packets as they go by and thus obtain the 54 password. 56 This document specifies the AUTH_ENCRYPT option, whose purpose is 57 two-fold: to provide a framework for the passing of authentication 58 information through the TELNET session and to provide a mechanism to 59 enable encryption of the data stream as a side effect of successful 60 authentication. This means that: 62 1) the user's password will not be sent unencrypted across the 63 network, 65 2) if the front end telnet process has the appropriate authentication 66 information it can automatically send it instead of the user typing 67 any password, and 69 3) once authentication has succeeded the data stream can be encrypted 70 to provide protection against active attacks. 72 It is intended that the AUTH_ENCRYPT option be general enough that it 73 can be used to pass information for any authentication and encryption 74 type. 76 It is expected that any implementation that supports the Telnet 77 AUTH_ENCRYPT option will support all of this specification. 79 2. Command Names and Codes 81 This section lists the codes for the Telnet authentication and 82 encryption option, commands, and modifiers, as well as the initially 83 defined authentication and encryption types. The codes for the 84 authentication and encryption types are officially assigned and 85 maintained by IANA. The values are published regularly in STD2, 86 which is currently RFC1700 [2]. 88 AUTH_ENCRYPT XX 90 Authentication and Encryption Commands 92 IS 0 93 SEND 1 94 REPLY 2 95 NAME 3 96 END_ENCRYPT 4 97 REQUEST_END_ENCRYPT 5 99 Authentication and Encryption Types 101 NULL 0 102 KERBEROS_V4 1 103 KERBEROS_V5 2 104 SPX 3 105 RSA 6 106 LOKI 10 107 GSSAPI XX 109 Modifiers 111 AUTH_WHO_MASK 1 112 AUTH_CLIENT_TO_SERVER 0 113 AUTH_SERVER_TO_CLIENT 1 115 AUTH_HOW_MASK 2 116 AUTH_HOW_ONE_WAY 0 117 AUTH_HOW_MUTUAL 2 119 ENCRYPT_MASK 4 120 ENCRYPT_OFF 0 121 ENCRYPT_ON 4 123 INI_CRED_FWD_MASK 8 124 INI_CRED_FWD_OFF 0 125 INI_CRED_FWD_ON 8 127 3. Command Meanings 129 This document makes reference to a "server" and a "client". For the 130 purposes of this document, the "server" is the side of the connection 131 that did the passive TCP open (TCP LISTEN state), and the "client" is 132 the side of the connection that did the active open. 134 IAC WILL AUTH_ENCRYPT 136 The client side of the connection sends this command to indicate 137 that it is willing to send and receive authentication and 138 encryption information. 140 IAC DO AUTH_ENCRYPT 142 The server side of the connection sends this command to indicate 143 that it is willing to send and receive authentication and 144 encryption information. 146 IAC WONT AUTH_ENCRYPT 148 The client side of the connection sends this command to indicate 149 that it refuses to send or receive authentication or encryption 150 information. The server side sends this command if it receives a 151 DO AUTH_ENCRYPT command and it refuses to send or receive 152 authentication or encryption information. 154 IAC DONT AUTH_ENCRYPT 156 The server side of the connection sends this command to indicate 157 that it refuses to send or receive authentication or encryption 158 information. The client side sends this command if it receives a 159 WILL AUTH_ENCRYPT command and it refuses to send or receive 160 authentication or encryption information. 162 IAC SB AUTH_ENCRYPT SEND authentication-type-pair-list IAC SE 164 The server side of the connection sends this command to request 165 that the client side of the connection send authentication 166 information for one of the authentication types listed in the 167 "authentication-type-pair-list". The "authentication-type-pair- 168 list" is an ordered list of "authentication-type" pairs. 170 IAC SB AUTH_ENCRYPT IS authentication-type-pair authentication-data 171 IAC SE 173 The client side of the connection sends this command to indicate 174 the "authentication-type-pair" that was chosen for the connection 175 from the list provided by the server side and to send the 176 authentication-data necessary for it. 178 IAC SB AUTH_ENCRYPT REPLY authentication-type-pair authentication- 179 data IAC SE 181 The server side of the connection sends this command in response 182 to authentication-data in a previous IS command and to send the 183 authentication-data the client needs. 185 IAC SB AUTH_ENCRYPT NAME remote-user IAC SE 187 The client side of the connection sends this command to indicate 188 the account name (remote-user) on the server that the user wishes 189 to be authorized to use. Note that while authentication may 190 succeed, the authorization to use a particular account may fail. 191 Some authentication types may ignore this command. This command 192 supercedes the value of the USER environment variable if it is 193 passed from the client to the server. 195 IAC SB AUTH_ENCRYPT END_ENCRYPT IAC SE 197 The sender of this command is stating that at this point in the 198 data stream, all following data will no longer be encrypted. This 199 command should only be sent in an encrypted data stream and should 200 be ignored if received in an unencrypted data stream. See the 201 "Implementation Rules" section for more details. 203 IAC SB AUTH_ENCRYPT REQUEST_END_ENCRYPT IAC SE 205 The sender of this command requests that the remote side stop 206 encryption of the telnet data stream. This command is advisory 207 only. This command should only be sent in an encrypted data 208 stream and should be ignored if received in an unencrypted data 209 stream. See the "Implementation Rules" section for more details. 211 The "authentication-type-pair" is two octets: the first is the 212 authentication type and the second is a modifier to the type. There 213 are currently four one bit fields defined in the modifier. Two of 214 these are processed as a pair: the AUTH_WHO_MASK bit and the 215 AUTH_HOW_MASK bit. There are four possible combinations of these two 216 bits: 218 AUTH_CLIENT_TO_SERVER 219 AUTH_HOW_ONE_WAY 221 The client will send authentication information about the local 222 user to the server. If the negotiation is successful, the 223 server will have authenticated the user on the client side of 224 the connection. 226 AUTH_SERVER_TO_CLIENT 227 AUTH_HOW_ONE_WAY 229 The server will authenticate itself to the client. If the 230 negotiation is successful, the client will know that it is 231 connected to the server to which it wants to be connected. 233 AUTH_CLIENT_TO_SERVER 234 AUTH_HOW_MUTUAL 236 The client will send authentication information about the local 237 user to the server and then the server will authenticate itself 238 to the client. If the negotiation is successful, the server 239 will have authenticated the user on the client side of the 240 connection and the client will know that it is connected to the 241 server to which it wants to be connected. 243 AUTH_SERVER_TO_CLIENT 244 AUTH_HOW_MUTUAL 246 The server will authenticate itself to the client and then the 247 client will send authentication information about the local 248 user to the server. If the negotiation is successful, the 249 client will know that it is connected to the server to which it 250 wants to be connected and the server will have authenticated 251 the user on the client side of the connection. 253 The third bit field in the modifier is the ENCRYPT_MASK bit. This 254 bit is either set to ENCRYPT_ON or ENCRYPT_OFF. Setting this bit 255 to ENCRYPT_ON implies that once authentication completes, the data 256 stream is to be encrypted in both directions using the encryption 257 method specified for the authentication type. 259 The fourth bit field in the modifier is the INI_CRED_FWD_MASK bit. 260 This bit is either set to INI_CRED_FWD_ON or INI_CRED_FWD_OFF. 261 Setting this bit to INI_CRED_FWD_ON implies that once 262 authentication completes, the client will immediately forward 263 authentication credentials to the server. This bit is set by the 264 client to advise the server to expect forwarded credentials from 265 the client. 267 The motivation for this advisory bit is that the server may wish 268 to wait until the forwarded credentials have been sent before 269 starting any operating system specific login procedures which may 270 depend on these credentials. Note that credentials forwarding may 271 not be supported by all authentication types. It is a protocol 272 error to set this bit if the underlying authentication type does 273 not support credentials forwarding. 275 The authentication-data may be omitted if there is none to be 276 provided for the type being negotiated. 278 4. Default Specification 280 The default specification for this option is 282 WONT AUTH_ENCRYPT 283 DONT AUTH_ENCRYPT 285 meaning there will not be any exchange of authentication or 286 encryption information. 288 5. Implementation Rules 290 WILL and DO are used only at the beginning of the connection to 291 obtain and grant permission for future negotiations. 293 The authentication is only negotiated in one direction; the server 294 MUST send the "DO" and the client MUST send the "WILL". This 295 restriction is due to the nature of authentication; there are three 296 possible cases; server authenticates client, client authenticates 297 server, and server and client authenticate each other. By only 298 negotiating the option in one direction and determining which of the 299 three cases is being used via the suboption, potential ambiguity is 300 removed. If the server receives a "DO", it MUST respond with a 301 "WONT". If the client receives a "WILL", it MUST respond with a 302 "DONT". 304 Once the two hosts have exchanged a DO and a WILL, the server is free 305 to request authentication information. In the request, a list of 306 supported authentication types is sent. Only the server MAY send 307 requests ("IAC SB AUTH_ENCRYPT SEND authentication-type-pair-list IAC 308 SE"). Only the client MAY transmit authentication information via 309 the "IAC SB AUTH_ENCRYPT IS authentication-type ... IAC SE" command. 310 Only the server MAY send replies ("IAC SB AUTH_ENCRYPT REPLY 311 authentication-type ... IAC SE"). As many IS and REPLY suboptions 312 MAY be exchanged as are needed for the particular authentication type 313 chosen. 315 When determining a match from the authentication-type-pair-list 316 received from the server, the client MAY ignore the AUTH_ENCRYPT_MASK 317 bit. If the AUTH_ENCRYPT_MASK bit was ENCRYPT_OFF, then the client 318 MUST respond with ENCRYPT_OFF. If the AUTH_ENCRYPT_MASK bit was on, 319 then the client MAY respond with either ENCRYPT_ON or ENCRYPT_OFF. 320 In the latter case the client is stating that it will do 321 authentication but it does not want to encrypt the data stream. 323 If the client does not support any of the authentication types listed 324 in the authentication-type-pair-list, it SHOULD indicate this in the 325 IS reply with a type of NULL. Note, if the client turns off the 326 ENCRYPT_ON bit or responds with a type of NULL, the server MAY choose 327 to close the connection. 329 Encryption from the server to the client begins with the first byte 330 immediately following the "IAC SB AUTH_ENCRYPT REPLY ... IAC SE" 331 command that signifies that the server has successfully completed the 332 authentication process. Encryption from the client to the server 333 begins with the first byte immediately following the "IAC SB 334 AUTH_ENCRYPT RESPONSE ... IAC SE" command that signifies that the 335 client has successfully completed the authentication process. Both 336 of these will be specified in the document for the specific 337 authentication and encryption type. All data, including TELNET 338 options, are encrypted. 340 The authentication types MUST be ordered to indicate a preference for 341 different authentication types, the first type being the most 342 preferred and the last type being the least preferred. 344 Special consideration applies to the use of END_ENCRYPT and 345 REQUEST_END_ENCRYPT. A scenario during which one may want to turn 346 off encryption is communication from the server to the client, which 347 has the bulk of the data; leaving the communication from the client 348 to the server encrypted ensures that typed passwords are not readable 349 by eavesdropping. To do this the client SHOULD send a 350 REQUEST_END_ENCRYPT command to the server, who SHOULD then send an 351 END_ENCRYPT command and stop encrypting the output data stream. At 352 this point, an active attacker could insert a REQUEST_END_ENCRYPT 353 command in the data stream from the server to the client to try and 354 get the client to stop encrypting its input stream to the server. 355 So, a REQUEST_END_ENCRYPT command SHOULD always be honored if 356 received within an encrypted data stream but SHOULD be ignored if 357 received over an unencrypted data stream. If it is desirable to 358 disable all encryption, a REQUEST_END_ENCRYPT SHOULD be sent prior to 359 the END_ENCRYPT to get the other side to stop encrypting first. 361 6. User Interface Rules 363 Normally protocol specifications do not address user interface 364 issues. However, due to the fact that the user should be able to 365 indicate the information necessary to achieve a successful 366 authentication and encryption negotiation and the user should know 367 whether the authentication and encryption succeeded, some guidance 368 must be given to implementors to assure a minimum level of user 369 control. 371 The user MUST be able to specify whether or not authentication is to 372 be used and whether or not encryption is to used if the 373 authentication succeeds. There SHOULD be at least four settings: 374 REQUIRE, PROMPT, WARN, and DISABLE. 376 Setting the authentication switch to REQUIRE means that if the 377 authentication fails, then an appropriate error message MUST be 378 displayed and the TELNET connection MUST be terminated. 380 Setting the authentication switch to PROMPT means that if the 381 authentication fails, then an appropriate error message MUST be 382 displayed and the user MUST be prompted for confirmation before 383 continuing the TELNET session. 385 Setting the authentication switch to WARN means that if the 386 authentication fails, then an appropriate error message MUST be 387 displayed before continuing the TELNET session. 389 Setting the authentication switch to DISABLE means that 390 authentication MUST NOT be attempted. 392 The encryption switch SHOULD have an independent set of the same 393 settings as the authentication switch. However, its settings MUST 394 only be used when authentication succeeds. 396 The default setting for both switches SHOULD be WARN. Both of these 397 switchs MAY be implemented as a single switch, though having them 398 separate gives more control to the user. 400 7. Example 402 The following is an example of the use of this option for 403 authentication without encryption for Kerberos Version 4 [3]: 405 Client Server 407 IAC DO AUTH_ENCRYPT 408 IAC WILL AUTH_ENCRYPT 410 [ The server is now free to request authentication information. 411 ] 413 IAC SB AUTH_ENCRYPT SEND 414 KERBEROS_V4 415 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 416 KERBEROS_V4 417 AUTH_CLIENT_TO_SERVER|AUTH_HOW_ONE_WAY 418 IAC SE 420 [ The server has requested mutual Kerberos authentication but is 421 willing to do just one-way Kerberos authentication. The client 422 will now respond with the name of the user that it wants to log 423 in as and the Kerberos ticket. ] 425 IAC SB AUTH_ENCRYPT NAME "joe" 426 IAC SE 427 IAC SB AUTH_ENCRYPT IS 428 KERBEROS_V4 429 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 430 AUTH 4 7 1 67 82 65 89 46 67 7 9 431 77 0 48 24 49 244 109 240 50 208 432 43 35 25 116 104 44 167 21 201 433 224 229 145 20 2 244 213 220 33 434 134 148 4 251 249 233 229 152 77 435 2 109 130 231 33 146 190 248 1 9 436 31 95 94 15 120 224 0 225 76 205 437 70 136 245 190 199 147 155 13 438 IAC SE 440 [ The server responds with an ACCEPT command to state that the 441 authentication was successful. ] 443 IAC SB AUTH_ENCRYPT REPLY 444 KERBEROS_V4 445 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 446 ACCEPT IAC SE 448 [ Next, the client sends across a CHALLENGE to verify that it is 449 really talking to the right server. ] 451 IAC SB AUTH_ENCRYPT IS 452 KERBEROS_V4 453 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 454 CHALLENGE xx xx xx xx xx xx xx 455 xx IAC SE 457 [ Lastly, the server sends across a RESPONSE to prove that it 458 really is the right server. ] 460 IAC SB AUTH_ENCRYPT REPLY 461 KERBEROS_V4 462 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 463 RESPONSE yy yy yy yy yy yy yy yy 464 IAC SE 466 The following is an example of the use of this option for authentica- 467 tion with encryption for Kerberos Version 4 [3]: 469 Client Server 471 IAC DO AUTH_ENCRYPT 472 IAC WILL AUTH_ENCRYPT 474 [ The server is now free to request authentication information. 475 ] 477 IAC SB AUTH_ENCRYPT SEND 478 KERBEROS_V4 479 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 480 |ENCRYPT_ON KERBEROS_V4 481 AUTH_CLIENT_TO_SERVER|AUTH_HOW_ONE_WAY 482 |ENCRYPT_ON IAC SE 484 [ The server has requested mutual Kerberos authentication but is 485 willing to do just one-way Kerberos authentication. In both 486 cases it is willing to encrypt the data stream. The client 487 will now respond with the name of the user that it wants to log 488 in as and the Kerberos ticket. ] 490 IAC SB AUTH_ENCRYPT NAME "joe" 491 IAC SE 492 IAC SB AUTH_ENCRYPT IS 493 KERBEROS_V4 494 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL|ENCRYPT_ON 495 AUTH 4 7 1 67 82 65 89 46 67 7 9 496 77 0 48 24 49 244 109 240 50 208 497 43 35 25 116 104 44 167 21 201 498 224 229 145 20 2 244 213 220 33 499 134 148 4 251 249 233 229 152 77 500 2 109 130 231 33 146 190 248 1 9 501 31 95 94 15 120 224 0 225 76 205 502 70 136 245 190 199 147 155 13 503 IAC SE 505 [ The server responds with an ACCEPT command to state that the 506 authentication was successful. ] 508 IAC SB AUTH_ENCRYPT REPLY 509 KERBEROS_V4 510 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 511 |ENCRYPT_ON ACCEPT IAC SE 513 [ Next, the client sends across a CHALLENGE to verify that it is 514 really talking to the right server. ] 516 IAC SB AUTH_ENCRYPT IS 517 KERBEROS_V4 518 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL|ENCRYPT_ON 519 CHALLENGE xx xx xx xx xx xx xx 520 xx IAC SE 522 [ At this point, the client begins to encrypt the outgoing data 523 stream, and the server, after receiving this command, begins to 524 decrypt the incoming data stream. Lastly, the server sends 525 across a RESPONSE to prove that it really is the right server. 526 ] 528 IAC SB AUTH_ENCRYPT REPLY 529 KERBEROS_V4 530 AUTH_CLIENT_TO_SERVER|AUTH_HOW_MUTUAL 531 |ENCRYPT_ON RESPONSE yy yy yy yy 532 yy yy yy yy IAC SE 534 [ At this point, the server begins to encrypt its outgoing data 535 stream, and the client, after receiving this command, begins to 536 decrypt its incoming data stream. ] 538 8. Security Considerations 540 The ability to negotiate a common authentication type between a 541 client and a server system is a feature of the authentication option 542 that should be used with caution. When the negotiation is performed 543 no authentication has yet occurred. Therefore, neither system knows 544 whether it is communicating with the intended system. An active at- 545 tacker could attempt to negotiate the use of an authentication system 546 which is either weak or already compromised by the intruder. 548 By linking the enabling of encryption as a side effect of successful 549 authentication, protection is provided against an active attacker. 550 An active attack is one where the underlying TCP stream can be modi- 551 fied or taken over by an active attacker. If encryption were enabled 552 as a separate negotiation, it would provide a window of vulnerability 553 from when the authentication completes up to and including the nego- 554 tiation to turn on encryption. It is because of this there is no 555 command to restart encryption. The only safe way to restart encryp- 556 tion once it has been turned off is to repeat the entire authentica- 557 tion process. 559 9. References 561 [1] D. Borman, Editor. Telnet Authentication Option. RFC1416, Cray 562 Research, Inc., February 1993. 564 [2] J. Reynolds, J. Postel. Assigned Numbers. RFC1700, ISI, October 565 1994. 567 [3] D. Borman, Editor. Telnet Authentication: Kerberos Version 4. 568 RFC1411, Cray Research, Inc., January 1993. 570 10. Authors' Address 572 Jim Galvin 573 Sandy Murphy 574 Dave Balenson 576 Trusted Information Systems 577 3060 Washington Road 578 Glenwood, MD 21738 580 Phone: 301.854.6889