idnits 2.17.1 draft-housley-telnet-auth-dsa-01.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 (2024-04-19) 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) 2024 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 == The page length should not exceed 58 lines per page, but there was 5 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 6 pages 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 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 (March 1998) is 9532 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' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Telnet Working Group Russell Housley (SPYRUS) 3 Todd Horting (SPYRUS) 4 Internet-Draft Peter Yee (SPYRUS) 5 Expire in six months March 1998 7 Telnet Authentication Using DSA 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are Draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ''work in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Distribution of this memo is unlimited. Please send comments to the 31 mailing list. 33 Abstract 35 This document defines a method to authenticate telnet using the 36 Digital Signature Algorithm (DSA) [2]. It relies on the Telnet 37 Authentication Option [1]. 39 1 Introduction 41 The Telnet protocol provides no protocol security. Telnet servers may 42 require users to login. This is typically a host level login 43 consisting of a user name and a password, transmitted in the clear. 45 The mechanism specified in this document relies on the Telnet 46 Authentication Option [1]. 48 2 Telnet Security Extensions 50 Telnet, as a protocol, has no concept of security. Without 51 negotiated options, it merely passes characters back and forth 52 between the NVTs represented by the two Telnet processes. In its 53 most common usage as a protocol for remote terminal access (TCP port 54 23), Telnet normally connects to a server that requires user-level 55 authentication through a user name and password in the clear. The 56 server does not authenticate itself to the user. 58 The Telnet Authentication Option provides for user authentication and 59 server authentication. User authentication replaces or augments the 60 normal host password mechanism. Server authentication is normally 61 done in conjunction with user authentication. 63 In order to support these security services, the two Telnet entities 64 must first negotiate their willingness to support the Telnet 65 Authentication Option. Upon agreeing to support these options, the 66 parties are then able to perform subnegotiations to determine the 67 authentication protocol to be used, and possibly the remote user name 68 to be used for authorization checking. 70 Authentication and parameter negotiation occur within an unbounded 71 series of exchanges. The server proposes a preference-ordered list 72 of authentication types (mechanisms) which it supports. In addition 73 to listing the mechanisms it supports, the server qualifies each 74 mechanism with a modifier that specifies whether the authentication 75 is to be one-way or mutual, and in which direction the authentication 76 is to be performed. The client selects one mechanism from the list 77 and responds to the server indicating its choice and the first set of 78 authentication data needed for the selected authentication type. The 79 server and the client then proceed through whatever number of 80 iterations are required to arrive at the requested authentication. 82 3 Use of Digital Signature Algorithm (DSA) 84 This paper specifies a method in which DSA may be used to achieve 85 certain security services when used in conjunction with the Telnet 86 Authentication Option. SHA-1 [3] is used with DSA [2]. 88 DSA may provide either unilateral or mutual authentication. Due to 89 Telnet's character-by-character nature, it is not well-suited to the 90 application of integrity-only services, therefore use of the DSA 91 profile provides authentication but it does not provide session 92 integrity. This specification follows the token and exchanges 93 defined in NIST FIPS PUB 196 [4], Standard for Public Key 94 Cryptographic Entity Authentication Mechanisms, draft of 28 February 95 1995, including Appendix A on ASN.1 encoding of messages and tokens. 97 3.1 Unilateral Authentication with DSA 99 Unilateral authentication must be done client-to-server. What 100 follows are the protocol steps necessary to perform DSA 101 authentication as specified in FIPS PUB 196 under the Telnet 102 Authentication Option framework. Where failure modes are 103 encountered, the return codes follow those specified in the Telnet 104 Authentication Option. They are not enumerated here, as they are 105 invariant among the mechanisms used. FIPS PUB 196 employs a set of 106 exchanges that are transferred to provide authentication. Each 107 exchange employs various fields and tokens, some of which are 108 optional. In addition, each token has several subfields that are 109 optional. A conformant subset of the fields and subfields have been 110 selected. Therefore, the exchanges below do not show the FIPS PUB 111 196 notations indicating optional fields, as all subfields used are 112 mandatory. The tokens are ASN.1 encoded as defined in Appendix A of 113 FIPS PUB 196, and each token is named to indicate the direction in 114 which it flows (e.g., TokenBA flows from Party B to Party A). In 115 Figure 1, the client binds the last transmission (token identifier, 116 certificate, and token) together as an ASN.1 SEQUENCE. 118 During authentication, the client may provide the user name to the 119 server by using the authentication name sub-option. If the name sub- 120 option is not used, the server will generally prompt for a name and 121 password in the clear. The name sub-option must be sent after the 122 server sends the list of authentication types supported and before 123 the client finishes the authentication exchange, this ensures that 124 the server will not prompt for a user name and password. In figure 125 1, the name sub-option is sent immediately after the server presents 126 the list of authentication types supported. 128 For one-way DSA authentication, the two-octet authentication type 129 pair is "DSA CLIENT-TO-SERVER ONE-WAY ENCRYPT_OFF INI_CRED_FWD_OFF." 130 This is encoded as two-octets: '0B01' in hexadecimal. This indicates 131 that the DSA authentication mechanism will be used to authenticate 132 the client to the server, and that no encryption will be performed. 134 Within the unbounded authentication exchange, implementation is 135 greatly simplified if each portion of the exchange carries a unique 136 identifier. For this reason, a single octet suboption identifier is 137 carried immediately after the two-octet authentication type pair. 139 The exchanges detailed below, in Figure 1, presume knowledge of FIPS 140 PUB 196 and the Telnet Authentication Option. The client is Party A, 141 while the server is Party B. At the end of the exchanges, the client 142 is authenticated to the server. 144 --------------------------------------------------------------------- 145 Client (Party A) Server (Party B) 147 <-- IAC DO AUTHENTICATION 149 IAC WILL AUTHENTICATION --> 151 <-- IAC SB AUTHENTICATION SEND 152 153 IAC SE 155 IAC SB AUTHENTICATION 156 NAME --> 158 IAC SB AUTHENTICATION IS 159 '0B01' '1' IAC SE --> 161 <-- IAC SB AUTHENTICATION REPLY 162 '0B01' '2' 163 Sequence( TokenID, TokenBA ) 164 IAC SE 166 IAC SB AUTHENTICATION IS 167 '0B01' '3' 168 Sequence( TokenID, CertA, TokenAB ) 169 IAC SE --> 170 --------------------------------------------------------------------- 171 Figure 1 173 3.2 Mutual Authentication with DSA 175 Mutual authentication is slightly more complex. Figure 2 illustrates 176 the exchanges. 178 For mutual DSA authentication, the two-octet authentication type pair 179 is "DSA CLIENT-TO-SERVER MUTUAL ENCRYPT_OFF INI_CRED_FWD_OFF." This 180 is encoded as two-octets: '0B03' in hexadecimal. This indicates that 181 the DSA authentication mechanism will be used to mutually 182 authenticate the client and the server, and that no encryption will 183 be performed. 185 --------------------------------------------------------------------- 186 Client (Party A) Server (Party B) 188 IAC WILL AUTHENTICATION --> 190 <-- IAC DO AUTHENTICATION 192 <-- IAC SB AUTHENTICATION SEND 193 194 IAC SE 196 IAC SB AUTHENTICATION 197 NAME --> 199 IAC SB AUTHENTICATION IS 200 '0B03' '1' IAC SE --> 202 <-- IAC SB AUTHENTICATION REPLY 203 '0B03' '2' 204 Sequence( TokenID, TokenBA ) 205 IAC SE 207 IAC SB AUTHENTICATION IS 208 '0B03' '3' 209 Sequence( TokenID, CertA, TokenAB ) 210 IAC SE --> 212 <-- IAC SB AUTHENTICATION REPLY 213 '0B03' '4' 214 Sequence( TokenID, CertB, TokenBA2 ) 215 IAC SE 216 --------------------------------------------------------------------- 217 Figure 2 219 4.0 Security Considerations 221 This entire memo is about security mechanisms. For DSA to provide 222 the authentication discussed, the implementation must protect the 223 private key from disclosure. 225 5.0 Acknowledgements 227 We would like to thank William Nace for support during implementation 228 of this specification. 230 6.0 References 232 [1] - Borman, David A. "Telnet Authentication Option". 233 RFC 1416. February 1993. 235 [2] - Digital Signature Standard (DSS). FIPS Pub 186. 236 May 19, 1994. 238 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 240 [4] - Standard for Entity Authentication Using Public Key 241 Cryptography. FIPS Pub 196. February 18, 1997. 243 7.0 Author's Address 245 Russell Housley 246 SPYRUS 247 PO Box 1198 248 Herndon, VA 20172 249 USA 251 Phone: +1 703 435-7344 252 Email: housley@spyrus.com 254 Todd Horting 255 SPYRUS 256 PO Box 1198 257 Herndon, VA 20172 258 USA 260 Phone: +1 703 435-4711 261 Email: thorthing@spyrus.com 263 Peter Yee 264 SPYRUS 265 2460 N. First Street 266 Suite 100 267 San Jose, CA 95131-1023 268 USA 270 Phone: +1 408 432-8180 271 Email: yee@spyrus.com