📄 draft-cam-winget-eap-fast-03.txt
字号:
Network Working Group N. Cam-Winget
Internet-Draft D. McGrew
Expires: April 22, 2006 J. Salowey
H. Zhou
Cisco Systems
October 19, 2005
The Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)
draft-cam-winget-eap-fast-03.txt
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 April 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the Extensible Authentication Protocol (EAP)
based Flexible Authentication via Secure Tunneling (EAP-FAST)
protocol. EAP-FAST is an EAP method that enables secure
communication between a peer and a server by using the Transport
Layer Security (TLS) to establish a mutually authenticated tunnel.
Cam-Winget, et al. Expires April 22, 2006 [Page 1]
Internet-Draft EAP-FAST October 2005
Within the tunnel, Type-Length-Value (TLV) objects are used to convey
authentication related data between the peer and the EAP server.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification Requirements . . . . . . . . . . . . . . . . 5
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Architectural Model . . . . . . . . . . . . . . . . . . . 6
2.2 Protocol Layering Model . . . . . . . . . . . . . . . . . 7
3. EAP-FAST Protocol . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Version Negotiation . . . . . . . . . . . . . . . . . . . 8
3.2 EAP-FAST Authentication Phase 1: Tunnel Establishment . . 9
3.2.1 TLS Session Resume using Server State . . . . . . . . 10
3.2.2 TLS Session Resume Using a PAC . . . . . . . . . . . . 10
3.2.3 Transition between Abbreviated and Full TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . 11
3.3 EAP-FAST Authentication Phase 2: Tunneled
Authentication . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 EAP Sequences . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Protected Termination and Acknowledged Result
Indication . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Error Handling . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 TLS Layer Errors . . . . . . . . . . . . . . . . . . . 14
3.4.2 Phase 2 Errors . . . . . . . . . . . . . . . . . . . . 14
3.5 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 EAP-FAST Message Format . . . . . . . . . . . . . . . . . 16
4.1.1 Authority ID Data . . . . . . . . . . . . . . . . . . 18
4.2 EAP-FAST TLV Format and Support . . . . . . . . . . . . . 19
4.2.1 General TLV Format . . . . . . . . . . . . . . . . . . 19
4.2.2 Result TLV . . . . . . . . . . . . . . . . . . . . . . 20
4.2.3 NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Error TLV . . . . . . . . . . . . . . . . . . . . . . 23
4.2.5 Vendor-Specific TLV . . . . . . . . . . . . . . . . . 24
4.2.6 EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 25
4.2.7 Intermediate-Result TLV . . . . . . . . . . . . . . . 26
4.2.8 Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 27
4.2.9 Request-Action TLV . . . . . . . . . . . . . . . . . . 29
4.3 Table of TLVs . . . . . . . . . . . . . . . . . . . . . . 30
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . . 31
5.1 EAP-FAST Authentication Phase 1: Key Derivations . . . . . 31
5.2 Intermediate Compound Key Derivations . . . . . . . . . . 32
5.3 Computing the Compound MAC . . . . . . . . . . . . . . . . 32
5.4 EAP Master Session Key Generation . . . . . . . . . . . . 33
5.5 T-PRF . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
Cam-Winget, et al. Expires April 22, 2006 [Page 2]
Internet-Draft EAP-FAST October 2005
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.1 Mutual Authentication and Integrity Protection . . . . . . 35
7.2 Method Negotiation . . . . . . . . . . . . . . . . . . . . 35
7.3 Separation of the EAP Server and the Authenticator . . . . 36
7.4 Separation of Phase 1 and Phase 2 Servers . . . . . . . . 36
7.5 Mitigation of Known Vulnerabilities and Protocol
Deficiencies . . . . . . . . . . . . . . . . . . . . . . . 37
7.5.1 User Identity Protection and Verification . . . . . . 38
7.5.2 Dictionary Attack Resistance . . . . . . . . . . . . . 39
7.5.3 Protection against MitM Attacks . . . . . . . . . . . 39
7.5.4 PAC Validation with User Credentials . . . . . . . . . 40
7.6 Protecting against Forged Clear Text EAP Packets . . . . . 41
7.7 Implementation . . . . . . . . . . . . . . . . . . . . . . 42
7.8 Server Certificate Validation . . . . . . . . . . . . . . 42
7.9 Security Claims . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1 Normative References . . . . . . . . . . . . . . . . . . . 43
9.2 Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44
A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.1 Successful Authentication . . . . . . . . . . . . . . . . 45
A.2 Failed Authentication . . . . . . . . . . . . . . . . . . 46
A.3 Full TLS Handshake using Certificate-based Cipher Suite . 48
A.4 Client authentication during Phase 1 with identity
privacy . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.5 Fragmentation and Reassembly . . . . . . . . . . . . . . . 51
A.6 Sequence of EAP Methods . . . . . . . . . . . . . . . . . 53
A.7 Failed Crypto-binding . . . . . . . . . . . . . . . . . . 55
A.8 Stateless Session Resume Using Authorization PAC . . . . . 57
A.9 Sequence of EAP Method with Vendor-Specific TLV
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 58
B. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 60
B.1 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 60
B.2 Crypto-Binding MIC . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . 63
Cam-Winget, et al. Expires April 22, 2006 [Page 3]
Internet-Draft EAP-FAST October 2005
1. Introduction
The need to provide user friendly and easily deployable network
access solutions has heightened the need for strong mutual
authentication protocols that internally use weak user credentials.
This document defines the base protocol which consists of
establishing a Transport Layer Security (TLS) tunnel as defined in
[RFC2246] and then exchanging data in the form of type, length, value
objects (TLV) to perform further authentication. [I-D.cam-winget-
eap-fast-provisioning] defines extensions to provision an additional
credential called a protected access credential (PAC) to optimize the
EAP-FAST exchange. In addition to regular TLS ciphersuites and
handshakes, EAP-FAST supports using a PAC with the TLS extension
defined in [I-D.salowey-tls-ticket] in order to support fast re-
establishment of the secure tunnel without having to maintain per-
session state on the server as described in Section 3.2.2.
EAP-FAST's design motivations included:
o Mutual Authentication: an EAP Server must be able to verify the
identity and authenticity of the peer, and the peer must be able
to verify the authenticity of the EAP server.
o Immunity to passive dictionary attacks: as many authentication
protocols require the password to be explicitly provided (either
in the clear or hashed) by the peer to the EAP server; at minimum,
the communication of the weak credential (e.g. password) must be
immune from eavesdropping.
o Immunity to man-in-the-middle (MitM) attacks: in establishing a
mutually authenticated protected tunnel, the protocol must prevent
adversaries from successfully interjecting information into the
conversation between the peer and the EAP server.
o Flexibility to enable support for most password authentication
interfaces: as many different password interfaces (e.g. MSCHAP,
LDAP, OTP, etc) exist to authenticate a peer, the protocol must
provide this support seamlessly.
o Efficiency: specifically when using wireless media, peers will be
limited in computational and power resources. The protocol must
enable the network access communication to be computationally
lightweight.
With these motivational goals defined, further secondary design
criteria are imposed:
Cam-Winget, et al. Expires April 22, 2006 [Page 4]
Internet-Draft EAP-FAST October 2005
o Flexibility to extend the communications inside the tunnel: with
the growing complexity in network infrastructures the need to gain
authentication, authorization and accounting is also evolving.
For instance, there may be instances in which multiple (already
existent) authentication protocols are required to achieve mutual
authentication. Similarly, different protected conversations may
be required to achieve the proper authorization once a peer has
successfully authenticated.
o Minimize the authentication server's per user authentication state
requirements: with large deployments, it is typical to have many
servers acting as the authentication servers for many peers. It
is also highly desirable for a peer to use the same shared secret
to secure a tunnel much the same way it uses the username and
password to gain access to the network. The protocol must
facilitate the use of a single strong shared secret by the peer
while enabling the servers to minimize the per user and device
state it must cache and manage.
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 in this document comes from [RFC3748].
Additional terms are defined below:
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 optionally other information.
The shared secret part contains the pre-shared key between the
peer and the authentication server. The opaque part is provided
to the peer and is presented to the authentication 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. The opaque part of the PAC is the same type of data as the
ticket in [I-D.salowey-tls-ticket].
2. Protocol Overview
EAP-FAST is an authentication protocol similar to EAP-TLS [RFC2716]
that enables mutual authentication and cryptographic context
establishment by using the TLS handshake protocol. EAP-FAST allows
Cam-Winget, et al. Expires April 22, 2006 [Page 5]
Internet-Draft EAP-FAST October 2005
for the established TLS tunnel to be used for further authentication
exchanges. EAP-FAST makes use of TLVs to carry out the inner
authentication exchanges. The tunnel is then used to protect weaker
inner authentication methods, which may be based on passwords, and to
communicate the results of the authentication.
EAP-FAST makes use of the TLS enhancements in [I-D.salowey-tls-
ticket] to enable an optimized TLS tunnel session resume while
minimizing server state. In EAP-FAST the key and ticket used to
establish the tunnel may be provisioned through mechanisms that do
not involve the TLS handshake. It is RECOMMENDED that
implementations support the capability to distribute the ticket and
secret key within the EAP-FAST tunnel as specified in [I-D.cam-
winget-eap-fast-provisioning]. The pre-shared secret used in EAP-
FAST is referred to as the protected access credential key (or PAC-
Key); the PAC-Key is used to mutually authenticate the peer and the
server when securing a tunnel. The ticket is referred to as the
protected access credential opaque data (or PAC-Opaque).
The EAP-FAST conversation is used to establish or resume an existing
session to typically establish network connectivity between a peer
and the network. Upon successful execution of EAP-FAST both EAP Peer
and EAP Server derive strong session keys which can then communicated
to the network access server (NAS).
2.1 Architectural Model
The network architectural model for EAP-FAST usage is shown below:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -