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

Versions: 00 01

Network Working Group                           William A. Nace(NSA)
Internet Draft                                  Peter Yee(SPYRUS)
expires in six months                           James E. Zmuda(SPYRUS)
                                                November 21st, 1997


             PPP EAP KEA Public Key Authentication Protocol
                   <draft-ietf-pppext-eapkea-01.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 of its peer before allowing Network Layer
        protocols to transmit over the link.




Nace, Yee & Zmuda        Expires in six months                  [Page 1]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


        PPP Extensible Authentication Protocol (EAP) [2] provides for a
        number of authentication mechanisms.  This document specifies
        yet another authentication mechanism that may be used within the
        EAP framework. This document defines the KEA Public Key
        Authentication Protocol within PPP EAP.  A side effect of KEA
        public key authentication is the creation of a session key for
        encryption of data on the PPP link.


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 Establish-
   ment phase.

   PPP Extensible Authentication Protocol (EAP) [2] allows for a number
   of authentication protocols including KEA Public Key Authentication
   Protocol.

   This document defines the PPP EAP KEA Public Key Authentication Pro-
   tocol.  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 specifi-
                  cation.

   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



Nace, Yee & Zmuda        Expires in six months                  [Page 2]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


                  circumstances to ignore this item, but the full impli-
                  cations 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 implementa-
                  tion 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 DSS Authentication in
                  the EAP-Request during Authentication phase.

   certificate    A certificate consists of the binding together of one
                  or more public key values and an identity.  This bind-
                  ing is effected through a digital signature which is
                  computed over the data containing both the public key
                  and the identity.  This signature is applied by a
                  "certification authority" who is recognized as issuing
                  this certificate on behalf of the entity identified in
                  the certificate. In this manner a recipient of this
                  certificate can determine the recognized public key of
                  the particular entity identified in the certificate.
                  This requires the recipient to, either directly or
                  indirectly, trust the authority who has issued this
                  certificate.

   certification authority (CA)
                  An authority trusted by one or more users to create
                  and assign certificates. [3].

   digital signature
                  In the DSS, a digital signature is produced by per-
                  forming the DSA signing operation with a private key
                  on the SHA-1 Hash value computed over the original
                  data to be signed.  The verification of this digital
                  signature requires the verifier to obtain the original
                  message, and the signature value, and the proper pub-
                  lic key value that is associated with the signer (see
                  certificates below).  The verifier then also computes
                  the SHA-1 Hash of the message data, and then perform a
                  computation whose inputs include this hash value, the



Nace, Yee & Zmuda        Expires in six months                  [Page 3]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


                  public key, and the signature value.  If the output of
                  this computation matches a particular part of the sig-
                  nature value produced by the signer, then the signa-
                  ture is verified.

   distinguished name
                  A unique heirarchical name.  Used in the certificate's
                  "subject" field to denote the entity associated with
                  the public key value(s) in the certificate[2]. Also
                  used in the certificate's "issuer" field to denote the
                  entity that issued this certificate.

   KEA key pair   A pair of related keys, used in the agreement of ses-
                  sion encryption key.  The two keys in the pair are
                  known as the public and private keys.  Knowledge of
                  the public key does not necessarily imply knowledge of
                  the private key of the pair.  This document frequently
                  uses the following terms:

   peer           The other end of the point-to-point link; the end
                  which is being authenticated by the authenticator.

   private key    That key of a key pair which is known only by that
                  user [3].

   public key     That key of a key pair which is publicly known [3].


2.  PPP EAP KEA 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 the KEA Public Key Authentication mechanisms at the Authenti-
   cation Phase.

   The KEA Public Key Authentication Protocol is a four pass request-
   response protocol involving both authentication and key derivation.
   Since a side effect of KEA authentication is the derivation of a ses-
   sion encryption key, only one party need initiate the KEA Public Key
   Authentication Protocol.  Liveness testing of the derived key indi-
   cates proper completion of the protocol.

   In order to ensure that the authentication protocol is performed only
   once, rules are introduced to handle the case where both parties ini-
   tiate the protocol.

   If one party transmits a KEA Request and the other a DSS Unilateral



