HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:38:05 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 09 Jan 1997 00:14:00 GMT ETag: "361ba1-66c3-32d43848" Accept-Ranges: bytes Content-Length: 26307 Connection: close Content-Type: text/plain Network Working Group William T. Whelan Internet Draft Cabletron Systems, Inc. expires in six months January 8, 1997 PPP EAP RSA Public Key Authentication Protocol Status of this Memo This document is a submission to the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. One of these is RSA Public Key Authentication. This document defines RSA Public Key Authentication Protocol within PPP EAP. Whelan Expires in six months [Page 1] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 1. Introduction In order to establish communications over a point-to- point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network- Layer Protocol phase. By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase. PPP Extensible Authentication Protocol (EAP) [2] allows for a number of authentication protocols including RSA Public Key Authentication Protocol. This document defines the PPP EAP RSA Public Key Authentication Protocol. The Link Establishment and Authentication phases, and the Authentication-Protocol Configuration Option are defined in The Point-to-Point Protocol (PPP) [1]. The Extensible Authentication protocol is defined in PPP Extensible Authentication Protocol (EAP) [2]. 1.1 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective required, means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective recommended, means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective optional, means that this item is one of an allowed set of alternatives. An implementation which does Whelan Expires in six months [Page 2] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.2 Terminology This document frequently uses the following terms: authenticator The end of the link requiring the authentication. The authenticator specifies use of RSA Public Key Authentication in the EAP-Request during Authentication phase. peer The other end of the point-to-point link; the end which is being authenticated by the authenticator. RSA key pair A pair of keys, each of which can be used to encode data or to reverse the encoding performed by the other. The two keys in the pair are known as the public and private keys. public key That key of a users key pair which is publicly known [3]. private key (secret key) That key of a users key pair which is known only by that user [3]. digital signature Encipherment, by the originator's secret key, of a compressed string of the relevant data to be transferred. The digital signature together with the plain data is sent to the recipient. This message is processed by the recipient to prove integrity. The digital signature mechanism also proves the authenticity of the originator and the unambiguous relationship between the originator and the data that was transferred [3]. A unique digital pattern produced by encoding a message digest of digital document using the signatory's private key. The signature can be produced only by someone holding the private key and cannot be applied to any but Whelan Expires in six months [Page 3] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 the intended digital document. The signature can be verified by anyone who has the signatory's public key. certificate The public keys of a user, together with some other information, rendered unforgeable by encipherment with the secret key of the certification authority which issued it [3]. certification authority (CA) An authority trusted by one or more users to create and assign certificates. Optionally the certification authority may create the users' keys [3]. 1.3 RSA Data Security, Inc. Licensing In a letter to the IESG Executive Secretary dated June 12, 1996, RSA Data Security, Inc. (RSADSI) stated that it is offering standard licensing terms to use RSA patent and software technology. By offering such licenses, RSADSI wishes to encourage the adoption of any and all standards which involve RSA technology. RSADSI's current standard patent licensing terms and conditions may be obtained directly from their web site or by contacting RSADSI. Whelan Expires in six months [Page 4] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 2. PPP EAP RSA Public Key Authentication The PPP Extensible Authentication Protocol is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP MAY be negotiated at Link Control Phase. EAP MAY then be used to select RSA Public Key Authentication at Authentication Phase. RSA Public Key Authentication Protocol is a challenge- response protocol based on unilateral two pass authentication as described in ISO/IEC 9798-3 [4]. The authenticator issues a challenge in the form of a Request packet. The peer MUST formulate a Response packet based on information in the Request packet as well as information only the peer knows (the peer's private key). The peer MUST also provide in its response its own public key as well as proof that it knows the corresponding private key. The Response MUST also contain the peer's certificate produced by a trusted Certification Authority. 1. After the Link Establishment phase is complete and Extensible Authentication Protocol is negotiated, the authenticator sends a Request packet to authenticate the peer. The Request packet has a type field specifying RSA Public Key Authentication plus some random data produced by the authenticator. 2. The peer sends a Response packet in reply to the Request. The exact contents of the Response is partially dependent upon the random data sent by the authenticator and partially dependent upon random data produced by the peer itself. Based on information contained in the Response packet, the authenticator ends the authentication phase with either a Success packet or a Failure packet. These packets are defined in PPP Extensible Authentication Protocol (EAP) [2]. Whelan Expires in six months [Page 5] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 3 PPP EAP RSA Public Key Authentication Packet Format A summary of the PPP EAP RSA Public Key Authentication Request/Response packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code 1 - Request 2 - Response Identifier The identifier field is one octet and aids in matching responses with requests. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Type 9 - RSA Public Key Authentication Data The format of the Data field is determined by the Code field. Whelan Expires in six months [Page 6] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 3.1 RSA Public Key Request Packet A summary of the PPP EAP RSA Public Key Authentication Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | ChallengeVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ChallengeVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ChallengeVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ChallengeVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |...ChallengeVal| +-+-+-+-+-+-+-+-+ Code 1 Identifier The identifier field is one octet and aids in matching responses with requests. The identifier field MUST be changed on each Request packet containing a different ChallengeVal. Length 21 Type 9 ChallengeVal The ChallengeVal is sixteen octets of data. It SHOULD be generated by the authenticator in such a way as to assure that it cannot be predicted by an attacker using a playback attack. The ChallengeVal will affect the Response packet sent by the peer. The ChallengeVal SHOULD be changed each time a Request is sent. This includes retransmitted Requests in instances where a previously transmitted Request or corresponding Response is lost. Changing the ChallengeVal on retransmissions is recommended so as to make a replay attack more difficult. Whelan Expires in six months [Page 7] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 3.2 RSA Public Key Response Packet A summary of the PPP EAP RSA Public Key Authentication Response packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Cert Type | Certificate... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ResponseVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ResponseVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ResponseVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ResponseVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChallengeVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ChallengeVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ChallengeVal... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...ChallengeVal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Len | Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 Identifier The identifier field is one octet and MUST match the Identifier field from the corresponding request. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, Certificate, Random Data, Echo Value, Signature Len, and Signature fields. Type 9 Whelan Expires in six months [Page 8] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 Cert Type This field identifies the type of certificate the peer is presenting. This is further defined in the following section. Certificate The peers certificate. This is further defined in the following section. ResponseVal The ResponseVal is a sixteen octet field. It SHOULD be generated by the peer in such a way as to assure that it cannot be predicted by an attacker. ChallengeVal The ChallengeVal is a sixteen octet field which MUST match the ChallengeVal which appeared in the corresponding Request packet. Signature Len The length in octets of the following signature. Signature The signature of the peer applied to the combination of ChallengeVal and ResponseVal. The peer MUST take the thirty-two octets formed by the ChallengeVal followed by the ResponseVal and produce an MD5 message digest. The 128 bit message digest MUST then be encrypted by the peer using the peer's private key. To verify this signature, the authenticator MUST decrypt the peer's signature using the peer's public key. The authenticator MUST also produce an MD5 message digest using the ChallengeVal followed by the ResponseVal. The two results MUST then be compared for equality. Whelan Expires in six months [Page 9] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 4 Certificates PPP EAP RSA Public Key Authentication allows for the use of different certificate formats. The Certificate Type field in the Response packet identifies the certificate format which follows. Two certificate formats and corresponding Certificate Types are currently defined for RSA public Key Authentication. A certificate MUST provide the RSA public key of the owner as well as some identification of the certificate owner. These information must be signed by a mutually trusted certifying authority. Certificate Type = 1 - DER encoded ISO-509 certificate. Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version must be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version must be v2 or v3 extensions [3] Extensions OPTIONAL -- If present, version must be v3 } } Version ::= INTEGER { v1(0), v2 (1), v3(2) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectKey BIT STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Whelan Expires in six months [Page 10] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 UniqueIdentifier ::= BIT STRING Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains a DER encoding of a value of type &ExtnType -- for the extensin object identified by extnId } Certificate Type = 255 - Simple Certificate. Simple Certificate Format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate Length |Identifier Len |Identifier Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Key Exp Length | Public Key Exponent... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Key Mod Length | Public Key Modulus... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Len | Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Certificate Length The length in octets of the entire certificate including all contiguous fields from the Certificate Length through the Signature fields. Identifier Len The total length in octets of the Identifier Type and Identification fields. Identifier Type This refers to the type of identification provided by the Identification field. 1 - Identification field contains a name. Whelan Expires in six months [Page 11] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 Identification Format depends upon the value in the Identifier Type. For Identifier Type = 1, this will be a name. The length of the name will depend upon the Identifier Len. The name will not be null terminated. Key Exp Len Length in octets of the Public Key Exponent field. Public Key Exponent The value of the RSA public key exponent in network byte order. Key Mod Len Length in octets of the Public Key Modulus field. Public Key Modulus The value of the RSA public key modulus in network byte order. Signature Len Length in octets of the Signature field. Signature This field contains the signature of a certifying authority applied to all contiguous fields within the certificate from the Identifier Len through the Public Key Modulus. To produce this signature, the certifying authority will produce an MD5 message digest of these fields then encrypt the result using its RSA private key. Whelan Expires in six months [Page 12] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 Security Considerations RSA Public Key Authentication is designed to allow an authenticator to obtain the public key from a peer and to authenticate the peer by requiring the peer to corroborate its identity by demonstrating its knowledge of its private key. The process is based on the unilateral two pass authentication described in ISO/IEC 9798-3 [4]. The use of random data fields within this protocol is necessary to prevent replay or interleaving attacks. Each entity (authenticator and peer) MUST provide unpredictable random data so as to assure an adequate level of security. Some techniques and considerations for generating suitably unpredictable random data are described in 'Randomness Recommendations for Security' [6]. RSA Public Key Authentication MUST provide for the following requirements: 1. The peer MUST possess a valid certificate signed by a mutually recognized certifying authority. 2. The peer MUST possess a valid private key corresponding to the public key in the peer's certificate. To assure these requirements are met, upon receipt of the EAP Response packet, the authenticator MUST verify the certification authority's signature within the certificate by decrypting using the certification authority's public key and compare the resulting information to the rest of the certificate. The authenticator MUST then obtain the peer's public key from the peer's certificate and use it to decrypt the peer's signature to verify it matches the MD5 digest of the two sets of random data. The set of recognized certifying authorities is implementation dependent. As a minimum, an authenticator MUST recognize any certifying authority which signed the authenticators certificate. Implementations MAY recognize certifying authorities from a hierarchical chain. If the peer's EAP Response satisfies all requirements, the authenticator MUST send an EAP Success packet. If the peer's EAP Response does not satisfy all requirements, the authenticator MUST send an EAP Failure packet and MAY take down the link. Whelan Expires in six months [Page 13] DRAFT PPP EAP RSA Public Key Authentication Protocol January 1997 References [1] Simpson, W. A., 'The Point to Point Protocol (PPP)', July 1994, RFC 1661. [2] Blunk, L. J. & Vollbrecht, J. R., 'PPP Extensible Authentication Protocol (EAP)', June 1996, work in progress. [3] CCITT Recommendation X.509, 'The Directory - Authentication Framework', 1988. [4] International Organization for Standardization and the International Electrotechnical Commission, ISO/IEC 9798-3, 'Information technology - Security techniques - Entity Authentication - mechanisms - Part 3: Entity authentication using a public key algorithm'. [5] Rivest, R., 'The MD5 Message Digest Algorithm', April 1992, RFC 1321. [6] Eastlake, D. E., Crocker, S. D., & Schiller, J. I., 'Randomness Recommendations for Security', December 1994, RFC 1750. Acknowledgments Dave Carrell, Jeff Schiller, and Fred Baker provided valuable feedback on earlier versions of this draft. Chair's Address The working group can be contacted via the current chair: Karl Fox Email: karl@ascend.com Author's Address Questions about this memo can also be directed to: William T. Whelan Cabletron Systems, Inc. bwhelan@nei.com Whelan Expires in six months [Page 14]