WDIFF

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

Network Working Group T. Clancy
Internet-Draft W. Arbaugh
Expires: January 10, 2005 December 30, 2004 University of Maryland
July 12, 2004

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

Status of this Memo

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026.
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.
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 January 10, 2005. December 30, 2004.

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 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, and avoids intellectual property
rights associated with competing EAP methods.

EAP-PAX consists of two different authentication protocols: PAX-Auth
and PAX-Update. PAX-Auth is an extremely lightweight protocol in
which a preexisting strong authentication key is used to explicitly
authenticate the client to the server, and derive session keys. PAX_STD

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

Internet-Draft EAP-PAX July 2004

PAX-Update

and PAX_IDP. PAX_STD is a more complex simple mutual authentication and key
derivation protocol that mutually authenticates the
client capable of deriving session keys and server, derives a new long-lived
authentication key from keys. PAX_IDP is a
weak preshared secret, variant that additionally provides
identity protection, and finally derives session keys. requires a server-side certificate.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
1.1 Language Requirements . . . . . . . . . . . . . . . . . . 3 4
1.2 EAP Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.3 PAX Terminology . . 4
2. Overview . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . 6
2.1 PAX_STD Protocol . . . . . . . . . . . . . . . . . . . . . 5
2.1 PAX-Auth 7
2.2 PAX_IDP Protocol . . . . . . . . . . . . . . . . . . . . 6
2.2 PAX-Update Protocol . 7
2.3 Key Derivation . . . . . . . . . . . . . . . . . . . 6
2.3 . . . 8
2.4 Verification Requirements . . . . . . . . . . . . . . . . 8
2.5 PAX Key Derivation Function . . . . . . . . . . . . . . . 9
3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8 9
3.1 Header Specification . . . . . . . . . . . . . . . . . . . 8
3.2 Payload Formatting 10
3.1.1 Op-Code . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations
3.1.2 Flags . . . . . . . . . . . . . . . . . . . 11
4.1 Server Certificates . . . . . 10
3.1.3 MAC ID . . . . . . . . . . . . . . 12
4.2 Server Security . . . . . . . . . . 11
3.1.4 DH Group ID . . . . . . . . . . . 13
4.3 EAP Security Claims . . . . . . . . . . 12
3.1.5 Public Key ID . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . 12
3.1.6 Sequence Number . . . . . . . . . . 16
6. Acknowledgment . . . . . . . . . 12
3.2 Payload Formatting . . . . . . . . . . . . . . . 16
7. References . . . . . 12
3.3 Integrity Check Value (ICV) . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . 16
7.1 Normative References . . . . . . . . . . . . 15
4.1 Server Certificates . . . . . . . . 16
7.2 Informative References . . . . . . . . . . . 15
4.2 Server Security . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . 17
4.3 EAP Security Claims . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20

Clancy & Arbaugh Expires January 10, 2005 [Page 2]
Internet-Draft EAP-PAX July . . 17
4.3.1 Protected Ciphersuite Negotiation . . . . . . . . . . 17
4.3.2 Mutual Authentication . . . . . . . . . . . . . . . . 17
4.3.3 Integrity Protection . . . . . . . . . . . . . . . . . 18
4.3.4 Replay Protection . . . . . . . . . . . . . . . . . . 18
4.3.5 Confidentiality . . . . . . . . . . . . . . . . . . . 18
4.3.6 Key Derivation . . . . . . . . . . . . . . . . . . . . 18
4.3.7 Key Strength . . . . . . . . . . . . . . . . . . . . . 18
4.3.8 Dictionary Attack Resistance . . . . . . . . . . . . . 18
4.3.9 Fast Reconnect . . . . . . . . . . . . . . . . . . . . 18
4.3.10 Session Independence . . . . . . . . . . . . . . . . 19
4.3.11 Fragmentation . . . . . . . . . . . . . . . . . . . 19
4.3.12 Channel Binding . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
7.2 Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22

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

Internet-Draft EAP-PAX July 2004

A. Implementation Suggestions . . . . . . . . . . . . . . . . . 22
A.1 WiFi Enterprise Network . . . . . . . . . . . . . . . . . 23
A.2 Mobile Phone Network . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . 25

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

