WDIFF

draft-clancy-eap-pax-01.txt --> draft-clancy-eap-pax-02.txt

Network Working Group T. Clancy
Internet-Draft W. Arbaugh
Expires: December 30, 2004 September 19, 2005 University of Maryland
July 2004
March 21, 2005

EAP Password Authenticated Exchange
draft-clancy-eap-pax-01
draft-clancy-eap-pax-02

Status of this Memo

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.

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 December 30, 2004. September 19, 2005.

Abstract

This Internet Draft defines a provably secure Extensible
Authentication Protocol method called EAP-PAX. This method is
designed for bootstrapping a shared key-based
lightweight shared-key authentication protocol with a weak preshared password or PIN. It includes key management
features, is secure against dictionary attacks, includes optional support
for identity protection, provisioning, key management, and avoids intellectual property
rights associated with competing EAP methods.

EAP-PAX consists of two different authentication protocols: PAX_STD identity protection.

Clancy & Arbaugh Expires December 30, 2004 September 19, 2005 [Page 1]

Internet-Draft EAP-PAX July 2004

and PAX_IDP. PAX_STD is a simple mutual authentication and key
derivation protocol capable of deriving session keys and new
authentication keys. PAX_IDP is a variant that additionally provides
identity protection, and requires a server-side certificate. March 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3
1.1 Language Requirements . . . . . . . . . . . . . . . . . . 4 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5
2.1 PAX_STD Protocol . . . . . . . . . . . . . . . . . . . . . 7 6
2.2 PAX_IDP PAX_SEC Protocol . . . . . . . . . . . . . . . . . . . . . 7 6
2.3 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Verification Requirements . . . . . . . . . . . . . . . . 8
2.5 PAX Key Derivation Function . . . . . . . . . . . . . . . 9
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 9 10
3.1 Header Specification . . . . . . . . . . . . . . . . . . . 10
3.1.1 Op-Code . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 10 11
3.1.3 MAC ID . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4 DH Group ID . . . . . . . . . . . . . . . . . . . . . 12 11
3.1.5 Public Key ID . . . . . . . . . . . . . . . . . . . . 12
3.1.6 Sequence Number . . . . . . . . . . . . . . . . . . . 12
3.2 Payload Formatting . . . . . . . . . . . . . . . . . . . . 12
3.3 Integrity Check Value (ICV) . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . 15 14
4.1 Server Certificates . . . . . . . . . . . . . . . . . . . 15 14
4.2 Server Security . . . . . . . . . . . . . . . . . . . . . 17 15
4.3 EAP Security Claims . . . . . . . . . . . . . . . . . . . 17 15
4.3.1 Protected Ciphersuite Negotiation . . . . . . . . . . 17 15
4.3.2 Mutual Authentication . . . . . . . . . . . . . . . . 17 16
4.3.3 Integrity Protection . . . . . . . . . . . . . . . . . 18 16
4.3.4 Replay Protection . . . . . . . . . . . . . . . . . . 18 16
4.3.5 Confidentiality . . . . . . . . . . . . . . . . . . . 18 16
4.3.6 Key Derivation . . . . . . . . . . . . . . . . . . . . 18 16
4.3.7 Key Strength . . . . . . . . . . . . . . . . . . . . . 18 16
4.3.8 Dictionary Attack Resistance . . . . . . . . . . . . . 18 17
4.3.9 Fast Reconnect . . . . . . . . . . . . . . . . . . . . 18 17
4.3.10 Session Independence . . . . . . . . . . . . . . . . 19 17
4.3.11 Fragmentation . . . . . . . . . . . . . . . . . . . 19 17
4.3.12 Channel Binding . . . . . . . . . . . . . . . . . . 19 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 17
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 19 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
7.2 Informative References . . . . . . . . . . . . . . . . . . . 21 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22

Clancy & Arbaugh Expires December 30, 2004 [Page 2]

Internet-Draft EAP-PAX July 2004 20
A. Implementation Suggestions . . . . . . . . . . . . . . . . . 22 20
A.1 WiFi Enterprise Network . . . . . . . . . . . . . . . . . 23 20
A.2 Mobile Phone Network . . . . . . . . . . . . . . . . . . . 23 21
Intellectual Property and Copyright Statements . . . . . . . 25 22

Clancy & Arbaugh Expires December 30, 2004 September 19, 2005 [Page 3] 2]

Internet-Draft EAP-PAX July 2004 March 2005

1. Introduction

EAP-PAX, or Extensible Authentication Protocol, Password

EAP-PAX (Password Authenticated eXchange, eXchange), is a secure an EAP method [RFC3748]
designed for authentication using a shared key. It provides makes use of two
separate subprotocols, PAX_STD and PAX_SEC. PAX_STD is a provisioning
mechanism suitable simple,
lightweight protocol for deriving a strong mutual authentication key from using a
weak preshared shared key. Two separate protocols,
PAX_SEC complements PAX_STD by providing support for provisioning and PAX_IDP, are
defined, with the distinguishing characteristic being that PAX_IDP
supports
identity protection and requires using a server-side certificate.
Both techniques have been optimized for minimal client-side
complexity. public key.

The idea motivating EAP-PAX is a desire for device authentication
bootstrapped by a simple personal identification number (PIN). If a
weak key is used or a expiration period has lapsed, elapsed, the
authentication server forces a key update. During a key update,
rather Rather than using a hash-based
symmetric key exchange, the client and server perform a
Diffie-Hellman key exchange which provides forward secrecy.

While the preferred mode of operation is for the server to have

Since implementing a
certificate it PKI can supply to the be cumbersome, PAX_SEC defines multiple
client when security policies, selectable based on ones threat model. In
the weakest mode, PAX_SEC allows the use of raw public keys
completely eliminating the need for a weak key is being
used, PKI. In the protocol supports strongest mode,
PAX_SEC requires that EAP servers use certificates signed by a purely symmetric-key mode of operation
when identity protection is not required. However, in this mode
trusted authority. In the
protocol weaker modes, during provisioning PAX_SEC
is vulnerable to an active a man-in-the-middle off-line dictionary attack during the initial key update, if a weak key
generated from a provisioned password or PIN is being used. When all attack. In the suggested security options are enabled,
strongest mode, EAP-PAX is provably secure under the Random Oracle
model.

