Request for Comments: 4072 Nokia
Category: Standards Track T. Hiller
Lucent Technologies
G. Zorn
Cisco Systems
August 2005
Diameter Extensible Authentication Protocol (EAP) Application
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Extensible Authentication Protocol (EAP) provides a standard
mechanism for support of various authentication methods. This
document defines the Command-Codes and AVPs necessary to carry EAP
packets between a Network Access Server (NAS) and a back-end
authentication server.
Table of Contents
1. Introduction ...................................................2
1.1. Conventions Used in This Document ........................3
2. Extensible Authentication Protocol Support in Diameter .........3
2.1. Advertising Application Support ..........................3
2.2. Protocol Overview ........................................4
2.3. Sessions and NASREQ Interaction ..........................6
2.3.1. Scenario 1: Direct Connection .....................7
2.3.2. Scenario 2: Direct Connection with Redirects ......8
2.3.3. Scenario 3: Direct EAP, Authorization via Agents ..9
2.3.4. Scenario 4: Proxy Agents .........................10
2.4. Invalid Packets .........................................10
2.5. Retransmission ..........................................11
2.6. Fragmentation ...........................................12
2.7. Accounting ..............................................12
2.8. Usage Guidelines ........................................13
2.8.1. User-Name AVP ....................................13
2.8.2. Conflicting AVPs .................................13
2.8.3. Displayable Messages .............................14
2.8.4. Role Reversal ....................................14
2.8.5. Identifier Space .................................14
3. Command-Codes .................................................14
3.1. Diameter-EAP-Request (DER) Command ......................15
3.2. Diameter-EAP-Answer (DEA) Command .......................16
4. Attribute-Value Pairs .........................................18
4.1. New AVPs ................................................18
4.1.1. EAP-Payload AVP ..................................18
4.1.2. EAP-Reissued-Payload AVP .........................18
4.1.3. EAP-Master-Session-Key AVP .......................19
4.1.4. EAP-Key-Name AVP .................................19
4.1.5. Accounting-EAP-Auth-Method AVP ...................19
5. AVP Occurrence Tables .........................................19
5.1. EAP Command AVP Table ...................................20
5.2. Accounting AVP Table ....................................21
6. RADIUS/Diameter Interactions ..................................22
6.1. RADIUS Request Forwarded as Diameter Request ............22
6.2. Diameter Request Forwarded as RADIUS Request ............23
6.3. Accounting Requests .....................................24
7. IANA Considerations ...........................................24
8. Security Considerations .......................................24
8.1. Overview ................................................24
8.2. AVP Editing .............................................26
8.3. Negotiation Attacks .....................................27
8.4. Session Key Distribution ................................28
8.5. Privacy Issues ..........................................28
8.6. Note about EAP and Impersonation ........................29
9. Acknowledgements ..............................................29
10. References ....................................................30
10.1. Normative References ....................................30
10.2. Informative References ..................................30
1. Introduction
The Extensible Authentication Protocol (EAP), defined in [EAP], is an
authentication framework which supports multiple authentication
mechanisms. EAP may be used on dedicated links, switched circuits,
and wired as well as wireless links.
To date, EAP has been implemented with hosts and routers that connect
via switched circuits or dial-up lines using PPP [RFC1661], IEEE 802
wired switches [IEEE-802.1X], and IEEE 802.11 wireless access points
[IEEE-802.11i]. EAP has also been adopted for IPsec remote access in
IKEv2 [IKEv2].
This document specifies the Diameter EAP application that carries EAP
packets between a Network Access Server (NAS) working as an EAP
Authenticator and a back-end authentication server. The Diameter EAP
application is based on the Diameter Network Access Server
Application [NASREQ] and is intended for environments similar to
NASREQ.
In the Diameter EAP application, authentication occurs between the
EAP client and its home Diameter server. This end-to-end
authentication reduces the possibility for fraudulent authentication,
such as replay and man-in-the-middle attacks. End-to-end
authentication also provides a possibility for mutual authentication,
which is not possible with PAP and CHAP in a roaming PPP environment.
The Diameter EAP application relies heavily on [NASREQ], and in
earlier versions was part of the Diameter NASREQ application. It can
also be used in conjunction with NASREQ, selecting the application
based on the user authentication mechanism (EAP or PAP/CHAP). The
Diameter EAP application defines new Command-Codes and Attribute-
Value Pairs (AVPs), and can work together with RADIUS EAP support
[RFC3579].
1.1. Conventions Used in This Document
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].
2. Extensible Authentication Protocol Support in Diameter
2.1. Advertising Application Support
Diameter nodes conforming to this specification MUST advertise
support by including the Diameter EAP Application ID value of 5 in
the Auth-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer command [BASE].
If the NAS receives a response with the Result-Code set to
DIAMETER_APPLICATION_UNSUPPORTED [BASE], it indicates that the
Diameter server in the home realm does not support EAP. If possible,
the access device MAY attempt to negotiate another authentication
protocol, such as PAP or CHAP. An access device SHOULD be cautious
when determining whether a less secure authentication protocol will
be used, since this could result from a downgrade attack (see
Section 8.3).
2.2. Protocol Overview
The EAP conversation between the authenticating peer and the access
device begins with the initiation of EAP within a link layer, such as
PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been
initiated, the access device will typically send a Diameter-EAP-
Request message with an empty EAP-Payload AVP to the Diameter server,
signifying an EAP-Start.
If the Diameter home server is willing to do EAP authentication, it
responds with a Diameter-EAP-Answer message containing an EAP-Payload
AVP that includes an encapsulated EAP packet. The Result-Code AVP in
the message will be set to DIAMETER_MULTI_ROUND_AUTH, signifying that
a subsequent request is expected. The EAP payload is forwarded by
the access device to the EAP client. This is illustrated in the
diagram below.
User NAS Server
| | |
| (initiate EAP) | |
|<------------------------------>| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Start) |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| | EAP-Payload(EAP Request #1) |
| |<-------------------------------|
| EAP Request #1 | |
|<-------------------------------| |
: : :
: ...continues... :
The initial Diameter-EAP-Answer in a multi-round exchange normally
includes an EAP-Request/Identity, requesting the EAP client to
identify itself. Upon receipt of the EAP client’s EAP-Response, the
access device will then issue a second Diameter-EAP-Request message,
with the client’s EAP payload encapsulated within the EAP-Payload
AVP.
A preferred approach is for the access device to issue the
EAP-Request/Identity message to the EAP client, and forward the
EAP-Response/Identity packet, encapsulated within the EAP-Payload
AVP, as a Diameter-EAP-Request to the Diameter server (see the
diagram below). This alternative reduces the number of Diameter
message round trips. When the EAP-Request/Identity message is issued
by the access device, it SHOULD interpret the EAP-Response/Identity
packet returned by the authenticating peer, and copy its value to a
User-Name AVP in Diameter-EAP-Request. This is useful in roaming
environments, since the Destination-Realm is needed for routing
purposes. Note that this alternative cannot be universally employed,
as there are circumstances in which a user’s identity is not needed
(such as when authorization occurs based on a calling or called phone
number).
User NAS Server
| | |
| (initiate EAP) | |
|<------------------------------>| |
| | |
| EAP Request(Identity) | |
|<-------------------------------| |
| | |
| EAP Response(Identity) | |
|------------------------------->| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Response) |
| |------------------------------->|
: : :
: ...continues... :
The conversation continues until the Diameter server sends a
Diameter-EAP-Answer with a Result-Code AVP indicating success or
failure, and an optional EAP-Payload. The Result-Code AVP is used by
the access device to determine whether service is to be provided to
the EAP client. The access device MUST NOT rely on the contents of
the optional EAP-Payload to determine whether service is to be
provided.
: ...continued... :
: : :
| EAP Response #N | |
|------------------------------->| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Response #N) |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| | Result-Code=DIAMETER_SUCCESS |
| | EAP-Payload(EAP Success) |
| | [EAP-Master-Session-Key] |
| | (authorization AVPs) |
| |<-------------------------------|
| | |
| EAP Success | |
|<-------------------------------| |
If authorization was requested, a Diameter-EAP-Answer with
Result-Code set to DIAMETER_SUCCESS SHOULD also include the
appropriate authorization AVPs required for the service requested
(see Section 5 and [NASREQ]). In some cases, the home server may not
be able to provide all necessary authorization AVPs; in this case, a
separate authorization step MAY be used as described in
Section 2.3.3. Diameter-EAP-Answer messages whose Result-Code AVP is
set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs.
A Diameter-EAP-Answer with successful Result-Code MAY also include an
EAP-Master-Session-Key AVP that contains keying material for
protecting the communication between the user and the NAS. Exactly
how this keying material is used depends on the link layer in
question, and is beyond the scope of this document.
A home Diameter server MAY request EAP re-authentication by issuing
the Re-Auth-Request [BASE] message to the Diameter client.
Should an EAP authentication session be interrupted due to a home
server failure, the session MAY be directed to an alternate server,
but the authentication session will have to be restarted from the
beginning.
2.3. Sessions and NASREQ Interaction
The previous section introduced the basic protocol between the NAS
and the home server. Since the Diameter-EAP-Answer message may
include a Master Session Key (MSK) for protecting the communication
between the user and the NAS, one must ensure that this key does not
fall into wrong hands.
Basic Diameter security mechanisms (IPsec and TLS) protect Diameter
messages hop-by-hop. Since there are currently no end-to-end
(NAS-to-home server) security mechanisms defined for Diameter, this
section describes possible scenarios on how the messages could be
transport protected using these hop-by-hop mechanisms.
This list of scenarios is not intended to be exhaustive, and it is
possible to combine them. For instance, the first proxy agent after
the NAS could use redirects as in Scenario 2 to bypass any additional
proxy agents.
2.3.1. Scenario 1: Direct Connection
The simplest case is when the NAS contacts the home server directly.
All authorization AVPs and EAP keying material are delivered by the
home server.
NAS home server
| |
| Diameter-EAP-Request |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| EAP-Payload(EAP Request) |
|<----------------------------------------------------------------|
| |
: ...more EAP Request/Response pairs... :
| |
| Diameter-EAP-Request |
| EAP-Payload(EAP Response) |
|---------------------------------------------------------------->|
| |
| Diameter-EAP-Answer |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
|<----------------------------------------------------------------|
This scenario is the most likely to be used in small networks, or in
cases where Diameter agents are not needed to provide routing or
additional authorization AVPs.
2.3.2. Scenario 2: Direct Connection with Redirects
In this scenario the NAS uses a redirect agent to locate the home
server. The rest of the session proceeds as before.
NAS Local redirect agent Home server
| | |
| Diameter-EAP-Request | |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | |
|------------------------------->| |