Internet-Draft EAP-PAX July 2004

1. Introduction

EAP-PAX, or Extensible Authentication Protocol -- Protocol, Password
Authenticated eXchange, is a secure EAP method designed for
authentication using a simple, short-term, shared secret. key. It provides a key update provisioning
mechanism suitable for deriving a strong authentication key from a
weak preshared password or PIN. Then using
the strong authentication key, it can derive session keys. The
password update mechanism is a Diffie-Hellman key exchange [RFC2631]
authenticated key. Two separate protocols, PAX_STD and PAX_IDP, are
defined, with the preshared password and optional server
certificate. The session key derivation is a simple nonce-based
authentication scheme distinguishing characteristic being that PAX_IDP
supports identity protection and MUST only be used with requires a strong shared
secret. server-side certificate.
Both techniques have been optimized for minimal client-side
complexity.

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 timeout expiration period has occurred, lapsed, the
authentication server forces a key update. During a key update, and the systems defaults to PAX-Update.
Otherwise,
rather than using a hash-based key exchange, the simpler PAX-Auth protocol is executed. 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 a
certificate,
certificate it can supply to the client when a weak key is being
used, the protocol supports a purely symmetric-key mode of operation
when identity protection is not required. However, in this mode the
protocol is vulnerable to an active man-in-the-middle off-line
dictionary attack during the initial key update, when if a weak key
generated from a provisioned password or PIN is being used. When all
the suggested security options are enabled, EAP-PAX is provably
secure under the Random Oracle model.

EAP-PAX includes built-in key management features, resistance to
dictionary attacks, and avoids intellectual property issues
associated with protocols such as EKE [BM92], SPEKE [Jab96], and SRP
[RFC2945][I-D.ietf-pppext-eap-srp].
[RFC2945]. 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 EAP Terminology

The following terminology is defined in

This section describes the EAP Key Management
Framework [I-D.ietf-eap-keying], various variables and functions used in
the PAX protocol. They will be referenced frequently in later
sections.

Clancy & Arbaugh Expires January 10, 2005 December 30, 2004 [Page 3] 4]

Internet-Draft EAP-PAX July 2004

peer
end client wishing to authenticate
authenticator
device initiating and enforcing authentication, often passing

Variables:

g
public Diffie-Hellman generator, typically 2
X, M
256-bit random integer generated by the
authentication through to a backend EAP server through an AAA
server; in 802.11, this is
Y, N
256-bit random integer generated by the Access Point (AP).
AAA server
Authentication, Authorization, and Accounting server responsible
for passing client
CID
EAP requests from the authenticator to the local client NAI [RFC2486]
SID
EAP server methods NAI [RFC2486]

Keys:

PK
EAP server
backend of the server's public key
CertPK
EAP methods, responsible server's certificate for performing public key PK
AK
authentication and key generation
EAP protocol
protocol between the peer and authenticator
AAA protocol
protocol shared between the authenticator client and the AAA EAP server
AK'
new authentication key generated during a key update
MK
Master Key shared between the peer client and EAP server from which all
other EAP method session keys are derived
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 for future use
IV
Initialization vector Vector used to seed stream ciphers; exported to the
authenticator

1.3 PAX Terminology

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

G
public Diffie-Hellman group
g
public generator of group G, typically 2
X
256-bit random integer generated by the client
Y
256-bit random integer generated by the server
K

Clancy & Arbaugh Expires January 10, 2005 [Page 4]
Internet-Draft EAP-PAX July 2004

EAP server's public key
CertK
EAP server's certificate for public key K
P
secret (weak password or strong key) shared between the client and
EAP server
P'
new strong shared key generated as a result of PAX-Update
IDc
client identity contained in the EAP Identity Response if not
using identity protection, and packets PAX-A2 and PAX-U2.
sign_X(Y)
digital signature of message Y with private key X

Operations:

enc_X(Y)
encryption of message Y with symmetric public key X
HMAC_X(Y)
MAC_X(Y)
keyed message authentication code [RFC2104][FIPS198] computed over message Y with
symmetric key X
TLS-PRF(X,

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

Internet-Draft EAP-PAX July 2004

PAX-KDF-W(X, Y, Z)
TLS Pseudorandom
PAX Key Derivation Function [RFC2246] computed using secret X, identifier Y,
and seed Z. Z, and producing W octets of output; defined in section
2.5
||
string or binary data concatination 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 are handled differently depending
on the link layer protocol, and are not discussed in this document.

+--------+ +---------+
| | Discovery EAP-Request/Identity | |
| CLIENT |<----------------------------------->| AUTHEN- |<------------------------------------| SERVER |
| | | TICATOR |
| | EAP Identity Request EAP-Response/Identity | |
| |<----------------------------------->| |------------------------------------>| |
| | | |
| | EAP Identity Response PAX_STD or PAX_IDP | |
| |------------------------------------>| |<------------------------------------| |
| |------------------------------------>| |
| |<------------------------------------| |
| |------------------------------------>| | PAX-Auth or PAX-Update
| | | |<----------------------------------->| |
| | EAP Success | |
| |<------------------------------------| | EAP Success
| | | |<------------------------------------| |

Clancy & Arbaugh Expires January 10, 2005 [Page 5]
Internet-Draft EAP-PAX July 2004
+--------+ +---------+

As mentioned above, there are two distinct protocols that can be
executed. The first, and simpler, is PAX-Auth. This is used when an
unexpired, strong key is being used to authenticate and generate
session keys. When used with an optional server certificate, this
protocol supports client identity protection.

The second protocol, PAX-Update, is used when an update of the
long-term key is required. It uses Diffie-Hellman to ensure the
forward secrecy of the new key, and then uses new credentials to
generate the required session keys. When +---------+

As mentioned earlier, there are two distinct protocols that can be
executed. The first, PAX_STD, is used with a server-side
certificate, PAX-Update provides client when identity protection and
security against off-line dictionary attacks. PAX-Update without a
certificate is only secure when a strong key is being used.

Each of the protocols are now defined.

2.1 PAX-Auth Protocol
not required. The PAX-Auth second, PAX_IDP provides this protection.

Each protocol has two modes of operation. When an AK update is a simple nonce-based authentication using being
performed, the strong long-term key. The client and server each exchange 256
bits of random data which is used to seed the TLS-PRF for generation
of session keys.

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

o PAX-A1 : client <- server : X, K, CertK
o PAX-A2 : client -> server : Enc_K( Y, IDc, HMAC_P( X, Y, IDc )) g^X and g^Y. When identity protection no
update is not required, being performed, and server-side
certificates are omitted, the protocol reduces to:

o PAX-A1 : client <- server : X
o PAX-A2 : client -> server : Y, IDc, HMAC_P( X, Y, IDc )

Session only session keys are computed as follows:

o MK = TLS-PRF( P, "Master Key", X || Y )
o MSK = TLS-PRF( MK, "Master Session Key", X || Y )
o EMSK = TLS-PRF( MK, "Extended Master Session Key", X || Y )
o IV = TLS-PRF( MK, "Initialization Vector", being derived, X ||
and Y )

2.2 PAX-Update Protocol

PAX-Update need only be performed if are exchanged. Using Diffie-Hellman during the current authentication key
has expired or update
provides forward secrecy, and secure key derivation when a weak
provisioned key is weak. If used.

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

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

Internet-Draft EAP-PAX July 2004

perform PAX-Update instead of PAX-Auth. The client MUST also refuse
to perform PAX-Auth if it has

hand can be accomplished using purely symmetric operations, provided
a weak or expired authentication key.

PAX-Update consists of three meaningful packets which establish
mutual authentication and provide the appropriate material for key
derivation. A fourth NULL packet update is sent from not being performed.

Each of the client to protocols are now defined.

2.1 PAX_STD Protocol

In the PAX_STD protocol, is a simple nonce-based authentication. The
client and server in the end each exchange 256 bits of random data which is used
to satisfy seed the challenge/response nature PAX-KDF for generation of the EAP
state machine. session keys.

The optional certificate and signature are used to
authenticate randomly exchanged data in the server when protocol differs depending on
whether a weak password key update is being used or to 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 identity protection if it forward secrecy and security when a weak key is required. See Section 4.1 for
more information on the risks associated with omitting used, let
the
server-side certificate. following be true when a key update is being performed:

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

The exchanges for PAX-Update: full protocol, when server-side certificates are used is as
follows:

o PAX-U1 PAX_STD-1 : client <- server : g^X, K, CertK A, SID, PK, CertPK
o PAX-U2 PAX_STD-2 : client -> server : Enc_K( g^Y, IDc, HMAC_P'( g^X, IDc Enc_PK( B, MAC_CK( A, B, CID, SID
))
o PAX-U3 PAX_STD-3 : client <- server : H_P'( g^X, g^Y, IDc MAC_CK( B, CID, SID )
o PAX-U4 PAX-ACK : client -> server : NULL
o P <- P'

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

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