EAP-PAX includes built-in supports the generation of strong key management features, material; mutual
authentication; resistance to
dictionary attacks, desynchronization, dictionary, and avoids intellectual property issues
associated
man-in-the-middle attacks; ciphersuite extensibility with protocols such as EKE [BM92], SPEKE [Jab96], protected
negotiation; and SRP
[RFC2945]. identity protection. These features satisfy the EAP
method requirements for wireless LANs [I-D.walker-ieee802-req],
making EAP-PAX is ideal for wireless environments such as IEEE 802.11
[IEEE.80211].

1.1 Language Requirements

In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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 [RFC2119].

1.2 Terminology

This section describes the various variables and functions used in
the PAX protocol. They will be referenced frequently in later
sections.

Clancy & Arbaugh Expires December 30, 2004 September 19, 2005 [Page 4] 3]

Internet-Draft EAP-PAX July 2004 March 2005

Variables:

CID
client NAI [RFC2486bis]
g
public Diffie-Hellman generator, typically 2
X,
M
256-bit
128-bit random integer generated by the server
Y,
N
256-bit
128-bit random integer generated by the client
CID
EAP client NAI [RFC2486]
SID
EAP
X
256-bit random integer generated by the server NAI [RFC2486]
Y
256-bit random integer generated by the client

Keys:

PK
EAP server's public key
CertPK
EAP server's certificate for public key PK

AK
authentication key shared between the client and EAP server
AK'
new authentication key generated during a key update
MK
Master Key shared between the client and EAP server from which all
other
CertPK
EAP method session keys are derived server's certificate containing public key PK
CK
Confirmation Key generated from the MK and used during
authentication to prove knowledge of AK
MSK
Master Session Key generated from the MK and exported by the EAP
method to the authenticator
EMSK
Extended Master Session Key also generated from the MK and
contains additional keying material
IV
Initialization Vector used to seed ciphers; exported to the
authenticator

Operations:

enc_X(Y)
encryption of message Y with public key X
MAC_X(Y)
keyed message authentication code computed over message Y with
symmetric key X

Clancy & Arbaugh Expires December 30, 2004 [Page 5]

Internet-Draft EAP-PAX July 2004

PAX-KDF-W(X, Y, Z)
PAX Key Derivation Function computed using
MID
Method ID used to construct the EAP Session ID and consequently
name all the exported keys [I-D.ietf-eap-keying]
MK
Master Key between the client and EAP server from which all other
EAP method session keys are derived
MSK
Master Session Key generated from the MK and exported by the EAP
method to the authenticator
PK
EAP server's public key

Operations:

Clancy & Arbaugh Expires September 19, 2005 [Page 4]

Internet-Draft EAP-PAX March 2005

enc_X(Y)
encryption of message Y with public key X
MAC_X(Y)
keyed message authentication code computed over message Y with
symmetric key X
PAX-KDF-W(X, Y, Z)
PAX Key Derivation Function computed using secret X, identifier Y,
and seed Z, and producing W octets of output; defined in section
2.5 output.
||
string or binary data concatenation

2. Overview

The EAP framework [RFC3748] defines four basic steps that occur
during the execution of an EAP conversation between client and
server. The first phase, discovery, is handled by the underlying MAC
protocol. The authentication phase is defined here. The key
distribution and secure association phases are handled differently
depending on the link layer underlying protocol, and are not discussed in this
document.

+--------+ +---------+ +--------+
| | EAP-Request/Identity | |
| CLIENT |<------------------------------------| SERVER |
| | | |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | PAX_STD or PAX_IDP PAX_SEC | |
| |<------------------------------------| |<----------------------------------->| |
| |------------------------------------>| | ... ... | |<------------------------------------| |
| |------------------------------------>| |<----------------------------------->| |
| | | |
| | EAP Success | |
| |<------------------------------------| |
| | | |
+--------+ +---------+

As mentioned earlier, there +--------+

There are two distinct protocols subprotocols that can be executed. The first,
PAX_STD, is used when identity protection is
not required. during typical authentications. The second, PAX_IDP PAX_SEC
provides this more secure features such as provisioning and identity
protection.

Each protocol has two modes of operation. When an AK update is being
performed, the client and server exchange g^X and g^Y. When no
update is being performed, and only session keys are being derived, X
and Y are exchanged. Using Diffie-Hellman during the key update
provides forward secrecy, and secure key derivation when a weak
provisioned key is used.

Clancy & Arbaugh Expires September 19, 2005 [Page 5]

Internet-Draft EAP-PAX March 2005

The main deployment difference between the protocols is that PAX_IDP PAX_SEC
requires a server-side certificate. public key. For every authentication, the
client is required to compute a public-key encryption. PAX_STD on
the other

Clancy & Arbaugh Expires December 30, 2004 [Page 6]

Internet-Draft EAP-PAX July 2004 hand can be accomplished using uses purely symmetric operations, provided other than a key update is not being performed.
possible Diffie-Hellman exchange.

Each of the protocols are now defined.

2.1 PAX_STD Protocol

In the

PAX_STD protocol, is a simple nonce-based authentication. authentication using the strong
long-term key. The client and server each exchange 256 bits of
random data which is used to seed the PAX-KDF for generation of
session keys. The randomly exchanged data in the protocol differs
depending on whether a key update is being performed. If no key
update is being performed, then let:

o A = X (256-bit random value)
o B = Y (256-bit random value)
o E = X || Y (512-bit concatenation)

To provide forward secrecy and security when a weak key is used, security, let the following be true
when a key update is being performed:

o A = g^X
o B = g^Y
o E = g^(XY)

The full protocol, when a server-side certificates are used certificate is used, is as
follows:

o PAX_STD-1 : client <- server : A, SID, PK, CertPK A
o PAX_STD-2 : client -> server : Enc_PK( B, MAC_CK( A, B, CID, SID
))
o PAX_STD-3 : client <- server : MAC_CK( B, CID, SID )
o PAX-ACK : client -> server

