Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
draft-cam-winget-eap-fast-provisioning-10
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5422.
|
|
|---|---|---|---|
| Authors | Joseph A. Salowey , Hao Zhou , Nancy Cam-Winget , David McGrew | ||
| Last updated | 2015-10-14 (Latest revision 2008-10-31) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5422 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Tim Polk | ||
| Send notices to | (None) |
draft-cam-winget-eap-fast-provisioning-10
Network Working Group N. Cam-Winget
Internet-Draft D. McGrew
Intended status: Informational J. Salowey
Expires: May 4, 2009 H. Zhou
Cisco Systems
October 31, 2008
Dynamic Provisioning using Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol (EAP-FAST)
draft-cam-winget-eap-fast-provisioning-10
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 May 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Cam-Winget, et al. Expires May 4, 2009 [Page 1]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Abstract
The flexible authentication via secure tunneling EAP method (EAP-
FAST) enables secure communication between a peer and a server by
using Transport Layer Security (TLS) to establish a mutually
authenticated tunnel. EAP-FAST also enables the provisioning
credentials or other information through this protected tunnel. This
document describes the use of EAP-FAST for dynamic provisioning.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Requirements . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. EAP-FAST Provisioning Modes . . . . . . . . . . . . . . . . . 6
3. Dynamic Provisioning using EAP-FAST Conversation . . . . . . . 8
3.1. Phase 1 TLS tunnel . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Server-Authenticated Phase 1 . . . . . . . . . . . . . 8
3.1.2. Server-Unauthenticated Phase 1 . . . . . . . . . . . . 8
3.2. Phase 2 - Tunneled Authentication and Provisioning . . . . 9
3.2.1. Server-Authenticated Tunneled Authentication . . . . . 9
3.2.2. Server-Unauthenticated Tunneled Authentication . . . . 10
3.2.3. Authenticating Using EAP-MSCHAPv2 . . . . . . . . . . 10
3.2.4. Use of other Inner EAP Methods for EAP-FAST
Provisioning . . . . . . . . . . . . . . . . . . . . . 11
3.3. Key Derivations Used in the EAP-FAST Provisioning
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Peer-Id, Server-Id and Session-Id . . . . . . . . . . . . 12
3.5. Network Access after EAP-FAST Provisioning . . . . . . . . 12
4. Information Provisioned in EAP-FAST . . . . . . . . . . . . . 14
4.1. Protected Access Credential . . . . . . . . . . . . . . . 14
4.1.1. Tunnel PAC . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. Machine Authentication PAC . . . . . . . . . . . . . . 15
4.1.3. User Authorization PAC . . . . . . . . . . . . . . . . 15
4.1.4. PAC Provisioning . . . . . . . . . . . . . . . . . . . 16
4.2. PAC TLV Format . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Formats for PAC Attributes . . . . . . . . . . . . . . 17
4.2.2. PAC-Key . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. PAC-Opaque . . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. PAC-Info . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.5. PAC-Acknowledgement TLV . . . . . . . . . . . . . . . 22
4.2.6. PAC-Type TLV . . . . . . . . . . . . . . . . . . . . . 22
4.3. Trusted Server Root Certificate . . . . . . . . . . . . . 23
4.3.1. Server-Trusted-Root TLV . . . . . . . . . . . . . . . 24
Cam-Winget, et al. Expires May 4, 2009 [Page 2]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
4.3.2. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Provisioning Modes and Man-in-the-middle Attacks . . . . . 28
6.1.1. Server-Authenticated Provisioning Mode and
Man-in-the-middle Attacks . . . . . . . . . . . . . . 28
6.1.2. Server-Unauthenticated Provisioning Mode and
Man-in-the-middle Attacks . . . . . . . . . . . . . . 28
6.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 30
6.3. Considerations in Selecting a Provisioning Mode . . . . . 31
6.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 31
6.5. Tunnel PAC Usage . . . . . . . . . . . . . . . . . . . . . 31
6.6. Machine Authentication PAC Usage . . . . . . . . . . . . . 31
6.7. User Authorization PAC Usage . . . . . . . . . . . . . . . 32
6.8. PAC Storage Considerations . . . . . . . . . . . . . . . . 32
6.9. Security Claims . . . . . . . . . . . . . . . . . . . . . 33
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37
A.1. Example 1: Successful Tunnel PAC Provisioning . . . . . . 37
A.2. Example 2: Failed Provisioning . . . . . . . . . . . . . . 38
A.3. Example 3: Provisioning a Authentication Server's
Trusted Root Certificate . . . . . . . . . . . . . . . . . 40
Appendix B. Recent Changes . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 45
Cam-Winget, et al. Expires May 4, 2009 [Page 3]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
1. Introduction
EAP-FAST [RFC4851] is an EAP method that can be used to mutually
authenticate peer and server. Credentials such as a pre-shared key,
certificate trust anchor or a Protected Access Credential (PAC) must
be provisioned to the peer before it can establish mutual
authentication with the server. In many cases, the provisioning of
such information presents deployment hurdles. Through the use of the
protected TLS [RFC4346] tunnel, EAP-FAST can enable dynamic in-band
provisioning to address such deployment obstacles.
1.1. Specification Requirements
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
Much of the terminology used in this document comes from [RFC3748].
The terms "peer" and "server" are used interchangeably with the terms
"EAP peer" and "EAP server" respectively. Additional terms are
defined below:
Man in the Middle (MitM)
An adversary that can successfully inject itself between a peer
and EAP server. The MitM succeeds by impersonating itself as a
valid peer or server.
Provisioning
Providing peer with a trust anchor, shared secret or other
appropriate information needed to establish a security
association.
Protected Access Credential (PAC)
Credentials distributed to a peer for future optimized network
authentication. The PAC consists of at most three components: a
shared secret, an opaque element and optional information. The
shared secret part contains the secret key shared between the peer
and server. The opaque part contains the shared secret encrypted
by a private key only known to the server. It is provided to the
peer and is presented back to the server when the peer wishes to
obtain access to network resources. Finally, a PAC may optionally
include other information that may be useful to the peer.
Cam-Winget, et al. Expires May 4, 2009 [Page 4]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Tunnel PAC
A set of credentials stored by the peer and consumed by both the
peer and the server to establish a TLS tunnel.
User Authorization PAC
A User Authorization PAC is server encrypted data containing
authorization information associated with a previously
authenticated user. The User Authorization PAC does not contain a
key, but rather it is generally bound to a Tunnel PAC which is
used with the User Authorization PAC.
Machine Authentication PAC
A Machine Authentication PAC contains server encrypted data
containing authorization information associated with a device. A
Machine Authentication PAC may be used instead of a Tunnel PAC to
establish the TLS tunnel to provide machine authentication and
authorization information. The Machine Authentication PAC is
useful in cases where the machine needs to be authenticated and
authorized to access a network before a user has logged in.
Cam-Winget, et al. Expires May 4, 2009 [Page 5]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
2. EAP-FAST Provisioning Modes
EAP-FAST supports two modes for provisioning:
1. Server-Authenticated Provisioning Mode - Provisioning inside a
TLS tunnel that provides server-side authentication.
2. Server-Unauthenticated Provisioning Mode - Provisioning inside an
anonymous TLS tunnel.
The EAP-FAST provisioning modes use EAP-FAST phase 2 inside a secure
TLS tunnel established during phase 1. [RFC4851] describes the EAP-
FAST phases in greater detail.
In the Server-Authenticated Provisioning Mode, the peer has
successfully authenticated the EAP server as part of EAP-FAST Phase 1
(i.e. TLS tunnel establishment). Additional exchanges MAY occur
inside the tunnel to allow the EAP Server to authenticate the EAP
peer before provisioning any information.
In the Server-Unauthenticated Provisioning Mode, an unauthenticated
TLS tunnel is established in the EAP-FAST Phase 1. The peer MUST
negotiate a TLS anonymous Diffie-Hellman based cipher suite to signal
that it wishes to use Server-Unauthenticateded Provisioning Mode.
This provisioning mode enables the bootstrapping of peers where the
peer lacks strong credentials usable for mutual authentication with
the server.
Since the server is not authenticated in the Server-Unauthenticated
Provisioning Mode, it is possible that an attacker may intercept the
TLS tunnel. If an anonymous tunnel is used then the peer and server
MUST negotiate and successfully complete an EAP method supporting
mutual authentication and key derivation as described in Section 6.
The peer then uses the Crypto-Binding TLV to validate the integrity
of the TLS tunnel, thereby verifying that the exchange was not
subject to a man-in-the-middle attack.
Server-Authenticated Provisioning Mode protects against the man-in-
the-middle, however it requires provisioning the peer with
credentials necessary to authenticate the server. Environments
willing to trade off the security risk of a man-in-the-middle for
ease of deployment can choose to use the Server-Unauthenticated
Provisioning Mode.
Assuming that an inner EAP method and Crypto-Binding TLV exchange is
successful, the server will subsequently provide credential
information, such as a shared key using a PAC TLV or the trusted
certificate root(s) of the server using a Server-Trusted-Root TLV.
Cam-Winget, et al. Expires May 4, 2009 [Page 6]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Once the EAP-FAST Provisioning conversation completes, the peer is
expected to use the provisioned credentials in subsequent EAP-FAST
authentications.
Cam-Winget, et al. Expires May 4, 2009 [Page 7]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
3. Dynamic Provisioning using EAP-FAST Conversation
The provisioning occurs in the following steps which are detailed in
the subsequent sections and in RFC 4851. First the EAP-FAST phase 1
TLS tunnel is established. During this process extra material is
extracted from the TLS key derivation for use as challenges in the
subsequent authentication exchange. Next, an inner EAP method, such
as EAP-MSCHAPv2, is executed within the EAP-FAST phase 2 TLS tunnel
to authenticate the client using the challenges derived from the
phase 1 TLS exchange. Following successful authentication and
Crypto-Binding TLV exchange, the server provisions the peer with PAC
information including the secret PAC-Key and the PAC-Opaque.
Finally, the EAP-FAST conversation completes with Result TLV
exchanges defined in RFC 4851. The exported EAP MSK and EMSK are
derived from a combination of the tunnel key material and key
material from the inner EAP method exchange.
3.1. Phase 1 TLS tunnel
3.1.1. Server-Authenticated Phase 1
The provisioning EAP-FAST exchange uses the same sequence as the EAP-
FAST authentication phase 1 to establish a protected TLS tunnel.
Implementations supporting this version of the Sever-Authenticated
Provisioning Mode MUST support the following TLS ciphersuites defined
in [RFC4346]:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Other TLS ciphersuites that provide server authentication and
encryption MAY be supported. The server MAY authenticate the peer
during the TLS handshake in Server-Authenticated Provisioning Mode.
To adhere to best security practices, the peer MUST validate the
server's certificate chain when performing server-side authentication
to obtain the full security benefits of Server-Authenticated
provisioning.
3.1.2. Server-Unauthenticated Phase 1
Implementations supporting this version of the Sever-Unauthenticated
Provisioning Mode MUST support the following TLS ciphersuites defined
in [RFC4346]:
TLS_DH_anon_WITH_AES_128_CBC_SHA
Anonymous cipher suites SHOULD NOT be allowed outside of EAP-FAST
Cam-Winget, et al. Expires May 4, 2009 [Page 8]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Server-Unauthenticated Provisioning Mode. Any cipher suites that are
used for Server-Unauthenticated Provisioning Mode MUST provide key
agreement contributed by both parties. Therefore, cipher suites
based on RSA key transport MUST NOT be used for this mode. Cipher
suites that are used for provisioning MUST provide encryption.
3.2. Phase 2 - Tunneled Authentication and Provisioning
Once a protected tunnel is established and the server is
unauthenticated, the peer and server MUST execute additional
authentication and perform integrity checks of the TLS tunnel. Even
if both parties are authenticated during TLS tunnel establishment the
peer and server MAY wish to perform additional authentication within
the tunnel. As defined in [RFC4851] the authentication exchange will
be followed by an Intermediate-Result TLV and a Crypto-Binding TLV if
the EAP method succeeded. The Crypto-Binding TLV provides a check on
the integrity of the tunnel with respect to the endpoints of the EAP
method. If the preceding is successful than a provisioning exchange
MAY take place. The provisioning exchange will use a PAC TLV
exchange if a PAC is being provisioned and a Server-Trusted-Root TLV
if a trusted root certificate is being provisioned. The provisioning
MAY be solicited by the peer or it MAY be unsolicited. The PAC TLV
exchange consists of the server distributing the PAC in a
corresponding PAC TLV to the peer and the peer confirming its receipt
in a final PAC TLV Acknowledgement message. The peer may also use
the PAC TLV to request that the server send a PAC. The provision
TLVs MAY be piggybacked on the Result TLV, following the Result TLV.
Many implementations process TLVs in the order they are received,
thus, for proper provisioning to occur, the Result TLV MUST precede
the TLVs to be provisioned (e.g. Tunnel PAC, Machine Authentication
PAC and User Authorization PAC). A PAC TLV MUST NOT be accepted if
it is not encapsulated in an encrypted TLS tunnel.
A fresh PAC MAY be distributed if the server detects that the PAC is
expiring soon. In-band PAC refreshing is through the PAC TLV
mechanism. The decision to refresh or not to refresh the PAC is
determined by the server. Based on the PAC-Opaque information, the
server MAY determine not to refresh a peer's PAC even if the PAC-Key
has expired.
3.2.1. Server-Authenticated Tunneled Authentication
If Server-Authenticated Provisioning Mode is in use then any EAP
method may be used within the TLS tunnel to authenticate the peer
that is allowed by the peer's policy.
Cam-Winget, et al. Expires May 4, 2009 [Page 9]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
3.2.2. Server-Unauthenticated Tunneled Authentication
If Server-Unauthenticated Provisioning Mode is in use then peer
authenticates the server and the server authenticates the peer within
the tunnel. The only method for performing authentication defined in
this version of EAP-FAST is EAP-MSCHAPv2 [EAP-MSCHAPv2] in a special
way as described in the following section. It is possible for other
methods to be defined to perform this authentication in the future.
3.2.3. Authenticating Using EAP-MSCHAPv2
Implementations of this version of the EAP-FAST Server-
Unauthenticated Provisioning Mode MUST support EAP-MSCHAPv2
[EAP-MSCHAPv2] as the inner authentication method. While other
authentication methods exist, EAP-MSCHAPv2 was chosen for several
reasons:
o Provide the ability of slowing an active attack by using a hash
based challenge-response protocol.
o The use of a challenge response protocol such as MSCHAPv2 provides
some ability to detect a man-in-the-middle attack during Server-
Unauthenticated Provisioning Mode.
o A large deployed base is already able to support MSCHAPv2.
o It allows support for password change during the EAP-FAST
provisioning modes.
When using an anonymous Diffie-Hellman key agreement and EAP-
MSCHAPv2, the challenges MUST be generated as defined in Section 3.3.
This forms a binding between the tunnel and the EAP-MSCHAPv2
exchanges by using keying material generated during the EAP-FAST
tunnel establishment as the EAP-MSCHAPv2 challenges instead of using
the challenges exchanged within the protocol itself. When EAP-
MSCHAPv2 is used within tunnel established using a cipher suite other
than one that provides anonymous key agreement the randomly generated
MSCHAPv2 challenges MUST be used.
The MSCHAPv2 [RFC2759] exchange forces the server to provide a valid
ServerChallengeResponse which must be a function of the server
challenge, peer challenge and password as part of its response. This
reduces the window of vulnerability of a man-in-the-middle spoofing
the server, by requiring the attacker to successfully break the
password within the peer's challenge response time limit.
Cam-Winget, et al. Expires May 4, 2009 [Page 10]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
3.2.4. Use of other Inner EAP Methods for EAP-FAST Provisioning
Once a protected tunnel is established, typically the peer
authenticates itself to the server before the server can provision
the peer. If the authentication mechanism does not support mutual
authentication and protection from man-in-the-middle attacks then
Server-Authenticated Provisioning Mode MUST be used. Within a server
side authenticated tunnel authentication mechanisms such as EAP-GTC
[I-D.zhou-emu-fast-gtc] MAY be used. This will enable peers using
other authentication mechanisms such as password database and one-
time passwords to be provisioned in-band as well. This version of
the EAP-FAST provisioning mode implementation MUST support both EAP-
GTC and EAP-MSCHAPv2 within the tunnel in Server-Authenticated
Provisioning Mode.
It should be noted that Server-Authenticated Provisioning Mode
provides significant security advantages over Server-Unauthenticated
Provisioning Mode even when EAP-MSCHAPv2 is being used as the inner
method. It protects the EAP-MSCHAPv2 exchanges from potential active
MitM attacks by verifying server's authenticity before exchanging
MSCHAPv2. Server-Authenticated Provisioning Mode is the recommended
provisioning mode. The EAP-FAST peer MUST use the Server-
Authenticated Provisioning Mode whenever it is configured with valid
trust root for a particular server.
3.3. Key Derivations Used in the EAP-FAST Provisioning Exchange
The TLS tunnel key is calculated according to the TLS version with an
extra 72 octets of key material derived from the end of the
key_block. Portions of the extra 72 octets are used for the EAP-FAST
provisioning exchange session key seed and as the random challenges
in the EAP-MSCHAPv2 exchange.
To generate the key material, compute
key_block = PRF(master_secret,
"key expansion",
server_random +
client_random);
until enough output has been generated.
For example, the key_block for TLS 1.0 [RFC2246] is partitioned as
follows:
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
Cam-Winget, et al. Expires May 4, 2009 [Page 11]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
and the key_block for TLS 1.1 [RFC4346] is partitioned as follows:
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
The extra key material, session_key_seed is used for the EAP-FAST
Crypto-Binding TLV exchange while the ServerChallenge and
ClientChallenge correspond to the authentication server's MSCHAPv2
challenge and the peer's MSCHAPv2 challenge respectively. The
ServerChallenge and ClientChallenge are only used for the MSCHAPv2
exchange when Diffie-Hellman anonymous key agreement is used in the
EAP-FAST tunnel establishment.
3.4. Peer-Id, Server-Id and Session-Id
The provisioning modes of EAP-FAST does not change the general EAP-
FAST protocol and thus how the Peer-Id, Server-Id and Session-Id are
determined is based on the [RFC4851] techniques.
[RFC4851] Section 3.4 describes how the Peer-Id and Server-Id are
determined; Section 3.5 describes how the Session-Id is generated.
3.5. Network Access after EAP-FAST Provisioning
After successful provisioning, network access MAY be granted or
denied depending upon server policy. For example, in the Server-
Authenticated Provisioning Mode, access can be granted after the EAP
server has authenticated the peer and provisioned the peer with a
Tunnel PAC (i.e. a PAC used to mutually authenticate and establish
the EAP-FAST tunnel). Additionally, peer policy MAY instruct the
peer to disconnect the current provisioning connection and initiate a
new EAP-FAST exchange for authentication utilizing the newly
provisioned information. At the end of the Server-Unauthenticated
Provisioning Mode, network access SHOULD NOT be granted as this
conversation is intended for provisioning only and thus no network
Cam-Winget, et al. Expires May 4, 2009 [Page 12]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
access is authorized. The server MAY grant access at the end of a
successful Server-Authenticated provisioning exchange.
If after successful provisioning access to the network is denied, the
EAP Server SHOULD conclude with an EAP Failure. The EAP Server SHALL
NOT grant network access or distribute any session keys to the NAS if
this exchange is not intended to provide network access. Even though
provisioning mode completes with a successful inner termination (e.g.
successful Result TLV), server policy defines whether the peer gains
network access or not. Thus, it is feasible for the server, while
providing a successful Result TLV may conclude that its
authentication policy was not satisfied and terminate the
conversation with an EAP Failure.
Denying network access after EAP-FAST Provisioning may cause
disruption in scenarios such as wireless devices (e.g. in IEEE 802.11
devices, an EAP Failure may trigger a full 802.11 disassociation).
While a full EAP restart can be performed, a smooth transition to the
subsequent EAP-FAST authentications to enable network access can be
achieved by the peer or server initiating TLS renegotiation, where
the newly provisioned credentials can be used to establish a server
authenticated or mutually authenticated TLS tunnel for
authentication. Either the peer or server may reject the request for
TLS renegotiation. Upon completion of the TLS negotiation and
subsequent authentication, normal network access policy on EAP-FAST
authentication can be applied.
Cam-Winget, et al. Expires May 4, 2009 [Page 13]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
4. Information Provisioned in EAP-FAST
Multiple types of credentials MAY be provisioned within EAP-FAST.
The most common credential is the Tunnel PAC that is used to
establish the EAP-FAST phase 1 tunnel. In addition to the Tunnel
PAC, other types of credentials and information can also be
provisioned through EAP-FAST. They may include trusted root
certificates, PACs for specific purposes, and user identities to name
a few. Typically, provisioning is invoked after both peer and server
authenticate each other and after a successful Crypto-Binding TLV
exchange. However, depending on the information being provisioned,
mutual authentication MAY not be needed.
At minimum, either the peer or server must prove authenticity before
credentials are provisioned to ensure that information is not freely
provisioned to or by adversaries. For example, the EAP server may
not need to authenticate the peer to provision the peer with trusted
root certificates. However, the peer SHOULD authenticate the server
before it can accept a trusted server root certificate.
4.1. Protected Access Credential
A Protected Access Credential (PAC) is a security credential
generated by the server that holds information specific to a peer.
The server distributes all PAC information through the use of a PAC
TLV. Different types of PAC information are identified through the
PAC Type and other PAC attributes defined in this section. This
document defines three types of PACs: a Tunnel PAC, a Machine
Authentication PAC and a User Authorization PAC.
4.1.1. Tunnel PAC
The server distributes the Tunnel PAC to the peer, which uses it in
subsequent attempts to establish a secure EAP-FAST TLS tunnel with
the server. The Tunnel PAC includes a secret key (PAC-Key), data
that is opaque to the peer (PAC-Opaque) and other information (PAC-
Info) which the peer can interpret. The opaque data is generated by
the server and cryptographically protected so it cannot be modified
or interpreted by the peer. The Tunnel PAC conveys the server policy
of what must and can occur in the protected phase 2 tunnel. It is up
to the server policy to include what is necessary in a PAC-Opaque to
enforce the policy in subsequent TLS handshakes. For example, user
identity, I-ID, can be included as the part of the server policy.
This I-ID information limits the inner EAP methods to be carried only
on the specified user identity. Other types of information can also
be included, such as which EAP method(s) and which TLS ciphersuites
are allowed. If the server policy is not included in a PAC-Opaque,
then there is no limitation imposed by the PAC on the usage of the
Cam-Winget, et al. Expires May 4, 2009 [Page 14]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
inner EAP methods or user identities inside the tunnel established by
the use of that PAC.
4.1.2. Machine Authentication PAC
The Machine Authentication PAC contains information in the PAC-Opaque
that identifies the machine. It is meant to be used by a machine
when network access is required and no user is logged in. Typically
a server will only grant the minimal amount of access required for a
machine without a user present based on the Machine Authentication
PAC. The Machine Authentication PAC MAY be provisioned during the
authentication of a user. It SHOULD be stored by the peer in a
location that is only accessible to the machine. This type of PAC
typically persists across sessions.
The peer can use the Machine Authentication PAC as the Tunnel PAC to
establish the TLS tunnel. The EAP server MAY have a policy to bypass
additional inner EAP method and grant limited network access based on
information in the Machine Authentication PAC. Server MAY request
additional exchanges to validate machine's other authorization
criteria, such as posture information etc., before granting network
access.
4.1.3. User Authorization PAC
The User Authorization PAC contains information in the PAC opaque
that identifies a user and provides authorization information. This
type of PAC does not contain a PAC-Key. It is presented within the
protected EAP-FAST TLS tunnel to provide user information during
stateless session resume so user authentication MAY be skipped. The
User Authorization PAC MAY be provisioned after user authentication.
It is meant to be short lived and not persisted across logon
sessions. The User Authorization PAC SHOULD only be available to the
user for which it is provisioned. The User Authorization PAC SHOULD
be deleted from the peer when the local authorization state of a
user's session changes, such as upon the user logs out.
Once the EAP-FAST phase 1 TLS tunnel is established the peer MAY
present a User Authorization PAC to the server in a PAC TLV. This is
sent as TLS application data, but it MAY be included in the same
message as the Finished Handshake message sent by the peer. The User
Authorization PAC MUST only be sent within the protection of an
encrypted tunnel to an authenticated entity. The server will decrypt
the PAC and evaluate the contents. If the contents are valid and the
server policy allows the session to be resumed based on this
information then the server will complete the session resumption and
grant access to the peer without requiring an inner authentication
method. This is called stateless session resume in EAP-FAST. In
Cam-Winget, et al. Expires May 4, 2009 [Page 15]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
this case the server sends the Result TLV indicating success without
the Crypto-Binding TLV and the peer sends back a Result TLV
indicating success. If the User Authorization PAC fails the server
validation or the server policy the server MAY either reject the
request or continue with performing full user authentication within
the tunnel.
4.1.4. PAC Provisioning
To request provisioning of a PAC, a peer sends a PAC TLV containing a
PAC attribute of PAC Type set to the appropriate value. For a Tunnel
PAC the value is '1', for a Machine Authentication PAC the value is
'2' and for a User Authorization PAC the value is '3'. The request
MAY be issued after the peer has determined that it has successfully
authenticated the EAP Server and validated the Crypto-Binding TLV to
ensure that the TLS tunnel's integrity is intact. Since anonymous DH
ciphersuites are only allowed for provisioning a Tunnel PAC, if an
anonymous ciphersuite is negotiated the Tunnel PAC MAY be provisioned
automatically by the server. The peer MUST send separate PAC TLVs
for each type of PAC they want to provision. Multiple PAC TLVs can
be sent in the same packet or different packets. When requesting the
Machine Authentication PAC the peer SHOULD include an I-ID TLV
containing the machine name prefixed by "host/". The EAP server will
send the PACs after its internal policy has been satisfied; or it MAY
ignore the request or request additional authentications if its
policy dictates. If a peer receives a PAC with unknown type, it MUST
ignore it.
A PAC-TLV containing PAC-Acknowledge Attribute MUST be sent by peer
to acknowledge the receipt of the Tunnel PAC. PAC-Acknowledge TLV
MUST NOT be used from peer to acknowledge the receipt of other types
of PACs.
Please see Appendix A.1 for an example of packet exchanges to
provision a Tunnel PAC.
4.2. PAC TLV Format
The PAC TLV provides support for provisioning the Protected Access
Credential (PAC) defined within [RFC4851]. The PAC TLV carries the
PAC and related information within PAC attribute fields.
Additionally, the PAC TLV MAY be used by the peer to request
provisioning of a PAC of the type specified in the PAC Type PAC
Attribute. The PAC TLV MUST only be used in a protected tunnel
providing encryption and integrity protection. A general PAC TLV
format is defined as follows:
Cam-Winget, et al. Expires May 4, 2009 [Page 16]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
11 - PAC TLV
Length
Two octets containing length of the PAC Attributes field in
octets
PAC Attributes
A list of PAC attributes in the TLV format
4.2.1. Formats for PAC Attributes
Each PAC Attribute in a PAC TLV is formatted as a TLV defined as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cam-Winget, et al. Expires May 4, 2009 [Page 17]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Type
The type field is two octets, denoting the attribute type
Allocated Types include:
1 - PAC-Key
2 - PAC-Opaque
3 - PAC-Lifetime
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type
Length
Two octets containing the length of the value field in
octets.
Value
The value of the PAC Attribute
4.2.2. PAC-Key
The PAC-Key is a secret key distributed in a PAC attribute of type
PAC-Key. The PAC-Key attribute is included within the PAC TLV
whenever the server wishes to issue or renew a PAC that is bound to a
key such as a Tunnel PAC. The key is a randomly generated octet
string 32 octets in length. The key is represented as an octet
string. The generator of this key is the issuer of the credential,
identified by the A-ID.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cam-Winget, et al. Expires May 4, 2009 [Page 18]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Type
1 - PAC-Key
Length
2 octet length indicating a 32 octet long key
Key
The value of the PAC-key
4.2.3. PAC-Opaque
The PAC-Opaque attribute is included within the PAC TLV whenever the
server wishes to issue or renew a PAC.
The PAC-Opaque is opaque to the peer and thus the peer MUST NOT
attempt to interpret it. A peer that has been issued a PAC-Opaque by
a server stores that data, and presents it back to the server
according to its PAC Type. The Tunnel PAC is used in the ClientHello
SessionTicket extension field defined in [RFC5077]. If a peer has
opaque data issued to it by multiple servers, then it stores the data
issued by each server separately according to A-ID. This requirement
allows the peer to maintain and use each opaque data as an
independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque
identified by the A-ID. As there is a one to one correspondence
between PAC-Key and PAC-Opaque, the peer determines the PAC-Key and
corresponding PAC-Opaque based on the A-ID provided in the EAP-FAST/
Start message and the A-ID provided in the PAC-Info when it was
provisioned with a PAC-Opaque.
The PAC-Opaque attribute format is summarized as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cam-Winget, et al. Expires May 4, 2009 [Page 19]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Type
2 - PAC-Opaque
Length
The Length filed is two octets, which contains the length of
the value field in octets
Value
The value field contains the actual data for PAC-Opaque. It is
specific to the server implementation.
4.2.4. PAC-Info
PAC-Info is comprised of a set of PAC attributes as defined in
Section 4.2.1. The PAC-Info attribute MUST contain the A-ID, A-ID-
Info, and PAC-Type attributes. Other attributes MAY be included in
the PAC-Info to provide more information to the peer. The PAC-Info
attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-Info
or PAC-Opaque attributes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9 - PAC-Info
Length
Two octet length field containing the length of the Attributes
field in octets
Attributes
The Attributes field contains a list of PAC Attributes Each
mandatory and optional field type is defined as follows:
Cam-Winget, et al. Expires May 4, 2009 [Page 20]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
3 - PAC-LIFETIME
This is a 4 octet quantity representing the expiration time
of the credential expressed as the number of seconds,
excluding leap seconds, after midnight UTC, January 1, 1970.
This attribute MAY be provided to the peer as part of PAC-
Info.
4 - A-ID
A-ID is the identity of the authority that issued the PAC.
The A-ID is intended to be unique across all issuing servers
to avoid namespace collisions. The A-ID is used by the peer
to determine which PAC to employ. The A-ID is treated as an
opaque octet string. This attribute MUST be included in the
PAC-Info attribute. The A-ID MUST match the A-ID the server
used to establish the tunnel. Since many existing
implementations expect the A-ID to be 16 octets in length,
it is RECOMMENDED that length of an A-ID be 16 octets for
maximum interoperability. One method for generating the
A-ID is to use a high quality random number generator to
generate a 16-octet random number. An alternate method
would be to take the hash of the public key or public key
certificate belonging a server represented by the A-ID.
5 - I-ID
Initiator identifier (I-ID) is the peer identity associated
with the credential. This identity is derived from the
inner EAP exchange or from the client side authentication
during tunnel establishment if inner EAP method
authentication is not used. The server employs the I-ID in
the EAP-FAST Phase 2 conversation to validate that the same
peer identity used to execute EAP-FAST Phase 1 is also used
in at minimum one inner EAP method in EAP-FAST Phase 2. If
the server is enforcing the I-ID validation on inner EAP
method, then I-ID MUST be included in PAC-Info, to enable
the peer to also enforce a unique PAC for each unique user.
If I-ID is missing from the PAC-Info, it is assumed that the
Tunnel PAC can be used for multiple users and peer will not
enforce the unique Tunnel PAC per user policy.
7 - A-ID-Info
Authority Identifier Information is intended to provide a
user-friendly name for the A-ID. It may contain the
enterprise name and server name in a human-readable format.
This TLV serves as an aid to the peer to better inform the
Cam-Winget, et al. Expires May 4, 2009 [Page 21]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
end-user about the A-ID. The name is encoded as UTF-8
[RFC3629] format. This attribute MUST be included in the
PAC-Info.
10 - PAC-type
PAC-Type is intended to provide the type of PAC. This
attribute SHOULD be included in the PAC-Info. If PAC-Type
is not present, then it defaults to a Tunnel PAC (Type 1).
4.2.5. PAC-Acknowledgement TLV
The PAC-Acknowledgement is used to acknowledge the receipt of the
Tunnel PAC by the peer. The peer includes the PAC-Acknowledgement
TLV in a PAC-TLV sent to the server to indicate the result of the
processing and storing of a newly provisioned Tunnel PAC. This TLV
is only used when Tunnel PAC is provisioned.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8 - PAC-Acknowledgement
Length
The length of this field is two octets containing a value of 2.
Result
The resulting value MUST be one of the following:
1 - Success
2 - Failure
4.2.6. PAC-Type TLV
The PAC-Type TLV is a TLV intended to specify the PAC type. It is
included in a PAC-TLV sent by the peer to request PAC provisioning
from the server. Its format is described below.
Cam-Winget, et al. Expires May 4, 2009 [Page 22]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
10 - PAC-Type
Length
Two Octet length field with a value of 2
PAC Type
This two octet field defined the type of PAC being requested or
provisioned. The following values are defined:
1 - Tunnel PAC
2 - Machine Authentication PAC
3 - User Authorization PAC
4.3. Trusted Server Root Certificate
Server-Trusted-Root TLV facilitates the request and delivery of a
trusted server root certificate. The Server-Trusted-Root TLV can be
exchanged in regular EAP-FAST Authentication mode or Provisioning
mode. The Server-Trusted-Root TLV is always marked as optional, and
cannot be responded to with a NAK TLV. The Server-Trusted-Root TLV
MUST only be sent as an inner TLV (inside the protection of the
tunnel).
After the peer has determined that it has successfully authenticated
the EAP server and validated the Crypto-Binding TLV, it MAY send one
or more Server-Trusted-Root TLVs (marked as optional) to request the
trusted server root certificates from from the EAP server. The EAP
server MAY send one or more root certificates with a PKCS#7 TLV
inside Server-Trusted-Root TLV. The EAP server MAY also choose not
to honor the request. Please see Section Appendix A.3 for an example
of a server provisioning a server trusted root certificate.
Cam-Winget, et al. Expires May 4, 2009 [Page 23]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
4.3.1. Server-Trusted-Root TLV
The Server-Trusted-Root TLV allows the peer to send a request to the
EAP server for a list of trusted roots. The server may respond with
one or more root certificates in PKCS#7 [RFC2315] format.
If the EAP server sets credential format to PKCS#7-Server-
Certificate-Root, then the Server-Trusted-Root TLV should contain the
root of the certificate chain of the certificate issued to the EAP
server packaged in a PKCS#7 TLV. If the Server certificate is a
self-signed certificate, then the root is the self-signed
certificate.
If the Server-Trusted-Root TLV credential format contains a value
unknown to the peer, then the EAP peer should ignore the TLV.
The Server-Trusted-Root TLV is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Non-mandatory TLV
R
Reserved, set to zero (0)
TLV Type
18 - Server-Trusted-Root TLV [RFC4851]
Length
>=2 octets
Credential-Format
The Credential-Format field is two octets. Values include:
Cam-Winget, et al. Expires May 4, 2009 [Page 24]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
1 - PKCS#7-Server-Certificate-Root
Cred TLVs
This field is of indefinite length. It contains TLVs
associated with the credential format. The peer may leave
this field empty when using this TLV to request server
trust roots.
4.3.2. PKCS#7 TLV
The PKCS#7 TLV is sent by the EAP server to the peer inside the
Server-Trusted-Root TLV. It contains PKCS #7 [RFC2315] wrapped X.509
certificates. The format consists of a certificate or certificate
chain in a Certificates-Only PKCS#7 SignedData message as defined in
[RFC2311].
The PKCS#7 TLV is always marked as optional, which cannot be
responded to with a NAK TLV. EAP-FAST server implementations that
claim to support the dynamic provisioning defined in this document
SHOULD support this TLV. EAP-FAST peer implementations MAY support
this TLV.
If the PKCS#7 TLV contains a certificate or certificate chain that is
not acceptable to the peer, then peer MUST ignore the TLV.
The PKCS#7 TLV is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS #7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
Cam-Winget, et al. Expires May 4, 2009 [Page 25]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
TLV Type
20 - PKCS#7 TLV [RFC4851]
Length
The length of the PKCS #7 Data field
PKCS #7 Data
This field contains the X.509 certificate or certificate chain
in a Certificates-Only PKCS#7 SignedData message.
Cam-Winget, et al. Expires May 4, 2009 [Page 26]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
5. IANA Considerations
This section explains the criteria to be used by the IANA for
assignment of Type value in PAC attribute, PAC Type value in PAC-
Type TLV, Credential-Format value in Server-Trusted-Root TLV. The
"Specification Required" policy is used here with the meaning defined
in BCP 26 [RFC5226].
A registry of values, named "EAP-FAST PAC Attribute Types", is needed
for the PAC Attribute types. The initial values to populate the
registry are:
1 - PAC-Key
2 - PAC-Opaque
3 - PAC-Lifetime
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type
Values from 11 to 63 are allocated for management by Cisco. Values
64 to 255 are assigned with a "Specification Required" policy.
A registry of values, named "EAP-FAST PAC Types", is needed for PAC-
Type values used in the PAC-Type TLV. The initial values to populate
the registry are:
1 - Tunnel PAC
2 - Machine Authentication PAC
3 - User Authorization PAC
Values from 4 to 63 are allocated for management by Cisco. Values 64
to 255 are assigned with a "Specification Required" policy.
A registry of values, named "EAP-FAST Server-Trusted-Root Credential
Format Types", is needed for Credential-Format values used in Server-
Trusted-Root TLV. The initial values to populate the registry are:
1 - PKCS#7-Server-Certificate-Root
Values from 2 to 63 are allocated for management by Cisco. Values 64
to 255 are assigned with a "Specification Required" policy.
Cam-Winget, et al. Expires May 4, 2009 [Page 27]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
6. Security Considerations
The Dynamic Provisioning EAP-FAST protocol shares the same security
considerations outlined in [RFC4851]. Additionally, it also has its
unique security considerations described below:
6.1. Provisioning Modes and Man-in-the-middle Attacks
EAP-FAST can be invoked in two different provisioning modes: Server-
Authenticated Provisioning Mode and Server-Unauthenticated
Provisioning Mode. Each mode provides different levels of resistance
to man-in-the-middle attacks. The following list identifies some of
the problems associated with a man-in-the-middle attack:
o Disclosure of secret information such as keys, identities and
credentials to an attacker
o Spoofing of a valid server to a peer and the distribution of false
credentials
o Spoofing of a valid peer and receiving credentials generated for
that peer
o Denial of service
6.1.1. Server-Authenticated Provisioning Mode and Man-in-the-middle
Attacks
In Server-Authenticated Provisioning Mode the TLS handshake assures
protected communications with the server because the peer must have
been securely pre-provisioned with the trust roots and/or other
authentication information necessary to authenticate the server
during the handshake. This pre-provisioning step prevents an
attacker from inserting themselves as a man-in-the-middle of the
communications. Unfortunately, secure pre-provisioning can be
difficult to achieve in many environments.
Cryptographic binding of inner authentication mechanisms to the TLS
tunnel provides additional protection from man-in-the-middle attacks
resulting from the tunneling of authentication mechanisms.
Server-Authenticated Provisioning Mode provides a high degree of
protection from man-in-the-middle attacks.
6.1.2. Server-Unauthenticated Provisioning Mode and Man-in-the-middle
Attacks
In Server-Unauthenticated Provisioning Mode the TLS handshake does
Cam-Winget, et al. Expires May 4, 2009 [Page 28]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
not assure protected communications with the server because either an
anonymous handshake is negotiated or the peer lacks the necessary
information to complete the authentication of the server. This
allows an attacker to insert themselves in the middle of the TLS
communications.
EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man-
in-the-middle attack through the following techniques:
o Binding the phase 2 authentication method to secret values derived
from the phase 1 TLS exchange:
In the case of MSCHAPv2 used with an anonymous Diffie-Hellman
ciphersuite the challenges for the MSCHAPv2 exchange are derived
from the TLS handshake and are not transmitted within the MSCHAPv2
exchange. Since the man-in-the-middle does not know these
challenges it cannot successfully impersonate the server without
cracking the MSCHAPv2 message from the peer before the peer times
out.
o Cryptographic binding of secret values derived from the phase 2
authentication exchange with secret values derived from the phase
1 TLS exchange:
This makes use of the cryptographic binding exchange defined
within EAP-FAST to discover the presence of a man-in-the-middle by
binding secret information obtained from the phase 2 MSCHAPv2
exchange with secret information from the phase 1 TLS exchange.
While it would be sufficient to only support the cryptographic
binding to mitigate the MitM; the binding of the MSCHAPv2 random
challenge derivations to the TLS key agreement protocol enables early
detection of a man-in-the-middle attack. This guards against
adversaries who may otherwise relay the inner EAP authentication
messages between the true peer and server and enforces that the
adversary successfully respond with a valid challenge response.
The cipher suite used to establish phase 1 of the Server-
Unauthenticated provisioning mode MUST be one in which both the peer
and server provide contribution to the derived TLS master key.
Cipher suites that use RSA key transport do not meet this
requirement. The authenticated and anonymous ephemeral Diffie-
Hellman cipher suites provide this type of key agreement.
This document specifies MSCHAPv2 as the inner authentication
exchange, however it is possible that other inner authentications
mechanisms to authenticate the tunnel may be developed in the future.
Since the strength of the man-in-the-middle protection is directly
Cam-Winget, et al. Expires May 4, 2009 [Page 29]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
dependent on the strength of the inner method it is RECOMMENDED that
any inner method used provide at least as much resistance to attack
as MSCHAPv2. Cleartext passwords MUST NOT be used in Server-
Unauthenticated Provisioning Mode. Note that an active man-in-the-
middle may observe phase 2 authentication method exchange until the
point that the peer determines that authentication mechanism fails or
is aborted. This allows for the disclosure of sensitive information
such as identity or authentication protocol exchanges to the man-in-
the-middle.
6.2. Dictionary Attacks
It is often the case that phase 2 authentication mechanisms are based
on password credentials. These exchanges may be vulnerable to both
online and offline dictionary attacks. The two provisioning modes
provide various degrees of protection from these attacks.
In online dictionary attacks the attacker attempts to discover the
password by repeated attempts at authentication using a guessed
password. Neither mode prevents this type of attack by itself.
Implementations should provide controls that limit how often an
attacker can execute authentication attempts.
In offline dictionary attacks the attacker captures information which
can be processed offline to recover the password. Server-
Authenticated provisioning mode provides effecting mitigation because
the peer will not engage in phase 2 authentication without first
authenticating the server during phase 1. Server-Unauthenticated
Provisioning Mode is vulnerable to this type of attack. If, during
phase 2 authentication, a peer receives no response or an invalid
response from the server then there is a possibility there is a man-
in-the-middle attack in progress. Implementations SHOULD logs these
events and, if possible, provide warnings to the user.
Implementations are also encouraged to provide controls that limit
how and where Server-Unauthenticated Provisioning Mode can be
performed that are appropriate to their environment. For example, an
implementation may limit this mode to be used only on certain
interfaces or require user intervention before allowing this mode if
provisioning has succeeded in the past.
Another mitigation technique that should not be overlooked is the
choice of good passwords that have sufficient complexity and length
and a password changing policy that requires regular password
changes.
Cam-Winget, et al. Expires May 4, 2009 [Page 30]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
6.3. Considerations in Selecting a Provisioning Mode
Since Server-Authenticated Provisioning Mode provides much better
protection from attacks than Server-Unauthenticated Provisioning
Mode, Server-Authenticated Provisioning Mode SHOULD be used whenever
possible. The Server-Unauthenticated Provisioning Mode provides a
viable option as there may be deployments that can physically confine
devices during the provisioning or are willing to accept the risk of
an active dictionary attack. Further, it is the only option that
enables zero touch provisioning and facilitates simpler deployments
requiring little to no peer configuration. The peer MAY choose to
use alternative secure out-of-band mechanisms for PAC provisioning
that afford better security than the Server Unauthenticated
Provisioning Mode.
6.4. Diffie-Hellman Groups
To encourage interoperability implementations of EAP-FAST anonymous
provisioning modes MUST support the 2048-bit group "14" in [RFC3526].
6.5. Tunnel PAC Usage
The basic usage of the Tunnel PAC is to establish the TLS tunnel. In
this operation it does not have to provide user authentication as it
is expected for user authentication to be carried out in phase 2 of
EAP-FAST. The EAP-FAST Tunnel PAC MAY contain information about the
identity of a peer to prevent a particular Tunnel PAC from being used
to establish a tunnel which can perform phase 2 authenticate other
peers. While it is possible for the server to accept the Tunnel PAC
as authentication for the peer many current implementations do not do
this. The ability to use PAC to authenticate peers and provide
authorizations will be the subject of a future document. [RFC5077]
gives an example PAC-Opaque format in the Recommended Ticket
Construction section.
6.6. Machine Authentication PAC Usage
In general the Machine Authorization PAC is expected to provide the
minimum access required by a machine without a user. This will
typically be a subset of the privilege a registered user has. The
server provisioning the PAC should include information necessary to
validate it at a later point in time. This would include expiration
information. The Machine Authentication PAC includes a key so it can
be used as a Tunnel PAC. The PAC-Key MUST be kept secret by the
peer.
Cam-Winget, et al. Expires May 4, 2009 [Page 31]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
6.7. User Authorization PAC Usage
The User Authorization PAC provides the privilege associated with a
user. The server provisioning the PAC should include the information
necessary to validate it at a later point in time. This includes
expiration and other information associated with the PAC. The User
Authorization PAC is a bearer credential such that it does not have a
key that used to authenticate its ownership. For this reason this
type of PAC MUST NOT be sent in the clear. For additional protection
the PAC MAY be bound to a Tunnel PAC used to establish the TLS
tunnel. On the peer, the User Authorization PAC SHOULD only be
accessible by the user for which it is provisioned.
6.8. PAC Storage Considerations
The main goal of EAP-FAST is to protect the authentication stream
over the media link. However, host security is still an issue. Some
care should be taken to protect the PAC on both the peer and server.
The peer must store securely both the PAC-Key and PAC-Opaque, while
the server must secure storage of its security association context
used to consume the PAC-Opaque. Additionally, if alternate
provisioning is employed, the transportation mechanism used to
distribute the PAC must also be secured.
Most of the attacks described here would require some level of effort
to execute; conceivably greater than their value. The main focus
therefore, should be to ensure that proper protections are used on
both the peer and server. There are a number of potential attacks
which can be considered against secure key storage such as:
o Weak Passphrases
On the peer side, keys are usually protected by a passphrase. On
some environments, this passphrase may be associated with the
user's password. In either case, if an attacker can obtain the
encrypted key for a range of users, he may be able to successfully
attack a weak passphrase. The tools are already in place today to
enable an attacker to easily attack all users in an enterprise
environment through the use of email viruses and other techniques.
o Key Finding Attacks
Key finding attacks are usually mentioned in reference to web
servers, where the private SSL key may be stored securely, but at
some point it must be decrypted and stored in system memory. An
attacker with access to system memory can actually find the key by
identifying their mathematical properties. To date, this attack
appears to be purely theoretical and primarily acts to argue
Cam-Winget, et al. Expires May 4, 2009 [Page 32]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
strongly for secure access controls on the server itself to
prevent such unauthorized code from executing.
o Key duplication, Key substitution, Key modification
Once keys are accessible to an attacker on either the peer or
server, they fall under three forms of attack: key duplication,
key substitution and key modification. The first option would be
the most common, allowing the attacker to masquerade as the user
in question. The second option could have some use if an attacker
could implement it on the server. Alternatively, an attacker
could use one of the latter two attacks on either the peer or
server to force a PAC re-key, and take advantage of the potential
MitM/dictionary attack vulnerability of the EAP-FAST Server-
Unauthenticated Provisioning Mode.
Another consideration is the use of secure mechanisms afforded by the
particular device. For instance, some laptops enable secure key
storage through a special chip. It would be worthwhile for
implementations to explore the use of such a mechanism.
6.9. Security Claims
The [RFC3748] security claims for EAP-FAST are given in Section 7.8
of [RFC4851]. When using anonymous provisioning mode there is a
greater risk of offline dictionary attack since it is possible for a
man-in-the-middle to capture the beginning of the inner MSCHAPv2
conversation. However as noted previously it is possible to detect
the man-in-the-middle.
Cam-Winget, et al. Expires May 4, 2009 [Page 33]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
7. Acknowledgements
The EAP-FAST design and protocol specification is based on the ideas
and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith,
Ilan Frenkel, Max Pritikin, Jan Vilhuber and Jeremy Steiglitz. The
authors would also like to thank Jouni Malinen, Pasi Eronen, Jari
Arkko, Chris Newman, Ran Canetti and Vijay Gurbani for reviewing this
document.
Cam-Winget, et al. Expires May 4, 2009 [Page 34]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
8. References
8.1. Normative References
[EAP-MSCHAPv2]
Microsoft Developer Network (MSDN), "[MS-CHAP]: Extensible
Authentication Protocol Method for Microsoft Challenge
Handshake Authentication Protocol (CHAP) Specification",
January 2008.
http://msdn2.microsoft.com/en-us/library/cc224612.aspx
[I-D.zhou-emu-fast-gtc]
Cam-Winget, N. and H. Zhou, "Basic Password Exchange
within the Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol (EAP-FAST)",
draft-zhou-emu-fast-gtc-04 (work in progress), July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, March 1998.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, January 2000.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
Cam-Winget, et al. Expires May 4, 2009 [Page 35]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
8.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Cam-Winget, et al. Expires May 4, 2009 [Page 36]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Appendix A. Examples
A.1. Example 1: Successful Tunnel PAC Provisioning
The following exchanges show anonymous DH with a successful EAP-
MSCHAPv2 exchange within Phase 2 to provision a Tunnel PAC, the
conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST,
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS Client Hello without
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello,
TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange
TLS Change Cipher Spec
TLS Finished) ->
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
Cam-Winget, et al. Expires May 4, 2009 [Page 37]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Response)) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2)
(Success))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Success)) ->
<- Intermediate Result TLV(Success)
Crypto-Binding-TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC)
Intermediate Result TLV (Success)
Crypto-Binding-TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC)
PAC-TLV (Type=1)
<- Result TLV (Success)
PAC TLV
Result TLV (Success)
PAC Acknowledgment ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
A.2. Example 2: Failed Provisioning
The following exchanges show a failed EAP-MSCHAPV2 exchange within
Phase 2, where the peer failed to authenticate the Server. The
conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST
Cam-Winget, et al. Expires May 4, 2009 [Page 38]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
(TLS Client Hello without
SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello
TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange
TLS Change Cipher Spec,
TLS Finished) ->
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP Payload TLV
(EAP-Response/Identity)->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Response)) ->
<- EAP Payload TLV
(EAP-Request EAP-MSCHAPV2
(Success))
// peer failed to verify server MSCHAPv2 response
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Failure)) ->
<- Result TLV (Failure)
Cam-Winget, et al. Expires May 4, 2009 [Page 39]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
A.3. Example 3: Provisioning a Authentication Server's Trusted Root
Certificate
The following exchanges show a successful provisioning of a server
trusted root certificate using anonymous DH and EAP-MSCHAPV2 exchange
within Phase 2, the conversation will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Requese/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST
(TLS Client Hello without
SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello,
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange
TLS Change Cipher Spec,
TLS Finished) ->
<- EAP-Request/EAP-FAST
(TLS Change Cipher Spec
TLS Finished)
(EAP-Payload-TLV(
EAP-Request/Identity))
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload TLV
Cam-Winget, et al. Expires May 4, 2009 [Page 40]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
(EAP-Response/Identity) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Response)) ->
<- EAP Payload TLV
(EAP-Request/EAP-MSCHAPV2
(success))
EAP Payload TLV
(EAP-Response/EAP-MSCHAPV2
(Success) ->
<- Intermediate Result TLV(Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Intermediate Result TLV(Success)
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC)
Server-Trusted-Root TLV
(Type = PKCS#7) ->
<- Result TLV (Success)
Server-Trusted-Root TLV
(PKCS#7 TLV)
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
Cam-Winget, et al. Expires May 4, 2009 [Page 41]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Appendix B. Recent Changes
changes in -07
o Added definition for User Authorization PAC and Machine
Authentication PAC
o Added sections for User Authorization PAC (4.1.3) and Machine
Authentication PAC (4.1.2).
o Added security considerations for new types of PACs
o Added recommendation for 16 octet A-ID
changes in -08
o Clarified that Server-Unauthenticated provisioning mode uses
anonymous TLS ciphersuites
o Editorial corrections
changes in -09
o Added text to section 3 to provide an overview of the provisioning
process
changes in -10
o Clarified that user authorization PAC is not associated with a
key.
o Removed conflicting SHOULD requirement for inner method
authentication.
o In section 3.1.1 change cert validation to MUST.
o Clarified that RSA ciphersuites MUST NOT be used with anonymous
mode.
o In section 3.2 added requirement for TLV order.
o Clarified that the modified MSCHAPv2 is only used for
provisioning.
o Fixed TLS key block derivation
o In section 3.5, made TLS renegotiation the optional method for
continuing authentication after provisioning
Cam-Winget, et al. Expires May 4, 2009 [Page 42]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
o define A-ID as opaque and included recommendations for generation
o defined I-ID as derived from the inner EAP method
o added details to PKCS encoding of certs
o updated IANA considerations section
o tightened specification to require 2048 DH group
Cam-Winget, et al. Expires May 4, 2009 [Page 43]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Authors' Addresses
Nancy Cam-Winget
Cisco Systems
3625 Cisco Way
San Jose, CA 95134
US
Email: ncamwing@cisco.com
David McGrew
Cisco Systems
San Jose, CA 95134
US
Email: mcgrew@cisco.com
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
Email: jsalowey@cisco.com
Hao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
US
Email: hzhou@cisco.com
Cam-Winget, et al. Expires May 4, 2009 [Page 44]
Internet-Draft Dynamic Provisioning using EAP-FAST October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cam-Winget, et al. Expires May 4, 2009 [Page 45]