idnits 2.17.1 draft-housley-telnet-auth-keasj-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 9) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [4], [1,5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (April 2000) is 8771 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 404 looks like a reference -- Missing reference section? '5' on line 416 looks like a reference -- Missing reference section? '4' on line 412 looks like a reference -- Missing reference section? '2' on line 407 looks like a reference -- Missing reference section? '6' on line 419 looks like a reference -- Missing reference section? '7' on line 423 looks like a reference -- Missing reference section? '3' on line 410 looks like a reference -- Missing reference section? '8' on line 428 looks like a reference -- Missing reference section? '9' on line 378 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure TELNET Working Group Russell Housley (SPYRUS) 2 Todd Horting (SPYRUS) 3 Internet-Draft Peter Yee (SPYRUS) 4 April 2000 6 TELNET Authentication Using KEA and SKIPJACK 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. Please send comments to the 32 mailing list. 34 Abstract 36 This document defines a method to authenticate TELNET [1,5] using the 37 Key Exchange Algorithm (KEA)[4], and encryption of the TELNET stream 38 using SKIPJACK[4]. Two encryption modes are specified; one provides 39 data integrity and the other does not. It relies on the TELNET 40 Authentication Option [2]. 42 1. Command Names and Codes 44 AUTHENTICATION 37 46 Authentication Commands: 48 IS 0 49 SEND 1 50 REPLY 2 51 NAME 3 53 Authentication Types: 55 KEA_SJ 12 56 KEA_SJ_INTEG 13 58 Modifiers: 60 AUTH_WHO_MASK 1 61 AUTH_CLIENT_TO_SERVER 0 62 AUTH_SERVER_TO CLIENT 1 64 AUTH_HOW_MASK 2 65 AUTH_HOW_ONE_WAY 0 66 AUTH_HOW_MUTUAL 2 68 ENCRYPT_MASK 20 69 ENCRYPT_OFF 0 70 ENCRYPT_USING_TELOPT 4 71 ENCRYPT_AFTER_EXCHANGE 16 72 ENCRYPT_RESERVED 20 74 INI_CRED_FWD_MASK 8 75 INI_CRED_FWD_OFF 0 76 INI_CRED_FWD_ON 8 78 Sub-option Commands: 80 KEA_CERTA_RA 1 81 KEA_CERTB_RB_IVB_NONCEB 2 82 KEA_IVA_RESPONSEB_NONCEA 3 83 KEA_RESPONSEA 4 85 2. TELNET Security Extensions 87 TELNET, as a protocol, has no concept of security. Without 88 negotiated options, it merely passes characters back and forth 89 between the NVTs represented by the two TELNET processes. In its 90 most common usage as a protocol for remote terminal access (TCP port 91 23), TELNET normally connects to a server that requires user-level 92 authentication through a user name and password in the clear. The 93 server does not authenticate itself to the user. 95 The TELNET Authentication Option provides for: 97 * User authentication -- replacing or augmenting the normal host 98 password mechanism; 99 * Server authentication -- normally done in conjunction with user 100 authentication; 101 * Session parameter negotiation -- in particular, encryption key 102 and attributes; 103 * Session protection -- primarily encryption of the data and 104 embedded command stream, but the encryption algorithm may also 105 provide data integrity. 107 In order to support these security services, the two TELNET entities 108 must first negotiate their willingness to support the TELNET 109 Authentication Option. Upon agreeing to support this option, sub- 110 options determine the authentication protocol to be used, and 111 possibly the remote user name to be used for authorization checking. 112 Encryption is negotiated along with the type of the authentication. 114 Authentication and parameter negotiation occur within an unbounded 115 series of exchanges. The server proposes a preference-ordered list 116 of authentication types (mechanisms) that it supports. In addition 117 to listing the mechanisms it supports, the server qualifies each 118 mechanism with a modifier that specifies whether the authentication 119 is to be unilateral or mutual, and in which direction the 120 authentication is to be performed, and if encryption of data is 121 desired. The client selects one mechanism from the list and responds 122 to the server indicating its choice and the first set of 123 authentication data needed for the selected authentication type. The 124 client may ignore a request to encrypt data and so indicate, but the 125 server may also terminate the connection if the client refuses 126 encryption. The server and the client then proceed through whatever 127 number of iterations is required to arrive at the requested 128 authentication. 130 Encryption is started immediately after the Authentication options 131 are completed. 133 3. Use of Key Exchange Algorithm (KEA) 135 This paper specifies the method in which KEA is used to achieve 136 TELNET Authentication. KEA (in conjunction with SKIPJACK) [4] 137 provides authentication and confidentiality. Integrity may also be 138 provided. 140 TELNET entities may use KEA to provide mutual authentication and 141 support for the setup of data encryption keys. A simple token format 142 and set of exchanges delivers these services. 144 NonceA and NonceB used in this exchange are 64-bit bit strings. The 145 client generates NonceA, and the server generates NonceB. The nonce 146 value is selected randomly. The nonce is sent in a big endian form. 147 The encryption of the nonce will be done with the same mechanism that 148 the session will use, detailed in the next section. 150 Ra and Rb used in this exchange are 1024 bit strings and are defined 151 by the KEA Algorithm[4]. 153 The IVa and IVb are 24 byte Initialization Vectors. They are 154 composed of "THIS IS NOT LEAF" followed by 8 random bytes. 156 CertA is the clients certificate. CertB is the server's certificate. 157 Both certificates are X.509 certificates [6] that contain KEA public 158 keys [7]. The client must validate the server's certificate before 159 using the KEA public key it contains. Likewise, the server must 160 validate the client's certificate before using the KEA public key it 161 contains. 163 On completing these exchanges, the parties have a common SKIPJACK 164 key. Mutual authentication is provided by verification of the 165 certificates used to establish the SKIPJACK encryption key and 166 successful use of the derived SKIPJACK session key. To protect 167 against active attacks, encryption will take place after successful 168 authentication. There will be no way to turn off encryption and 169 safely turn it back on; repeating the entire authentication is the 170 only safe way to restart it. If the user does not want to use 171 encryption, he may disable encryption after the session is 172 established. 174 3.1. SKIPJACK Modes 176 There are two distinct modes for encrypting TELNET streams; one 177 provides integrity and the other does not. Because TELNET is 178 normally operated in a character-by-character mode, the SKIPJACK with 179 stream integrity mechanism requires the transmission of 4 bytes for 180 every TELNET data byte. However, a simplified mode SKIPJACK without 181 integrity mechanism will only require the transmission of one byte 182 for every TELNET data byte. 184 The cryptographic mode for SKIPJACK with stream integrity is Cipher 185 Feedback on 32 bits of data (CFB-32) and the mode of SKIPJACK is 186 Cipher Feedback on 8 bits of data (CFB-8). 188 3.1.1. SKIPJACK without stream integrity 190 The first and least complicated mode uses SKIPJACK CFB-8. This mode 191 provides no stream integrity. 193 For SKIPJACK without stream integrity, the two-octet authentication 194 type pair is KEA_SJ CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | 195 ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF. This indicates that the 196 SKIPJACK without integrity mechanism will be used for mutual 197 authentication and TELNET stream encryption. Figure 1 illustrates 198 the authentication mechanism of KEA followed by SKIPJACK without 199 stream integrity. 201 --------------------------------------------------------------------- 202 Client (Party A) Server (Party B) 204 <-- IAC DO AUTHENTICATION 206 IAC WILL AUTHENTICATION --> 208 <-- IAC SB AUTHENTICATION SEND 209 210 IAC SE 212 IAC SB AUTHENTICATION 213 NAME --> 215 IAC SB AUTHENTICATION IS 216 KEA_SJ 217 CLIENT_TO_SERVER | 218 AUTH_HOW_MUTUAL | 219 ENCRYPT_AFTER_EXCHANGE | 220 INI_CRED_FWD_OFF 221 KEA_CERTA_RA 222 CertA||Ra IAC SE --> 223 --------------------------------------------------------------------- 224 Figure 1 (continued) 225 Figure 1 (continued) 226 --------------------------------------------------------------------- 227 Client (Party A) Server (Party B) 229 <-- IAC SB AUTHENTICATION REPLY 230 KEA_SJ 231 CLIENT_TO_SERVER | 232 AUTH_HOW_MUTUAL | 233 ENCRYPT_AFTER_EXCHANGE | 234 INI_CRED_FWD_OFF 235 IVA_RESPONSEB_NONCEA 236 KEA_CERTB_RB_IVB_NONCEB 237 CertB||Rb||IVb|| 238 Encrypt( NonceB ) 239 IAC SE 241 IAC SB AUTHENTICATION IS 242 KEA_SJ 243 CLIENT_TO_SERVER | 244 AUTH_HOW_MUTUAL | 245 ENCRYPT_AFTER_EXCHANGE | 246 INI_CRED_FWD_OFF 247 KEA_IVA_RESPONSEB_NONCEA 248 IVa||Encrypt( (NonceB XOR 0x0C12)||NonceA ) 249 IAC SE --> 251 252 <-- IAC SB AUTHENTICATION REPLY 253 KEA_SJ 254 CLIENT_TO_SERVER | 255 AUTH_HOW_MUTUAL | 256 ENCRYPT_AFTER_EXCHANGE | 257 INI_CRED_FWD_OFF 258 KEA_RESPONSEA 259 Encrypt( NonceA XOR 0x0C12 ) 260 IAC SE 262 263 --------------------------------------------------------------------- 264 Figure 1. 266 3.1.2. SKIPJACK with stream integrity 268 SKIPJACK with stream integrity is more complicated. It uses the 269 SHA-1 [3] one-way hash function to provide integrity of the 270 encryption stream as follows: 272 Set H0 to be the SHA-1 hash of a zero-length string. 274 Cn is the nth character in the TELNET stream. 275 Hn = SHA-1( Hn-1||Cn ), where Hn is the hash value 276 associated with the nth character in the stream. 277 ICVn is set to the three most significant bytes of Hn. 278 Transmit Encrypt( Cn||ICVn ). 280 The ciphertext that is transmitted is the SKIPJACK CFB-32 encryption 281 of ( Cn||ICVn ). The receiving end of the TELNET link reverses the 282 process, first decrypting the ciphertext, separating Cn and ICVn, 283 recalculating Hn, recalculating ICVn, and then comparing the received 284 ICVn with the recalculated ICVn. Integrity is indicated if the 285 comparison succeeds, and Cn can then be processed normally as part of 286 the TELNET stream. Failure of the comparison indicates some loss of 287 integrity, whether due to active manipulation or loss of 288 cryptographic synchronization. In either case, the only recourse is 289 to drop the TELNET connection and start over. 291 For SKIPJACK with stream integrity, the two-octet authentication type 292 pair is KEA_SJ_INTEG CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | 293 ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF. This indicates that the 294 KEA SKIPJACK with integrity mechanism will be used for mutual 295 authentication and TELNET stream encryption. Figure 2 illustrates 296 the authentication mechanism of KEA SKIPJACK with stream integrity. 298 --------------------------------------------------------------------- 299 Client (Party A) Server (Party B) 301 <-- IAC DO AUTHENTICATION 303 IAC WILL AUTHENTICATION --> 305 <-- IAC SB AUTHENTICATION SEND 306 307 IAC SE 309 IAC SB AUTHENTICATION 310 NAME --> 312 IAC SB AUTHENTICATION IS 313 KEA_SJ_INTEG 314 CLIENT_TO_SERVER | 315 AUTH_HOW_MUTUAL | 316 ENCRYPT_AFTER_EXCHANGE | 317 INI_CRED_FWD_OFF 318 KEA_CERTA_RA 319 CertA||Ra IAC SE --> 320 --------------------------------------------------------------------- 321 Figure 2 (continued) 322 Figure 2 (continued) 323 --------------------------------------------------------------------- 324 Client (Party A) Server (Party B) 326 <-- IAC SB AUTHENTICATION REPLY 327 KEA_SJ_INTEG 328 CLIENT_TO_SERVER | 329 AUTH_HOW_MUTUAL | 330 ENCRYPT_AFTER_EXCHANGE | 331 INI_CRED_FWD_OFF 332 IVA_RESPONSEB_NONCEA 333 KEA_CERTB_RB_IVB_NONCEB 334 CertB||Rb||IVb|| 335 Encrypt( NonceB ) 336 IAC SE 338 IAC SB AUTHENTICATION IS 339 KEA_SJ_INTEG 340 CLIENT_TO_SERVER | 341 AUTH_HOW_MUTUAL | 342 ENCRYPT_AFTER_EXCHANGE | 343 INI_CRED_FWD_OFF 344 KEA_IVA_RESPONSEB_NONCEA 345 IVa||Encrypt( (NonceB XOR 0x0D12)||NonceA ) 346 IAC SE --> 348 349 <-- IAC SB AUTHENTICATION REPLY 350 KEA_SJ_INTEG 351 CLIENT_TO_SERVER | 352 AUTH_HOW_MUTUAL | 353 ENCRYPT_AFTER_EXCHANGE | 354 INI_CRED_FWD_OFF 355 KEA_RESPONSEA 356 Encrypt( NonceA XOR 0x0D12 ) 357 IAC SE 359 360 --------------------------------------------------------------------- 361 Figure 2 363 4.0. Security Considerations 365 This entire memo is about security mechanisms. For KEA to provide 366 the authentication discussed, the implementation must protect the 367 private key from disclosure. Likewise, the SKIPJACK keys must be 368 protected from disclosure. 370 Implementations must randomly generate KEA private keys, 371 initialization vectors (IVs), and nonces. The use of inadequate 372 pseudo-random number generators (PRNGs) to generate cryptographic 373 keys can result in little or no security. An attacker may find it 374 much easier to reproduce the PRNG environment that produced the keys, 375 searching the resulting small set of possibilities, rather than brute 376 force searching the whole key space. The generation of quality 377 random numbers is difficult. RFC 1750 [8] offers important guidance 378 in this area, and Appendix 3 of FIPS Pub 186 [9] provides one quality 379 PRNG technique. 381 By linking the enabling of encryption as a side effect of successful 382 authentication, protection is provided against an active attacker. 383 If encryption were enabled as a separate negotiation, it would 384 provide a window of vulnerability from when the authentication 385 completes, up to and including the negotiation to turn on encryption. 386 The only safe way to restart encryption, if it is turned off, is to 387 repeat the entire authentication process. 389 5. IANA Considerations 391 The authentication types KEA_SJ and KEA_SJ_INTEG and their associated 392 suboption valuesare registered with IANA. Any suboption values used 393 to extend the protocol as described in this document must be registered 394 with IANA before use. IANA is instructed not to issue new suboption 395 values without submission of documentation of their use. 397 6.0. Acknowledgements 399 We would like to thank William Nace for support during implementation 400 of this specification. 402 7.0. References 404 [1] - Postel, J., Reynolds, J., "TELNET Protocol Specification". 405 RFC 854. May 1983. 407 [2] - T. Ts'o, "TELNET Authentication Option". 408 , July 1999. 410 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 412 [4] - "SKIPJACK and KEA Algorithm Specification", Version 2.0, 413 May 29, 1998. Available from 414 http://csrc.nist.gov/encryption/skipjack-kea.htm 416 [5] - Postel, J., Reynolds, J., "TELNET Option Specifications". 417 RFC 855. May 1983. 419 [6] - Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 420 X.509 Public Key Infrastructure: X.509 Certificate and CRL 421 Profile", RFC 2459, January 1999. 423 [7] - Housley, R., Polk, W., "Internet X.509 Public Key 424 Infrastructure - Representation of Key Exchange Algorithm (KEA) 425 Keys in Internet X.509 Public Key Infrastructure Cerificates", 426 RFC 2528, March 1999. 428 [8] - Eastlake, D., Crocker, S. and J. Schiller, "Randomness 429 Recommendations for Security", RFC 1750, December 1994. 431 [9) - National Institute of Standards and Technology. 432 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 434 8.0. Authors' Addresses 436 Russell Housley 437 SPYRUS 438 381 Elden Street, Suite 1120 439 Herndon, VA 20170 440 USA 441 Email: housley@spyrus.com 443 Todd Horting 444 SPYRUS 445 381 Elden Street, Suite 1120 446 Herndon, VA 20170 447 USA 448 Email: thorting@spyrus.com 450 Peter Yee 451 SPYRUS 452 5303 Betsy Ross Drive 453 Santa Clara, CA 95054 454 USA 455 Email: yee@spyrus.com 457 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 458 The Kermit Project * Columbia University 459 612 West 115th St #716 * New York, NY * 10025 460 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org