When not performing an initial key update, where server-side
certificates can be omitted, the protocol reduces to:

o PAX_STD-1 : client <- server : A, SID
o PAX_STD-2 : client -> server : B, MAC_CK( A, MAC_CK(A, B, CID, SID ) CID)
o PAX_STD-3 : client <- server : MAC_CK( B, CID, SID ) MAC_CK(B, CID)
o PAX-ACK : client -> server

2.2 PAX_IDP PAX_SEC Protocol

PAX_IDP

PAX_SEC is an alternate the "high-security" protocol designed to provide identity
protection. The main disadvantage of PAX_IDP is that it
protection and support for provisioning. PAX_SEC requires a
server-side certificate, public key, and public key operations for every

Clancy & Arbaugh Expires December 30, 2004 [Page 7]

Internet-Draft EAP-PAX July 2004
authentication.

PAX_IDP

PAX_SEC can be performed with and without key update. Let A, B, and
E be defined as in the previous section.

The exchanges for PAX_IDP PAX_SEC are as follows:

Clancy & Arbaugh Expires September 19, 2005 [Page 6]

Internet-Draft EAP-PAX March 2005

o PAX_IDP-1 PAX_SEC-1 : client <- server : M, SID, PK, PK or CertPK
o PAX_IDP-2 PAX_SEC-2 : client -> server : Enc_PK( M, Enc_PK(M, N, CID ) CID)
o PAX_IDP-3 PAX_SEC-3 : client <- server : A, MAC_N( A, CID, SID ) MAC_N(A, CID)
o PAX_IDP-4 PAX_SEC-4 : client -> server : B, MAC_CK( A, MAC_CK(A, B, CID, SID )

2.3 Key Derivation

Keys are derived independently CID)
o PAX_SEC-5 : client <- server : MAC_CK(B, CID)
o PAX-ACK : client -> server

Use of which authentication mechanism was
used. The process uses CertPK is optional in PAX_SEC, however careful consideration
should be applied depending on the entropy value E computed as described
above. Session intended use and authentication keys are computed as follows:

o AK' = PAX-KDF-16( AK, "Authentication Key", E )
o MK = PAX-KDF-16( AK, "Master Key", E )
o CK = PAX-KDF-16( MK, "Confirmation Key", E )
o ICK = PAX-KDF-16( MK, "Integrity Check Key", E )
o MSK = PAX-KDF-64( MK, "Master Session Key", E )
o EMSK = PAX-KDF-64( MK, "Extended Master Session Key", E )
o IV = PAX-KDF-64( 0x00^16, "Initialization Vector", E ) desired level of
security. The IV is computed following table describes the risks involved when
using PAX_SEC without a 16-octet NULL key. The value certificate.

When using PAX_SEC to support provisioning with a weak key, use of AK' a
CA-signed certificate is
only used RECOMMENDED. When not using a CA-signed
certificate, the initial authentication is vulnerable to replace AK if an offline
man-in-the-middle dictionary attack.

When using PAX_SEC to support identity protection, use of either a
CA-signed certificate or key update caching is being performed. If RECOMMENDED. Caching
involves a client recording the public key
update is not performed, AK' need not be computed.

2.4 Verification Requirements

In order for EAP-PAX to be secure, certificates and MACs must be
properly verified each step of the way.

PAX_STD-1/PAX_IDP-1 -> Client : If a public key EAP server and certificate are
included, the client SHOULD either compare the public key
verifying its consistency between sessions, similar to SSH.
Otherwise, an attacker can spoof an EAP server during a
locally cached copy or use the certificate authority's public key to session and
gain knowledge of a client's identity.

Whenever certificates are used, clients MUST validate that the server's public
certificate's extended key and certificate. usage, KeyPurposeID, be either
"eapOverPPP" or "eapOverLAN" [RFC3770]. If this validation
fails, and the client's security policy prohibits the use of a
non-verifiable certificate, underlying EAP
transport protocol is known, then the client MUST send SHOULD differentiate
between these fields. For example, an EAP-Failure
message.

PAX_STD-2 -> Server : After possibly decrypting the packet, the
server MUST 802.11 supplicant SHOULD
require KeyPurposeID == eapOverLAN.

When using EAP-PAX with Wireless LAN, clients SHOULD validate that
the included MAC. This MAC serves to
authenticate the client to certificate's wlanSSID extension match the server. If this validation fails, SSID of the
server MUST send an EAP-Failure message. network to

Clancy & Arbaugh Expires December 30, 2004 September 19, 2005 [Page 8] 7]

Internet-Draft EAP-PAX July 2004

PAX_IDP-2 -> Server : The server MUST verify that the decrypted value March 2005

which it is currently authenticating.

In order to facilitate discussion of M matches the value transmitted in PAX_IDP-1. packet validations, three client
security policies for PAX_SEC are defined.

open
Clients support both use of PK and CertPK. If this validation
fails, CertPK is used, the server MUST send an EAP-Failure message.

PAX_STD-3/PAX_IDP-3 -> Client : The
client MUST validate the
transmitted MAC, as KeyPurposeID.
caching
Clients save PK for each EAP server the first time it serves to authenticate encounters
the server server, and SHOULD NOT authenticate to the
client. EAP servers whose
public key has been changed. If this validation fails, CertPK is used, the client MUST send an
EAP-Failure message.

PAX_IDP-4 -> Server : The server MUST
validate the transmitted KeyPurposeID.
strict
In strict mode, clients require servers to present a valid
certificate signed by a trusted authority. As with the other
modes, the KeyPurposeID MUST be validated.

2.3 Key Derivation

Keys are derived independently of which authentication mechanism was
used. The process uses the entropy value E computed as described
above. Session and authentication keys are computed as follows:

o AK' = PAX-KDF-16(AK, "Authentication Key", E)
o MK = PAX-KDF-16(AK, "Master Key", E)
o CK = PAX-KDF-16(MK, "Confirmation Key", E)
o ICK = PAX-KDF-16(MK, "Integrity Check Key", E)
o MID = PAX-KDF-16(MK, "Method ID", E)
o MSK = PAX-KDF-64(MK, "Master Session Key", E)
o EMSK = PAX-KDF-64(MK, "Extended Master Session Key", E)
o IV = PAX-KDF-64(0x00^16, "Initialization Vector", E)