Nace, Yee & Zmuda        Expires in six months                  [Page 4]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


   Request (or any other Request for that matter), then the second party
   may refuse the KEA Request by transmitting an LCP Terminate-Request.
   Should it be willing to honor the KEA Request, it will not terminate
   the link.  Rather it shall no longer expect a Response to its DSS
   Unilateral Request and shall transmit a KEA Response.

   If both parties transmit KEA Requests, the party transmitting the
   lesser value for the KEA Ra value shall no longer expect a Response
   to its Request, but shall instead generate a Response to the KEA
   Request containing the higher Ra value.

   The initiating party starts the protocol with a EAP KEA Request
   packet.  The peer MUST formulate a Response packet based on informa-
   tion 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
   a reference (i.e. the Distinguished Name in the Certificate) to its
   own certificate (the certificate containing the peer's public key),
   as well as proof that it knows the corresponding private key. The
   peer's certificate is assumed to have been obtained through other
   means.  One such means is the use of the Certificate Exchange Proto-
   col. The Certificate Exchange Protocol is defined as an extension to
   the PPP protocol suite. It is suggested as occurring during a new
   phase in between Link Control and Authentication. The Certificate
   Exchange Protocol is defined in [5].

   After the initial request and response, a second request/response
   exchange is used to test the liveness of the derived key.  Successful
   completion of this exchange is signaled to the peer by the sending of
   the EAP Success Packet.

   In detail, the steps in EAP KEA are:

   After the Link Establishment phase is complete and Extensible Authen-
   tication Protocol is negotiated, the authenticator sends a Request
   packet to authenticate the peer.  The Request packet has a type field
   specifying KEA Public Key Authentication plus the requester's certi-
   ficate reference and Ra value.

   2.             The peer sends a Response packet in reply to the
                  Request.  The Response packet contains the peer's cer-
                  tificate reference, Rb value, a wrapped Message
                  Encryption Key, an initialization vector, and a nonce,
                  The nonce is encrypted using the MEK.  Underlying the
                  transmission of this Response is the calculation by
                  the peer of a Token Encryption Key, generation and
                  wrapping of a Message Encryption Key, and encryption
                  of a random nonce using the Message Encryption Key.




Nace, Yee & Zmuda        Expires in six months                  [Page 5]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


   3.             The initiator then begins the KEA-Validate EAP
                  exchange by sending a Request containing another ini-
                  tialization vector, and, encrypted in the MEK, the
                  original nonce, incremented by one, and a new, random
                  nonce.  Again, underlying the transmission of this
                  Request is the calculation by the initiator of the
                  Token Encryption Key, the successful unwrapping of the
                  Message Encryption Key, and its use to decrypt the
                  peer's nonce.

   4.             The peer checks the KEA-Validate Request by decrypting
                  both nonces.  The original is checked to see that it
                  has been incremented, while the initiator's nonce is
                  incremented and encrypted and sent back in the KEA-
                  Validate Response.

   5.             The initiator checks the KEA Validate Response by
                  decrypting the nonce.  This returned nonce should
                  equal the nonce sent by the originator plus one.  If
                  the nonce matches as expected the initiator ends the
                  authentication phase by sending the peer a Success
                  packet.  Otherwise the peer is sent a Failure packet.
                  These packets are defined in PPP Extensible Authenti-
                  cation Protocol (EAP) [2].


3.  PPP KEA DSS Public Key Authentication Packet Format

   KEA authentication is performed using a derivative of the mechanism
   introduced in draft-ietf-cat-ftpkeasj-00.txt.

   The initiating party is identified as "A"; its peer as "B".  Four
   packets are exchanged in order to perform the authentication, first
   from A to B, and then from B to A, then repeating that sequence.

   Both the EAP Response and Request packets for the KEA and KEA-
   Validate Type have the following 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Code      |  Identifier   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |  Type Data ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 3.0-1 - The PPP EAP packet format

          Code



Nace, Yee & Zmuda        Expires in six months                  [Page 6]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


               1    (Request)
               2    (Response)

          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

               The Length field is two octets and indicates the length
               of the EAP Request and Response packets including the
               Code, Identifier, Length, Type, and Type Data fields.
               Octets in the packet outside the range of the Length
               field should be treated as Data Link Layer padding and
               should be ignored on reception.

          Type

               The Type field in the Request will carry the value 11
               (KEA) or 12 (KEA-VALIDATE).  The Type field in the
               Response SHOULD carry the corresponding value unless the
               peer wishes to send a Nak Type to indicate that it is
               incapable of handling KEA authentication.

          Type Data

               The contents and formats of the remainder of the packet
               differ for each of the four packet types: 1) KEA Request;
               2) KEA Response; 3) KEA-VALIDATE Request; and 4)
               KEA VALIDATE Response.


   The following sections define the format of the request and response.


