idnits 2.17.00 (12 Aug 2021) /tmp/idnits30614/draft-housley-telnet-auth-dsa-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 2) being 60 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC1416], [FIPS186]), 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 8064 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? 'FIPS186' on line 122 looks like a reference -- Missing reference section? 'RFC1416' on line 38 looks like a reference -- Missing reference section? 'FIPS180-1' on line 122 looks like a reference -- Missing reference section? 'FIPS196' on line 129 looks like a reference -- Missing reference section? 'RFC2459' on line 178 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 DSA 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 telnet authentication mechanism using the 37 Digital Signature Algorithm (DSA) [FIPS186]. It relies on the TELNET 38 Authentication Option [RFC1416]. 40 1. Command Names and Codes 42 AUTHENTICATION 37 44 Authentication Commands: 46 IS 0 47 SEND 1 48 REPLY 2 49 NAME 3 51 Authentication Types: 53 DSS 14 55 Modifiers: 57 AUTH_WHO_MASK 1 58 AUTH_CLIENT_TO_SERVER 0 59 AUTH_SERVER_TO CLIENT 1 61 AUTH_HOW_MASK 2 62 AUTH_HOW_ONE_WAY 0 63 AUTH_HOW_MUTUAL 2 65 ENCRYPT_MASK 20 66 ENCRYPT_OFF 0 67 ENCRYPT_USING_TELOPT 4 68 ENCRYPT_AFTER_EXCHANGE 16 69 ENCRYPT_RESERVED 20 71 INI_CRED_FWD_MASK 8 72 INI_CRED_FWD_OFF 0 73 INI_CRED_FWD_ON 8 75 Sub-option Commands: 77 DSS_INITIALIZE 1 78 DSS_TOKENBA 2 79 DSS_CERTA_TOKENAB 3 80 DSS_CERTB_TOKENBA2 4 82 2. TELNET Security Extensions 84 TELNET, as a protocol, has no concept of security. Without 85 negotiated options, it merely passes characters back and forth 86 between the NVTs represented by the two TELNET processes. In its 87 most common usage as a protocol for remote terminal access (TCP port 88 23), TELNET connects to a server that requires user-level 89 authentication through a user name and password in the clear; the 90 server does not authenticate itself to the user. 92 The TELNET Authentication Option provides for user authentication and 93 server authentication. User authentication replaces or augments the 94 normal host password mechanism. Server authentication is normally 95 done in conjunction with user authentication. 97 In order to support these security services, the two TELNET entities 98 must first negotiate their willingness to support the TELNET 99 Authentication Option. Upon agreeing to support this option, the 100 parties are then able to perform sub-options determine the 101 authentication protocol to be used, and possibly the remote user name 102 to be used for authorization checking. 104 Authentication and parameter negotiation occur within an unbounded 105 series of exchanges. The server proposes a preference-ordered list 106 of authentication types (mechanisms) which it supports. In addition 107 to listing the mechanisms it supports, the server qualifies each 108 mechanism with a modifier that specifies whether the authentication 109 is to be one-way or mutual, and in which direction the authentication 110 is to be performed. The client selects one mechanism from the list 111 and responds to the server indicating its choice and the first set of 112 authentication data needed for the selected authentication type. The 113 server and the client then proceed through whatever number of 114 iterations are required to arrive at the requested authentication. 116 3. Use of Digital Signature Algorithm (DSA) 118 DSA is also known as the Digital Signature Standard (DSS), and the 119 names are used interchangeably. This paper specifies a method in 120 which DSA may be used to achieve certain security services when used 121 in conjunction with the TELNET Authentication Option. SHA-1 122 [FIPS180-1] is used with DSA [FIPS186]. 124 DSA may provide either unilateral or mutual authentication. Due to 125 TELNET's character-by-character nature, it is not well-suited to the 126 application of integrity-only services, therefore use of the DSA 127 profile provides authentication but it does not provide session 128 integrity. This specification follows the token and exchanges 129 defined in NIST FIPS PUB 196 [FIPS196], Standard for Public Key 130 Cryptographic Entity Authentication Mechanisms including Appendix A 131 on ASN.1 encoding of messages and tokens. All data that is covered 132 by a digital signature must be encoded using the Distinguished 133 Encoding Rules (DER). However, other data may use either the Basic 134 Encoding Rules (BER) or DER [X.208]. 136 3.1. Unilateral Authentication with DSA 138 Unilateral authentication must be done client-to-server. What 139 follows are the protocol steps necessary to perform DSA 140 authentication as specified in FIPS PUB 196 under the TELNET 141 Authentication Option framework. Where failure modes are 142 encountered, the return codes follow those specified in the TELNET 143 Authentication Option. They are not enumerated here, as they are 144 invariant among the mechanisms used. FIPS PUB 196 employs a set of 145 exchanges that are transferred to provide authentication. Each 146 exchange employs various fields and tokens, some of which are 147 optional. In addition, each token has several subfields that are 148 optional. A conformant subset of the fields and subfields have been 149 selected. Therefore, the exchanges below do not use the FIPS PUB 196 150 notation indicating optional fields, as all subfields used are 151 mandatory. The tokens are ASN.1 encoded as defined in Appendix A of 152 FIPS PUB 196, and each token is named to indicate the direction in 153 which it flows (e.g., TokenBA flows from Party B to Party A). All 154 data that is covered by a digital signature must be encoded using the 155 Distinguished Encoding Rules (DER). Data that is not covered by a 156 digital signature may use either the Basic Encoding Rules (BER) or 157 DER [X.208]. Figure 1 illustrates the exchanges for unilateral 158 authentication. 160 During authentication, the client may provide the user name to the 161 server by using the authentication name sub-option. If the name sub- 162 option is not used, the server will generally prompt for a name and 163 password in the clear. The name sub-option must be sent after the 164 server sends the list of authentication types supported and before 165 the client finishes the authentication exchange, this ensures that 166 the server will not prompt for a user name and password. In figure 167 1, the name sub-option is sent immediately after the server presents 168 the list of authentication types supported. 170 For one-way DSS authentication, the two-octet authentication type 171 pair is DSS CLIENT_TO_SERVER | ONE_WAY ENCRYPT_OFF | 172 INI_CRED_FWD_OFF. This indicates that the DSS authentication 173 mechanism will be used to authenticate the client to the server and 174 that no encryption will be performed. 176 CertA is the clients certificate. CertB is the server's certificate. 177 Both certificates are X.509 certificates that contain DSS public 178 keys[RFC2459]. The client must validate the server's certificate 179 before using the KEA public key it contains. 181 Within the unbounded authentication exchange, implementation is 182 greatly simplified if each portion of the exchange carries a unique 183 identifier. For this reason, a single octet sub-option identifier is 184 carried immediately after the two-octet authentication type pair. 186 The exchanges detailed in Figure 1 below presume knowledge of FIPS 187 PUB 196 and the TELNET Authentication Option. The client is Party A, 188 while the server is Party B. At the end of the exchanges, the client 189 is authenticated to the server. 191 --------------------------------------------------------------------- 192 Client (Party A) Server (Party B) 194 <-- IAC DO AUTHENTICATION 196 IAC WILL AUTHENTICATION --> 198 <-- IAC SB AUTHENTICATION SEND 199 200 IAC SE 202 IAC SB AUTHENTICATION 203 NAME --> 205 IAC SB AUTHENTICATION IS 206 DSS 207 CLIENT_TO_SERVER| 208 ONE_WAY | 209 ENCRYPT_OFF | 210 INI_CRED_FWD_OFF 211 DSS_INITIALIZE 212 IAC SE --> 214 <-- IAC SB AUTHENTICATION REPLY 215 DSS 216 CLIENT_TO_SERVER| 217 ONE_WAY | 218 ENCRYPT_OFF | 219 INI_CRED_FWD_OFF 220 DSS_TOKENBA 221 Sequence( TokenID, TokenBA ) 222 IAC SE 223 --------------------------------------------------------------------- 224 Figure 1 (continued) 225 Figure 1 (continued) 226 --------------------------------------------------------------------- 227 Client (Party A) Server (Party B) 229 IAC SB AUTHENTICATION IS 230 DSS 231 CLIENT_TO_SERVER| 232 ONE_WAY | 233 ENCRYPT_OFF | 234 INI_CRED_FWD_OFF 235 DSS_CERTA_TOKENAB 236 Sequence( TokenID, CertA, TokenAB ) 237 IAC SE --> 238 --------------------------------------------------------------------- 239 Figure 1 241 3.2. Mutual Authentication with DSA 243 Mutual authentication is slightly more complex. Figure 2 illustrates 244 the exchanges. 246 For mutual DSS authentication, the two-octet authentication type pair 247 is DSS CLIENT_TO_SERVER | MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF. 248 This indicates that the DSS authentication mechanism will be used to 249 mutually authenticate the client and the server and that no 250 encryption will be performed. 252 --------------------------------------------------------------------- 253 Client (Party A) Server (Party B) 255 IAC WILL AUTHENTICATION --> 257 <-- IAC DO AUTHENTICATION 259 <-- IAC SB AUTHENTICATION SEND 260 261 IAC SE 263 IAC SB AUTHENTICATION 264 NAME --> 265 --------------------------------------------------------------------- 266 Figure 2 (continued) 267 Figure 2 (continued) 268 --------------------------------------------------------------------- 269 Client (Party A) Server (Party B) 271 IAC SB AUTHENTICATION IS 272 DSS 273 CLIENT_TO_SERVER | 274 MUTUAL | 275 ENCRYPT_OFF | 276 INI_CRED_FWD_OFF 277 DSS_INITIALIZE 278 IAC SE --> 280 <-- IAC SB AUTHENTICATION REPLY 281 DSS 282 CLIENT_TO_SERVER | 283 MUTUAL | 284 ENCRYPT_OFF | 285 INI_CRED_FWD_OFF 286 DSS_TOKENBA 287 Sequence( TokenID, TokenBA ) 288 IAC SE 290 IAC SB AUTHENTICATION IS 291 DSS 292 CLIENT_TO_SERVER | 293 MUTUAL | 294 ENCRYPT_OFF | 295 INI_CRED_FWD_OFF 296 DSS_CERTA_TOKENAB 297 Sequence( TokenID, CertA, TokenAB ) 298 IAC SE --> 300 <-- IAC SB AUTHENTICATION REPLY 301 DSS 302 CLIENT_TO_SERVER | 303 MUTUAL | 304 ENCRYPT_OFF | 305 INI_CRED_FWD_OFF 306 DSS_CERTB_TOKENBA2 307 Sequence( TokenID, CertB, TokenBA2 ) 308 IAC SE 309 --------------------------------------------------------------------- 310 Figure 2 312 4. Security Considerations 314 This entire memo is about security mechanisms. For DSA to provide 315 the authentication discussed, the implementation must protect the 316 private key from disclosure. 318 5. Acknowledgements 320 We would like to thank William Nace for support during implementation 321 of this specification. 323 6. IANA Considerations 325 The authentication type DSS and its associated suboption values 326 are registered with IANA. Any suboption values used to extend 327 the protocol as described in this document must be registered 328 with IANA before use. IANA is instructed not to issue new suboption 329 values without submission of documentation of their use. 331 7. References 333 FIPS186 Digital Signature Standard (DSS). FIPS Pub 186. 334 May 19, 1994. 335 337 FIPS180-1 Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 338 340 FIPS196 Standard for Entity Authentication Using Public Key 341 Cryptography. FIPS Pub 196. February 18, 1997. 342 344 RFC1416 Borman, David A. "TELNET Authentication Option". 345 RFC 1416. February 1993. 347 RFC2459 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 348 X.509 Public Key Infrastructure: X.509 Certificate and 349 CRL Profile", RFC 2459, January 1999. 351 X.208 CCITT. Recommendation X.208: Specification of Abstract 352 Syntax Notation One (ASN.1). 1988. 354 8. Author's Address 356 Russell Housley 357 SPYRUS 358 381 Elden Street, Suite 1120 359 Herndon, VA 20172 360 USA 361 Email: housley@spyrus.com 363 Todd Horting 364 SPYRUS 365 381 Elden Street, Suite 1120 366 Herndon, VA 20172 367 USA 368 Email: thorthing@spyrus.com 370 Peter Yee 371 SPYRUS 372 5303 Betsy Ross Drive 373 Santa Clara, CA 95054 374 USA 375 Email: yee@spyrus.com 376 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 377 The Kermit Project * Columbia University 378 612 West 115th St #716 * New York, NY * 10025 379 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org