[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04

Network Working Group                             William T. Whelan
Internet Draft                              Cabletron Systems, Inc.
expires in six months                             February 20, 1997

             PPP EAP RSA Public Key Authentication Protocol
                 <draft-ietf-pppext-eaprsa-04.txt>

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   February 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   February 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   February 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 non-discriminatory 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   February 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   February 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   February 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   February 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   February 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   February 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   February 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   February 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   February 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   February 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/