HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:38:00 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 23 Nov 1995 23:00:00 GMT ETag: "304d52-5bc2-30b4fcf0" Accept-Ranges: bytes Content-Length: 23490 Connection: close Content-Type: text/plain Network Working Group William T. Whelan Internet Draft Network Express, Inc. expires in six months November 13, 1995 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. 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 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 Configure- 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 originators 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 signatorys private key. The signature can be produced only by someone holding the private key and cannot be applied to any but the intended digital document. The signature can be verified by anyone who has the signatorys 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]. 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 peers 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 peers 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]. 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. 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. 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 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 produces this signature by taking the thirty- two octets formed by the ChallengeVal followed by the ResponseVal and producing an MD5 message digest. The 128 bit message digest is then encrypted by the peer using the peers private key. To verify this signature, the authenticator will decrypt the peers signature using the peers public key. The authenticator would also produce an MD5 message digest using the ChallengeVal followed by the ResponseVal. The two results would then be compared for equality. 4 Certificates For the purposes of this document, it is necessary that a certificate 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. Other applications may require additional information. It is desirable to be able to use any certificate formats providing the necessary information so as to not require owners to possess different certificate formats for different applications. Since it is impossible to predict in advance all the possible information one may ever want in a certificate, it was decided to provide for the support of multiple certificate types. One certificate type is described here. Compliance with PPP EAP RSA Public Key Authentication requires support of this certificate type. Support for other certificate types is optional. Certificate Type 1 - Mandatory 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. 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. 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 has been defined to prevent replay or interleaving attacks. Each entity (authenticator and peer) SHOULD provide unpredictable random data so as to assure an adequate level of security. 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 peers certificate. To assure these requirements are met, upon receipt of the EAP Response packet, the authenticator SHOULD verify the certification authoritys signature within the certificate by decrypting using the certification authoritys public key and compare the resulting information to the rest of the certificate. The authenticator SHOULD then obtain the peers public key from the peers certificate and use it to decrypt the peers signature to verify it matches 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 peers EAP Response satisfies all requirements, the authenticator MUST send an EAP Success packet. If the peers EAP Response does not satisfy all requirements, the authenticator MUST send an EAP Failure packet and MAY take down the link. 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)', July 1995, 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. 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: Fred Baker Cisco Systems, Inc. Email: fbaker@cisco.com Author's Addresses Questions about this memo can also be directed to: William T. Whelan bwhelan@nei.com