idnits 2.17.1 draft-housley-telnet-auth-dsa-03.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 7 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 8 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 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 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), 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 (August 1999) is 8993 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2459 (ref. '5') (Obsoleted by RFC 3280) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 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 August 1999 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) [2]. It relies on the TELNET 38 Authentication Option [1]. 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 [3] is 122 used with DSA [2]. 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 [4], Standard for Public Key 130 Cryptographic Entity Authentication Mechanisms including Appendix A 131 on ASN.1 encoding of messages and tokens. 133 3.1. Unilateral Authentication with DSA 135 Unilateral authentication must be done client-to-server. What 136 follows are the protocol steps necessary to perform DSA 137 authentication as specified in FIPS PUB 196 under the TELNET 138 Authentication Option framework. Where failure modes are 139 encountered, the return codes follow those specified in the TELNET 140 Authentication Option. They are not enumerated here, as they are 141 invariant among the mechanisms used. FIPS PUB 196 employs a set of 142 exchanges that are transferred to provide authentication. Each 143 exchange employs various fields and tokens, some of which are 144 optional. In addition, each token has several subfields that are 145 optional. A conformant subset of the fields and subfields have been 146 selected. Therefore, the exchanges below do not use the FIPS PUB 196 147 notation indicating optional fields, as all subfields used are 148 mandatory. The tokens are ASN.1 encoded as defined in Appendix A of 149 FIPS PUB 196, and each token is named to indicate the direction in 150 which it flows (e.g., TokenBA flows from Party B to Party A). Figure 151 1 illustrates the exchanges for unilateral authentication. 153 During authentication, the client may provide the user name to the 154 server by using the authentication name sub-option. If the name sub- 155 option is not used, the server will generally prompt for a name and 156 password in the clear. The name sub-option must be sent after the 157 server sends the list of authentication types supported and before 158 the client finishes the authentication exchange, this ensures that 159 the server will not prompt for a user name and password. In figure 160 1, the name sub-option is sent immediately after the server presents 161 the list of authentication types supported. 163 For one-way DSS authentication, the two-octet authentication type 164 pair is DSS CLIENT_TO_SERVER | ONE_WAY ENCRYPT_OFF | 165 INI_CRED_FWD_OFF. This indicates that the DSS authentication 166 mechanism will be used to authenticate the client to the server and 167 that no encryption will be performed. 169 CertA is the clients certificate. CertB is the server's certificate. 170 Both certificates are X.509 certificates that contain DSS public 171 keys[5]. The client must validate the server's certificate before 172 using the KEA public key it contains. 174 Within the unbounded authentication exchange, implementation is 175 greatly simplified if each portion of the exchange carries a unique 176 identifier. For this reason, a single octet sub-option identifier is 177 carried immediately after the two-octet authentication type pair. 179 The exchanges detailed in Figure 1 below presume knowledge of FIPS 180 PUB 196 and the TELNET Authentication Option. The client is Party A, 181 while the server is Party B. At the end of the exchanges, the client 182 is authenticated to the server. 184 --------------------------------------------------------------------- 185 Client (Party A) Server (Party B) 187 <-- IAC DO AUTHENTICATION 189 IAC WILL AUTHENTICATION --> 191 <-- IAC SB AUTHENTICATION SEND 192 193 IAC SE 195 IAC SB AUTHENTICATION 196 NAME --> 198 IAC SB AUTHENTICATION IS 199 DSS 200 CLIENT_TO_SERVER| 201 ONE_WAY | 202 ENCRYPT_OFF | 203 INI_CRED_FWD_OFF 204 DSS_INITIALIZE 205 IAC SE --> 207 <-- IAC SB AUTHENTICATION REPLY 208 DSS 209 CLIENT_TO_SERVER| 210 ONE_WAY | 211 ENCRYPT_OFF | 212 INI_CRED_FWD_OFF 213 DSS_TOKENBA 214 Sequence( TokenID, TokenBA ) 215 IAC SE 217 IAC SB AUTHENTICATION IS 218 DSS 219 CLIENT_TO_SERVER| 220 ONE_WAY | 221 ENCRYPT_OFF | 222 INI_CRED_FWD_OFF 223 DSS_CERTA_TOKENAB 224 Sequence( TokenID, CertA, TokenAB ) 225 IAC SE --> 226 --------------------------------------------------------------------- 227 Figure 1 229 3.2. Mutual Authentication with DSA 231 Mutual authentication is slightly more complex. Figure 2 illustrates 232 the exchanges. 234 For mutual DSS authentication, the two-octet authentication type pair 235 is DSS CLIENT_TO_SERVER | MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF. 236 This indicates that the DSS authentication mechanism will be used to 237 mutually authenticate the client and the server and that no 238 encryption will be performed. 240 --------------------------------------------------------------------- 241 Client (Party A) Server (Party B) 243 IAC WILL AUTHENTICATION --> 245 <-- IAC DO AUTHENTICATION 247 <-- IAC SB AUTHENTICATION SEND 248 249 IAC SE 251 IAC SB AUTHENTICATION 252 NAME --> 254 IAC SB AUTHENTICATION IS 255 DSS 256 CLIENT_TO_SERVER | 257 MUTUAL | 258 ENCRYPT_OFF | 259 INI_CRED_FWD_OFF 260 DSS_INITIALIZE 261 IAC SE --> 263 <-- IAC SB AUTHENTICATION REPLY 264 DSS 265 CLIENT_TO_SERVER | 266 MUTUAL | 267 ENCRYPT_OFF | 268 INI_CRED_FWD_OFF 269 DSS_TOKENBA 270 Sequence( TokenID, TokenBA ) 271 IAC SE 272 --------------------------------------------------------------------- 273 Figure 2 (continued) 274 Figure 2 (continued) 275 --------------------------------------------------------------------- 276 Client (Party A) Server (Party B) 278 IAC SB AUTHENTICATION IS 279 DSS 280 CLIENT_TO_SERVER | 281 MUTUAL | 282 ENCRYPT_OFF | 283 INI_CRED_FWD_OFF 284 DSS_CERTA_TOKENAB 285 Sequence( TokenID, CertA, TokenAB ) 286 IAC SE --> 288 <-- IAC SB AUTHENTICATION REPLY 289 DSS 290 CLIENT_TO_SERVER | 291 MUTUAL | 292 ENCRYPT_OFF | 293 INI_CRED_FWD_OFF 294 DSS_CERTB_TOKENBA2 295 Sequence( TokenID, CertB, TokenBA2 ) 296 IAC SE 297 --------------------------------------------------------------------- 298 Figure 2 300 4. Security Considerations 302 This entire memo is about security mechanisms. For DSA to provide 303 the authentication discussed, the implementation must protect the 304 private key from disclosure. 306 5. Acknowledgements 308 We would like to thank William Nace for support during implementation 309 of this specification. 311 6. References 313 [1] - Borman, David A. "TELNET Authentication Option". 314 RFC 1416. February 1993. 316 [2] - Digital Signature Standard (DSS). FIPS Pub 186. 317 May 19, 1994. 319 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 321 [4] - Standard for Entity Authentication Using Public Key 322 Cryptography. FIPS Pub 196. February 18, 1997. 324 [5] - Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 325 X.509 Public Key Infrastructure: X.509 Certificate and CRL 326 Profile", RFC 2459, January 1999. 328 7.0 Author's Address 330 Russell Housley 331 SPYRUS 332 381 Elden Street, Suite 1120 333 Herndon, VA 20172 334 USA 335 Email: housley@spyrus.com 337 Todd Horting 338 SPYRUS 339 381 Elden Street, Suite 1120 340 Herndon, VA 20172 341 USA 342 Email: thorthing@spyrus.com 344 Peter Yee 345 SPYRUS 346 5303 Betsy Ross Drive 347 Santa Clara, CA 95054 348 USA 349 Email: yee@spyrus.com