The IV is computed using a 16-octet NULL key. The value of AK' is
only used to replace AK if a key update is being performed. The EAP
Method ID is represented in ASCII as 32 hexadecimal characters
without any byte delimiters such as colons or dashes.

2.4 Verification Requirements

In order for EAP-PAX to be secure, MACs must be properly verified
each step of the way.

PAX_STD-2
The server MUST validate the included MAC, as it serves to
authenticate the client to the server. If this validation fails,
the server MUST send an EAP-Failure message.

2.5 PAX Key Derivation Function

Clancy & Arbaugh Expires September 19, 2005 [Page 8]

Internet-Draft EAP-PAX March 2005

PAX_STD-3
The PAX-KDF is a secure key derivation function used to generate
various keys from the provided entropy and shared key.

PAX-KDF-W(X, Y, Z)

W length, in octets, of client MUST validate the desired output
X secret key used included MAC, as it serves to protect the computation
Y public identifier for
authenticate the key being derived
Z exchanged entropy used server to seed the KDF

Let's define some variables and functions:

o S = length in octets of the output of client. If this validation fails,
the MAC function client MUST send an EAP-Failure message.
PAX_SEC-1
The client MUST validate PK or CertPK in a manner specified by its
local security policy (see section 2.2). If this validation
fails, the client MUST send an EAP-Failure message.
PAX_SEC-2
The server MUST verify that the decrypted value of M matches the
value transmitted in PAX_SEC-1. If this validation fails, the
server MUST send an EAP-Failure message.
PAX_SEC-3
The client MUST validate the included MAC, as it serves to prevent
replay attacks. If this validation fails, the client MUST send an
EAP-Failure message.
PAX_SEC-4
The server MUST validate the included MAC, as it serves to
authenticate the client to the server. If this validation fails,
the server MUST send an EAP-Failure message.
PAX_SEC-5
The client MUST validate the included MAC, as it serves to
authenticate the server to the client. If this validation fails,
the client MUST send an EAP-Failure message.

2.5 PAX Key Derivation Function

The PAX-KDF is a secure key derivation function used to generate
various keys from the provided entropy and shared key.

PAX-KDF-W(X, Y, Z)

W length, in octets, of the desired output
X secret key used to protect the computation
Y public identifier for the key being derived
Z exchanged entropy used to seed the KDF

Let's define some variables and functions:

o M_i = MAC_X(Y || Z || i), where i is an 8-bit unsigned integer
o L = ceiling(W/S) ceiling(W/16)
o F(A, B) = first A octets of binary data B

We define PAX-KDF-W(X, Y, Z) = F(W, M_1 || M_2 || ... || M_L).

For example when using a 128-bit MAC function,

Consequently for the two values of W used in this draft, we have:

Clancy & Arbaugh Expires September 19, 2005 [Page 9]

Internet-Draft EAP-PAX March 2005

o PAX-KDF-16(X, Y, Z) = MAC_X(Y || Z || 0x01)
o PAX-KDF-64(X, Y, Z) = MAC_X(Y || Z || 0x01) || MAC_X(Y || Z ||
0x02) || MAC_X(Y || Z || 0x03) || MAC_X(Y || Z || 0x04)

The MAC used in this the PRF is extensible, and is the same MAC used in
the rest of the protocol. It is specified in the EAP-PAX header.

3. Protocol Specification

In this section, the packet format and content for the challenge and
response messages are defined.

EAP-PAX packets have the following

Clancy & Arbaugh Expires December 30, 2004 [Page 9]

Internet-Draft EAP-PAX July 2004 structure:

Figure 2 3

3.1 Header Specification

The Code, Identifier, Length, and Type fields are all part of the EAP
header, and defined in [RFC3748]. See The type field has yet to be
allocated; see the "IANA Considerations"
section for more information on the type field. section.

3.1.1 Op-Code

The OP-Code field is one of eight possible six values:

Clancy & Arbaugh Expires September 19, 2005 [Page 10]

Internet-Draft EAP-PAX March 2005

o 0x01 : PAX_STD-1
o 0x02 : PAX_STD-2
o 0x03 : PAX_STD-3
o 0x11 : PAX_IDP-1 PAX_SEC-1
o 0x12 : PAX_IDP-2 PAX_SEC-2
o 0x13 : PAX_IDP-3 PAX_SEC-3
o 0x14 : PAX_IDP-4 PAX_SEC-4
o 0x15 : PAX_SEC-5
o 0x21 : PAX-ACK

3.1.2 Flags

The flags field is broken up into 8 bits each representing a binary
flag. The field is defined as the Logical OR of the following

Clancy & Arbaugh Expires December 30, 2004 [Page 10]

Internet-Draft EAP-PAX July 2004
values:

o 0x01 : server-side certificate available (SSCA) more fragments (MF)
o 0x02 : public-key encryption required (PKER) certificate enabled (CE)
o 0x04 : public-key encryption used (PKEU)
o 0x08 : more fragments (MF)
o 0x10 - 0x80 : reserved

The SSCA MF flag is set in packets of type PAX_STD-1 if and only if
those packets include the server's public key current packet required fragmentation, and certificate. For
PAX_STD packets of any other type,
further fragments need to be transmitted. If a packet does not
require fragmentation, the SSCA MF flag MUST equal the value
of SSCA in is not set.

When a payload requires fragmentation, each fragment is transmitted,
and the original PAX_STD-1 packet. receiving party responds with a PAX-ACK packet for each
received fragment.

When using PAX_STD, the PAX_IDP protocol
is used, SSCA MUST be set.

The PKER CE flag SHOULD be set in packets of type PAX_STD-1 if the
current authentication key is weak. PKER MUST be set in all packets
if PAX_IDP is used. For PAX_STD packets of any other type, zero. When using PAX_SEC,
the PKER CE flag MUST equal the value of PKER in the original PAX_STD-1 packet.
PKER can only be set if SSCA is set.

