idnits 2.17.1 draft-housley-telnet-auth-dsa-02.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-24) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 (July 1998) is 9415 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 July 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 the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Distribution of this memo is unlimited. Please send comments to the 30 mailing list. 32 Abstract 34 This document defines a telnet authentication mechanism using the 35 Digital Signature Algorithm (DSA) [2]. It relies on the Telnet 36 Authentication Option [1]. 38 1 Introduction 40 The Telnet protocol provides no protocol security. Telnet servers may 41 require users to login. This is typically a host level login 42 consisting of a user name and a password, transmitted in the clear. 44 The mechanism specified in this document relies on the Telnet 45 Authentication Option [1]. 47 2 Telnet Security Extensions 49 Telnet, as a protocol, has no concept of security. Without 50 negotiated options, it merely passes characters back and forth 51 between the NVTs represented by the two Telnet processes. In its 52 most common usage as a protocol for remote terminal access (TCP port 53 23), Telnet connects to a server that requires user-level 54 authentication through a user name and password in the clear; the 55 server does not authenticate itself to the user. 57 The Telnet Authentication Option provides for user authentication and 58 server authentication. User authentication replaces or augments the 59 normal host password mechanism. Server authentication is normally 60 done in conjunction with user authentication. 62 In order to support these security services, the two Telnet entities 63 must first negotiate their willingness to support the Telnet 64 Authentication Option. Upon agreeing to support these options, the 65 parties are then able to perform suboptions to determine the 66 authentication protocol to be used, and possibly the remote user name 67 to be used for authorization checking. 69 Authentication and parameter negotiation occur within an unbounded 70 series of exchanges. The server proposes a preference-ordered list 71 of authentication types (mechanisms) which it supports. In addition 72 to listing the mechanisms it supports, the server qualifies each 73 mechanism with a modifier that specifies whether the authentication 74 is to be one-way or mutual, and in which direction the authentication 75 is to be performed. The client selects one mechanism from the list 76 and responds to the server indicating its choice and the first set of 77 authentication data needed for the selected authentication type. The 78 server and the client then proceed through whatever number of 79 iterations are required to arrive at the requested authentication. 81 3 Use of Digital Signature Algorithm (DSA) 83 This paper specifies a method in which DSA may be used to achieve 84 certain security services when used in conjunction with the Telnet 85 Authentication Option. SHA-1 [3] is used with DSA [2]. 87 DSA may provide either unilateral or mutual authentication. Due to 88 Telnet's character-by-character nature, it is not well-suited to the 89 application of integrity-only services, therefore use of the DSA 90 profile provides authentication but it does not provide session 91 integrity. This specification follows the token and exchanges 92 defined in NIST FIPS PUB 196 [4], Standard for Public Key 93 Cryptographic Entity Authentication Mechanisms, draft of 28 February 94 1995, including Appendix A on ASN.1 encoding of messages and tokens. 96 3.1 Unilateral Authentication with DSA 98 Unilateral authentication must be done client-to-server. What 99 follows are the protocol steps necessary to perform DSA 100 authentication as specified in FIPS PUB 196 under the Telnet 101 Authentication Option framework. Where failure modes are 102 encountered, the return codes follow those specified in the Telnet 103 Authentication Option. They are not enumerated here, as they are 104 invariant among the mechanisms used. FIPS PUB 196 employs a set of 105 exchanges that are transferred to provide authentication. Each 106 exchange employs various fields and tokens, some of which are 107 optional. In addition, each token has several subfields that are 108 optional. A conformant subset of the fields and subfields have been 109 selected. Therefore, the exchanges below do not show the FIPS PUB 110 196 notations indicating optional fields, as all subfields used are 111 mandatory. The tokens are ASN.1 encoded as defined in Appendix A of 112 FIPS PUB 196, and each token is named to indicate the direction in 113 which it flows (e.g., TokenBA flows from Party B to Party A). Figure 114 1 illustrates the exchanges for unilateral authentication. 116 During authentication, the client may provide the user name to the 117 server by using the authentication name suboption. If the name 118 suboption is not used, the server will generally prompt for a name 119 and password in the clear. The name sub-option must be sent after 120 the server sends the list of authentication types supported and 121 before the client finishes the authentication exchange, this ensures 122 that the server will not prompt for a user name and password. In 123 figure 1, the name suboption is sent immediately after the server 124 presents 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: '0E01' 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 '0E01' '1' IAC SE --> 159 <-- IAC SB AUTHENTICATION REPLY 160 '0E01' '2' 161 Sequence( TokenID, TokenBA ) 162 IAC SE 164 IAC SB AUTHENTICATION IS 165 '0E01' '3' 166 Sequence( TokenID, CertA, TokenAB ) 167 IAC SE --> 168 --------------------------------------------------------------------- 169 Figure 1 171 3.2 Mutual Authentication with DSA 173 Mutual authentication is slightly more complex. Figure 2 illustrates 174 the exchanges. 176 For mutual DSA authentication, the two-octet authentication type pair 177 is "DSA CLIENT-TO-SERVER MUTUAL ENCRYPT_OFF INI_CRED_FWD_OFF." This 178 is encoded as two-octets: '0E03' in hexadecimal. This indicates that 179 the DSA authentication mechanism will be used to mutually 180 authenticate the client and the server and that no encryption will be 181 performed. 183 --------------------------------------------------------------------- 184 Client (Party A) Server (Party B) 186 IAC WILL AUTHENTICATION --> 188 <-- IAC DO AUTHENTICATION 190 <-- IAC SB AUTHENTICATION SEND 191 192 IAC SE 194 IAC SB AUTHENTICATION 195 NAME --> 197 IAC SB AUTHENTICATION IS 198 '0E03' '1' IAC SE --> 200 <-- IAC SB AUTHENTICATION REPLY 201 '0E03' '2' 202 Sequence( TokenID, TokenBA ) 203 IAC SE 205 IAC SB AUTHENTICATION IS 206 '0E03' '3' 207 Sequence( TokenID, CertA, TokenAB ) 208 IAC SE --> 210 <-- IAC SB AUTHENTICATION REPLY 211 '0E03' '4' 212 Sequence( TokenID, CertB, TokenBA2 ) 213 IAC SE 214 --------------------------------------------------------------------- 215 Figure 2 217 4.0 Security Considerations 219 This entire memo is about security mechanisms. For DSA to provide 220 the authentication discussed, the implementation must protect the 221 private key from disclosure. 223 5.0 Acknowledgements 225 We would like to thank William Nace for support during implementation 226 of this specification. 228 6.0 References 230 [1] - Borman, David A. "Telnet Authentication Option". 231 RFC 1416. February 1993. 233 [2] - Digital Signature Standard (DSS). FIPS Pub 186. 234 May 19, 1994. 236 [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995. 238 [4] - Standard for Entity Authentication Using Public Key 239 Cryptography. FIPS Pub 196. February 18, 1997. 241 7.0 Author's Address 243 Russell Housley 244 SPYRUS 245 381 Elden Street, Suite 1120 246 Herndon, VA 20172 247 USA 248 Phone: +1 703 707-0696 249 Email: housley@spyrus.com 251 Todd Horting 252 SPYRUS 253 381 Elden Street, Suite 1120 254 Herndon, VA 20172 255 USA 256 Phone: +1 703 707-0696 257 Email: thorthing@spyrus.com 259 Peter Yee 260 SPYRUS 261 2460 N. First Street 262 Suite 100 263 San Jose, CA 95131-1023 264 USA 265 Phone: +1 408 432-8180 266 Email: yee@spyrus.com