idnits 2.17.1 draft-ietf-pppext-eapdss-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-03-29) 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 1 longer page, the longest (page 7) being 60 lines == It seems as if not all pages are separated by form feeds - found 11 form feeds but 13 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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 64: '...ed, an implementation MUST specify the...' RFC 2119 keyword, line 84: '... MUST This word, or the ad...' RFC 2119 keyword, line 88: '... MUST NOT This phrase means th...' RFC 2119 keyword, line 91: '... SHOULD This word, or the ad...' RFC 2119 keyword, line 99: '... MAY This word, or the ad...' (4 more instances...) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '1' on line 440 looks like a reference -- Missing reference section? '2' on line 443 looks like a reference -- Missing reference section? '3' on line 447 looks like a reference -- Missing reference section? '4' on line 450 looks like a reference -- Missing reference section? '5' on line 454 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group William A. Nace(NSA) 3 Internet Draft James E. Zmuda(SPYRUS) 4 expires in six months November 21st, 1997 6 PPP EAP DSS Public Key Authentication Protocol 7 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol 12 Extensions Working Group of the Internet Engineering Task Force 13 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 14 mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as 'work 27 in progress.' 29 To learn the current status of any Internet-Draft, please check 30 the '1id-abstracts.txt' listing contained in the Internet-Drafts 31 Shadow Directories on ds.internic.net (US East Coast), 32 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 33 munnari.oz.au (Pacific Rim). 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method 38 for transporting multi-protocol datagrams over point-to-point 39 links 41 PPP also defines an extensible Link Control Protocol, which 42 allows negotiation of an Authentication Protocol for 43 authentication of its peer before allowing Network Layer 44 protocols to transmit over the link. 46 PPP Extensible Authentication Protocol (EAP) [2] provides for a 48 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 50 number of authentication mechanisms. This document specifies 51 yet another authentication mechanism that may be used within the 52 EAP framework. This document defines the DSS Public Key 53 Authentication Protocol within PPP EAP. 55 1. Introduction 57 In order to establish communications over a point-to- point link, 58 each end of the PPP link must first send LCP packets to configure the 59 data link during Link Establishment phase. After the link has been 60 established, PPP provides for an optional Authentication phase before 61 proceeding to the Network- Layer Protocol phase. 63 By default, authentication is not mandatory. If authentication of 64 the link is desired, an implementation MUST specify the 65 Authentication-Protocol Configuration Option during Link Establish- 66 ment phase. 68 PPP Extensible Authentication Protocol (EAP) [2] allows for a number 69 of authentication protocols including DSS Public Key Authentication 70 Protocol. 72 This document defines the PPP EAP DSS Public Key Authentication Pro- 73 tocol. The Link Establishment and Authentication phases, and the 74 Authentication-Protocol Configuration Option are defined in The 75 Point-to-Point Protocol (PPP) [1]. The Extensible Authentication 76 protocol is defined in PPP Extensible Authentication Protocol (EAP) 77 [2]. 79 1.1. Specification of Requirements 81 In this document, several words are used to signify the requirements 82 of the specification. These words are often capitalized. 84 MUST This word, or the adjective required, means that the 85 definition is an absolute requirement of the specifi- 86 cation. 88 MUST NOT This phrase means that the definition is an absolute 89 prohibition of the specification. 91 SHOULD This word, or the adjective recommended, means that 92 there may exist valid reasons in particular cir- 93 cumstances to ignore this item, but the full implica- 94 tions must be understood and carefully weighed before 95 choosing a different course. 97 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 99 MAY This word, or the adjective optional, means that this 100 item is one of an allowed set of alternatives. An 101 implementation which does not include this option MUST 102 be prepared to interoperate with another implementa- 103 tion which does include the option. 105 1.2. Terminology 107 This document frequently uses the following terms: 109 authenticator The end of the link requiring the authentication. The 110 authenticator specifies use of DSS Authentication in 111 the EAP-Request during Authentication phase. 113 certificate A certificate consists of the binding together of one 114 or more public key values and an identity. This bind- 115 ing is effected through a digital signature which is 116 computed over the data containing both the public key 117 and the identity. This signature is applied by a 118 "certification authority" who is recognized as issuing 119 this certificate on behalf of the entity identified in 120 the certificate. In this manner a recipient of this 121 certificate can determine the recognized public key of 122 the particular entity identified in the certificate. 123 This requires the recipient to, either directly or 124 indirectly, trust the authority who has issued this 125 certificate. 127 certification authority (CA) 128 An authority trusted by one or more users to create 129 and assign certificates. [3]. 131 digital signature 132 In the DSS, a digital signature is produced by per- 133 forming the DSA signing operation with a private key 134 on the SHA-1 Hash value computed over the original 135 data to be signed. The verification of this digital 136 signature requires the verifier to obtain the original 137 message, and the signature value, and the proper pub- 138 lic key value that is associated with the signer (see 139 certificates below). The verifier then also computes 140 the SHA-1 Hash of the message data, and then perform a 141 computation whose inputs include this hash value, the 142 public key, and the signature value. If the output of 143 this computation matches a particular part of the sig- 144 nature value produced by the signer, then the signa- 145 ture is verified. 147 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 149 DSA Digital Signature Algorithm 151 DSS Digital Signature Standard 153 DSS key pair A pair of keys, one of which, the private key, can be 154 used to produce a "signature". The other, or public, 155 key can be used only to verify that a digital signa- 156 ture has been produced by the private key it is asso- 157 ciated with, when acting on a particular piece of 158 data. Under the DSA these two keys do not form an 159 encryption/decryption pair, however. 161 distinguished name 162 A unique heirarchical name. Used in the certificate's 163 "subject" field to denote the entity associated with 164 the public key value(s) in the certificate[2]. Also 165 used in the certificate's "issuer" field to denote the 166 entity that issued this certificate. 168 peer The other end of the point-to-point link; the end 169 which is being authenticated by the authenticator. 171 private key That key of a key pair which is known only by that 172 user [3]. 174 public key That key of a key pair which is publicly known [3]. 176 SHA-1 Secure Hash Algorithm revision one. 178 2. PPP EAP DSS Public Key Authentication 180 The PPP Extensible Authentication Protocol is a general protocol for 181 PPP authentication which supports multiple authentication mechanisms. 182 EAP MAY be negotiated at Link Control Phase. EAP MAY then be used to 183 select the DSS Public Key Authentication mechanisms at the Authenti- 184 cation Phase. 186 The DSS Public Key Authentication Protocol is a challenge- response 187 protocol based on unilateral two pass authentication as described in 188 NIST FIPS PUB 196 "Standard for Public Key Cryptographic Entity 189 Authentication Mechanisms" [4]. The authenticator issues a challenge 190 in the form of a Request packet. The peer MUST formulate a Response 191 packet based on information in the Request packet as well as informa- 192 tion only the peer knows (the peer's private key). The peer MUST 193 also provide in its response a reference (i.e. the subject Dis- 194 tinguished Name in the Certificate) to its own certificate (the cer- 195 tificate containing the peer's public key), as well as proof that it 197 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 199 knows the corresponding private key. The peer's certificate is 200 assumed to have been obtained through other means. One such means is 201 the use of the Certificate Exchange Protocol. The Certificate 202 Exchange Protocol is defined as an extension to the PPP protocol 203 suite. It is suggested as occurring during a new phase in between 204 Link Control and Authentication. The Certificate Exchange Protocol is 205 defined in [5]. 207 In detail, the steps in EAP DSS are: 209 1. After the Link Establishment phase is complete and 210 Extensible Authentication Protocol is negotiated, the 211 authenticator sends a Request packet to authenticate 212 the peer. The Request packet has a type field speci- 213 fying DSS Public Key Authentication plus some random 214 data produced by the authenticator. 216 2. The peer sends a Response packet in reply to the 217 Request. The response contains the digital signature 218 computed by the peer over the concatenation of the 219 challenge, the timestamp, and the peer's distinguished 220 name. 222 3. Based on information contained in the Response packet, 223 the authenticator ends the authentication phase with 224 either a Success packet or a Failure packet. These 225 packets are defined in PPP Extensible Authentication 226 Protocol (EAP) [2]. 228 3. PPP EAP DSS Public Key Authentication Packet Format 230 DSS Unilateral authentication is performed using a derivative of the 231 FIPS PUB 196 mechanism as defined below. The FIPS PUB 196 verifier 232 corresponds to the EAP authenticator, while the claimant has a simi- 233 lar relation to the EAP authenticatee. 235 In keeping with FIPS PUB 196 notation, the authenticator is identi- 236 fied as "B"; the authenticatee as "A". Two packets are exchanged in 237 order to perform the authentication, first from B to A, and then from 238 A to B. 240 Both the EAP Response and Request packets for the DSS Unilateral Type 241 have the following format: 243 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 245 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 Public Key Authentication ProtocolNovember 1997 249 NOT imply that we will use ASN.1 to represent the contents of TokenBA 250 or TokenAB in the EAP DSS Request and Response packets. This is 251 rather just a list of the information found in the EAP DSS packets.] 253 Token BA1 is profiled from FIPS PUB 196 Appendix A as: 255 TokenBA ::= SEQUENCE { 256 ranB RandomNumber, 257 timestampB TimeStamp 258 } 260 TokenAB is then profiled as: 262 TokenABU ::= SEQUENCE { 263 ranA RandomNumber, -- unused 264 entityA EntityName, 265 certA Certificate, -- from X.509 -- unused 266 signature SigDataABU 267 } 269 SigDataABU ::= SIGNATURE SEQUENCE { 270 ranA RandomNumber, -- unused 271 ranB RandomNumber, -- as sent in TokenBA 272 entityA EntityName 273 } 275 RandomNumber ::= INTEGER 277 EntityName is a CHOICE and for this specification, the Name CHOICE is 278 the only one acceptable. EmailName may not be used. 280 The following sections define the format of the request and response. 282 3.1. EAP DSS Public Key Request Packet 284 The DSS Unilateral Request packet Type Data field contains the data 285 from the FIPS PUB 196 Token BA1. 287 This information is formatted in a length-value format. No explicit 288 type field is necessary because all fields are required and are in a 289 determinate order. In this one case the last element includes a 290 length field also, even though its length can be determined from the 291 overall length. This allows for easy expansion in this case. The EAP 292 DSS Request packet has the following overall format: 294 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 296 0 1 2 3 297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Code | Identifier | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | timeStampLen | timeStamp... | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | ...timeStamp | ranB Length | ranB... | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | ...ranB... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | ...ranB... 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3.0-2 - EAP DSS Request Packet format 311 Code 313 1 (Request) 315 Identifier 317 The Identifier field is one octet and serves the same 318 purpose as the TokenID field in FIPS PUB 196, namely 319 disambiguating between multiple outstanding Requests and 320 Responses. Handling of the Identifier field with respect 321 to time-outs, new Requests, and duplicate Responses is as 322 specified in EAP. 324 Length 326 The Length field is two octets and indicates the length 327 of the EAP Request and Response packets including the 328 Code, Identifier, Length, Type, timeStampLen, timeStamp, 329 ranB Length, and ranB fields. Octets in the packet out- 330 side the range of the Length field should be treated as 331 Data Link Layer padding and should be ignored on recep- 332 tion. 334 Type 336 The Type field in the Request will carry the value 10 337 (DSS Unilateral). 339 timeStampLen 341 The Length of the timeStamp field in bytes is specified 342 here. A single byte is used to represent this length. 344 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 346 For the current version this value is 4. 348 timestampB 350 This value is a monotonically increasing (aside from wra- 351 paround) four byte integer in network byte order (Big 352 Endian). 354 ranB Length 356 The Length of the ranB field in bytes is specified here. 357 A single byte is used to represent this length. For the 358 Fortezza version this value is 20. 360 ranB 362 The value of the random challenge from the initiator to 363 the responder. This value cannot exceed 255 bytes in 364 length. For the Fortezza version the length of this 365 field is 20 bytes. 367 3.2. EAP DSS Public Key Response Packet 369 The DSS Unilateral Response packet Type Data field contains the data 370 from the FIPS PUB 196 Token AB1. 372 This information is formatted in a length-value format. No explicit 373 type field is necessary because all fields are required and are in a 374 determinate order. The last element does not include a length field 375 because its length can be determined from the overall length. The 376 EAP DSS Response packet has the following overall format: 378 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 380 0 1 2 3 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Code | Identifier | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Signature Len | Signature... | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | ...Signature... | 388 peer (in FIPS 389 196 terms entity A). The peer signs the concatenation of 390 the random challenge sent to it in the EAP DSS Request, 391 the timestamp sent to it, and its own entity name from 392 the certificate whose public key corresponds to the 393 private key used in forming the signature. The entity 394 name is the DER-encoded form of the Distinguished Name 395 contained in the subject field of the certificate. The 396 signature is computed as described under "digital signa- 397 ture" in section 1.2. This value cannot exceed 255 bytes 398 in length. 400 DName 402 The DER-encoded form of the subject field in the X.509 403 certificate whose public key corresponds to the private 404 key used by the entity to produce the signature value. 406 4. PPP EAP DSS Public Key Authentication Processing 408 If TokenAB is successfully verified by B and B is willing to operate 409 a PPP link with A then B shall transmit an EAP Success packet. Oth- 410 erwise, B may transmit an EAP Failure packet, and shall in all cases 411 transmit an LCP Terminate-Request. 413 Figure 4.0-1 depicts the operation of the EAP Unilateral authentica- 414 tion protocol with DSS. In this and the following figures depicting 415 PDU exchanges, the curly braces ({, }) denote items in Length-Value 416 representation. 418 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 420 Side: B A 422 Authenticator Authenticatee 424 EAP Request (ID1, DSS Unilateral, {ranB, timestampB }) => 426 <= EAPResponse(ID1,DSSUnilateral, 427 {SIGNA({ranB, timeStampB, entityA}), entityA) 429 EAP Success Packet( ID2) => 431 Figure 4.0-1 DSS Unilateral Authentication processing 433 Security Considerations 435 This memo defines a method for using EAP to perform Strong authenti- 436 cation of a peer using the DSS signature algorithm. 438 References: 440 [1] Simpson, W. A., 'The Point to Point Protocol 441 (PPP)', July 1994, RFC 1661. 443 [2] Blunk, L. J. & Vollbrecht, J. R., 'PPP Extensible 444 Authentication Protocol (EAP)', June 1996, work in 445 progress. 447 [3] CCITT Recommendation X.509, 'The Directory - 448 Authentication Framework', 1988. 450 [4] Federal Information Processing Standards Publication, 451 FIPS Pub 196, 'Entity Authentication using Public 452 Key Cryptography', February 18, 1997. 454 [5] Zmuda, J., 'The PPP Certificate Exchange Protocol', 455 July 1997, work in progress. 457 Acknowledgements: 459 This work is based largely on EAP. The authors would like to thank 460 John Vollbrecht of Merit specifically for his help in understanding 461 the intention of the EAP Internet Draft. The authors would also like 462 to thank Paul Amaranth of Oakland University for his EAP implementa- 463 tion. Thanks also are due to Bill Whelan of Network Express for his 464 Internet Draft showing a worked example of the use of EAP for public 466 DRAFT PPP EAP DSS Public Key Authentication ProtocolNovember 1997 468 key based authentication. Also both Peter Yee and Russ Housley pro- 469 vided helpful comments on earlier versions of this Memo. And thanks 470 finally to Bill Simpson for the standard PPP spec boilerplate from 471 which we have borrowed heavily. 473 Chair's Address: 475 The working group can be contacted via the current 476 chair: 478 Karl Fox 479 Ascend Communications, Inc. 481 Email: karl@ascend.com 483 Author's Address: 485 Questions about this memo can also be directed to: 487 DIRNSA 488 Attn: X22 (W. Nace) 489 9800 Savage Road 490 Fort Meade, MD 20755-6000 491 USA 493 Phone: +1 410 859-4464 494 Email: WANace@missi.ncsc.mil 496 James E. Zmuda 497 SPYRUS 498 2460 N. First Street 499 Suite 100 500 San Jose, CA 95131-1023 501 USA 503 Phone: +1 408 432-8180 504 Email: jzmuda@spyrus.com