2.2 PAX_IDP Protocol

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

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

Internet-Draft EAP-PAX July 2004

authentication.

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

The exchanges for PAX_IDP are as follows:

o PAX-U1 PAX_IDP-1 : client <- server : g^X M, SID, PK, CertPK
o PAX-U2 PAX_IDP-2 : client -> server : g^Y, IDc, HMAC_P'( g^X, IDc Enc_PK( M, N, CID )
o PAX-U3 PAX_IDP-3 : client <- server : H_P'( g^X, g^Y, IDc A, MAC_N( A, CID, SID )
o PAX-U4 PAX_IDP-4 : client -> server : NULL
o P <- P'

As with PAX-Auth, the only difference in the protocol when the
certificate is omitted, is that the public key information is left
out from the first packet and the second packet is not encrypted by
the client using B, MAC_CK( A, B, CID, SID )

2.3 Key Derivation

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

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

Once the DH

The IV is computed using a 16-octet NULL key. The value g^XY has been computed, it of AK' is
only used to seed the
TLS-PRF and compute replace AK if a new authentication key. This P' then replaces
P as the current password on both the client and server. Regardless
of the strength of P, P' key update is being performed. If a strong shared key immune to dictionary
attacks.

Clancy & Arbaugh Expires January 10, 2005 [Page 7]
Internet-Draft EAP-PAX July 2004

2.3
update is not performed, AK' need not be computed.

2.4 Verification Requirements

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

[PAX-A1 and PAX-U1]

PAX_STD-1/PAX_IDP-1 -> Client : If a public key and certificate are
included, the client MUST SHOULD either compare the public key to a
locally cached copy or use the certificate authority's public key to
validate the server's public key and certificate. server's public key and certificate. If this validation
fails, and the client's security policy prohibits the use of a
non-verifiable certificate, then the client MUST send an EAP-Failure
message.

PAX_STD-2 -> Server : After possibly decrypting the packet, the
server MUST validate the included MAC. This MAC serves to
authenticate the client to the server. If this validation fails, the
server MUST send an EAP-Failure message.

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

Internet-Draft EAP-PAX July 2004

PAX_IDP-2 -> Server : The server MUST verify that the decrypted value
of M matches the value transmitted in PAX_IDP-1. If this validation
fails, the client server MUST send an EAP-Failure message and disconnect.

[PAX-A2 and PAX-U2] message.

PAX_STD-3/PAX_IDP-3 -> Server Client : After possibly decrypting the packet,
the server The client MUST validate the included HMAC. This HMAC
transmitted MAC, as it serves to authenticate the client server to the server.
client. If this validation fails, the client MUST send an
EAP-Failure message and disconnect.

PAX-U3 message.

PAX_IDP-4 -> Client Server : The client must server MUST validate the HMAC transmitted in
PAX-U3, MAC,
as it serves to authenticate the server client to the client. server. If this
validation fails, the client server MUST send an EAP-Failure message 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 disconnect.

PAX-U4 -> Server : No validation 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 S = length in octets of the output of the MAC function
o M_i = MAC_X(Y || Z || i), where i is required. an 8-bit unsigned integer
o L = ceiling(W/S)
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, for the two values of
W used in this draft, we have:

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

3.1 Header Specification EAP-PAX packets have the following

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