3.1.  EAP KEA Request Packet

   The KEA Request packet is formatted as follows:

   This information is formatted in a length-value format.  No explicit
   type field is necessary because all fields are required and are in a
   determinate order.   The last element does not include a length field
   because its length can be determined from the overall length.  The
   EAP KEA Request packet has the following overall format:




Nace, Yee & Zmuda        Expires in six months                  [Page 7]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


      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      | ranA Length   |          ranA...              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ...ranA...                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ...ranA...                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
                                     .
                                     .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ...ranA...                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ...ranA                   |           DName...
      overall length.  The
   EAP KEA Response packet has the following overall format:


























Nace, Yee & Zmuda        Expires in six months                  [Page 9]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


      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      | ranB Length   |          ranB...              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ...ranB...                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
                                     .
                                     .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ...ranB                   |  wMEK Length  |    wMEK...    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ...wMEK...                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          ...wMEK...                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     ...wMEK                                   |   IV Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              IV...                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
                                     .
                                     .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           ...IV                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  EncNonce Len |                    EncNonce...                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
                                     .
                                     .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | ...EncNonce   |                     DName...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             Figure 3.0-3 - EAP KEA Response Packet format


          Code

               2    (Response)

          Identifier




Nace, Yee & Zmuda        Expires in six months                 [Page 10]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


               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 Request and Response packets including the
               Code, Identifier, Length, Type, RanB length field, RanB
               field, wMEK Length field, wMEK field, IV Length field, IV
               field, Encrypted Nonce Length field, Encrypted Nonce
               field, and DName field. Octets in the packet outside the
               range of the Length field should be treated as Data Link
               Layer padding and should be ignored on reception.

          Type

               The Type field in the Response will carry the value 11
               (KEA) unless the peer wishes to send a Nak Type to indi-
               cate that it is incapable of handling KEA authentication.

          ranB Length

               The Length of the ranB field in bytes is specified here.
               A single byte is used to represent this length.  For KEA
               this value is 128.

          ranB

               The value of the random number from the responder to the
               initiator.  For KEA this field is 128 bytes in length.

          wMEK Length

               The Length of the wMEK field in bytes is specified here.
               A single byte is used to represent this length.  For KEA
               and the default encryption algorithm this value is 12.

          wMEK

               The value of the TEK-wrapped MEK.  This MEK is a truly
               random key generated by the responder. It is wrapped in
               the TEK created during the KEA computation on the
               responder's side. This means this MEK can only be
               unwrapped by the entity that initiated this KEA exchange.
               For KEA and the default encryption algorithm this field
               is 12 bytes in length.

          IV Length



