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

Versions: 00 01

Individual Contribution                                  R. Berrendonner
Internet-Draft                                               H. Chabanne
Expires: May 1, 2002                                          SAGEM S.A.
                                                        October 31, 2001


             MAKE : Mutual Authentication with Key Exchange
               draft-berrendo-chabanne-pppext-eapmake-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 1, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo describes EAP-MAKE protocol, an authentication protocol
   based on EAP which emphasizes on simplicity and scalability.
   Authentication is provided through a mechanism derived from the
   Diffie-Hellman scheme, and it is possible to derive and check a
   common symmetric key for the purpose of privacy.  Scalability is
   provided by the underlying support of legacy PKI systems.








Berrendonner & Chabanne    Expires May 1, 2002                  [Page 1]


Internet-Draft                    MAKE                      October 2001


Table of Contents

   1.  Document Conventions . . . . . . . . . . . . . . . . . . . . .  3
   2.  PPP EAP MAKE Mutual Authentication Protocol  . . . . . . . . .  4
   2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2 Prerequisites  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.3 PPP EAP MAKE protocol in a nutshell  . . . . . . . . . . . . .  5
   3.  MAKE key derivation scheme . . . . . . . . . . . . . . . . . .  8
   4.  EAP MAKE Packet Format . . . . . . . . . . . . . . . . . . . .  9
   4.1 EAP MAKE1 Request Packet . . . . . . . . . . . . . . . . . . . 11
   4.2 EAP MAKE1 Response Packet  . . . . . . . . . . . . . . . . . . 12
   4.3 MAKE2 Request Packet . . . . . . . . . . . . . . . . . . . . . 14
   4.4 MAKE2 Response Packet  . . . . . . . . . . . . . . . . . . . . 16
   4.5 PPP EAP MAKE and MAKE-VALIDATE Protocol Processing . . . . . . 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22































Berrendonner & Chabanne    Expires May 1, 2002                  [Page 2]


Internet-Draft                    MAKE                      October 2001


1. Document Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.














































Berrendonner & Chabanne    Expires May 1, 2002                  [Page 3]


Internet-Draft                    MAKE                      October 2001


2. PPP EAP MAKE Mutual Authentication Protocol

2.1 Introduction

   This document describes the PPP EAP MAKE protocol where MAKE stands
   for Mutual Authentication protocol with Key Exchange.

   PPP EAP MAKE protocol borrows a lot to "PPP EAP KEA Public Key
   Authentication Protocol" (see Appendix A), namely :

   o  both protocols are aimed at defining an authentication mechanism
      within PPP EAP [1] and both permits the creation of a session key
      for encryption of data on the PPP link,

   o  PPP EAP MAKE protocol takes the two 2-pass EAP request-response of
      PPP EAP KEA and their format for its own, in the sequel, the first
      2-pass is called EAP MAKE1 and the second one EAP MAKE2,

   o  the underlying cryptographic property which allows mutual
      authentication is essentially the same and consists in supplying
      the prover and the verifier with a private/public Diffie-Hellman
      key pair.

   Nevertheless, EAP MAKE protocol has its own specificities which are :

   o  the flow of operations is asymmetric in the sense that there is a
      prover and a verifier, that prover and verifier do not perform the
      same computations ; most notably only partial "prover side"
      forward secrecy is wanted,

   o  the general format of a message of the PPP EAP MAKE protocol is
      "some data" followed by the HMAC [2] of these data under the
      common prover/verifier Diffie-Hellman key.


2.2 Prerequisites

   Before describing the PPP EAP MAKE protocol, some elements have to be
   established.

   The hypothesis is here made that both have exchanged some data before
   the use of the PPP EAP MAKE protocol.  In particular they MUST agree
   on a way of identifying each other.  For instance,this could be by
   the ASCII representation of their distinguished name.  But some other
   ways can also be imagined.  In the following, the verifier is
   identified as "A" , the prover as "B" .

   By certificate, X509 certificate as defined for instance in [4] are



Berrendonner & Chabanne    Expires May 1, 2002                  [Page 4]


Internet-Draft                    MAKE                      October 2001


   here understood.  Other choices are possible.  In any case, it is
   assumed that B SHOULD (resp.  A MUST) be able to retrieve and check
   the validity of the certificate of their correspondent.

   They also agree on a Diffie-Hellman group.  In this memo by Diffie-
   Hellman we understand Diffie-Hellman computations made modulo a big
   prime.  Other choices are possible as working in finite fields of
   characteristic 2 or over elliptic curves, as suggested in Appendix 6
   of [6].  In any cases, A and B MUST share the knowledge of the
   underlying group required for Diffie-Hellmann common key computation.

   Then they MUST agree on an encryption algorithm, an hash algorithm
   and an HMAC algorithm.

   Finally, a counter which provides a basic but efficient anti-replay
   mechanism is maintained.  This counter is incremented at each attempt
   of identification.  The initial value of this counter is 0.  In the
   following, LID stands for the value of this counter.  Both A and B
   MUST store LID.  In what follows, LID is 4 bytes long, but this can
   be easily changed.  This value should be sufficient for classical
   dialin users as well as mobile-ip with periodic authentication

2.3 PPP EAP MAKE protocol in a nutshell

   Let's call this Diffie-Hellman common key between A and B, KDH, p the
   "big prime" which defines the group where Diffie-Hellman keys are
   computed, privA (resp.  privB)/ pubA (resp.  pubB) the private /
   public Diffie-Hellman key pair of A (resp.  of B).

   We note

   ENCRYPT(D ; K) the encryption of data D under key K,

   H(D) the computation of the hash of data D,

   HMAC(D1, D2, ...  , Dn ; K) the computation of the HMAC of
      concatenated data D1, D2, ..., Dn under key K,

   p is 128 bytes long.

   For instance

   o  HMAC is performed using SHA-1 as an hash function.  Its output is
      truncated to 16 bytes [2],

   o  H is computed according to SHA-1 [5],

   o  ENCRYPT corresponds to 3DES E-D-E in CBC mode.



Berrendonner & Chabanne    Expires May 1, 2002                  [Page 5]


Internet-Draft                    MAKE                      October 2001


   MAKE1 Request :

   o  A initiates the protocol by sending to B its identity.

   MAKE1 Response :

   o  B checks A's certificate validity

   o  B computes KDH

   o  B increments LID and updates its database

   o  B chooses at random r, a private Diffie-Hellman key

   o  B computes R the public key corresponding to r

   o  B computes HMAC(B, LID, R, A ; KDH)

   o  B sends to A : B, LID, R, HMAC(B, LID, R, A ; KDH)

   MAKE2 Request :

   o  A checks validity of LID, B's certificate

   o  A computes KDH

   o  A checks validity of HMAC(B, LID, R, A ; KDH)

   o  A computes Ks a session key following Section 3, with S = R**privA
      mod p.

   o  A chooses at random K which is going to encrypt data on the PPP
      link

   o  A chooses at random n a nonce

   o  A encrypts K under Ks, set

         K' = ENCRYPT(K ; Ks)

   o  A encrypts n under K, set

         n' = ENCRYPT(n ; K)

   o  A computes HMAC (B, LID, R, A, K', n' ; KDH)

   o  A sends to B :




Berrendonner & Chabanne    Expires May 1, 2002                  [Page 6]


Internet-Draft                    MAKE                      October 2001


         K', n', HMAC (B, LID, R, A, K', n' ; KDH)

   MAKE2 Response :

   o  B checks validity of HMAC (B, LID, R, A, K', n' ; KDH)

   o  B computes Ks the same way A does, using S = pubA**r mod p.

   o  B retrieves K and n

   o  B computes H(n)

   o  B sends to A :

         H(n)

   Finally :

   o  A checks validity of H(n)

   o  A updates LID (with the value sent by B)






























Berrendonner & Chabanne    Expires May 1, 2002                  [Page 7]


Internet-Draft                    MAKE                      October 2001


3. MAKE key derivation scheme

   This paragraph describes a method for getting a session key from a
   given master key.  Let's call S the master key, and Ks the session
   key.  The length of Ks depends on the keysize used with the symetric
   cipher algorithm.  For instance, if 3DES is chosen, Ks must be
   168bits long.  If AES is, it may be 128, 192 or 256 bits long.

   The following computations are done in order to get Ks:

   o  S' = HMAC(LID, KDH ; S)

   o  Ks1 = HMAC(A, B, 1 ; S')

   o  Ks2 = HMAC(A, B, 2 ; Ks1)

   o  ...

   o  KsN = HMAC(A, B, N ; Ks(N-1)

   o  A computes enough KsI to meet the key length requirements for the
      symetric cipher in use, by concatenating them: Ks = Ks1 | Ks2 |
      ...  | KsN.




























Berrendonner & Chabanne    Expires May 1, 2002                  [Page 8]


Internet-Draft                    MAKE                      October 2001


4. EAP MAKE Packet Format

   Four packets are exchanged in order to perform a complete
   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 MAKE1 and MAKE2
   Subtypes have the format defined in Figure 1.

   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      |   Subtype     |    Type Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1:The PPP EAP packet format

   Code:

         1 - Request

         2 - Response

   Identifier:

    The Identifier field is one octet and aids in matching responses
      with requests.  The Identifier MUST be changed for each new
      Request message sent and MUST NOT be changed on retransmission of
      a given message.  The Identifier in the Response message MUST
      match the corresponding Request.  The verifier MUST discard non-
      matching Response messages.

   Length:

    The Length field is two octets and indicates the length in bytes of
      the EAP packet including the Code, Identifier, Length, Type,
      Subtype, and Subtype-Data fields.  Octets outside the range of the
      Length field should be treated as Data Link Layer padding and
      should be ignored on reception.  Truncated packets (with Length
      greater than the link layer reported length) MUST be silently
      discarded.

   Type:

    The Type field  will carry the value xxx (EAP MAKE).  The Type field
      in the Response SHOULD carry the corresponding value unless the



Berrendonner & Chabanne    Expires May 1, 2002                  [Page 9]


Internet-Draft                    MAKE                      October 2001


      peer wishes to send a Nak Type to indicate that it is unable of
      handling MAKE authentication.

   Subtype:

         1 - MAKE1

         2 - MAKE2

      The Subtype field is one octet and must contain the value 1 or 2.
      If any other subtype value is encountered in an EAP MAKE Request
      message, then the prover SHOULD return an EAP Response with the
      Type field set to Nak.  In EAP MAKE Response messages, the Subtype
      value MUST be copied from the corresponding Request message.  The
      verifier SHOULD treat unknown Subtype values in Response messages
      as malformed packets and silently discard.  Values from 3 to 255
      are reserved for futur use.(for instance, for a configuration
      protocol or a rekeying scheme...).

   Type Data:

    The contents and formats of the remainder of the packet differ for
      each of the four packet types:

      1.  MAKE1 Request,

      2.  MAKE1 Response,

      3.  MAKE2 Request,

      4.  MAKE2 Response.

   The following sections define the format of the request and response
   where the 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.  When a packet is ill-formatted, an EAP failure packet MUST
   be send.












Berrendonner & Chabanne    Expires May 1, 2002                 [Page 10]


Internet-Draft                    MAKE                      October 2001


4.1 EAP MAKE1 Request Packet

    The EAP MAKE1 Request 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      |   Subtype     |          ...A's ID...         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: EAP MAKE1 Request Packet Format

   Code: 1 (Request)

   Identifier: ID1 (random value)

   Length: length of

         Code

         Identifier

         Length

         Type

         Subtype

         A's Identity

   Type: xxx (MAKE)

   Subtype: 1 (MAKE1)

   A's ID: The identity of the verifier.

   When receiving a MAKE1 Request, B SHOULD check A's certificate
   validity.  If not valid, B SHOULD send an EAP Failure packet.











Berrendonner & Chabanne    Expires May 1, 2002                 [Page 11]


Internet-Draft                    MAKE                      October 2001


4.2 EAP MAKE1 Response Packet

    The EAP MAKE1 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      |   Subtype     |  LID length   |    LID...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...LID...                  |  R length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...R...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...R...            | B's ID length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...B's ID ...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...B's ID ...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ...HMAC...                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ...HMAC...                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3: EAP MAKE1 Response Packet Format

   Code: 2 (Response)

   Identifier: ID1 (The identifier field MUST match the Identifier field
      from the corresponding request, i.e.  ID1)

   Length: length of

         Code

         Identifier

         Length

         Type



Berrendonner & Chabanne    Expires May 1, 2002                 [Page 12]


Internet-Draft                    MAKE                      October 2001


         Subtype

         LID length

         LID

         R length

         R

         B's ID length

         B's ID

         HMAC

   Type: xxx (MAKE)

   Subtype: 1 (MAKE1)

   LID length: 4

   LID: actual value of LID (in network byte order).  .

   R length: length in bytes of R.

   R: is the public key corresponding to r(a private Diffie-Hellman key
      choosen at random)

   B's ID length: length of B's ID will vary accordingly to B's ID
      format.

   B's ID: B's Identity.  If not valid, A MUST send an EAP Failure
      packet

   HMAC: HMAC is computed as the HMAC of B, LID, R, A under KDH.

   On reception of a MAKE1 Response packet, A MUST check that there is
   an increment with regard to its stored value.  A MUST check the
   validity of B's certificate before computing KDH.  If these values
   are correct, A MUST check the validity of HMAC.  In case one or more
   of these checkings fail, A MUST send an EAP Failure packet.
   Otherwise, it must send a MAKE2 request packet.








Berrendonner & Chabanne    Expires May 1, 2002                 [Page 13]


Internet-Draft                    MAKE                      October 2001


4.3 MAKE2 Request Packet

   The EAP MAKE2 Request 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      |   Subtype     |   IV length   |  IVK...       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ...IVK...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ...IVn...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ...IVn     |  K' length    |            ...K'...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...K'...           |  n' length    |     n'...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...n'...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         ...n'...                              |  ... HMAC     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ...HMAC...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ...HMAC...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4: EAP MAKE2 Request Packet Format

   Code: 1 (Request)

   Identifier: ID2 (random value)

   Length: length in bytes of

         Code

         Identifier

         Length




Berrendonner & Chabanne    Expires May 1, 2002                 [Page 14]


Internet-Draft                    MAKE                      October 2001


         Type

         Subtype

         IV length

         IVK

         IVn

         K' length

         K'

         n' length

         n'

         HMAC

   Type: xxx (MAKE)

   Subtype: 2 (MAKE2)

   IV length: we here consider that the encryption of K and n is
      performed using the same algorithm in the same mode of operation.
      IV length gives the length of the Initialization Vector for these
      encryptions

   IVK: Initialization Vector used to encrypt K choosen at random

   IVn: Initialization Vector used to encrypt n choosen at random

   HMAC: HMAC is computed as HMAC of B, LID, R, A, K', n' under KDH.

   K': K' is the encryption of K under Ks where Ks is defined in Section
      3, using S = R**privA mod p.

   n': n' is the encryption of n under K where K is chosen at random.

   On reception of a MAKE2 Request packet, B MUST check the HMAC.  If
   not valid, B MUST send an EAP Failure packet.  Otherwise B computes
   Ks, as defined in Section 3 with S = pubA**r mod p,  retrieves K and
   n, and computes the hash of n.  Then B MUST send an MAKE2 response
   packet.






Berrendonner & Chabanne    Expires May 1, 2002                 [Page 15]


Internet-Draft                    MAKE                      October 2001


4.4 MAKE2 Response Packet

   The EAP MAKE2 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      |   Subtype     |            H...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...H...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 5: EAP MAKE2 Response Packet Format

   Code: 2 (Response)

   Identifier: ID2 (The identifier field MUST match the Identifier field
      from the corresponding request, i.e.  ID2)

   Length: length in bytes of

         Code

         Identifier

         Length

         Type

         H

   Type: xxx (MAKE)

   Subtype: 2 (MAKE2)

   H: H is the hash of n

   On reception of MAKE2 Response, A MUST check this hash.  If not
   valid, A MUST send an EAP Failure packet.

4.5 PPP EAP MAKE and MAKE-VALIDATE Protocol Processing

   Figure 6 depicts the operation of the EAP MAKE and MAKE-VALIDATE
   protocol.  In this figure depicting PDU exchanges, the curly braces



Berrendonner & Chabanne    Expires May 1, 2002                 [Page 16]


Internet-Draft                    MAKE                      October 2001


   ({, }) denote items in Length-Value representation.

                 A                           B

   => EAP Request (ID1,
                   MAKE,
                   MAKE1,
                   {A})

                            <= EAP Response (ID1,
                                             MAKE,
                                             MAKE1,
                                             {B, LID, R, HMAC})

   => EAP Request (ID2,
                   MAKE,
                   MAKE2,
                   {IVK, IVn, K', n', HMAC})

                                  <= EAP Response (ID2,
                                                   MAKE,
                                                   MAKE2
                                                   {H(n)})

   => EAP Success Packet(ID3)

   Figure 6: PPP EAP MAKE and MAKE-VALIDATE Protocol processing
























Berrendonner & Chabanne    Expires May 1, 2002                 [Page 17]


Internet-Draft                    MAKE                      October 2001


5. Security Considerations

   When the verifier A is a server from which the prover B is the
   client, A has some advantages to secure its database in
   confidentiality too, allowing the storage of pre-computed KDH.  Doing
   so, some Denial of Service attacks should be more difficult to
   achieve.  Note also that besides its anti-replay role, the counter
   LID may avoid to the verifier some extras computations against a
   malevolent prover.

   It should be noted that the HMAC computation is performed over data
   in plaintext as well as in encrypted format (see [3] for a treatment
   of this subject).

   Finally, please note that most prover's computations might be carried
   out off-line.  This is especially true when the verifier is known.



































Berrendonner & Chabanne    Expires May 1, 2002                 [Page 18]


Internet-Draft                    MAKE                      October 2001


6. IANA Considerations

   In this memo, xxx should be substituted with whatever value IANA will
   assign to MAKE.















































Berrendonner & Chabanne    Expires May 1, 2002                 [Page 19]


Internet-Draft                    MAKE                      October 2001


References

   [1]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [2]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC : Keyed-Hashing
        for Message Authentication", RFC 2104, February 1997.

   [3]  Bellare, M. and C. Mamprempre, "Authenticated encryption :
        Relations among notions and analysis of the generic composition
        paradigm", September 2000.

   [4]  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and CRL Profile", RFC
        2459, January 1999.

   [5]  NIST, "FIPS PUB 180-1: Secure Hash Standard", FIPS PUB 180-1,
        April 1995.

   [6]  NIST, "FIPS PUB 186-2: Digital Signature Standard (DSS)", FIPS
        PUB 186-2, January 2000.


Authors' Addresses

   Romain Berrendonner
   SAGEM S.A.
   Avenue du Gros-Chene
   Eragny-sur-Oise  95610
   France

   Phone: +33 1 34 30 37 15
   EMail: romain.berrendonner@sagem.com


   Herve Chabanne
   SAGEM S.A.
   Avenue du Gros-Chene
   Eragny-sur-Oise  95610
   France

   Phone: +33 1 34 30 37 30
   EMail: herve.chabanne@sagem.com








Berrendonner & Chabanne    Expires May 1, 2002                 [Page 20]


Internet-Draft                    MAKE                      October 2001


Appendix A. Acknowledgments

   The authors wish to express their gratitude to W.  Nace, P.  Yee, J.
   Zmuda for their stimulating work " PPP EAP KEA Public Key
   Authentication Protocol " , which appears as an Internet Draft in
   November 1997.  This memo shares more than a simple resemblance with
   their work.

   They also want to thank warmly S.  Tramoni for her fruitful
   contributions to the subject and her implementation of MAKE.









































Berrendonner & Chabanne    Expires May 1, 2002                 [Page 21]


Internet-Draft                    MAKE                      October 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Berrendonner & Chabanne    Expires May 1, 2002                 [Page 22]


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