Network Working Group T. Clancy
Internet-Draft DoD/LTS
Expires: July 19, 2006 W. Arbaugh
UMD
January 15, 2006
EAP Password Authenticated Exchange
draft-clancy-eap-pax-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 July 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This Internet Draft defines a provably secure Extensible
Authentication Protocol method called EAP-PAX. This method is a
lightweight shared-key authentication protocol with optional support
for provisioning, key management, identity protection, and
authenticated data exchange.
Clancy & Arbaugh Expires July 19, 2006 [Page 1]
Internet-Draft EAP-PAX January 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Language Requirements . . . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 PAX_STD Protocol . . . . . . . . . . . . . . . . . . . . . 7
2.2 PAX_SEC Protocol . . . . . . . . . . . . . . . . . . . . . 7
2.3 Authenticated Data Exchange . . . . . . . . . . . . . . . 9
2.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Verification Requirements . . . . . . . . . . . . . . . . 11
2.6 PAX Key Derivation Function . . . . . . . . . . . . . . . 12
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 12
3.1 Header Specification . . . . . . . . . . . . . . . . . . . 13
3.1.1 Op-Code . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Flags . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3 MAC ID . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.4 DH Group ID . . . . . . . . . . . . . . . . . . . . . 14
3.1.5 Public Key ID . . . . . . . . . . . . . . . . . . . . 15
3.1.6 Mandatory to Implement . . . . . . . . . . . . . . . . 15
3.2 Payload Formatting . . . . . . . . . . . . . . . . . . . . 15
3.3 Authenticated Data Exchange (ADE) . . . . . . . . . . . . 18
3.4 Integrity Check Value (ICV) . . . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . 19
4.1 Server Certificates . . . . . . . . . . . . . . . . . . . 19
4.2 Server Security . . . . . . . . . . . . . . . . . . . . . 20
4.3 EAP Security Claims . . . . . . . . . . . . . . . . . . . 20
4.3.1 Protected Ciphersuite Negotiation . . . . . . . . . . 20
4.3.2 Mutual Authentication . . . . . . . . . . . . . . . . 21
4.3.3 Integrity Protection . . . . . . . . . . . . . . . . . 21
4.3.4 Replay Protection . . . . . . . . . . . . . . . . . . 21
4.3.5 Confidentiality . . . . . . . . . . . . . . . . . . . 21
4.3.6 Key Derivation . . . . . . . . . . . . . . . . . . . . 21
4.3.7 Key Strength . . . . . . . . . . . . . . . . . . . . . 21
4.3.8 Dictionary Attack Resistance . . . . . . . . . . . . . 22
4.3.9 Fast Reconnect . . . . . . . . . . . . . . . . . . . . 22
4.3.10 Session Independence . . . . . . . . . . . . . . . . 22
4.3.11 Fragmentation . . . . . . . . . . . . . . . . . . . 22
4.3.12 Channel Binding . . . . . . . . . . . . . . . . . . 22
4.3.13 Cryptographic Binding . . . . . . . . . . . . . . . 22
4.3.14 Negotiation Attack Prevention . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1 Normative References . . . . . . . . . . . . . . . . . . . 23
7.2 Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
A. Key Generation from Passwords . . . . . . . . . . . . . . . 26
Clancy & Arbaugh Expires July 19, 2006 [Page 2]
Internet-Draft EAP-PAX January 2006
B. Implementation Suggestions . . . . . . . . . . . . . . . . . 26
B.1 WiFi Enterprise Network . . . . . . . . . . . . . . . . . 26
B.2 Mobile Phone Network . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 28
Clancy & Arbaugh Expires July 19, 2006 [Page 3]
Internet-Draft EAP-PAX January 2006
1. Introduction
EAP-PAX (Password Authenticated eXchange), is an EAP method [RFC3748]
designed for authentication using a shared key. It makes use of two
separate subprotocols, PAX_STD and PAX_SEC. PAX_STD is a simple,
lightweight protocol for mutual authentication using a shared key,
supporting authenticated data exchange. PAX_SEC complements PAX_STD
by providing support for provisioning and identity protection using a
server-side 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 elapsed, the
authentication server forces a key update. Rather than using a
symmetric key exchange, the client and server perform a Diffie-
Hellman key exchange which provides forward secrecy.
Since implementing a PKI can be cumbersome, PAX_SEC defines multiple
client security policies, selectable based on one's threat model. In
the weakest mode, PAX_SEC allows the use of raw public keys
completely eliminating the need for a PKI. In the strongest mode,
PAX_SEC requires that EAP servers use certificates signed by a
trusted authority. In the weaker modes, during provisioning PAX_SEC
is vulnerable to a man-in-the-middle dictionary attack. In the
strongest mode, EAP-PAX is provably secure under the Random Oracle
model.
EAP-PAX supports the generation of strong key material; mutual
authentication; resistance to desynchronization, dictionary, and man-
in-the-middle attacks; ciphersuite extensibility with protected
negotiation; identity protection; and the authenticated exchange of
data, useful for implementing channel binding. These features
satisfy the EAP method requirements for wireless LANs [RFC4017],
making EAP-PAX 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
Clancy & Arbaugh Expires July 19, 2006 [Page 4]
Internet-Draft EAP-PAX January 2006
sections.
Variables:
CID
client NAI [RFC2486bis]
g
public Diffie-Hellman generator, typically 2
M
128-bit random integer generated by the server
N
128-bit random integer generated by the client
X
256-bit random integer generated by the server
Y
256-bit random integer generated by the client
Keys:
AK
authentication key shared between the client and EAP server
AK'
new authentication key generated during a key update
CertPK
EAP server's certificate containing public key PK
CK
Confirmation Key generated from the MK and used during
authentication to prove knowledge of AK
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
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
Clancy & Arbaugh Expires July 19, 2006 [Page 5]
Internet-Draft EAP-PAX January 2006
EAP server's public key
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
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.
||
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 underlying protocol, and are not discussed in this
document.
+--------+ +--------+
| | EAP-Request/Identity | |
| CLIENT |<------------------------------------| SERVER |
| | | |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-PAX (STD or SEC) | |
| |<----------------------------------->| |
| | ... ... | |
| |<----------------------------------->| |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
There are two distinct subprotocols that can be executed. The first,
PAX_STD, is used during typical authentications. The second, PAX_SEC
provides more secure features such as provisioning and identity
protection.
PAX_STD and PAX_SEC have two modes of operation. When an AK update
is being performed, the client and server exchange g^X and g^Y. When
Clancy & Arbaugh Expires July 19, 2006 [Page 6]
Internet-Draft EAP-PAX January 2006
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.
The main deployment difference between PAX_STD and PAX_SEC is that
PAX_SEC requires a server-side public key. For every authentication,
the client is required to compute a public-key encryption. PAX_STD
on the other hand uses purely symmetric operations, other than a
possible Diffie-Hellman exchange.
Each of the protocols are now defined.
2.1 PAX_STD Protocol
PAX_STD is a simple nonce-based 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, 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 is as follows:
o PAX_STD-1 : client <- server : A
o PAX_STD-2 : client -> server : B, CID, MAC_CK(A, B, CID),
[optional ADE]
o PAX_STD-3 : client <- server : MAC_CK(B, CID), [optional ADE]
o PAX-ACK : client -> server : [optional ADE]
See section 2.3 for more information on the ADE component.
2.2 PAX_SEC Protocol
PAX_SEC is the high-security protocol designed to provide identity
protection and support for provisioning. PAX_SEC requires a server-
side public key, and public key operations for every authentication.
Clancy & Arbaugh Expires July 19, 2006 [Page 7]
Internet-Draft EAP-PAX January 2006
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_SEC are as follows:
o PAX_SEC-1 : client <- server : M, PK or CertPK
o PAX_SEC-2 : client -> server : Enc_PK(M, N, CID)
o PAX_SEC-3 : client <- server : A, MAC_N(A, CID)
o PAX_SEC-4 : client -> server : B, MAC_CK(A, B, CID), [optional
ADE]
o PAX_SEC-5 : client <- server : MAC_CK(B, CID), [optional ADE]
o PAX-ACK : client -> server : [optional ADE]
See section 2.3 for more information on the ADE component.
Use of CertPK is optional in PAX_SEC, however careful consideration
should be applied depending on the intended use and desired level of
security. The following table describes the risks involved when
using PAX_SEC without a certificate.
Certificate | Provisioning | Identity
Mode | | Protection
==================+=====================+======================
No Certificate | MiTM offline | ID reveal attack
| dictionary attack |
------------------+---------------------+---------------------
Self-Signed | MiTM offline | ID reveal attack
Certificate | dictionary attack |
------------------+---------------------+---------------------
Certificate/PK | MiTM offline | ID reveal attack
Caching | dictionary attack | during first auth
------------------+---------------------+---------------------
CA-Signed | secure mutual | secure mutual
Certificate | authentication | authentication
When using PAX_SEC to support provisioning with a weak key, use of a
CA-signed certificate is RECOMMENDED. When not using a CA-signed
certificate, the initial authentication is vulnerable to 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 caching is RECOMMENDED. Caching
involves a client recording the public key of the EAP server and
verifying its consistency between sessions, similar to SSH.
Otherwise, an attacker can spoof an EAP server during a session and
gain knowledge of a client's identity.
Whenever certificates are used, clients MUST validate that the
Clancy & Arbaugh Expires July 19, 2006 [Page 8]
Internet-Draft EAP-PAX January 2006
certificate's extended key usage, KeyPurposeID, be either
"eapOverPPP" or "eapOverLAN" [RFC3770bis]. If the underlying EAP
transport protocol is known, then the client SHOULD differentiate
between these fields. For example, an 802.11 supplicant SHOULD
require KeyPurposeID == eapOverLAN.
When using EAP-PAX with Wireless LAN, clients SHOULD validate that
the certificate's wlanSSID extension match the SSID of the network to
which it is currently authenticating.
In order to facilitate discussion of packet validations, three client
security policies for PAX_SEC are defined.
open
Clients support both use of PK and CertPK. If CertPK is used, the
client MUST validate the KeyPurposeID.
caching
Clients save PK for each EAP server the first time it encounters
the server, and SHOULD NOT authenticate to EAP servers whose
public key has been changed. If CertPK is used, the client MUST
validate the 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 Authenticated Data Exchange
Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK
contain optional component ADE. This component is used to convey
authenticated data between the client and server during the
authentication. This feature can be used in a variety of ways,
including the implementation of channel bindings.
It is important to note that ADE is not encrypted, so any data
included will not be confidential. However, since these packets are
all protected by the ICV, authenticity is guaranteed.
The ADE element consists of an arbitrary number of subelements, each
with length and type specified. If the number and size of
subelements is too large, packet fragmentation will be necessary.
Vendor-specific options are supported. See section 3.3.
Note that more than 1.5 round trips may be necessary to execute a
particular authenticated protocol within EAP-PAX. In this case,
instead of sending an EAP-Success after receiving the PAX_ACK, the
server can continue sending PAX_ACK messages with attached elements.
The client responds to these PAX_ACK messages with PAX_ACK messages
Clancy & Arbaugh Expires July 19, 2006 [Page 9]
Internet-Draft EAP-PAX January 2006
possibly containing more ADE elements. Such an execution could look
something like the following:
+--------+ +--------+
| | PAX_STD-1 | |
| |<------------------------------------| |
| | PAX_STD-2(ADE[1]) | |
| |------------------------------------>| |
| | PAX_STD-3(ADE[2]) | |
| |<------------------------------------| |
| | PAX_ACK(ADE[3]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[4]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | PAX_ACK(ADE[i]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[i+1]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
2.4 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.
Clancy & Arbaugh Expires July 19, 2006 [Page 10]
Internet-Draft EAP-PAX January 2006
The EAP Key Managment Framework [I-D.ietf-eap-keying] recommends
specification of key names and scope. The EAP-PAX Method-ID is the
MID value computed as described above. The EAP peer name is the CID
value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is
an empty string.
2.5 Verification Requirements
In order for EAP-PAX to be secure, MACs must be properly verified
each step of the way. Any packet with an ICV (see section 3.3) that
fails validation must be silently discarded. After ICV validation,
the following checks must be performed:
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.
PAX_STD-3
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.
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.
PAX-ACK
If PAX-ACK is received in response to a message fragment, the
receiver continues the protocol execution. If PAX-ACK is received
in response to PAX_STD-3 or PAX_SEC-5, then the server MUST send
an EAP-Success message. This indicates a successful execution of
PAX.
Clancy & Arbaugh Expires July 19, 2006 [Page 11]
Internet-Draft EAP-PAX January 2006
2.6 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/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).
Consequently 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 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 structure:
Clancy & Arbaugh Expires July 19, 2006 [Page 12]
Internet-Draft EAP-PAX January 2006
--- 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 | MAC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group ID | Public Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ICV ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
3.1 Header Specification
The Code, Identifier, Length, and Type fields are all part of the EAP
header, and defined in [RFC3748]. IANA has allocated EAP Method Type
46 for EAP-PAX, thus the Type field in the EAP header MUST be 46.
3.1.1 Op-Code
The OP-Code field is one of six values:
o 0x01 : PAX_STD-1
o 0x02 : PAX_STD-2
o 0x03 : PAX_STD-3
o 0x11 : PAX_SEC-1
o 0x12 : PAX_SEC-2
o 0x13 : PAX_SEC-3
o 0x14 : 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
values:
Clancy & Arbaugh Expires July 19, 2006 [Page 13]
Internet-Draft EAP-PAX January 2006
o 0x01 : more fragments (MF)
o 0x02 : certificate enabled (CE)
o 0x04 : ADE Included (AI)
o 0x08 - 0x80 : reserved
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.
When using PAX_STD, the CE flag MUST be zero. When using PAX_SEC,
the CE flag MUST be set if PAX_SEC-1 includes CertPK. It MUST NOT be
set if PAX_SEC-1 includes PK. If CE is set in PAX_SEC-1, it MUST be
set in PAX_SEC-2, PAX_SEC-3, PAX_SEC-4, and PAX_SEC-5. If either
party detects an inconsistent value of the CE flag, he MUST send an
EAP-Failure message and discontinue the session.
The AI flag indicates the presence of an ADE element. AI MUST only
be set on packets on packets PAX_STD-2, PAX_STD-3, PAX_SEC-4,
PAX_SEC-5, and PAX_ACK if an ADE element is included. On packets of
other types, ADE elements MUST be silently discarded as they cannot
be authenticated.
3.1.3 MAC ID
The MAC field specifies the cryptographic hash used to generate the
keyed hash value. The following are currently supported:
o 0x01 : HMAC_SHA1_128 [FIPS198] [FIPS180]
o 0x02 : AES_CBC_MAC_128 [FIPS113] [FIPS197]
o 0x03 : HMAC_SHA256_128 [FIPS180]
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 : 2048-bit MODP Group (IANA DH Group 14) [RFC3526]
o 0x02 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526]
o 0x03 : NIST ECC Group P-256 [FIPS186]
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.
Clancy & Arbaugh Expires July 19, 2006 [Page 14]
Internet-Draft EAP-PAX January 2006
3.1.5 Public Key ID
The public key ID field specifies the cipher used to encrypt the
client's EAP-Response in PAX_SEC-2.
The following are currently supported:
o 0x00 : NONE (iff using PAX_STD)
o 0x01 : RSAES-OAEP [RFC3447]
o 0x02 : RSA-PKCS1-V1_5 [RFC3447]
o 0x03 : El-Gamal Over NIST ECC Group P-256 [FIPS186]
If PAX_STD is begin executed, the Public Key ID field MUST be zero.
If PAX_SEC is being executed, the Public Key ID field MUST NOT be
zero.
When using RSAES-OAEP, the hash algorithm and mask generation
algorithm used shall be the MAC specified by the MAC ID, keyed using
an all-zero key. The label shall be null.
The RSA-based schemes specified here do not dictacte the length of
the public keys. DER encoding rules will specify the key size in the
key or certificate. Key sizes SHOULD be used that reflect the
desired level of security.
3.1.6 Mandatory to Implement
The following ciphersuite is mandatory to implement, achieves roughly
112 bits of security, and is required for FIPS 140-2 [FIPS140]
compliance:
o HMAC_SHA1_128
o IANA DH Group 14 (2048 bits)
o RSA-PKCS1-V1_5 (RECOMMEND 2048-bit public key)
The following ciphersuite is RECOMMENDED and achieves 128 bits of
security:
o HMAC_SHA256_128
o IANA DH Group 15 (3072 bits)
o RSAES-OAEP (RECOMMEND 3072-bit public key)
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
Clancy & Arbaugh Expires July 19, 2006 [Page 15]
Internet-Draft EAP-PAX January 2006
ciphersuite, each value is prepended with a two-octet length value.
--- 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.
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. 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 July 19, 2006 [Page 16]
Internet-Draft EAP-PAX January 2006
--- 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||
||
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:
--- 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|32 | 32-octet integer B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L | |
+-+-+-+-+ +
| |
... L-byte CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16 | MAC computed above |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These 52+L octets are 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.
Clancy & Arbaugh Expires July 19, 2006 [Page 17]
Internet-Draft EAP-PAX January 2006
3.3 Authenticated Data Exchange (ADE)
This section describes the formatting of the ADE elements. ADE
elements can only occur on packets of type PAX_STD-2, PAX_STD-3,
PAX_SEC-4, PAX_SEC-5, and PAX_ACK. Values included in other packets
MUST be silently ignored.
The ADE element is preceeded by its two-octet length L. Each
subelement has first a two-octet length Li followed by a two-octet
type Ti. The entire ADE element looks as follows:
--- 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L |L1 |T1 | |
+-+-+-+-+-+-+ +
| |
... subADE-1, type T1, length L1 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |L2 |T2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... subADE-2, type T2, length L2 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | more subADE elements... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following type values have been allocated:
o 0x01 : Vendor Specific
o 0x02 : Client Channel Binding Data
o 0x03 : Server Channel Binding Data
The first three bytes of a subADE utilizing type code 0x01 must be
the vendor's Enterprise Number [RFC3232] as registered with IANA.
The format for such a subADE is as follows:
Clancy & Arbaugh Expires July 19, 2006 [Page 18]
Internet-Draft EAP-PAX January 2006
--- 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Li | 1 | ENi | |
+-+-+-+-+-+-+-+ +
| |
... subADE-i, type Vendor Specific , length Li, vendor ENi ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Channel binding subADEs have yet to be defined. Future IETF
documents will specify the format for these subADE fields.
3.4 Integrity Check Value (ICV)
The ICV is computed as the MAC over the entire EAP packet, including
the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC
is keyed using the 16-octet ICK, using the MAC type specified by the
MAC ID in the EAP-PAX header. For packets of type PAX_STD-1,
PAX_SEC-1, PAX_SEC-2, and 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
Any authentication protocol, especially one geared for wireless
environments, 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. Also note that the
security of PAX can be proved using under the Random Oracle model.
4.1 Server Certificates
PAX_SEC can be used in several configurations. It can be used with
or without a server-side certificate. Section 2.2 details the
possible modes and the resulting security risk.
When using PAX_SEC for identity protection and not using a 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
Clancy & Arbaugh Expires July 19, 2006 [Page 19]
Internet-Draft EAP-PAX January 2006
message and send it to the client. The client would respond with a
PAX_SEC-2 message containing his encrypted username. The attacker
can then use his associated private key to decrypt the client's
username. Use of key caching can reduce the risk of identity
revelation by allowing clients to detect when the EAP server to which
they are accustom has a different public key.
When provisioning with PAX_SEC and not using a CA-signed certificate,
an attacker could first forge a PAX_SEC-1 message and send it to the
client. The client would respond with a 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 guess values of the weak AK and compute CK = PAX-KDF(AK,
"Confirmation Key", g^XY). Given enough time, the 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 should
manage 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 B 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
ciphersuite will not be able to authenticate. Additionally, each
clients' local security policy should specify secure ciphersuites the
Clancy & Arbaugh Expires July 19, 2006 [Page 20]
Internet-Draft EAP-PAX January 2006
client will accept. The ciphersuite specified in PAX_STD-1 and
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_SEC authenticate the client and the server, and
consequently achieve explicit mutual authentication.
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
EAP-PAX is inherently designed to avoid replay attacks by
cryptographically binding each packet to the previous one. Also the
EAP sequence number is covered by the ICV to further strengthen
resistance to replay attacks.
4.3.5 Confidentiality
With identity protection enabled, 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 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 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.
Clancy & Arbaugh Expires July 19, 2006 [Page 21]
Internet-Draft EAP-PAX January 2006
4.3.8 Dictionary Attack Resistance
EAP-PAX is resistant to dictionary attacks, except for the case where
a weak 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.
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 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 includes support for the authenticated exchange of data using
its subADE fields. Fields have currently been allocated for channel
binding but their format has yet to be defined.
4.3.13 Cryptographic Binding
EAP-PAX does not include any cryptographic binding. This is relevent
only for tunneled methods.
4.3.14 Negotiation Attack Prevention
EAP is susceptible to an attack where an attacker uses NAKs to
Clancy & Arbaugh Expires July 19, 2006 [Page 22]
Internet-Draft EAP-PAX January 2006
convince an EAP client and server to use a less secure method, and
can be prevented using method-specific integrity protection on NAK
messages. Since EAP-PAX does not have suitable keys derived for this
integrity protection at the begining of a PAX conversation, this is
not included.
5. IANA Considerations
This document requires IANA to maintain the namespace for the
following header fields: MAC ID, DH Group ID, Public Key ID, and ADE
type.
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,
Jari Arkko for his expert review, and Florent Bersani for feedback
and suggestions. Finally, the authors would like to thank the
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 Technology, "Secure
Hash Standard", Federal Information Processing
Standard 180-2, August 2002.
[FIPS186] National Institute for Standards and Technology, "Digital
Signature Standard (DSS)", Federal Information Processing
Standard 186, May 1994.
Clancy & Arbaugh Expires July 19, 2006 [Page 23]
Internet-Draft EAP-PAX January 2006
[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 (HMAC)", Federal
Information Processing Standard 198, March 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2486bis]
Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier",
draft-ietf-radext-rfc2486bis-06 (work in progress),
July 2005.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 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.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3770bis]
Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks (WLAN)",
draft-ietf-pkix-rfc3770bis-03 (work in progress),
April 2005.
[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.
Clancy & Arbaugh Expires July 19, 2006 [Page 24]
Internet-Draft EAP-PAX January 2006
[X.690] International Telecommunications Union, "Information
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
[FIPS140] National Institute for Standards and Technology, "Security
Requirements for Cryptographic Modules", Federal
Information Processing Standard 140-2, May 2001.
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
Levkowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-06 (work in
progress), April 2005.
[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.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", RFC 3766,
April 2004.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "EAP Method
Requirements for Wireless LANs", RFC 4017, March 2005.
Authors' Addresses
T. Charles Clancy
Department of Defense
Laboratory for Telecommunication Sciences
College Park, MD 20740
USA
Email: clancy@cs.umd.edu
Clancy & Arbaugh Expires July 19, 2006 [Page 25]
Internet-Draft EAP-PAX January 2006
William A. Arbaugh
University of Maryland
Department of Computer Science
College Park, MD 20742
USA
Email: waa@cs.umd.edu
Appendix A. Key Generation from Passwords
If a 128-bit key is not available to bootstrap the authentication
process, then one must be generated from some sort of weak preshared
key. Note that the security of the hashing process is unimportant,
as long as it does not significantly decrease the password's entropy.
Resistance to dictionary attacks is provided by PAX_SEC.
Consequently, computing the SHA-1 of the password and truncating the
output to 128 bits is RECOMMENDED as a means of converting a weak
password to a key for provisioning.
When using other preshared credentials, such as a Kerberos DES key,
or an MD4-hashed MSCHAP password, to provision clients, these keys
SHOULD still be put through SHA-1 before being used. This serves to
protect the credentials from possible compromise, and also keeps
things uniform. As an example, consider provisioning using an
existing Kerberos credential. The initial key computation could be
SHA1_128(string2key(password)). The KDC, storing
string2key(password), would also be able to compute this initial key
value.
Appendix B. 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.
B.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.
Clancy & Arbaugh Expires July 19, 2006 [Page 26]
Internet-Draft EAP-PAX January 2006
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
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 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 to generate a key verifiable by the server. It is suggested
that this key then be fed through SHA1_128 before being used in a
non-Microsoft authentication protocol (see Appendix B).
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.
B.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.
Provisioning could easily be accomplished by issuing a customer a
6-digit PIN they could type into their phone's keypad.
Clancy & Arbaugh Expires July 19, 2006 [Page 27]
Internet-Draft EAP-PAX January 2006
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 Statement
Copyright (C) The Internet Society (2006). 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 July 19, 2006 [Page 28]