Internet-Draft EAP-PAX July 2004

structure:

--- bit 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
+---------------+---------------+-------------------------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | Flags | HMAC MAC ID |
+---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group ID | Public Key ID | Sequence No | Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Payload ...
+---------------+---------------+-----------
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ICV ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2

3.1 Header Specification

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

Clancy & Arbaugh Expires January 10, 2005 [Page 8]
Internet-Draft EAP-PAX July 2004 field.

3.1.1 Op-Code

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

o 0x01 : PAX-Auth : PAX-A1 PAX_STD-1
o 0x02 : PAX-Auth : PAX-A2 PAX_STD-2
o 0x03 : PAX-Update : PAX-U1 PAX_STD-3
o 0x04 : PAX-Update 0x11 : PAX-U2 PAX_IDP-1
o 0x05 0x12 : PAX-Update PAX_IDP-2
o 0x13 : PAX-U3 PAX_IDP-3
o 0x06 0x14 : PAX-Update PAX_IDP-4
o 0x21 : PAX-U4 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 Enabled server-side certificate available (SSCA)
o 0x02 : Last Fragment public-key encryption required (PKER)
o 0x04 : public-key encryption used (PKEU)
o 0x08 : more fragments (MF)
o 0x10 - 0x80 : Reserved reserved

The certificate SSCA flag is set in packets of type PAX_STD-1 if and only if
those packets include the server's public key and certificate. For
PAX_STD packets of any other type, the SSCA flag MUST equal the value
of SSCA in the original PAX_STD-1 packet. When the PAX_IDP protocol
is used, SSCA MUST be set.

The PKER 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, the PKER
flag MUST equal the value of PKER in the original PAX_STD-1 packet.
PKER can only be set if SSCA is enabled set.

The PKEU flag MUST equal zero in packets of type PAX_STD-1 and
PAX_IDP-1. In packets of type PAX_STD-2, PKEU should 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. If in PAX_STD-1, PKER was set, PKEU
MUST be set in PAX_STD-2. If in PAX_STD-1, SSCA was set and PKER was
not set, PKEU MAY be set in PAX_STD-2.

In general, for PAX_STD, the server side
certificates are being used is responsible for setting SSCA
and PKER in this particular transaction, packet PAX_STD-1, while the client is responsible for
setting PKEU in packet PAX_STD-2. SSCA and
either 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-A2 or PAX-U2 will PAX_IDP-1, and MUST be encrypted. set in all other PAX_IDP
packets.

The fragment MF flag is enabled set if this particular packet represents the current packet in a series of
fragmented packets making up a single EAP-PAX message. required fragmentation, and
further fragments need to be transmitted. If a message
only contains one fragment, this packet does not
require fragmentation, the MF flag is enabled. 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.

3.1.3 HMAC MAC ID

The HMAC 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]
o 0x02 : AES_CBC_MAC_128 [FIPS113]

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:

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 signature public key ID field specifies the signature cipher used to
authenticate encrypt the server's DH exponent
client's EAP-Response in PAX-U1, PAX_STD-2 and provide client
identity protection.

Clancy & Arbaugh Expires January 10, 2005 [Page 9]
Internet-Draft EAP-PAX July 2004 PAX_IDP-2.

The following are currently supported:

o 0x00 : NONE (iff certificate flag = 0) SSCA is not set)
o 0x01 : RSA-OAEP-2048 RSA_OAEP_2048

If the SSCA flag is not set, the Public Key ID field MUST be zero.
Otherwise, 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 the sequence number to
0 for each transaction, and increments it for each packet. For every
EAP-Request/PAX packet fragment transmitted the associated
EAP-Response/PAX packet MUST contain a matching sequence number.
Packets with invalid sequence numbers MUST be silently discarded.

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-byte length. 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 byte octet arrays in network-byte order,
with the most significant byte first. Integers are padded on the
most significant end to reach byte boundaries. For example, a
128-bit integer I is saved in the 16-byte array b as follows:

I = b[0]*256^15 + b[1]*256^14 + ... + b[15]

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-terminanted not null-terminated and are encoded using 8-bit ASCII
characters. UTF-8. Binary
data, such as message authentication codes, are transmitted as-is.

