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]