The PKEU flag PAX_SEC-1 includes CertPK. It MUST equal zero in packets of type PAX_STD-1 and
PAX_IDP-1. In packets of type PAX_STD-2, PKEU should NOT be
set if and
only if the client has encrypted the packet payload using the
server's public key. In packets of type PAX_IDP-2, PKEU MUST be set,
since encryption is required. PAX_SEC-1 includes PK. If CE is set in PAX_STD-1, PKER was set, PKEU PAX_SEC-1, it MUST be
set in PAX_STD-2. If in PAX_STD-1, SSCA was set PAX_SEC-2, PAX_SEC-3, PAX_SEC-4, and PKER was
not set, PKEU MAY be set in PAX_STD-2.

In general, for PAX_STD, PAX_SEC-5. If either
party detects an inconsistent value of the server is responsible for setting SSCA CE flag, he MUST send an
EAP-Failure message and PKER in packet PAX_STD-1, while discontinue the client is responsible for
setting PKEU in packet PAX_STD-2. SSCA and PKER must remain constant
in all packets. PKEU must be zero in PAX_STD-1, and constant in all
successive packets.

For PAX_IDP, SSCA and PKER MUST be set in all packets. PKEU MUST NOT
be set in packet PAX_IDP-1, and MUST be set in all other PAX_IDP
packets.

The MF flag is set if the current packet required fragmentation, and
further fragments need to be transmitted. If a packet does not
require fragmentation, the MF flag is not set. When a payload
requires fragmentation, each fragment is transmitted, and the
receiving party responds with a PAX-ACK packet for each received
fragment. session.

3.1.3 MAC ID

The MAC field specifies the cryptographic hash used to generate the

Clancy & Arbaugh Expires December 30, 2004 [Page 11]

Internet-Draft EAP-PAX July 2004
keyed hash value. The following are currently supported:

o 0x01 : HMAC_SHA1_128 [FIPS180] [FIPS180][FIPS198]
o 0x02 : AES_CBC_MAC_128 [FIPS113] [FIPS113][FIPS197]

3.1.4 DH Group ID

The Diffie-Hellman group field specifies the group used in the
Diffie-Hellman computations. The following are currently supported:

Clancy & Arbaugh Expires September 19, 2005 [Page 11]

Internet-Draft EAP-PAX March 2005

o 0x00 : NONE (iff not performing a key update)
o 0x01 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526]

If no key update is being performed, the DH Group ID field MUST be
zero. Otherwise, the DH Group ID field MUST NOT be zero.

3.1.5 Public Key ID

The public key ID field specifies the cipher used to encrypt the
client's EAP-Response in PAX_STD-2 and PAX_IDP-2. PAX_SEC-2.

The following are currently supported:

o 0x00 : NONE (iff SSCA is not set) using PAX_STD)
o 0x01 : RSA_OAEP_2048 [RFC3447]

If the SSCA flag PAX_STD is not set, begin executed, the Public Key ID field MUST be zero.
Otherwise,
If PAX_SEC is being executed, the Public Key ID field MUST NOT be
zero.

3.1.6 Sequence Number

Sequence numbers are used to prevent replay attacks, in particular
with respect to ACKs. The server initializes

When using RSA_OAEP, the sequence number to
0 for each transaction, hash algorithm and increments it for each packet. For every
EAP-Request/PAX packet fragment transmitted mask generation algorithm
used shall be the associated
EAP-Response/PAX packet MUST contain a matching sequence number.
Packets with invalid sequence numbers MUST MAC specified by the MAC ID, keyed using an
all-zero key. The label shall be silently discarded. null.

3.2 Payload Formatting

This section describes how to format the payload field. Depending on
the packet type, different values are transmitted. Sections 2.1 and
2.2 define the fields, and in what order they are to be concatenated.
For simplicity and since many field lengths can vary with the
ciphersuite, each value is prepended with a two-octet length value.

Clancy & Arbaugh Expires December 30, 2004 [Page 12]

Internet-Draft EAP-PAX July 2004

--- byte offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-
+---+---------------------
|len| value ....
+-+-+-+-+-+-+-
+---+--------

All integer values are stored as octet arrays in network-byte order,
with the most significant byte first. Integers are padded on the
most significant end to reach byte boundaries.

Public keys and certificates SHALL be in X.509 format [X.509] encoded
using the Distinguished Encoding Rules (DER) format [X.690].

Strings are not null-terminated and are encoded using UTF-8. Binary
data, such as message authentication codes, are transmitted as-is.

Clancy & Arbaugh Expires September 19, 2005 [Page 12]

Internet-Draft EAP-PAX March 2005

MACs are computed by concatenating the specified values in the
specified order. Values are encoded as described above, except that
no length field is specified.

To illustrate this process, an example is presented. What follows is
the encoding of the payload for PAX_STD-2 with encryption. PAX_STD-2. The three basic steps
will be computing the MAC, forming the payload, and encrypting the
payload.

To create the MAC, we first need to form the buffer that will be
MACed. For this example, assume no key update is being done and
HMAC_SHA1_128 is used such that the result will be a 16-octet value.

Clancy & Arbaugh Expires December 30, 2004 [Page 13]

Internet-Draft EAP-PAX July 2004

--- byte offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-octet 32-octet integer A | 16-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length SID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

||
||
CK --> MAC
||
\/

--- byte offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-octet MAC output |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With this, we can now create the encoded payload:

Clancy & Arbaugh Expires September 19, 2005 [Page 13]

Internet-Draft EAP-PAX March 2005

--- byte offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16
|32 | 16-octet 32-octet integer B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L | |
+-+-+-+-+ +
| |
... L-byte CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16 | MAC computed above
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

These 36 52+L octets are then encrypted using the server's public key.
The output of the encryption algorithm is then attached to attached to the packet as the payload.
The ICV is then computed by MACing the packet headers and payload,
and appended after the payload.

3.3 Integrity Check Value (ICV)

The ICV is computed as the MAC over the entire EAP packet, including

Clancy & Arbaugh Expires December 30, 2004 [Page 14]

Internet-Draft EAP-PAX July 2004
the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC
is keyed using the 16-octet MK. For packets of type PAX_STD-1,
PAX_IDP-1, PAX_IDP-2,
PAX_SEC-1, PAX_SEC-2, and PAX_IDP-3, PAX_SEC-3, where the MK has not yet been
derived, the MAC is keyed using a zero-octet NULL key.

If the ICV field is incorrect, the receiver MUST silently discard the
packet.

4. Security Considerations

For any

Any authentication protocol, especially one geared for wireless
environments, one must assume adversaries have many capabilities. In
general, one must assume that all messages between the client and
server are delivered via the adversary. This allows passive
attackers to eavesdrop on all traffic, while active attackers can
modify data in any way before delivery.

In this section, we discuss the security properties and requirements
of EAP-PAX with respect to this threat model.

The Also note that the
security of PAX can be proved using under the Random Oracle model. Key updates using a certificate is a slight variation on
Halevi and Krawczyk's proved mutually authenticated Diffie-Hellman
scheme [HK99].

4.1 Server Certificates

Since many vendors are leery of establishing a public key
infrastructure (PKI), or the client-side computation power needed to
implement them, some discussion is required with respect to the PKI
requirements of this protocol. First of all, realize that only the
server needs a public key. The client is authenticated based on the
shared secret, not a key pair. This should make deployment
significantly easier.

Secondly, this protocol is only guaranteed to be secure if when using
a weak key (i.e. during provisioning), the client has a means of
verifying the authenticity of the server's public key. This can be
easily achieved by establishing a certificate authority (CA), signing
the server's public key with the CA's private key, and then
distributing the CA's public key. The CA's public key can be easily
loaded onto the client during the initial software installation. If
a CA is not used, then the public key of all servers

PAX_SEC can be preloaded
onto the client, so the client can match the received certificate
with the one cached locally.

Lastly, if identity protection is required, and PAX_IDP is being
executed, the server-side certificate is required. Without using

Clancy & Arbaugh Expires December 30, 2004 [Page 15]

Internet-Draft EAP-PAX July 2004

some form of authenticated public-key cryptography, identity
protection with forward secrecy is theoretically impossible. The
only other possibility is to use an aliasing scheme where users are
given new usernames after every successful authentication--generally
considered a fragile approach, prone to synchronization problems.

Use of self-signed certificates with client-side SSH-style caching is
only suggested if identity protection is required and a PKI is
infeasible. When identity protection is not used, self-signed
certificates provide no additional security over no signatures at
all.

When using cached self-signed certificates used in PAX_IDP, realize that
clients have no way to authenticate the authenticator before sending
them their identity. An attacker could impersonate an authenticator
and gain knowledge of the client's identity. In a roaming wireless
environment, this attack becomes much easier since the client could
possibly interact with multiple authentication servers. Provided a
client positively knows they will only interact several configurations. It can be used with one backend
authentication server, even when roaming
or without a self-signed, cached
certificate approach may be sufficient, depending on one's threat
model. server-side certificate. Section 2.2 details the
possible modes and the resulting security risk.

Clancy & Arbaugh Expires September 19, 2005 [Page 14]

Internet-Draft EAP-PAX March 2005

When a PKI is using PAX_SEC for identity protection and not used, realize that using a active man-in-the-middle
dictionary attack is possible during PAX_STD-1 if CA-signed
certificate, an attacker can convince a client to reveal his
username. To achieve this, an attacker can simply forge a PAX_SEC-1
message and send it to the client. The client is
authenticating would respond with a weak
PAX_SEC-2 message containing his encrypted username. The attacker
can then use his associated private key and does not have to decrypt the server's public
key locally cached for verification. The effects client's
username. Use of this key caching can be
mitigated reduce the risk of identity
revelation by performing provisioning in allowing clients to detect when the EAP server to which
they are accustom has a controlled environment.

Specifically, in different public key.