HMACs

MACs are computed by concatenating the specified values in the
specified order. Strings are encoded as 8-bit ASCII characters, and
NOT null-terminated. Integers Values are encoded as specified above.

Packets of type PAX-U4 have a payload of described above, except that
no length zero. field is specified.

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

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

Clancy & Arbaugh Expires January 10, 2005 December 30, 2004 [Page 10] 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-byte 16-octet integer X A | 16-byte 16-octet integer Y B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length CID ...
| |
+-------------------------------+-------------------------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length IDc SID ...
+------------------
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

||
||
P
CK --> HMAC MAC
||
\/

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

With this, we can now create the encoded payload:

--- 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 | 16-byte integer Y | L | length L IDc ...
+---+-------------------------------+---+----------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16 | HMAC 16-octet integer B |16 | MAC computed above
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+---+-------------------------------+
+-+-+-+-+

These 32+L bytes 36 octets are then encrypted using the server's public key.
The output of the encryption algorithm is then 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, and PAX_IDP-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 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.

Clancy & Arbaugh Expires January 10, 2005 [Page 11]
Internet-Draft EAP-PAX July 2004

The security of PAX-Auth PAX can be easily proven proved using under the Random Oracle
model. In fact, the authentication portion can be proven
under the Standard Model, while the Random Oracle (RO) model is only
required to ensure secure session key generation. Assuming the
difficulty of the Decision Diffie Hellman problem, PAX-Update with a
strong key and without a certificate can be proven under the RO
model. PAX-Update with a weak key and with Key updates using a certificate is a slight variation on
Halevi and Krawczyk's proven proved mutually authenticated Diffie-Hellman
scheme [HK99].

4.1 Server Certificates

Since many vendors are leary leery of establishing a public key
infrastructure (PKI), or the client-side computation power required 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 password key (i.e. during registration), 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 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 integrity identity protection is required and a PKI is
infeasible. When integrity identity protection is not used, self-signed
certificates provide no additional security over no signatures at
all.

When using cached self-signed certificates in integrity protection
mode, 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 many
different multiple authentication servers. Provided a
client positively knows they will only interact with one backend
authentication server, even when roaming a self-signed, cached
certificate approach may be sufficient, depending on one's threat
model.

When the a PKI is not used, realize that a active man-in-the-middle
dictionary attack is possible during PAX-Update PAX_STD-1 if the client is
authenticating with a weak password and does not have the server's

Clancy & Arbaugh Expires January 10, 2005 [Page 12]
Internet-Draft EAP-PAX July 2004 weak key and does not have the server's public
key locally cached for verification. The effects of this can be
mitigated by performing registration provisioning in a controlled environment.

Specifically, in a certificateless environment, an attacker could
first forge a PAX-U1 PAX_STD-1 message and send it to the client. The
client would respond with a PAX-U2 PAX_STD-2 packet containing g^X and HMAC_P'(
MAC_CK( g^X || g^Y || IDc CID || SID ). The attacker can now guess
values of the weak P AK and compute P' CK = TLS-PRF(P, "Authentication PAX-KDF-16(AK, "Confirmation
Key", g^XY). Given enough time, the attacker can obtain both the old P
AK and new P', AK', and would then be capable of forging PAX-U3 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 registration. 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

4.2 Server Security

In order to maintain a reasonable security policy, the server must
maintain
manage four 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 or
not. 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 perfect forward secrecy described earlier, 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
the ciphersuite, thus a client not supporting the specified

Clancy & Arbaugh Expires January 10, 2005 [Page 13]
Internet-Draft EAP-PAX July 2004
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-A1 PAX_STD-1 and PAX-U1
PAX_IDP-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

When PAX-Auth

Both PAX_STD and PAX_IDP authenticate the client and the server, and
consequently achieve explicit mutual authentication. Notice however
that if PAX_STD is used, only 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 sequence number in the header prevents replay attacks.

4.3.5 Confidentiality

