home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-eaprsa-03.txt < prev    next >
Text File  |  1997-01-08  |  26KB  |  774 lines
  1.  
  2.  
  3. Network Working Group                             William T. Whelan
  4. Internet Draft                              Cabletron Systems, Inc.
  5. expires in six months                               January 8, 1997
  6.  
  7.              PPP EAP RSA Public Key Authentication Protocol
  8.                  <draft-ietf-pppext-eaprsa-03.txt>
  9.  
  10. Status of this Memo
  11.  
  12.       This document is a submission to the Point-to-Point
  13.       Protocol Extensions Working Group of the Internet
  14.       Engineering Task Force (IETF).  Comments should be
  15.       submitted to the ietf-ppp@merit.edu mailing list.
  16.  
  17.       Distribution of this memo is unlimited.
  18.  
  19.       This document is an Internet-Draft.  Internet-Drafts
  20.       are working documents of the Internet Engineering Task
  21.       Force (IETF), its areas, and its working groups.  Note
  22.       that other groups may also distribute working documents
  23.       as Internet-Drafts.
  24.  
  25.       Internet-Drafts are draft documents valid for a maximum
  26.       of six months and may be updated, replaced, or
  27.       obsoleted by other documents at any time.  It is not
  28.       appropriate to use Internet-Drafts as reference
  29.       material or to cite them other than as 'work in
  30.       progress.'
  31.  
  32.       To learn the current status of any Internet-Draft,
  33.       please check the '1id-abstracts.txt' listing contained
  34.       in the Internet-Drafts Shadow Directories on
  35.       ds.internic.net (US East Coast), nic.nordu.net
  36.       (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
  37.       (Pacific Rim).
  38.  
  39. Abstract
  40.  
  41.       The Point-to-Point Protocol (PPP) [1] provides a
  42.       standard method for transporting multi-protocol
  43.       datagrams over point-to-point links
  44.  
  45.       PPP also defines an extensible Link Control Protocol,
  46.       which allows negotiation of an Authentication Protocol
  47.       for authentication its peer before allowing Network
  48.       Layer protocols to transmit over the link.
  49.  
  50.       PPP Extensible Authentication Protocol (EAP) [2]
  51.       provides for a number of authentication mechanisms.
  52.       One of these is RSA Public Key Authentication.  This
  53.       document defines RSA Public Key Authentication Protocol
  54.       within PPP EAP.
  55.  
  56. Whelan                 Expires in six months                   [Page 1]
  57. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  58.  
  59.  
  60. 1.   Introduction
  61.  
  62.       In order to establish communications over a point-to-
  63.       point link, each end of the PPP link must first send
  64.       LCP packets to configure the data link during Link
  65.       Establishment phase.  After the link has been
  66.       established, PPP provides for an optional
  67.       Authentication phase before proceeding to the Network-
  68.       Layer Protocol phase.
  69.  
  70.       By default, authentication is not mandatory.  If
  71.       authentication of the link is desired, an
  72.       implementation MUST specify the Authentication-Protocol
  73.       Configuration Option during Link Establishment phase.
  74.  
  75.       PPP Extensible Authentication Protocol (EAP) [2] allows
  76.       for a number of authentication protocols including RSA
  77.       Public Key Authentication Protocol.
  78.  
  79.       This document defines the PPP EAP RSA Public Key
  80.       Authentication Protocol.  The Link Establishment and
  81.       Authentication phases, and the Authentication-Protocol
  82.       Configuration Option are defined in The Point-to-Point
  83.       Protocol (PPP) [1].  The Extensible Authentication
  84.       protocol is defined in PPP Extensible Authentication
  85.       Protocol (EAP) [2].
  86.  
  87. 1.1  Specification of Requirements
  88.  
  89.       In this document, several words are used to signify the
  90.       requirements of the specification.  These words are
  91.       often capitalized.
  92.  
  93.      MUST      This word, or the adjective required, means
  94.                that the definition is an absolute
  95.                requirement of the specification.
  96.  
  97.      MUST NOT  This phrase means that the definition is an
  98.                absolute prohibition of the specification.
  99.  
  100.      SHOULD    This word, or the adjective recommended,
  101.                means that there may exist valid reasons in
  102.                particular circumstances to ignore this item,
  103.                but the full implications must be understood
  104.                and carefully weighed before choosing a
  105.                different course.
  106.  
  107.      MAY       This word, or the adjective optional, means
  108.                that this item is one of an allowed set of
  109.                alternatives.  An implementation which does
  110.  
  111. Whelan                 Expires in six months                   [Page 2]
  112. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  113.  
  114.  
  115.                not include this option MUST be prepared to
  116.                interoperate with another implementation
  117.                which does include the option.
  118.  
  119. 1.2  Terminology
  120.  
  121.       This document frequently uses the following terms:
  122.  
  123.       authenticator   The end of the link requiring the
  124.                      authentication.  The authenticator
  125.                      specifies use of RSA Public Key
  126.                      Authentication in the EAP-Request
  127.                      during Authentication phase.
  128.  
  129.       peer            The other end of the point-to-point
  130.                      link; the end which is being
  131.                      authenticated by the authenticator.
  132.  
  133.       RSA key pair    A pair of keys, each of which can be
  134.                      used to encode data or to reverse the
  135.                      encoding performed by the other.  The
  136.                      two keys in the pair are known as the
  137.                      public and private keys.
  138.  
  139.       public key      That key of a users key pair which is
  140.                      publicly known [3].
  141.  
  142.       private key (secret key)  That key of a users key
  143.                      pair which is known only by that user
  144.                      [3].
  145.  
  146.       digital signature    Encipherment, by the originator's
  147.                      secret key, of a compressed string of
  148.                      the relevant data to be transferred.
  149.                      The digital signature together with
  150.                      the plain data is sent to the
  151.                      recipient.  This message is processed
  152.                      by the recipient to prove integrity.
  153.                      The digital signature mechanism also
  154.                      proves the authenticity of the
  155.                      originator and the unambiguous
  156.                      relationship between the originator
  157.                      and the data that was transferred [3].
  158.  
  159.                      A unique digital pattern produced by
  160.                      encoding a message digest of digital
  161.                      document using the signatory's private
  162.                      key.  The signature can be produced
  163.                      only by someone holding the private
  164.                      key and cannot be applied to any but
  165.  
  166. Whelan                 Expires in six months                   [Page 3]
  167. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  168.  
  169.  
  170.                      the intended digital document.  The
  171.                      signature can be verified by anyone
  172.                      who has the signatory's public key.
  173.  
  174.       certificate     The public keys of a user, together
  175.                      with some other information, rendered
  176.                      unforgeable by encipherment with the
  177.                      secret key of the certification
  178.                      authority which issued it [3].
  179.  
  180.       certification authority (CA)   An authority trusted by
  181.                      one or more users to create and assign
  182.                      certificates.  Optionally the
  183.                      certification authority may create the
  184.                      users' keys [3].
  185.  
  186.  
  187. 1.3  RSA Data Security, Inc. Licensing
  188.  
  189.      In a letter to the IESG Executive Secretary dated June 12,
  190.      1996, RSA Data Security, Inc. (RSADSI) stated that it is
  191.      offering standard licensing terms to use RSA patent and
  192.      software technology.  By offering such licenses, RSADSI
  193.      wishes to encourage the adoption of any and all standards
  194.      which involve RSA technology.
  195.  
  196.      RSADSI's current standard patent licensing terms and conditions
  197.      may be obtained directly from their web site or by contacting
  198.      RSADSI.
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Whelan                 Expires in six months                   [Page 4]
  222. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  223.  
  224.  
  225. 2.   PPP EAP RSA Public Key Authentication
  226.  
  227.       The PPP Extensible Authentication Protocol is a general
  228.       protocol for PPP authentication which supports multiple
  229.       authentication mechanisms.  EAP MAY be negotiated at
  230.       Link Control Phase.  EAP MAY then be used to select RSA
  231.       Public Key Authentication at Authentication Phase.
  232.  
  233.       RSA Public Key Authentication Protocol is a challenge-
  234.       response protocol based on unilateral two pass
  235.       authentication as described in ISO/IEC 9798-3 [4].  The
  236.       authenticator issues a challenge in the form of a
  237.       Request packet.  The peer MUST formulate a Response
  238.       packet based on information in the Request packet as
  239.       well as information only the peer knows (the peer's
  240.       private key).  The peer MUST also provide in its
  241.       response its own public key as well as proof that it
  242.       knows the corresponding private key.  The Response MUST
  243.       also contain the peer's certificate produced by a
  244.       trusted Certification Authority.
  245.  
  246.       1.   After the Link Establishment phase is complete and
  247.           Extensible Authentication Protocol is negotiated,
  248.            the authenticator sends a Request packet to
  249.            authenticate the peer.  The Request packet has a
  250.            type field specifying RSA Public Key
  251.            Authentication plus some random data produced by
  252.            the authenticator.
  253.  
  254.       2.   The peer sends a Response packet in reply to the
  255.            Request.  The exact contents of the Response is
  256.            partially dependent upon the random data sent by
  257.            the authenticator and partially dependent upon
  258.            random data produced by the peer itself.
  259.  
  260.       Based on information contained in the Response packet,
  261.       the authenticator ends the authentication phase with
  262.       either a Success packet or a Failure packet.  These
  263.       packets are defined in PPP Extensible Authentication
  264.       Protocol (EAP) [2].
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276. Whelan                 Expires in six months                   [Page 5]
  277. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  278.  
  279.  
  280. 3    PPP EAP RSA Public Key Authentication Packet Format
  281.  
  282.       A summary of the PPP EAP RSA Public Key Authentication
  283.       Request/Response packet format is shown below.  The
  284.       fields are transmitted from left to right.
  285.  
  286.       0                   1                   2                   3
  287.       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
  288.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  289.      |     Code      |   Identifier  |            Length             |
  290.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  291.      |     Type      |     Data ...
  292.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  293.  
  294.       Code
  295.            1 - Request
  296.            2 - Response
  297.  
  298.       Identifier
  299.            The identifier field is one octet and aids in
  300.            matching responses with requests.
  301.  
  302.       Length
  303.            The Length field is two octets and indicates the
  304.            length of the EAP packet including the Code,
  305.            Identifier, Length, Type, and Data fields.  Octets
  306.            outside the range of the Length field should be
  307.            treated as Data Link Layer padding and should be
  308.            ignored on reception.
  309.  
  310.       Type
  311.            9 - RSA Public Key Authentication
  312.  
  313.       Data
  314.            The format of the Data field is determined by the
  315.            Code field.
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331. Whelan                 Expires in six months                   [Page 6]
  332. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  333.  
  334.  
  335. 3.1  RSA Public Key Request Packet
  336.  
  337.       A summary of the PPP EAP RSA Public Key Authentication
  338.       Request packet format is shown below.  The fields are
  339.       transmitted from left to right.
  340.  
  341.       0                   1                   2                   3
  342.       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
  343.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  344.      |     Code      |   Identifier  |            Length             |
  345.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  346.      |     Type      |   ChallengeVal...                             |
  347.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  348.      |     ...ChallengeVal...                                        |
  349.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  350.      |     ...ChallengeVal...                                        |
  351.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  352.      |     ...ChallengeVal...                                        |
  353.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  354.      |...ChallengeVal|
  355.      +-+-+-+-+-+-+-+-+
  356.  
  357.       Code
  358.            1
  359.  
  360.       Identifier
  361.            The identifier field is one octet and aids in
  362.            matching responses with requests.  The identifier
  363.            field MUST be changed on each Request packet
  364.            containing a different ChallengeVal.
  365.  
  366.       Length
  367.            21
  368.  
  369.       Type
  370.            9
  371.  
  372.       ChallengeVal
  373.            The ChallengeVal is sixteen octets of data.  It
  374.            SHOULD be generated by the authenticator in such a
  375.            way as to assure that it cannot be predicted by an
  376.            attacker using a playback attack.  The
  377.            ChallengeVal will affect the Response packet sent
  378.            by the peer.  The ChallengeVal SHOULD be changed
  379.            each time a Request is sent.  This includes
  380.            retransmitted Requests in instances where a
  381.            previously transmitted Request or corresponding
  382.            Response is lost.  Changing the ChallengeVal on
  383.            retransmissions is recommended so as to make a
  384.            replay attack more difficult.
  385.  
  386. Whelan                 Expires in six months                   [Page 7]
  387. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  388.  
  389.  
  390. 3.2  RSA Public Key Response Packet
  391.  
  392.       A summary of the PPP EAP RSA Public Key Authentication
  393.       Response packet format is shown below.  The fields are
  394.       transmitted from left to right.
  395.  
  396.       0                   1                   2                   3
  397.       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
  398.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  399.      |     Code      |   Identifier  |            Length             |
  400.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  401.      |     Type      |   Cert Type   |   Certificate...
  402.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  403.      |     ResponseVal...                                            |
  404.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  405.      |     ...ResponseVal...                                         |
  406.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  407.      |     ...ResponseVal...                                         |
  408.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  409.      |     ...ResponseVal...                                         |
  410.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  411.      |     ChallengeVal...                                           |
  412.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  413.      |     ...ChallengeVal...                                        |
  414.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  415.      |     ...ChallengeVal...                                        |
  416.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.      |     ...ChallengeVal                                           |
  418.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.      | Signature Len | Signature...
  420.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.  
  422.       Code
  423.            2
  424.  
  425.       Identifier
  426.            The identifier field is one octet and MUST match
  427.            the Identifier field from the corresponding
  428.            request.
  429.  
  430.       Length
  431.            The Length field is two octets and indicates the
  432.            length of the EAP packet including the Code,
  433.            Identifier, Length, Type, Certificate, Random
  434.            Data, Echo Value, Signature Len, and Signature
  435.            fields.
  436.  
  437.       Type
  438.            9
  439.  
  440.  
  441. Whelan                 Expires in six months                   [Page 8]
  442. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  443.  
  444.  
  445.       Cert Type
  446.            This field identifies the type of certificate the
  447.            peer is presenting.  This is further defined in
  448.            the following section.
  449.  
  450.       Certificate
  451.            The peers certificate.  This is further defined
  452.            in the following section.
  453.  
  454.       ResponseVal
  455.            The ResponseVal is a sixteen octet field.  It
  456.            SHOULD be generated by the peer in such a way as
  457.            to assure that it cannot be predicted by an
  458.            attacker.
  459.  
  460.       ChallengeVal
  461.            The ChallengeVal is a sixteen octet field which
  462.            MUST match the ChallengeVal which appeared in the
  463.            corresponding Request packet.
  464.  
  465.       Signature Len
  466.            The length in octets of the following signature.
  467.  
  468.       Signature
  469.            The signature of the peer applied to the
  470.            combination of ChallengeVal and ResponseVal.  The
  471.            peer MUST take the thirty-two octets formed by
  472.            the ChallengeVal followed by the ResponseVal and
  473.            produce an MD5 message digest.  The 128 bit
  474.            message digest MUST then be encrypted by the peer
  475.            using the peer's private key.
  476.  
  477.            To verify this signature, the authenticator
  478.            MUST decrypt the peer's signature using the peer's
  479.            public key.  The authenticator MUST also produce
  480.            an MD5 message digest using the ChallengeVal
  481.            followed by the ResponseVal.  The two results
  482.            MUST then be compared for equality.
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496. Whelan                 Expires in six months                   [Page 9]
  497. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  498.  
  499.  
  500. 4    Certificates
  501.  
  502.       PPP EAP RSA Public Key Authentication allows for the use
  503.       of different certificate formats.  The Certificate Type
  504.       field in the Response packet identifies the certificate
  505.       format which follows.  Two certificate formats and
  506.       corresponding Certificate Types are currently defined
  507.       for RSA public Key Authentication.
  508.  
  509.       A certificate MUST provide the RSA public key of the
  510.       owner as well as some identification of the certificate
  511.       owner.  These information must be signed by a mutually
  512.       trusted certifying authority.
  513.  
  514.  
  515.       Certificate Type = 1 - DER encoded ISO-509 certificate.
  516.  
  517.  
  518.       Certificate ::= SIGNED { SEQUENCE {
  519.           version                 [0] Version DEFAULT v1,
  520.           serialNumber            CertificateSerialNumber,
  521.           signature               AlgorithmIdentifier,
  522.           issuer                  Name,
  523.           validity                Validity,
  524.           subjectPublicKeyInfo    SubjectPublicKeyInfo,
  525.           issuerUniqueID          [1] IMPLICIT UniqueIdentifier OPTIONAL,
  526.                                           -- If present, version must be v2 or v3
  527.           subjectUniqueID         [2] IMPLICIT UniqueIdentifier OPTIONAL,
  528.                                           -- If present, version must be v2 or v3
  529.           extensions              [3] Extensions OPTIONAL
  530.                                           -- If present, version must be v3 } }
  531.  
  532.       Version ::= INTEGER { v1(0), v2 (1), v3(2) }
  533.  
  534.       CertificateSerialNumber ::= INTEGER
  535.  
  536.       Validity ::= SEQUENCE {
  537.           notBefore               UTCTime,
  538.           notAfter                UTCTime
  539.       }
  540.  
  541.       SubjectPublicKeyInfo ::= SEQUENCE {
  542.           algorithm               AlgorithmIdentifier,
  543.           subjectKey              BIT STRING
  544.       }
  545.  
  546.       AlgorithmIdentifier ::= SEQUENCE {
  547.           algorithm               OBJECT IDENTIFIER,
  548.           parameters              ANY DEFINED BY algorithm OPTIONAL
  549.       }
  550.  
  551. Whelan                 Expires in six months                  [Page 10]
  552. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  553.  
  554.  
  555.  
  556.       UniqueIdentifier ::= BIT STRING
  557.  
  558.  
  559.       Extension ::= SEQUENCE {
  560.           extnId                  EXTENSION.&id ({ExtensionSet}),
  561.           critical                BOOLEAN DEFAULT FALSE,
  562.           extnValue               OCTET STRING
  563.           -- contains a DER encoding of a value of type &ExtnType
  564.           -- for the extensin object identified by extnId
  565.       }
  566.  
  567.  
  568.       Certificate Type = 255 - Simple Certificate.
  569.  
  570.  
  571.       Simple Certificate Format:
  572.  
  573.       0                   1                   2                   3
  574.       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
  575.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  576.      |     Certificate Length        |Identifier Len |Identifier Type|
  577.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  578.      |     Identification...
  579.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  580.      |Key Exp Length |   Public Key Exponent...
  581.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  582.      |Key Mod Length |   Public Key Modulus...
  583.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  584.      | Signature Len |   Signature...
  585.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  586.  
  587.       Certificate Length
  588.              The length in octets of the entire certificate
  589.              including all contiguous fields from the
  590.              Certificate Length through the Signature fields.
  591.  
  592.       Identifier Len
  593.              The total length in octets of the Identifier Type
  594.              and Identification fields.
  595.  
  596.       Identifier Type
  597.              This refers to the type of identification provided
  598.              by the Identification field.
  599.  
  600.              1 - Identification field contains a name.
  601.  
  602.  
  603.  
  604.  
  605.  
  606. Whelan                 Expires in six months                  [Page 11]
  607. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  608.  
  609.  
  610.       Identification
  611.              Format depends upon the value in the Identifier
  612.              Type.  For Identifier Type = 1, this will be a
  613.              name.  The length of the name will depend upon the
  614.              Identifier Len.  The name will not be null
  615.              terminated.
  616.  
  617.       Key Exp Len
  618.              Length in octets of the Public Key Exponent field.
  619.  
  620.  
  621.       Public Key Exponent
  622.              The value of the RSA public key exponent in
  623.              network byte order.
  624.  
  625.       Key Mod Len
  626.              Length in octets of the Public Key Modulus field.
  627.  
  628.       Public Key Modulus
  629.              The value of the RSA public key modulus in network
  630.              byte order.
  631.  
  632.       Signature Len
  633.              Length in octets of the Signature field.
  634.  
  635.       Signature
  636.              This field contains the signature of a certifying
  637.              authority applied to all contiguous fields within
  638.              the certificate from the Identifier Len through
  639.              the Public Key Modulus.  To produce this
  640.              signature, the certifying authority will produce
  641.              an MD5 message digest of these fields then encrypt
  642.              the result using its RSA private key.
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661. Whelan                 Expires in six months                  [Page 12]
  662. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  663.  
  664.  
  665.       Security Considerations
  666.  
  667.       RSA Public Key Authentication is designed to allow an
  668.       authenticator to obtain the public key from a peer and
  669.       to authenticate the peer by requiring the peer to
  670.       corroborate its identity by demonstrating its knowledge
  671.       of its private key.  The process is based on the
  672.       unilateral two pass authentication described in ISO/IEC
  673.       9798-3 [4].
  674.  
  675.       The use of random data fields within this protocol is
  676.       necessary to prevent replay or interleaving attacks.
  677.       Each entity (authenticator and peer) MUST provide
  678.       unpredictable random data so as to assure an adequate
  679.       level of security.  Some techniques and considerations
  680.       for generating suitably unpredictable random data are
  681.       described in 'Randomness Recommendations for Security' [6].
  682.  
  683.       RSA Public Key Authentication MUST provide for the
  684.       following requirements:
  685.  
  686.       1. The peer MUST possess a valid certificate signed by
  687.           a mutually recognized certifying authority.
  688.  
  689.       2. The peer MUST possess a valid private key corresponding
  690.           to the public key in the peer's certificate.
  691.  
  692.       To assure these requirements are met, upon receipt of
  693.       the EAP Response packet, the authenticator MUST
  694.       verify the certification authority's signature within
  695.       the certificate by decrypting using the certification
  696.       authority's public key and compare the resulting
  697.       information to the rest of the certificate.  The
  698.       authenticator MUST then obtain the peer's public key
  699.       from the peer's certificate and use it to decrypt the
  700.       peer's signature to verify it matches the MD5 digest
  701.      of the two sets of random data.
  702.  
  703.       The set of recognized certifying authorities is
  704.       implementation dependent.  As a minimum, an
  705.       authenticator MUST recognize any certifying authority
  706.       which signed the authenticators certificate.
  707.       Implementations MAY recognize certifying authorities
  708.       from a hierarchical chain.
  709.  
  710.       If the peer's EAP Response satisfies all requirements,
  711.       the authenticator MUST send an EAP Success packet.  If
  712.       the peer's EAP Response does not satisfy all
  713.       requirements, the authenticator MUST send an EAP
  714.       Failure packet and MAY take down the link.
  715.  
  716. Whelan                 Expires in six months                  [Page 13]
  717. DRAFT   PPP EAP RSA Public Key Authentication Protocol    January 1997
  718.  
  719.  
  720. References
  721.  
  722.       [1]  Simpson, W. A., 'The Point to Point Protocol
  723.              (PPP)', July 1994, RFC 1661.
  724.  
  725.       [2]  Blunk, L. J. & Vollbrecht, J. R., 'PPP Extensible
  726.              Authentication Protocol (EAP)', June 1996, work in
  727.              progress.
  728.  
  729.       [3]  CCITT Recommendation X.509, 'The Directory -
  730.              Authentication Framework', 1988.
  731.  
  732.       [4]  International Organization for Standardization and
  733.              the International Electrotechnical Commission,
  734.              ISO/IEC 9798-3, 'Information technology - Security
  735.              techniques - Entity Authentication - mechanisms -
  736.              Part 3: Entity authentication using a public key
  737.              algorithm'.
  738.  
  739.       [5]  Rivest, R., 'The MD5 Message Digest Algorithm',
  740.              April 1992, RFC 1321.
  741.  
  742.       [6]  Eastlake, D. E., Crocker, S. D., & Schiller, J. I.,
  743.              'Randomness Recommendations for Security', December
  744.              1994, RFC 1750.
  745.  
  746. Acknowledgments
  747.  
  748.       Dave Carrell, Jeff Schiller, and Fred Baker provided
  749.       valuable feedback on earlier versions of this draft.
  750.  
  751. Chair's Address
  752.  
  753.       The working group can be contacted via the current
  754.       chair:
  755.  
  756.       Karl Fox
  757.  
  758.       Email: karl@ascend.com
  759.  
  760.  
  761. Author's Address
  762.  
  763.       Questions about this memo can also be directed to:
  764.  
  765.       William T. Whelan
  766.      Cabletron Systems, Inc.
  767.       bwhelan@nei.com
  768.  
  769.  
  770.  
  771. Whelan                 Expires in six months                  [Page 14]
  772.  
  773.  
  774.