When provisioning with PAX_SEC and not using a certificateless environment, CA-signed certificate,
an attacker could first forge a PAX_STD-1 PAX_SEC-1 message and send it to the
client. The client would respond with a PAX_STD-2 packet containing g^X and
MAC_CK( g^X || g^Y || CID || SID ). The PAX_SEC-2 message. Using
the decrypted value of N, an attacker could forge a PAX_SEC-3
message. Once the client responds with a PAX_SEC-4 message, an
attacker can now guess values of the weak AK and compute CK = PAX-KDF-16(AK, PAX-KDF(AK,
"Confirmation Key", g^XY). Given enough time, the attacker can obtain both the old
AK and new AK', and would then be capable of forging PAX_STD-3 and
falsely authenticating himself to the client.

In short, in identity protection mode, certificates are required, and
use of cached self-signed certificates can lead to man-in-the-middle
attacks the first time a client interacts with a particular
authenticator. When identity protection is not used, certificates
are optional, but clients are vulnerable to an active off-line
dictionary attack during provisioning. Implementors should assess
these risks with respect to their threat model before deciding not to
use the PKI features of EAP-PAX.

Clancy & Arbaugh Expires December 30, 2004 [Page 16]

Internet-Draft EAP-PAX July 2004 attacker can
obtain both the old AK and new AK' and forge a responding PAX_SEC-5.

4.2 Server Security

In order to maintain a reasonable security policy, the server must should
manage four five pieces of information concerning each user. Most
obviously, their username and current key. Additionally, the server
must keep a bit that indicates whether the current key is weak. Weak
keys must be updated prior to key derivation. Also, the server
should track the date of last key update. To implement the
coarse-grained forward secrecy, the authentication key must be
updated on a regular basis, and this field can be used to expire
keys. Lastly, the server should track the previous key, to prevent
attacks where an adversary desynchronizes the key state by
interfering with PAX-ACK packets. See Appendix A for more suggested
implementation strategies that prevent key desynchronization attacks.

Since the client keys are stored in plaintext on the server, special
care should be given to the overall security of the authentication
server. An operating system-level attack yielding root access to an
intruder would result in the compromise of all client credentials.

4.3 EAP Security Claims

This section describes EAP-PAX in terms of specific security
terminology as required by [RFC3748].

4.3.1 Protected Ciphersuite Negotiation

In the initial packet from the server, the server specifies the
ciphersuite in the packet header. The server is in total control of

Clancy & Arbaugh Expires September 19, 2005 [Page 15]

Internet-Draft EAP-PAX March 2005

the ciphersuite, thus a client not supporting the specified
ciphersuite will not be able to authenticate. Additionally, each
clients' local security policy should specify secure ciphersuites the
client will accept. The ciphersuite specified in PAX_STD-1 and
PAX_IDP-1
PAX_SEC-1 MUST remain the same in successive packets within the same
authentication session. Since later packets are covered by an ICV
keyed with the ICK, the server can verify that the originally
transmitted ciphersuite was not altered by an adversary.

4.3.2 Mutual Authentication

Both PAX_STD and PAX_IDP PAX_SEC authenticate the client and the server, and
consequently achieve explicit mutual authentication. Notice however
that if PAX_STD is used with a weak key and no server-side
certificate, the server to client authentication is weak, as the
server may have cracked the client's key in order to forge a valid
authentication packet.

Clancy & Arbaugh Expires December 30, 2004 [Page 17]

Internet-Draft EAP-PAX July 2004

4.3.3 Integrity Protection

The ICV described in Section 3.3 provides integrity protection once
the integrity check key has been derived. The header values in the
unprotected packets can be verified when an ICV is received later in
the session.

4.3.4 Replay Protection

The

EAP-PAX is inherently designed to avoid replay attacks by
cryptographically binding each packet to the previous one. Also the
EAP sequence number in is covered by the header prevents ICV to further strengthen
resistance to replay attacks.

4.3.5 Confidentiality

With identity protection enabled, PAX_IDP PAX_SEC provides full
confidentiality.

4.3.6 Key Derivation

Session keys are derived using the PAX-KDF and fresh entropy supplied
by both the client and the server. Since the key hierarchy is
derived from the shared key, password, only someone with knowledge of that key
password is capable of deriving the session keys.

4.3.7 Key Strength

Authentication keys are 128 bits. The key generation is protected by
a public-key signature and Diffie-Hellman key exchange. It is
believed that a 3000-bit MODP public-key scheme is roughly equivalent
[RFC3766] to a 128-bit symmetric-key scheme. Consequently, EAP-PAX
requires the use of a Diffie-Hellman group with modulus larger than
3000. Also, the exponent used as the private DH parameter must be at

Clancy & Arbaugh Expires September 19, 2005 [Page 16]

Internet-Draft EAP-PAX March 2005

least twice as large as the key eventually generated. Consequently,
EAP-PAX uses 256-bit DH exponents. Thus, the authentication keys
contain the full 128 bits of security.

4.3.8 Dictionary Attack Resistance

EAP-PAX is resistant to dictionary attacks, except for the case where
a weak key password is initially used and the server is not using a
certificate for authentication. See section 4.1 for more information
on resistance to dictionary attacks.

4.3.9 Fast Reconnect

While a specific fast reconnection option is not included, execution
of EAP-PAX requires such minimal effort that the time required to
perform a full reauthentication is not prohibitive.

Clancy & Arbaugh Expires December 30, 2004 [Page 18]

Internet-Draft EAP-PAX July 2004

4.3.10 Session Independence

This protocol easily achieves backward secrecy through, among other
things, use of the PAX-KDF. Given a current session key, they can
neither discover the entropy used to generate it, nor the key used to
encrypt that entropy as it was transmitted across the network.

This protocol has coarse-grained forward secrecy. Compromised
session keys are only useful on data for that session, and one cannot
derive AK from them. If an attacker can discover AK, that value can
only be used to compromise session keys derived using that AK.
Reasonably frequent key password updates will help mitigate such attacks.

Session keys are independently generated using fresh nonces for each
session, and therefore the sessions are independent.

4.3.11 Fragmentation

Fragmentation and reassembly is supported through the fragmentation
flag in the header.

4.3.12 Channel Binding

EAP-PAX does not explicitly include any channel binding.

5. IANA Considerations

This document introduces one new IANA consideration.

It requires IANA to allocate a new EAP Type for EAP-PAX. EAP-PAX
and also requires IANA to maintain the namespace for the following
header fields: MAC ID, DH Group ID, and Public Key ID.

Clancy & Arbaugh Expires September 19, 2005 [Page 17]

Internet-Draft EAP-PAX March 2005

Allocation of values for these namespaces shall be reviewed by a
Designated Expert appointed by the IESG area director. The
Designated expert will post a request to the EAP WG mailing list (or
a successor designated by the Area Director) for comment and review,
including an Internet-Draft. Before a period of 30 days has passed,
the Designated Expert will either approve or deny the registration
request and publish a notice of the decision to the EAP WG mailing
list or its successor, as well as informing IANA. A denial notice
must be justified by an explanation and, in the cases where it is
possible, concrete suggestions on how the request can be modified so
as to become acceptable.

6. Acknowledgment

The authors would like to thank Jonathan Katz for discussion with
respect to provable security, Bernard Aboba for technical guidance,
and Florent Bersani for extensive feedback and suggestions. Finally,
the authors would like to thank the Defense Information Systems
Agency for initially funding this work.

7. References

7.1

7 Normative References

[FIPS113] National Institute for Standards and Technology, "Standard
on Computer Data Authentication", Federal Information
Processing Standard 113, May 1985.

[FIPS180] National Institute for Standards and Technology,

Clancy & Arbaugh Expires December 30, 2004 [Page 19]

Internet-Draft EAP-PAX July 2004
"Announcing the Secure Hash Standard", Federal Information
Processing Standard 180, April 1995.

[FIPS197] National Institute for Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", Federal Information Processing Standard 197,
November 2001.

[FIPS198] National Institute for Standards and Technology, "The
Keyed-Hash Message Technology, "The
Keyed-Hash Message Authentication Code", Federal
Information Processing Standard 198, March 2002.

[I-D.ietf-eap-keying]
Aboba, B., Simon, D., Arkko, J., Eronen, P. and H.
Levkowetz, "Extensible Authentication Code", Federal
Information Processing Standard 198, Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-05 (work in
progress), February 2005.

[I-D.walker-ieee802-req]
Stanley, D., Walker, J. and B. Aboba, "EAP Method
Requirements for Wireless LANs",

Clancy & Arbaugh Expires September 19, 2005 [Page 18]

Internet-Draft EAP-PAX March 2002. 2005

draft-walker-ieee802-req-04 (work in progress), August
2004.

[IEEE.80211]
Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11-1997,
1997.

[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.

[RFC2486]

[RFC2486bis]
Aboba, B. and M. B., Beadles, M., Arkko, J. and P. Eronen, "The
Network Access Identifier",
RFC 2486, January 1999.

[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.

[RFC2945] Wu, T., "The SRP Authentication
draft-ietf-radext-rfc2486bis-03 (work in progress).

[RFC3447] Jonsson, J. and Key Exchange System", B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 2945, September 2000. 3447, February 2003.

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.

Clancy & Arbaugh Expires December 30, 2004 [Page 20]

Internet-Draft EAP-PAX July 2004
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", RFC 3766,
April 2004.

[RFC3770] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks (WLAN)",
RFC 3770.

[X.509] International Telecommunications Union, "Information
technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks", Data
Networks and Open System Communication Recommendation
X.509, March 2000.

[X.690] International Telecommunications Union, "Information

Clancy & Arbaugh Expires September 19, 2005 [Page 19]

Internet-Draft EAP-PAX March 2005

technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", Data Networks and
Open System Communication Recommendation X.690, July 2002.

7.2 Informative References

[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
Password-based Protocols Secure Against Dictionary
Attack", IEEE Symposium on Research in Security and
Privacy, May 1992.

[DH76] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
1976.

[Gut04] Gutmann, P., "Simplifying Public Key Management", IEEE
Computer, February 2004.

[HK99] Halevi, S. and H. Krawczyk, "Public-key Cryptography and
Password Protocols", ACM Conference on Computer and
Communication Security, February 1999.

[Jab96] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", ACM Computer Communications Review, October
1996.

[I-D.bersani-eap-psk]
Bersani, F., "The EAP PSK Protocol", draft-bersani-eap-psk
(work in progress), March 2004.

[I-D.bersani-eap-synthesis-sharedkeymethods]
Bersani, F., "EAP shared key methods: a tentative
synthesis of those proposed so far",

Clancy & Arbaugh Expires December 30, 2004 [Page 21]

Internet-Draft EAP-PAX July 2004

draft-bersani-eap-synthesis-sharedkeymethods (work in
progress), April 2004.

[I-D.ietf-eap-keying]
Aboba, B., Simon, D., Arkko, J., Eronen, P. and H.
Levkowetz, Ed., "EAP Key Management Framework",
draft-ietf-eap-keying-02b (work in progress), November
2003.

[I-D.ietf-secsh-architecture]
Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-15 (work in progress),
October 2003.

[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
2759, January 2000.

Authors' Addresses

T. Charles Clancy
University of Maryland
4122 A.V. Williams Building
College Park, MD 20742
USA

EMail: clancy@cs.umd.edu

William A. Arbaugh
University of Maryland
4137 A.V. Williams Building
College Park, MD 20742
USA

EMail: waa@cs.umd.edu

Appendix A. Implementation Suggestions

In this section, two implementation strategies are discussed. The
first describes how best to implement and deploy EAP-PAX in an
enterprise network for 802.11i authentication. The second describes
how to use EAP-PAX for device authentication in a 3G-style mobile
phone network.

Clancy & Arbaugh Expires December 30, 2004 [Page 22]

Internet-Draft EAP-PAX July 2004

A.1 WiFi Enterprise Network

For the purposes of this section, a wireless enterprise network is
defined to have the following characteristics:

o Users wish to obtain network access through 802.11 access points.
o Users can possibly have multiple devices (laptops, PDAs, etc) they
wish to authenticate.
o A preexisting authentication framework already exists, for example
a Microsoft Active Directory domain or a Kerberos realm.

Two of the biggest challenges in an enterprise WiFi network is key
provisioning and support for multiple devices. Consequently, it is
recommended that the client's NAI have the format username/KID@realm,
where KID is a key ID that can be used to distinguish between

Clancy & Arbaugh Expires September 19, 2005 [Page 20]

Internet-Draft EAP-PAX March 2005

different devices.

The client's supplicant can use a variety of sources to automatically
generate the KID. Two of the better choices would likely be the
computer's NETBIOS name, or local Ethernet adapter's MAC address.
The wireless adapter's address may be a suboptimal choice, as the
user may only have one PCCARD adapter for multiple systems.

With an authentication system already in place, there is a natural
choice for the provisioned key. Clients can authenticate using their
preexisting key. password. When the server is presented with a new KID,
it can create a new key record on the server, and use the user's
current password as the provisioned key. For example, for Active
Directory, the supplicant could use Microsoft's NtPasswordHash
function
[RFC2759] to generate a key verifiable by the server. For security,
it is suggested that this key be fed through SHA1_128 before being
used in a non-Microsoft authentication protocol.

After a key update, the server SHOULD keep track of both the old and
new authentication key. When two keys exist, the server SHOULD
attempt to use both to validate the MACs on transmitted packets.
Once a client successfully authenticates using the new key, the
server SHOULD discard the old key. This prevents desynchronization
attacks.

A.2 Mobile Phone Network

In a mobile phone system, we no longer need to worry about supporting
multiple keys per identity. Presumably each mobile device has a
unique identity. However, if multiple devices per identity are
desired, a method similar to that presented in section A.1 could be
used.

Clancy & Arbaugh Expires December 30, 2004 [Page 23]

Internet-Draft EAP-PAX July 2004

Provisioning could easily be accomplished by issuing a customer a
4-digit
6-digit PIN they could type into their phone's keypad.

Clancy & Arbaugh Expires December 30, 2004 September 19, 2005 [Page 24] 21]

Internet-Draft EAP-PAX July 2004 March 2005

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.

Copyright (C) The Internet Society (2004). (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

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

Clancy & Arbaugh Expires December 30, 2004 September 19, 2005 [Page 25] 22]

----