Nace, Yee & Zmuda        Expires in six months                 [Page 11]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


               The Length of the IV field in bytes is specified here. A
               single byte is used to represent this length.  For KEA
               and the default encryption algorithm this value is 24.

          IV

               The value of the IV.  This value is required to support
               the subsequent use of encryption algorithms that will use
               the MEK generated during this exchange.  This is the IV
               value to be fed into the decryptor on the Requestor's
               side.  For KEA and the default encryption algorithm this
               field is 24 bytes in length.

          Encrypted Nonce Length

               The Length of the Encrypted Nonce field in bytes is
               specified here. A single byte is used to represent this
               length.  For KEA and the default encryption algorithm
               this value is 24.

          Encrypted Nonce

               The value of the Encrypted Nonce.  This value is used      ...IVPrime...                                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
                                     .
                                     .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       ...IVPrime              |   Encrypted Nonces...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
                                     .
                                     .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    ...Encrypted Nonces...     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Figure 3.0-4 - EAP KEA-VALIDATE Request Packet format


          Code

               1    (Request)

          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
               EncryptedNonces value.

          Length

               The Length field is two octets and indicates the length
               of the EAP KEA-VALIDATE Request packet including the
               Code, Identifier, Length, Type, IVPrime length field,
               IVPrime field, and Encrypted Nonce fields. Octets in the
               packet outside the range of the Length field should be
               treated as Data Link Layer padding and should be ignored
               on reception.



Nace, Yee & Zmuda        Expires in six months                 [Page 13]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


          Type

               The Type field in the Request will carry the value 12
               (KEA-VALIDATE).

          IVPrime Length

               The Length of the IVPrime field in bytes is specified
               here. A single byte is used to represent this length.
               For KEA and the default encryption algorithm this value
               is 24.

          IVPrime

               The value of the IV from the Initiator to the peer.  This
               value is required to support the subsequent use of
               encryption algorithms that will use the MEK generated
               during this exchange.  This is the IV value to be fed
               into the decryptor on the Responder's side.  For KEA and
               the default encryption algorithm this field is 24 bytes
               in length.

          Encrypted Nonces Length

               The Length of the Encrypted Nonces field in bytes is
               specified here. A single byte is used to represent this
               length.  For KEA and the default encryption algorithm
               this value is 40.

          Encrypted Nonces

               The value of the Encrypted Nonces.  There are two values
               which are concatenated together and encrypted (with the
               current MEK) here.  The first is the number the Requestor
               forms when he takes the Nonce value that the Responder
               sent over in the previous KEA Response and adds one to
               it.  The second value in this field is the NoncePrime
               value, or the random value chosen by the Requestor.  The
               Requestor expects the Responder to increment this value
               by one and send this new value of NoncePrime+1 back
               (encrypted in the MEK) in the KEA-VALIDATE Response.  For
               KEA and the default encryption algorithm these two values
               together are 40 bytes in length.


3.4.  EAP KEA-VALIDATE Response Packet

The KEA-VALIDATE Response packet is formatted as follows:



Nace, Yee & Zmuda        Expires in six months                 [Page 14]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


This information is formatted in a length-value format.  No explicit
type field is necessary because all fields are required and are in a
determinate order.   The last element does not include a length field
because its length can be determined from the overall length.  The EAP
KEA-VALIDATE Response packet has the following overall 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Code      |  Identifier   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |          Encrypted NoncePrime                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               ...Encrypted NoncePrime...                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
                                     .
                                     .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              ...Encrypted NoncePrime...                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      ...      |
     +-+-+-+-+-+-+-+-+
         Figure 3.0-5 - EAP KEA-VALIDATE Response Packet format


          Code

               2    (Response)

          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 KEA-VALIDATE Request packet including the
               Code, Identifier, Length, Type, and Encrypted NoncePrime
               fields.  Octets in the packet outside the range of the
               Length field should be treated as Data Link Layer padding
               and should be ignored on reception.

          Type

               The Type field in the Response will carry the value 12
               (KEA-VALIDATE).