With identity protection enabled, PAX_IDP 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, only someone with knowledge of that key
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 explicitly authenticated.
The server
believed that a 3000-bit MODP public-key scheme is implicitly authenticated roughly equivalent
[RFC3766] to the client because only a
valid server would be able to generate 128-bit symmetric-key scheme. Consequently, EAP-PAX
requires the required session keys.
Thus use of a Diffie-Hellman group with PAX-Auth, mutual authentication is achieved only
implicitly. The client can only verify the server's authenticity
after receiving modulus larger than
3000. Also, the first packet encrypted with exponent used as the derived session
key.

On private DH parameter must be at
least twice as large as the other hand, PAX-Update authenticates both key eventually generated. Consequently,
EAP-PAX uses 256-bit DH exponents. Thus, the client and authentication keys
contain the
server, and consequently achieves explicit mutual authentication.
Notice however that if PAX-Update full 128 bits of security.

4.3.8 Dictionary Attack Resistance

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

4.3.9 Fast Reconnect

While a specific fast reconnection option is
weak, as the server may have cracked not included, execution
of EAP-PAX requires such minimal effort that the client's password in order time required to forge
perform a valid authentication packet.

4.3.3 Integrity Protection

The fields 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 EAP and EAP-PAX headers are not explicitly covered
by an integrity protection field. Since PAX-KDF. Given a current session key, they can
neither discover the identity entropy used to generate it, nor a
strong key may yet exist, there is no guarantee that a the key will be
available used to perform an HMAC. However, the security of the scheme is
not compromised by the lack of an integrity check field. The options
are validated and must agree with
encrypt that entropy as it was transmitted across the client's security policy.
Altered payloads will only create a denial of service condition.

4.3.4 Replay Protection

Replays network.

This protocol has coarse-grained forward secrecy. Compromised
session keys are avoided because replies include values from previous
requests. The only packets capable of being replayed are PAX-A1 useful on data for that session, and
PAX-U1. However, replaying these packets provides one cannot
derive AK from them. If an attacker with can discover AK, that value can
only a negligible advantage.

4.3.5 Confidentiality

With identity protection enabled, EAP-PAX provides full
confidentiality.

4.3.6 Key Derivation be used to compromise session keys derived using that AK.
Reasonably frequent key updates will help mitigate such attacks.

Session keys are derived 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.

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 TLS-PRF Defense Information Systems
Agency for initially funding this work.

7. References

7.1 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 fresh entropy supplied Technology,

Clancy & Arbaugh Expires January 10, 2005 December 30, 2004 [Page 14] 19]

Internet-Draft EAP-PAX July 2004

by both

"Announcing the client Secure Hash Standard", Federal Information
Processing Standard 180, April 1995.

[FIPS197] National Institute for Standards and Technology,
"Specification for the server. Since the key hierarchy is
derived from the shared password, only someone with knowledge of that
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 Advanced Encryption Standard
(AES)", Federal Information Processing Standard 197,
November 2001.

[FIPS198] National Institute for Standards 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
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.

Since the public-key is solely used to authenticate the server, its
compromise will not affect previously generated keys. Thus, provided
proper certificate management policies a smaller key size may be used
without affecting the derived authentication key strength.

While the session keys are each generated from 512 bits of entropy,
the entropy is exchanged using the 128-bit authentication key.
Therefore, they have at most 128 bits of security.

4.3.8 Dictionary Attack Resistance

EAP-PAX is resistant to dictionary attacks, except Technology, "The
Keyed-Hash Message Authentication Code", Federal
Information Processing Standard 198, March 2002.

[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 the case where
a weak password is initially used Security", RFC 1750, December 1994.

[RFC2104] Krawczyk, H., Bellare, M. and the server is not using a
certificate R. Canetti, "HMAC:
Keyed-Hashing for authentication. See section 4.1 Message Authentication", RFC 2104,
February 1997.

[RFC2119] Bradner, S., "Key words for more information
on resistance to dictionary attacks.

4.3.9 Fast Reconnect

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

4.3.10 Session Independence

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

This protocol has coarse-grained perfect forward secrecy. Compromised
session keys are only useful on data 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] Aboba, B. and M. Beadles, "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 and Key Exchange System",
RFC 2945, September 2000.

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

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and one cannot
derive P from them. If an attacker can discover P, that value can H.

