idnits 2.17.1 draft-housley-telnet-auth-dsa-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 (2024-04-25) 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 5 instances of too long lines in the document, the longest one being 3 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 (February 1998) is 9566 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 February 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 learn the current status of any Internet-Draft, please check the 24 "1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 Distribution of this memo is unlimited. Please send comments to the 29 mailing list. 31 Abstract 33 This document defines a method to authenticate telnet using the 34 Digital Signature Algorithm (DSA) [2]. It relies on the Telnet 35 Authentication Option [1]. 37 1 Introduction 39 The Telnet protocol provides no protocol security. Telnet servers may 40 require users to login. This is typically a host level login 41 consisting of a user name and a password, transmitted in the clear. 43 The mechanism specified in this document relies on the Telnet 44 Authentication Option [1]. 46 2 Telnet Security Extensions 48 Telnet, as a protocol, has no concept of security. Without 49 negotiated options, it merely passes characters back and forth 50 between the NVTs represented by the two Telnet processes. In its 51 most common usage as a protocol for remote terminal access (TCP port 52 23), Telnet normally connects to a server that requires user-level 53 authentication through a user name and password in the clear. The 54 server does not authenticate itself to the user. 56 The Telnet Authentication Option provide for user authentication and 57 server authentication. User authentication replaces or augments the 58 normal host password mechanism. Server authentication is normally 59 done in conjunction with user authentication. 61 In order to support these security services, the two Telnet entities 62 must first negotiate their willingness to support the Telnet 63 Authentication Option. Upon agreeing to support these options, the 64 parties are then able to perform subnegotiations to determine the 65 authentication protocol to be used, and possibly the remote user name 66 to be used for authorization checking. 68 Authentication and parameter negotiation occur within an unbounded 69 series of exchanges. The server proposes a preference-ordered list 70 of authentication types (mechanisms) which it supports. In addition 71 to listing the mechanisms it supports, the server qualifies each 72 mechanism with a modifier that specifies whether the authentication 73 is to be one-way or mutual, and in which direction the authentication 74 is to be performed. The client selects one mechanism from the list 75 and responds to the server indicating its choice and the first set of 76 authentication data needed for the selected authentication type. The 77 server and the client then proceed through whatever number of 78 iterations are required to arrive at the requested authentication. 80 3 Use of Digital Signature Algorithm (DSA) 82 This paper specifies a method in which DSA may be used to achieve 83 certain security services when used in conjunction with the Telnet 84 Authentication Option. SHA-1 [3] is used with DSA [2]. 86 DSA may provide either unilateral or mutual authentication. Due to 87 Telnet's character-by-character nature, it is not well-suited to the 88 application of integrity-only services, therefore use of the DSA 89 profile provides authentication but it does not provide session 90 integrity. This specification follows the token and exchanges 91 defined in NIST FIPS PUB 196 [4], Standard for Public Key 92 Cryptographic Entity Authentication Mechanisms, draft of 28 February 93 1995, including Appendix A on ASN.1 encoding of messages and tokens. 95 3.1 Unilateral Authentication with DSA 97 Unilateral authentication must be done client-to-server. What 98 follows are the protocol steps necessary to perform DSA 99 authentication as specified in FIPS PUB 196 under the Telnet 100 Authentication Option framework. Where failure modes are 101 encountered, the return codes follow those specified in the Telnet 102 Authentication Option. They are not enumerated here, as they are 103 invariant among the mechanisms used. FIPS PUB 196 employs a set of 104 exchanges that are transferred to provide authentication. Each 105 exchange employs various fields and tokens, some of which are 106 optional. In addition, each token has several subfields that are 107 optional. A conformant subset of the fields and subfields have been 108 selected. Therefore, the exchanges below do not show the FIPS PUB 109 196 notations indicating optional fields, as all subfields used are 110 mandatory. The tokens are ASN.1 encoded as defined in Appendix A of 111 FIPS PUB 196, and each token is named to indicate the direction in 112 which it flows (e.g., TokenBA flows from Party B to Party A). In 113 Figure 1, the client binds the last transmission (token identifier, 114 certificate, and token) together as an ASN.1 SEQUENCE. 116 During authentication, the client may provide the user name to the 117 server by using the authentication name sub-option. If the name sub- 118 option is not used, the server will generally prompt for a name and 119 password in the clear. The name sub-option must be sent after the 120 server sends the list of authentication types supported and before 121 the client finishes the authentication exchange, this ensures that 122 the server will not prompt for a user name and password. In figure 123 1, the name sub-option is sent immediately after the server presents 124 the list of authentication types supported. 126 For one-way DSA authentication, the two-octet authentication type 127 pair is "DSA CLIENT-TO-SERVER ONE-WAY ENCRYPT_OFF INI_CRED_FWD_OFF." 128 This is encoded as two-octets: '0B01' in hexadecimal. This indicates 129 that the DSA authentication mechanism will be used to authenticate 130 the client to the server, and that no encryption will be performed. 132 Within the unbounded authentication exchange, implementation is 133 greatly simplified if each portion of the exchange carries a unique 134 identifier. For this reason, a single octet suboption identifier is 135 carried immediately after the two-octet authentication type pair. 137 The exchanges detailed below, in Figure 1, presume knowledge of FIPS 138 PUB 196 and the Telnet Authentication Option. The client is Party A, 139 while the server is Party B. At the end of the exchanges, the client 140 is authenticated to the server. 142 --------------------------------------------------------------------- 143 Client (Party A) Server (Party B) 145 <-- IAC DO AUTHENTICATION 147 IAC WILL AUTHENTICATION --> 149 <-- IAC SB AUTHENTICATION SEND 150 151 IAC SE 153 IAC SB AUTHENTICATION 154 NAME --> 156 IAC SB AUTHENTICATION IS 157 '0B01' '1' IAC SE --> 159 <-- IAC SB AUTHENTICATION REPLY 160 '0B01' '2' 161 Base64( Sequence( TokenID, 162 TokenBA ) ) 163 IAC SE 165 IAC SB AUTHENTICATION IS 166 '0B01' '3' 167 Base64( Sequence( 168 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 Base64( Sequence( TokenID, 205 TokenBA ) ) 206 IAC SE 208 IAC SB AUTHENTICATION IS 209 '0B03' '3' 210 Base64( Sequence( 211 TokenID, CertA, TokenAB ) ) 212 IAC SE --> 214 <-- IAC SB AUTHENTICATION REPLY 215 '0B03' '4' 216 Base64( Sequence( TokenID, 217 CertB, TokenBA2 ) ) 218 IAC SE 219 --------------------------------------------------------------------- 220 Figure 2 222 4.0 Security Considerations 224 This entire memo is about security mechanisms. For DSA to provide 225 the authentication discussed, the implementation must protect the 226 private key from disclosure. 228 5.0 Acknowledgements 230 We would like to thank William Nace for support during implementation 231 of this specification. 233 6.0 References 235 [1] - Borman, David A. "Telnet Authentication Option". 236 RFC 1416. February 1993. 238 [2] - Digital Signature Standard (DSS). FIPS Pub 186. 239 May 19, 1994. 241 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 243 [4] - Standard for Entity Authentication Using Public Key 244 Cryptography. FIPS Pub 196. February 18, 1997. 246 7.0 Author's Address 248 Russell Housley 249 SPYRUS 250 PO Box 1198 251 Herndon, VA 20172 252 USA 254 Phone: +1 703 435-7344 255 Email: housley@spyrus.com 257 Todd Horting 258 SPYRUS 259 PO Box 1198 260 Herndon, VA 20172 261 USA 263 Phone: +1 703 435-4711 264 Email: thorthing@spyrus.com 266 Peter Yee 267 SPYRUS 268 2460 N. First Street 269 Suite 100 270 San Jose, CA 95131-1023 271 USA 273 Phone: +1 408 432-8180 274 Email: yee@spyrus.com