Nace, Yee & Zmuda        Expires in six months                 [Page 15]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


          Encrypted NoncePrime

               The value of the Encrypted NoncePrime.  This value is
               formed by the Responder by taking the NoncePrime value
               which he received in the KEA-VALIDATE request and sending
               it back encrypted in the same MEK, after being incre-
               mented by one.  This completes the two-way key liveness
               checks and the Requestor will upon checking this value,
               proceed to a successful authentication state and sending
               over a EAP success packet to the peer.


4.  PPP EAP KEA and KEA-VALIDATE Protocol Processing

   The operation of the complete PPP KEA protocol, including the two
   steps of Authentication/Key Generation and Liveness Checking are both
   show.  The first is performed by the PPP KEA protocol and the second
   by the EAP KEA-VALIDATE protocol.

   Figure 4.0-1 depicts the operation of the EAP KEA and KEA-VALIDATE
   protocol.  In this and the following figures depicting PDU exchanges,
   the curly braces ({, }) denote items in Length-Value representation.



   Side:       A                 B

   Initiator               Recipient

   =>EAP Request (ID1, KEA, {certA, ra})

               <= EAP Response (ID1,
                                KEA,
                                {certB, rb, wMEK, iv,
                                ENCRYPTMEK(eNonce)}))

   =>EAP Request (ID2,
          KEA-Validate,
          { ivPrime,ENCRYPTMEK(eNonce+1,eNoncePrime)})

               <= EAP Response (ID2,
                                KEA-Validate,
                                {ENCRYPTMEK(eNoncePrime+1)}))

   => EAP Success Packet(ID3)

      Figure 4.0-1  PPP EAP KEA and KEA-VALIDATE Protocol processing




Nace, Yee & Zmuda        Expires in six months                 [Page 16]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


Security Considerations

   This memo defines a method for using EAP to perform Strong authenti-
   cation and key generation of/with a peer using the KEA Key Exchange
   and authentication algorithm.

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]  Federal Information Processing Standards Publication,
           FIPS Pub 196, 'Entity Authentication using Public
           Key Cryptography', February 18, 1997.

      [5]  Nace, William, and Zmuda, J., 'The PPP Certificate
           Exchange Protocol', November 1997, work in progress.


Acknowledgements:

   This work is based largely on EAP.  The authors would like to thank
   John Vollbrecht of Merit specifically for his help in understanding
   the intention of the EAP Internet Draft.  The authors would also like
   to thank Paul Amaranth of Oakland University for his EAP implementa-
   tion. Thanks also are due to Bill Whelan of Network Express for his
   Internet Draft showing a worked example of the use of EAP for public
   key based authentication.  And thanks go to Russ Housley for his
   helpful comments on earlier versions of this memo.  And thanks
   finally to Bill Simpson for the standard PPP spec boilerplate from
   which we have borrowed heavily.

Chair's  Address:

   The working group can be contacted via the current
   chair:

   Karl Fox
   Ascend Communications, Inc.

   Email: karl@ascend.com



Nace, Yee & Zmuda        Expires in six months                 [Page 17]


DRAFT        PPP EAP KEA Public Key Authentication ProtocolNovember 1997


Author's  Address:

   Questions about this memo can also be directed to:

      DIRNSA
      Attn: X22 (W. Nace)
      9800 Savage Road
      Fort Meade, MD 20755-6000
      USA

      Phone: +1 410 859-4464
      Email: WANace@missi.ncsc.mil

      Peter Yee
      SPYRUS
      2460 N. First Street
      Suite 100
      San Jose, CA 95131-1023
      USA

      Phone: +1 408 432-8180
      Email: pyee@spyrus.com

      James E. Zmuda
      SPYRUS
      2460 N. First Street
      Suite 100
      San Jose, CA 95131-1023
      USA

      Phone: +1 408 432-8180
      Email: jzmuda@spyrus.com



















Nace, Yee & Zmuda        Expires in six months                 [Page 18]


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