Clancy & Arbaugh Expires January 10, 2005 December 30, 2004 [Page 15] 20]

Internet-Draft EAP-PAX July 2004

only be used to compromise session keys derived using that

Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.

[RFC3766] Orman, H. and P.
Reasonably frequent password updates will help mitigate such attacks.

Session keys are independently generated for each session, Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", RFC 3766,
April 2004.

[X.509] International Telecommunications Union, "Information
technology - Open Systems Interconnection - The Directory:
Public-key and
therefore the sessions are independent.

4.3.11 Fragmentation

Fragmentation attribute certificate frameworks", Data
Networks 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.

6. Acknowledgment

The authors would like to thank Jonathan Katz for discussion with
respect to provable security, Bernard Aboba for technical guidance, Open System Communication Recommendation
X.509, March 2000.

[X.690] International Telecommunications Union, "Information
technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Florent Bersani for extensive feedback
Distinguished Encoding Rules (DER)", Data Networks and suggestions. Finally,
the authors would like to thank the Defense Information Systems
Agency for initially funding this work.

7. References

7.1 Normative
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.

[FIPS180] National Institute for Standards and Technology,
"Announcing the Secure Hash Standard", Federal Information

[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 January 10, 2005 December 30, 2004 [Page 16] 21]

Internet-Draft EAP-PAX July 2004

Processing Standard 180,

draft-bersani-eap-synthesis-sharedkeymethods (work in
progress), 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 Authentication Code", Federal
Information Processing Standard 198, March 2002. 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-pppext-eap-srp]
Carlson, J., Aboba, B.

[I-D.ietf-secsh-architecture]
Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and H. Haverinen, "EAP SRP-SHA1
Authentication Protocol", draft-ietf-pppext-eap-srp-03 S.
Lehtinen, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-15 (work in progress), July 2001.

[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security",
October 2003.

[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 1750, December 1994.

[RFC2104] Krawczyk, H., Bellare, M.
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 R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.

[RFC2119] Bradner, S., "Key words deploy EAP-PAX in an
enterprise network for 802.11i authentication. The second describes
how to use EAP-PAX for device authentication 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.

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

[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", a 3G-style mobile
phone network.

Clancy & Arbaugh Expires January 10, 2005 December 30, 2004 [Page 17] 22]

Internet-Draft EAP-PAX July 2004

RFC 2945, September 2000.

[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.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used

A.1 WiFi Enterprise Network

For Exchanging Symmetric Keys", RFC 3766,
April 2004.

[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
technology - ASN.1 encoding rules: Specification the purposes 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

[DH76] Diffie, W. 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 M. Hellman, "New Directions 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
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
Cryptography", IEEE Transactions place, there is a natural
choice for the provisioned key. Clients can authenticate using their
preexisting key. When the server is presented with a new KID, it can
create a new key record on Information Theory,
1976.

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

[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 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 methods: verifiable by the server. For security,
it is suggested that this key be fed through SHA1_128 before being
used in a tentative
synthesis non-Microsoft authentication protocol.

After a key update, the server SHOULD keep track of those proposed so far",
draft-bersani-eap-synthesis-sharedkeymethods (work in
progress), April 2004.

[I-D.ietf-secsh-architecture]
Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. both the old and S.
Lehtinen, "SSH Protocol Architecture",
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 January 10, 2005 December 30, 2004 [Page 18] 23]

Internet-Draft EAP-PAX July 2004

draft-ietf-secsh-architecture-15 (work in progress),
October 2003.

Authors' Addresses

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

EMail: clancy@cs.umd.edu

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

EMail: waa@cs.umd.edu

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

Clancy & Arbaugh Expires January 10, 2005 December 30, 2004 [Page 19] 24]

Internet-Draft EAP-PAX July 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
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; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation RFC documents can be
found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

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 at
ietf-ipr@ietf.org.

Disclaimer 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 assignees. Validity

This document and the information contained herein is 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 DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION

Clancy & Arbaugh Expires January 10, 2005 [Page 20]
Internet-Draft EAP-PAX July 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2004). 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 [Page 25]

----