📄 draft-cam-winget-eap-fast-03.txt
字号:
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| EAP-FAST |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
The entities depicted above are logical entities and may or may not
correspond to separate network components. For example, the EAP-
FAST server and Inner Method server might be a single entity; the
authenticator and EAP-FAST server might be a single entity; or, the
functions of the authenticator, EAP-FAST server and Inner Method
server might be combined into a single physical device. For example,
typical 802.11 deployments place the Authenticator in an access point
(AP) while a Radius Server may provide the EAP-FAST and Inner Method
server components. The above diagram illustrates the division of
labor among entities in a general manner and shows how a distributed
Cam-Winget, et al. Expires April 22, 2006 [Page 6]
Internet-Draft EAP-FAST October 2005
system might be constructed; however, actual systems might be
realized more simply. The security considerations Section 7.4
provides an additional discussion of the implications of separating
EAP-FAST server from the inner method server.
2.2 Protocol Layering Model
EAP-FAST packets are encapsulated within EAP, and EAP in turn,
requires a carrier protocol for transport. EAP-FAST packets
encapsulate TLS, which is then used to encapsulate user
authentication information. Thus, EAP-FAST messaging can be
described using a layered model, where each layer encapsulates the
layer beneath it. The following diagram clarifies the relationship
between protocols:
+---------------------------------------------------------------+
| Inner EAP Method | Other TLV information |
|---------------------------------------------------------------|
| TLV Encapsulation (TLVs) |
|---------------------------------------------------------------|
| TLS |
|---------------------------------------------------------------|
| EAP-FAST |
|---------------------------------------------------------------|
| EAP |
|---------------------------------------------------------------|
| Carrier Protocol (EAPOL, RADIUS, Diameter, etc.) |
+---------------------------------------------------------------+
The TLV layer is a payload with standard Type-Length-Value (TLV)
Objects defined in Section 4.2. The TLV objects are used to carry
arbitrary parameters between an EAP peer and an EAP server. All
conversations in the EAP-FAST protected tunnel must be encapsulated
in a TLV layer.
Methods for encapsulating EAP within carrier protocols are already
defined. For example, IEEE 802.1x EAPOL may be used to transport EAP
between the peer and the authenticator; RADIUS or Diameter are used
to transport EAP between the authenticator and the EAP-FAST server.
3. EAP-FAST Protocol
EAP-FAST authentication occurs in two phases. For the first phase
EAP-FAST employs the TLS handshake to invoke an authenticated key
agreement exchange to establish a protected tunnel. Once the tunnel
is established phase 2 begins in which the peer and server can engage
Cam-Winget, et al. Expires April 22, 2006 [Page 7]
Internet-Draft EAP-FAST October 2005
in further conversations to establish the required authentication and
authorization policies. The operation of the protocol including
phase 1 and phase 2 are the topic of this section. The format of
EAP-FAST messages is given in Section 4 and the cryptographic
calculations are given in Section 5.
3.1 Version Negotiation
EAP-FAST packets contain a three bit version field, following the TLS
Flags field, which enables EAP-FAST implementations to be backward
compatible with previous versions of the protocol. This
specification documents the EAP-FAST version 1 protocol;
implementations of this specification MUST use a version field set to
1.
Version negotiation proceeds as follows:
In the first EAP-Request sent with EAP type=EAP-FAST, the EAP
server must set the version field to the highest supported version
number.
If the EAP peer supports this version of the protocol, it MUST
respond with an EAP-Response of EAP type=EAP-FAST, and the version
number proposed by the EAP-FAST server.
If the EAP-FAST peer does not support this version, it responds
with an EAP-Response of EAP type=EAP-FAST and the highest
supported version number.
If the EAP-FAST server does not support the version number
proposed by the EAP-FAST peer, it terminates the conversation.
Otherwise the EAP-FAST conversation continues.
The version negotiation procedure guarantees that the EAP-FAST peer
and server will agree to the latest version supported by both
parties. If version negotiation fails, then use of EAP-FAST will not
be possible, and another mutually acceptable EAP method will need to
be negotiated if authentication is to proceed.
The EAP-FAST version is not protected by TLS; and hence can be
modified in transit. In order to detect modification of EAP-FAST
version and specifically downgrade of an EAP-FAST version negotiated,
the peers MUST exchange information on the EAP-FAST version number
received during version negotiation using the Crypto-Binding TLV
described in Section 3.3.2. The receiver of the Crypto-Binding TLV
MUST verify that the version in the Crypto-Binding TLV matches the
version sent in the EAP-FAST version negotiation.
Cam-Winget, et al. Expires April 22, 2006 [Page 8]
Internet-Draft EAP-FAST October 2005
3.2 EAP-FAST Authentication Phase 1: Tunnel Establishment
EAP-FAST is based on TLS handshake [RFC2246] to establish an
authenticated and protected tunnel. The TLS version offered by the
peer and server MUST be TLS v1.0 or later. This version of the EAP-
FAST implementation MUST support the following TLS ciphersuites:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]
TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC3268]
Other ciphersuites MAY be supported. It is RECOMMENDED that
anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only
be used in the context of the provisioning described in [I-D.cam-
winget-eap-fast-provisioning]. During the EAP-FAST Phase 1
conversation the EAP-FAST endpoints MAY negotiate TLS compression.
The EAP server initiates the EAP-FAST conversation with an EAP
request containing an EAP-FAST/Start packet. This packet includes a
set Start (S) bit, the EAP-FAST version as specified in Section 3.1,
and an authority identity. The TLS payload in the initial packet is
empty. The authority identity (A-ID) is used to provide the peer a
hint of the server's identity which may be useful in helping the peer
select the appropriate credential to use. Assuming that the peer
supports EAP-FAST the conversation continues with the peer sending an
EAP-Response packet with EAP type of EAP-FAST with the start (s) bit
clear and the version as specified in Section 3.1. This message
encapsulates one or more TLS records containing the TLS handshake
messages. If the EAP-FAST version negotiation is successful then the
EAP-FAST conversation continues until the EAP server and EAP peer are
ready to enter phase 2. When the full TLS handshake is performed,
then the first payload of EAP-FAST Phase 2 MAY be sent along with
finished handshake message to reduce the number of round trips.
After the TLS session is established, another EAP exchange may occur
within the tunnel to authenticate the EAP peer. EAP-FAST
implementations MUST support client authentication during tunnel
establishment using the specified TLS ciphersuites specified in
Section 3.2. EAP-FAST implementations MUST also support the
immediate re-negotiation of a TLS session to initiate a new handshake
message exchange under the protection of the current ciphersuite.
This allows support for protection of the peer's identity. Note that
the EAP peer does not need to authenticate as part of the TLS
exchange, but can alternatively be authenticate through additional
EAP exchanges carried out in phase 2.
The EAP-FAST tunnel protects peer identity information from
disclosure outside the tunnel. Implementations that wish to provide
Cam-Winget, et al. Expires April 22, 2006 [Page 9]
Internet-Draft EAP-FAST October 2005
identity privacy for the peer identity must carefully consider what
information is disclosed outside the tunnel.
The following sections describe resuming a TLS session based on
server side or client side state.
3.2.1 TLS Session Resume using Server State
EAP-FAST session resumption is achieved in the same manner TLS
achieves session resume. To support session resumption, the server
and peer must minimally cache the Session ID, master secret and
ciphersuite. The peer attempts to resume a session by including a
valid Session ID from a previous handshake in its ClientHello
message. If the server finds a match for the Session ID and is
willing to establish a new connection using the specified session
state, the server will respond with the same session ID and proceed
with the EAP-FAST Authentication Phase 1 tunnel establishment based
on a TLS abbreviated handshake. After a successful conclusion of the
EAP-FAST Authentication Phase 1 conversation, the conversation then
continues on to phase 2.
3.2.2 TLS Session Resume Using a PAC
EAP-FAST supports the resumption of sessions based on client side
state using techniques described in [I-D.salowey-tls-ticket]. This
version of EAP-FAST does not support the provisioning of a ticket
through the use of the SessionTicket handshake message. Instead it
supports the provisioning of a ticket called a Protected Access
Credential (PAC) as described in [I-D.cam-winget-eap-fast-
provisioning]. Since the PAC mentioned here is used for establishing
the TLS Tunnel, it is more specifically referred to as the Tunnel
PAC. The Tunnel PAC is a security credential provided by the EAP
server to a peer and comprised of:
1. PAC-Key: this is a 32-octet key used by the peer to establish the
EAP-FAST Phase 1 tunnel. This key is used to derive the TLS
premaster secret as described in Section 5.1. The PAC-Key is
randomly generated by the EAP Server to produce a strong entropy
32-octet key. The PAC-Key is a secret and MUST be treated
accordingly. For example a PAC-Key MUST be delivered in a secure
channel and stored securely.
2. PAC-Opaque: this is a variable length field that is sent to the
EAP Server during the EAP-FAST Phase 1 tunnel establishment. The
PAC-Opaque can only be interpreted by the EAP Server to recover
the required information for the server to validate the peer's
identity and authentication. For example, the PAC-Opaque may
include the PAC-Key and the PAC's peer identity. The PAC-Opaque
Cam-Winget, et al. Expires April 22, 2006 [Page 10]
Internet-Draft EAP-FAST October 2005
format and contents are specific to the PAC issuing server. The
PAC-Opaque is a public credential and MAY be presented in the
clear, so an attacker MUST NOT be able to gain useful information
from the PAC-Opaque itself.
3. PAC-Info: this is a variable length field used to provide at
minimum, the authority identity of PAC issuer. Other useful but
not mandatory information, such as the PAC-Key lifetime, may also
be conveyed by the EAP Server to the peer during PAC provisioning
or refreshment.
The use of the PAC is based on the SessionTicket extension defined in
[I-D.salowey-tls-ticket]. The EAP Server initiates the TLS
conversation as in the previous section. Upon receiving the A-ID
from the server the Peer checks to see if it has an existing valid
PAC-Key and PAC-Opaque for the server. If it does then it obtains
the PAC-Opaque and puts it in the SessionTicket extension in the
ClientHello. It is RECOMMENDED in EAP-FAST that the peer include an
empty session ID in a ClientHello containing a PAC-Opaque. EAP-FAST
does not currently support the SessionTicket Handshake message so an
empty SessionTicket extension MUST NOT be included in the
ClientHello. If the PAC-Opaque included in SessionTicket extension
is valid and EAP server permits the abbreviated TLS handshake, it
will select the ciphersuite allowed to be used from information
within the PAC and finish with the abbreviated TLS handshake. If the
server receives a Session ID and a PAC-Opaque in the SessionTicket
extension in a ClientHello it should place the same Session ID in the
ServerHello if it is resuming a session based on the PAC-Opaque. The
conversation then proceeds as described in [I-D.salowey-tls-ticket]
until the handshake completes or a fatal error occurs. After the
abbreviated handshake completes the peer and server are ready to
enter phase 2. Note that when a PAC is used the TLS master secret is
calculated from the PAC-Key, client random and server random as
described in Section 5.1.
3.2.3 Transition between Abbreviated and Full TLS Handshake
If session resumption based on server side or client side state fails
the server can gracefully fall back to a full TLS handshake. If the
ServerHello received by the peer contains a empty Session ID or a
Session ID that is different than in the ClientHello the server may
be falling back to a full handshake. The peer can distinguish
Server's intent of negotiating full or abbreviated TLS handshake by
checking the next TLS handshake messages in the server response to
ClientHello. If ChangeCipherSpec follows the ServerHello in response
to the ClientHello, then the Server has accepted the session
resumption and intends to negotiate the abbreviated handshake.
Cam-Winget, et al. Expires April 22, 2006 [Page 11]
Internet-Draft EAP-FAST October 2005
Otherwise, the Server intends to negotiate the full TLS handshake. A
peer can request for a new PAC to be provisioned after the full TLS
handshake and mutual authentication of the peer and the server. In
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -