One document matched: draft-cam-winget-eap-fast-provisioning-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY rfc3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY rfc5077 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY rfc3268 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3268.xml">
<!ENTITY rfc2759 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2759.xml">
<!ENTITY rfc2315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2315.xml">
<!ENTITY rfc3526 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3526.xml">
<!ENTITY rfc4419 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4419.xml">
<!ENTITY rfc3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY rfc4851 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4851.xml">
<!ENTITY zhou-emu-fast-gtc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhou-emu-fast-gtc.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="info" docName="draft-cam-winget-eap-fast-provisioning-09"
ipr="full3978">
<front>
<title abbrev="Dynamic Provisioning using EAP-FAST">Dynamic Provisioning
using Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol (EAP-FAST)</title>
<author fullname="Nancy Cam-Winget" initials="N" surname="Cam-Winget">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street>3625 Cisco Way</street>
<city>San Jose</city>
<country>US</country>
<code>95134</code>
<region>CA</region>
</postal>
<email>ncamwing@cisco.com</email>
</address>
</author>
<author fullname="David McGrew" initials="D" surname="McGrew">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>San Jose</city>
<country>US</country>
<code>95134</code>
<region>CA</region>
</postal>
<email>mcgrew@cisco.com</email>
</address>
</author>
<author fullname="Joseph Salowey" initials="J" surname="Salowey">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street>2901 3rd Ave</street>
<city>Seattle</city>
<country>US</country>
<code>98121</code>
<region>WA</region>
</postal>
<email>jsalowey@cisco.com</email>
</address>
</author>
<author fullname="Hao Zhou" initials="H" surname="Zhou">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street>4125 Highlander Parkway</street>
<city>Richfield</city>
<country>US</country>
<code>44286</code>
<region>OH</region>
</postal>
<email>hzhou@cisco.com</email>
</address>
</author>
<date month="July" year="2008" />
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section title="Introduction ">
<t>EAP-FAST <xref target="RFC4851"></xref> 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 <xref target="RFC4346" /> tunnel, EAP-FAST can enable dynamic in-band provisioning to
address such deployment obstacles.</t>
<section title="Specification Requirements">
<t>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 <xref
target="RFC2119"></xref>. </t>
</section>
<section title="Terminology ">
<t>Much of the terminology used in this document comes from <xref
target="RFC3748"></xref>. The terms "peer" and "server" are used
interchangeably with the terms "EAP peer" and "EAP server" respectively.
Additional terms are defined below: </t>
<t><list hangIndent="" style="hanging">
<t hangText="Man in the Middle (MitM) "><vspace
blankLines="1" />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. </t>
<t hangText="Provisioning"><vspace
blankLines="1" />Providing peer with a trust anchor, shared secret or other
appropriate information needed to establish a security association. </t>
<t hangText="Protected Access Credential (PAC)"><vspace
blankLines="1" />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. </t>
<t hangText="Tunnel PAC "><vspace
blankLines="1" /> A set of credentials stored by the peer and consumed by both
the peer and the server to establish a TLS tunnel. </t>
<t hangText="User Authorization PAC"><vspace blankLines="1" />
A User Authorization PAC is server encrypted data containing authorization information associated with a previously authenticated user. The user authorization PAC does not typically contain a key, but rather it is generally bound to a tunnel PAC which is used with the User Authorization PAC. </t>
<t hangText="Machine Authentication PAC"><vspace blankLines="1" />
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. </t>
</list></t>
</section>
</section>
<section title="EAP-FAST Provisioning Modes">
<t>EAP-FAST supports two modes for provisioning: </t>
<t><list style="numbers" >
<t hangText="">Server-Authenticated Provisioning Mode - Provisioning inside a TLS tunnel that provides server-side authentication. </t>
<t hangText="">Server-Unauthenticated Provisioning Mode - Provisioning inside an anonymous TLS tunnel.</t>
</list></t>
<t>The EAP-FAST provisioning modes use EAP-FAST phase 2 inside a secure TLS tunnel established during phase 1. <xref target="RFC4851"></xref> describes the EAP-FAST phases in greater detail. </t>
<t>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.</t>
<t>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. </t>
<t>Since the server is not authenticated in the Server-Unauthenticated
Provisioning Mode, it is possible that an attacker may intercept the TLS tunnel. When using this mode,
an inner, phase 2, EAP method SHOULD be used to provide authentication and man-in-the-middle
detection as described in <xref target="security"></xref>. 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. 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. </t>
<t>Server-Authenticated 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 mode. </t>
<t>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. Once the EAP-FAST Provisioning conversation completes, the peer is
expected to use the provisioned credentials in subsequent EAP-FAST
authentications. </t>
</section>
<section title="Dynamic Provisioning using EAP-FAST Conversation">
<t>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,
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
EAP-MSCHAPv2 exchange.</t>
<section title="Phase 1 TLS tunnel">
<section title="Server-Authenticated Phase 1">
<t>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 <xref target="RFC4346"></xref>: </t>
<t><list>
<t>TLS_RSA_WITH_RC4_128_SHA
<vspace></vspace>TLS_RSA_WITH_AES_128_CBC_SHA
<vspace></vspace>TLS_DHE_RSA_WITH_AES_128_CBC_SHA </t>
</list></t>
<t>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, it is highly RECOMMENDED that the peer validate the server's
certificate chain when performing server-side authentication to obtain the full security benefits of Server-Authenticated provisioning.</t>
</section>
<section title="Server-Unauthenticated Phase 1">
<t> Implementations supporting this version of the Sever-Unauthenticated Provisioning Mode MUST
support the following TLS ciphersuites defined in <xref target="RFC4346"></xref>: </t>
<t><list >
<t>TLS_DH_anon_WITH_AES_128_CBC_SHA</t>
</list></t>
<t>
Anonymous
ciphersuites SHOULD NOT be allowed outside of EAP-FAST Server-Unauthenticated Provisioning
Mode. Ciphersuites that are used for provisioning MUST provide encryption. </t>
</section>
</section>
<section title="Phase 2 - Tunneled Authentication and Provisioning">
<t>Once a protected tunnel is established, the peer and server MAY wish to execute additional
authentication and perform checks on the integrity of the TLS tunnel. As defined in <xref target="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. A PAC TLV MUST NOT be accepted if it is not encapsulated in an encrypted TLS tunnel.</t>
<t> 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. </t>
<section title="Server-Authenticated Tunneled Authentication">
<t> If
Server-Authenticated 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. </t>
</section>
<section title="Server-Unauthenticated Tunneled Authentication">
<t> If
Server-Unauthenticated 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 <xref target="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. </t>
</section>
<section title="Authenticating Using EAP-MSCHAPv2" anchor="mschap">
<t>Implementations of this version of the EAP-FAST Server-Unauthenticated Provisioning Mode MUST
support EAP-MSCHAPv2 <xref target="EAP-MSCHAPv2"/> as the inner authentication method. While other authentication
methods exist, EAP-MSCHAPv2 was chosen
for several reasons: </t>
<t><list style="symbols">
<t>Provide the ability of slowing an active attack by using a hash based challenge-response protocol.</t>
<t>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. </t>
<t> A large deployed base is already able to
support MSCHAPv2 </t>
<t>It allows support for password change during the EAP-FAST
provisioning modes. </t>
</list></t>
<t>When using an anonymous Diffie-Hellman key agreement and EAP-MSCHAPv2, a binding
between the tunnel and the EAP-MSCHAPv2 exchanges is formed 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. A detailed description of the challenge
generation is described in <xref target="keyderiv"></xref>. </t>
<t>The MSCHAPv2 <xref target="RFC2759"></xref> 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. </t>
</section>
<section title="Use of other Inner EAP Methods for EAP-FAST Provisioning">
<t>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 <xref target="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.</t>
<t> 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. </t>
</section>
</section>
<section title="Key Derivations Used in the EAP-FAST Provisioning Exchange" anchor="keyderiv">
<t>The TLS tunnel key is calculated according to the TLS <xref target="RFC4346"></xref>
with an extra 72 octets of key material. 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. </t>
<t><list style="hanging" hangIndent="10">
<t hangText="To generate the key material, compute"> <vspace blankLines="1"></vspace> <list hangIndent="15" style="hanging">
<t hangText="key_block = PRF(master_secret, ">
<vspace ></vspace>"key expansion",
<vspace></vspace>server_random +
<vspace></vspace>client_random); </t>
</list></t>
</list></t>
<t> until enough output has been generated. </t>
<t><list style="hanging" hangIndent="10">
<t hangText="Then the key_block is partitioned as follows: ">
<vspace blankLines="1"></vspace> client_write_MAC_secret[hash_size]
<vspace ></vspace>server_write_MAC_secret[hash_size]
<vspace ></vspace>client_write_key[Key_material_length]
<vspace ></vspace>server_write_key[key_material_length]
<vspace ></vspace>client_write_IV[IV_size]
<vspace ></vspace>server_write_IV[IV_size]
<vspace ></vspace>session_key_seed[40]
<vspace ></vspace>MSCHAPv2 ServerChallenge[16]
<vspace ></vspace>MSCHAPv2 ClientChallenge[16] </t>
</list></t>
<t>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. </t>
</section>
<section title="Peer-Id, Server-Id and Session-Id ">
<t>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 <xref target="RFC4851"></xref> techniques. </t>
<t><xref target="RFC4851"></xref> Section 3.4 describes how the Peer-Id and Server-Id are
determined; Section 3.5 describes how the Session-Id is generated. </t>
</section>
<section title="Network Access after EAP-FAST Provisioning" >
<t> 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 access is authorized. The server MAY grant access at the end of a successful Server-Authenticated provisioning exchange. </t>
<t>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. </t>
<t>The EAP-FAST server, when denying network access after EAP-FAST
Provisioning, MAY choose to instead, immediately invoke another EAP-
FAST Start and thus initiate the EAP-FAST Phase 1 conversation. This
server based implementation policy MAY be chosen to avoid
applications such as wireless devices from being disrupted (e.g. in
IEEE 802.11 devices, an EAP Failure may trigger a full 802.11
disassociation) and allow them to smoothly transition to the
subsequent EAP-FAST authentications to enable network access. As an
alternative, both the peer and server can initiate TLS renegotiation,
where the newly provisioned credentials can be used to establish a
server authenticated or mutually authenticated TLS tunnel for
authentication. Upon completion of the TLS negotiation and subsequent
authentication, normal network access policy on EAP-FAST
authentication can be applied. </t>
</section>
</section>
<section title="Information Provisioned in EAP-FAST">
<t> 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. </t>
<t> 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. </t>
<section title="Protected Access Credential">
<t> 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.
</t>
<section title="Tunnel PAC">
<t>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 inner EAP methods or user identities inside the tunnel
established by the use of that PAC. </t>
</section>
<section title="Machine Authentication PAC">
<t>
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 is typically persisted across sessions.
</t>
<t>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. </t>
</section>
<section title="User Authorization PAC">
<t>
The User Authorization PAC contains information in the PAC opaque that identifies a user and provides authorization information. The User Authorization PAC is used to provide user information during stateless session resume so user authentication MAY be skipped. The User Authorization PAC MAY be provisioned during a 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. </t>
<t>
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 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.
</t>
</section>
<section title="PAC Provisioning">
<t>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. </t>
<t>
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.</t>
<t>Please see <xref target="tpacex"></xref> for an example of packet exchanges to
provision a Tunnel PAC. </t>
</section>
</section>
<section title="PAC TLV Format" anchor="pac-tlv">
<t>The PAC TLV provides support for provisioning the Protected Access Credential (PAC)
defined within <xref target="RFC4851"></xref>. 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: </t>
<figure>
<artwork><![CDATA[
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure>
<t><list hangIndent="5">
<t><list style="hanging" hangIndent="5">
<t hangText="M">
<vspace blankLines="1"></vspace>0 - Non-mandatory TLV
<vspace></vspace>1 - Mandatory TLV</t>
<t hangText="R">
<vspace blankLines="1"></vspace>Reserved, set to zero (0)</t>
<t hangText="TLV Type"><vspace blankLines="1"></vspace>11 - PAC TLV</t>
<t hangText="Length"><vspace blankLines="1"></vspace>Two octets containing length of the PAC Attributes field in octets</t>
<t hangText="PAC Attributes"><vspace blankLines="1"></vspace>A list of PAC attributes in the TLV format</t>
</list></t>
</list></t>
<t></t>
<section title="Formats for PAC Attributes" anchor="pacat">
<t> Each PAC Attribute in a PAC TLV is formatted as a TLV defined as follows: </t>
<figure>
<artwork><![CDATA[
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure>
<t><list hangIndent="5">
<t><list style="hanging" hangIndent="5">
<t hangText="Type">
<vspace blankLines="1"></vspace>The type field is two octets, denoting the attribute type
Allocated Types include:
<list style="hanging">
<t><vspace></vspace>1 - PAC-Key
<vspace></vspace>2 - PAC-Opaque
<vspace></vspace>3 - PAC-Lifetime
<vspace></vspace>4 - A-ID
<vspace></vspace>5 - I-ID
<vspace></vspace>6 - Reserved
<vspace></vspace>7 - A-ID-Info
<vspace></vspace>8 - PAC-Acknowledgement
<vspace></vspace>9 - PAC-Info
<vspace></vspace>10 - PAC-Type </t>
</list></t>
<t hangText="Length">
<vspace blankLines="1"></vspace>Two octets containing the length of
the value field in octets. </t>
<t hangText="Value"><vspace blankLines="1"></vspace>The value of the PAC Attribute</t>
</list></t>
</list></t>
</section>
<section title="PAC-Key">
<t>The PAC-Key is a secret key distributed in a PAC attribute of type PAC-Key. The PAC-Key field 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. </t>
<figure>
<artwork>
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
</figure>
<t><list>
<t><list style="hanging">
<t hangText="Type"><vspace blankLines="1"></vspace>1 - PAC-Key</t>
<t hangText="Length"><vspace blankLines="1"></vspace>2 octet length indicating a 32 octet long key</t>
<t hangText="Key"><vspace blankLines="1"></vspace>The value of the PAC key</t>
</list>
</t>
</list></t>
</section>
<section title="PAC-Opaque">
<t>The PAC-Opaque field is included within the PAC TLV whenever the server wishes to issue or renew a PAC.
</t>
<t> 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 <xref target="RFC5077"></xref>. 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. </t>
<t>The PAC-Opaque field format is summarized as follows:</t>
<figure>
<artwork>
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
</figure>
<t><list>
<t><list style="hanging">
<t hangText="Type"><vspace blankLines="1"></vspace>2 - PAC-Opaque </t>
<t hangText="Length"><vspace blankLines="1"></vspace>The Length filed is two octets, which contains the length of
the value field in octets</t>
<t hangText="Value"><vspace blankLines="1"></vspace>The value field contains the actual data for PAC-Opaque. It is specific to the server implementation.</t>
</list></t>
</list></t>
</section>
<section title="PAC-Info">
<t> PAC-Info is comprised of a set of PAC attributes as defined in
<xref target="pacat"></xref>. 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.</t>
<figure>
<artwork>
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
</figure>
<t><list>
<t><list style="hanging">
<t hangText="Type"><vspace blankLines="1" />9 - PAC-Info</t>
<t hangText="Length"><vspace blankLines="1" />Two octet length field containing the length of
the Attributes field in octets </t>
<t hangText="Attributes"><vspace blankLines="1" />The Attributes field contains a list of PAC Attributes
Each mandatory and optional field type is defined as follows:
<list style="hanging">
<t hangText="3 - PAC-LIFETIME"><vspace blankLines="1" />
This is a 4 octet quantity representing the expiration time
of the credential in UNIX UTC time. This attribute MAY be
provided to the peer as part of PAC-Info.
</t>
<t hangText="4 - A-ID"><vspace blankLines="1" />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. 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.</t>
<t hangText="5 - I-ID"><vspace blankLines="1" />Initiator identifier (I-ID) is the peer identity associated
with the credential. 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.</t>
<t hangText="7 - A-ID-Info"><vspace blankLines="1" />Authority Identifier Information is a mandatory TLV 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 end-user about the A-ID. The name is encoded as UTF-8 <xref target="RFC3629"></xref> format. This attribute MUST be included in the PAC-Info.
</t>
<t hangText="10 - PAC-type"><vspace blankLines="1" />PAC-Type is a mandatory TLV intended to provide the type of
PAC. This field SHOULD be included in the PAC-Info. If PAC-Type is not present, then it
defaults to a Tunnel PAC (Type 1). </t>
</list>
</t>
</list></t>
</list></t>
</section>
<section title="PAC-Acknowledgement TLV">
<t>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.</t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
</figure>
<t><list>
<t><list style="hanging">
<t hangText="Type"><vspace blankLines="1" />8 - PAC-Acknowledgement</t>
<t hangText="Length"><vspace blankLines="1" />The length of this field is two octets containing a value of 2.</t>
<t hangText="Result"><vspace blankLines="1" />The resulting value MUST be one of the following: <list style="hanging">
<t>1 - Success
<vspace></vspace>2 - Failure </t>
</list></t>
</list></t>
</list></t>
</section>
<section title="PAC-Type TLV">
<t>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. </t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>
</figure>
<t><list>
<t><list style="hanging">
<t hangText="Type"><vspace blankLines="1"></vspace>10 - PAC-Type </t>
<t hangText="Length"><vspace blankLines="1"></vspace>Two Octet length field with a value of 2</t>
<t hangText="PAC Type"><vspace blankLines="1"></vspace>This two octet field defined the type of PAC being requested or
provisioned. The following values are defined: <list style="hanging">
<t>1 - Tunnel PAC <vspace></vspace>
2 - Machine Authentication PAC <vspace></vspace>
3 - User Authorization PAC</t>
</list></t>
</list></t>
</list></t>
</section>
</section>
<section title="Trusted Server Root Certificate">
<t>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).</t>
<t>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 <xref target="certex"></xref> for an example of a server provisioning a
server trusted root certificate. </t>
<section title="Server-Trusted-Root TLV">
<t>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 <xref target="RFC2315"></xref> format.</t>
<t>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. </t>
<t>If the Server-Trusted-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV. </t>
<t>The Server-Trusted-Root TLV is defined as follows: </t>
<figure>
<artwork>
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-</artwork>
</figure>
<t><list hangIndent="5">
<t><list style="hanging" hangIndent="5">
<t hangText="M">
<vspace blankLines="1"></vspace>0 - Non-mandatory TLV</t>
<t hangText="R">
<vspace blankLines="1"></vspace>Reserved, set to zero (0)</t>
<t hangText="TLV Type"><vspace blankLines="1"></vspace>18 - Server-Trusted-Root TLV [RFC4851]</t>
<t hangText="Length"><vspace blankLines="1"></vspace>>=2 octets</t>
<t hangText="Credential-Format"><vspace blankLines="1"></vspace>The Credential-Format field is two octets. Values include: <list style="hanging">
<t>1 - PKCS#7-Server-Certificate-Root</t>
</list></t>
<t hangText="Cred TLVs"><vspace blankLines="1" />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. </t>
</list></t>
</list></t>
</section>
<section title="PKCS#7 TLV">
<t>The PKCS#7 TLV is sent by the EAP server to the peer inside the
Server-Trusted-Root TLV. It contains the PKCS #7 <xref target="RFC2315"></xref> wrapped
X.509 certificate. This field contains a certificate or certificate
chain in PKCS#7 format requested by the peer as defined in <xref target="RFC2315"></xref>.</t>
<t>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. </t>
<t>If the PKCS#7 TLV contains a certificate or certificate chain that is
not acceptable to the peer, then peer MUST ignore the TLV. </t>
<t>The PKCS#7 TLV is defined as follows: </t>
<figure>
<artwork>
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- </artwork>
</figure>
<t>
<list>
<t><list style="hanging">
<t hangText="M"><vspace blankLines="1" />0 - Optional TLV</t>
<t hangText="R"><vspace blankLines="1" />Reserved, set to zero (0)</t>
<t hangText="TLV Type"><vspace blankLines="1" />20 - PKCS#7 TLV [RFC4851]</t>
<t hangText="Length"><vspace blankLines="1" />The length of the PKCS #7 Data field </t>
<t hangText="PKCS #7 Data"><vspace blankLines="1" /> This field contains the PKCS #7 wrapped X.509 certificate or
certificate chain in the PKCS #7 format.</t>
</list></t>
</list></t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t> 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 <xref target="RFC2434"></xref>.</t>
<t>A registry of values is needed for the PAC Attribute types. The initial
values to populate the registry are:
<list style="hanging"><t>
<vspace></vspace>1 - PAC-Key
<vspace></vspace>2 - PAC-Opaque
<vspace></vspace>3 - PAC-Lifetime
<vspace></vspace>4 - A-ID
<vspace></vspace>5 - I-ID
<vspace></vspace>6 - Reserved
<vspace></vspace>7 - A-ID-Info
<vspace></vspace>8 - PAC-Acknowledgement
<vspace></vspace>9 - PAC-Info
<vspace></vspace>10 - PAC-Type </t>
</list>
Values from 11 to 63 are reserved. Values 64 to 255 are assigned with a "Specification Required" policy.</t>
<t>A registry of values is needed for PAC-Type values used in the PAC-Type TLV. The initial values to populate the registry are:<list style="hanging">
<t>1 - Tunnel PAC</t>
<t>2 - Machine Authentication PAC</t>
<t>3 - User Authorization PAC</t>
</list>
Values from 4 to 63 are reserved. Values 64 to 255 are assigned with a "Specification Required" policy.</t>
<t>A registry of values is needed for Credential-Format values used in Server-Trusted-Root TLV. The initial values to populate the registry are:<list style="hanging">
<t>1 - PKCS#7-Server-Certificate-Root</t>
</list>
Values from 2 to 63 are reserved. Values 64 to 255 are assigned with a "Specification Required" policy.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The Dynamic Provisioning EAP-FAST protocol shares the same security
considerations outlined in <xref target="RFC4851"></xref>. Additionally, it also has its
unique security considerations described below: </t>
<section title="Provisioning Modes and Man-in-the-middle Attacks">
<t>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:</t>
<t><list style="symbols">
<t>Disclosure of secret information such as keys, identities and credentials to an attacker</t>
<t>Spoofing of a valid server to a peer and the distribution of false credentials</t>
<t>Spoofing of a valid peer and receiving credentials generated for that peer</t>
<t>Denial of service</t>
</list> </t>
<section title="Server-Authenticated Provisioning Mode and Man-in-the-middle Attacks">
<t>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. </t>
<t>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 mechanism. </t>
<t>Server-Authenticated Provisioning Mode provides a high degree of protection from man-in-the-middle attacks. </t>
</section>
<section title="Server-Unauthenticated Provisioning Mode and Man-in-the-middle Attacks">
<t>In Server-Unauthenticated Provisioning Mode the TLS handshake does 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. </t>
<t>EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man-in-the-middle attack through the following techniques:</t>
<t><list style="symbols">
<t>Binding the phase 2 authentication method to secret values derived from the phase 1 TLS exchange:
<vspace blankLines="1" />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.</t>
<t>Cryptographic binding of secret values derived from the phase 2 authentication exchange with secret values derived from the phase 1 TLS exchange:
<vspace blankLines="1" />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.</t>
</list></t>
<t> 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.</t>
<t>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 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. </t>
<t>The ciphersuite 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. The authenticated ephemeral Diffie-Hellman ciphersuites provide this type of key agreement. </t>
</section>
</section>
<section title="Dictionary Attacks">
<t>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. </t>
<t>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.</t>
<t>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. </t>
<t>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. </t>
</section>
<section title="Considerations in Selecting a Provisioning Mode">
<t>Since Server-Authenticated Provisioning Mode provides much better protection from attacks than Server-Unauthenticated Provisioning Mode, Server-Authenticated 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. </t>
</section>
<section title="Diffie-Hellman Groups">
<t>Implementations of EAP-FAST anonymous provisioning modes MUST support
the Diffie-Hellman groups defined in <xref target="RFC3526"></xref>.</t>
<t>The security of the DH key exchange is based on the difficulty of
solving the Discrete Logarithm Problem (DLP). As algorithms and
adversaries become more efficient in their abilities to pre-compute
values for a given fixed group, it becomes more important for a
server to generate new groups as a means to allay this threat. EAP-FAST servers in closed environments may make use of groups outside <xref target="RFC3526"></xref>. The
server could, for instance, constantly compute new groups in the
background. Peers in these environments need to employ proper parameter validation. Such an example is cited in <xref target="RFC4419"></xref>.</t>
<t> The server can maintain a list of safe primes and corresponding
generators to choose from. A prime p is safe, if: </t>
<t>p = 2q + 1 and q is prime </t>
<t>Initial implementations of the EAP-FAST provisioning exchange limit
the generator to be 2 as it both improves the multiplication
efficiency and still covers half of the space of possible residues.
</t>
<t>Additionally, since the EAP-FAST provisioning exchange employs DH per
<xref target="RFC3268"></xref> to generate AES keys, the DH keys should provide enough
entropy to ensure that a strong 128bit results from the DH key
agreement. </t>
</section>
<section title="Tunnel PAC Usage">
<t>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. <xref target="RFC5077" /> gives an example PAC opaque format in the Recommended Ticket Construction section. </t>
</section>
<section title="Machine Authentication PAC Usage">
<t> 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.
</t>
</section>
<section title="User Authorization PAC Usage">
<t>
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 typically used as 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.
</t>
</section>
<section title="PAC Storage Considerations">
<t>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. </t>
<t>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: </t>
<t><list style="symbols">
<t hangText="">Weak Passphrases <vspace blankLines="1"></vspace> 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.
</t>
<t hangText="">Key Finding Attacks <vspace blankLines="1"></vspace> 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
strongly for secure access controls on the server itself to prevent
such unauthorized code from executing. </t>
<t hangText="">Key duplication, Key substitution, Key modification <vspace blankLines="1"></vspace>
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.
</t>
</list></t>
<t> 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. </t>
</section>
<section title="Security Claims ">
<t>The <xref target="RFC3748"></xref> security claims for EAP-FAST are given in Section 7.8 of <xref target="RFC4851"></xref>. 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. </t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t> The EAP-FAST design and protocol specification is based on the ideas
and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith,
Ilan Frenkel and Jeremy Steiglitz. The authors would also like to thank Jouni Malinen for reviewing this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3748;
&rfc4346;
&rfc3268;
&rfc4851;
&rfc2759;
&rfc5077;
&rfc2315;
&rfc3526;
&rfc3629;
&zhou-emu-fast-gtc;
<reference anchor="EAP-MSCHAPv2" >
<front>
<title>[MS-CHAP]: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) Specification</title>
<author>
<organization>Microsoft Developer Network (MSDN)</organization>
</author>
<date month="January" year="2008" />
</front>
<format type="html" target='http://msdn2.microsoft.com/en-us/library/cc224612.aspx' />
<annotation>http://msdn2.microsoft.com/en-us/library/cc224612.aspx</annotation>
</reference>
</references>
<references title="Informative References">
&rfc2434;
&rfc4419;
</references>
<section title="Examples">
<section title="Example 1: Successful Tunnel PAC Provisioning" anchor="tpacex">
<t>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: </t>
<figure>
<artwork><![CDATA[
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
(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 ]]></artwork>
</figure>
</section>
<section title="Example 2: Failed Provisioning">
<t>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: </t>
<figure>
<artwork><![CDATA[
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
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)
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure]]></artwork>
</figure>
</section>
<section title="Example 3: Provisioning a Authentication Server's Trusted Root Certificate" anchor="certex">
<t>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: </t>
<figure>
<artwork><![CDATA[
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
(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 ]]></artwork>
</figure>
</section>
</section>
<section title="Recent Changes">
<t>changes in -07</t>
<t><list style="symbols">
<t>Added definition for User Authorization PAC and Machine Authentication PAC</t>
<t>Added sections for User Authorization PAC (4.1.3) and Machine Authentication PAC (4.1.2).</t>
<t>Added security considerations for new types of PACs</t>
<t>Added recommendation for 16 octet A-ID</t>
</list></t><t>changes in -08</t>
<t><list style="symbols">
<t>Clarified that Server-Unauthenticated provisioning mode uses anonymous TLS ciphersuites</t>
<t>Editorial corrections</t>
</list></t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 08:24:38 |