| | |
| Diameter-EAP-Answer |
| Redirect-Host=homeserver.example.com |
| Redirect-Host-Usage=REALM_AND_APPLICATION |
|<-------------------------------| |
| : |
| Diameter-EAP-Request : |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) : |
|---------------------------------------------------------------->|
| : |
: ...rest of the session continues as in first case... :
: : :
The advantage of this scenario is that knowledge of realms and home
servers is centralized to a redirect agent, and it is not necessary
to modify the NAS configuration when, for example, a new roaming
agreement is made.
2.3.3. Scenario 3: Direct EAP, Authorization via Agents
In this scenario the EAP authentication is done directly with the
home server (with Auth-Request-Type set to AUTHENTICATE_ONLY), and
authorization AVPs are retrieved from local proxy agents. This
scenario is intended for environments in which the home server cannot
provide all the necessary authorization AVPs to the NAS.
NAS Local proxy agent Home server
| : |
| Diameter-EAP-Request : |
| Auth-Request-Type=AUTHENTICATE_ONLY |
| 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) |
|<----------------------------------------------------------------|
| | |
| AA-Request | |
| Auth-Request-Type=AUTHORIZE_ONLY |
| (some AVPs from first session) | |
|------------------------------->| |
| | |
| AA-Answer | |
| Result-Code=DIAMETER_SUCCESS | |
| (authorization AVPs) | |
|<-------------------------------| |
The NASREQ application is used here for authorization because the
realm-specific routing table supports routing based on application,
not on Diameter commands.
2.3.4. Scenario 4: Proxy Agents
This scenario is the same as Scenario 1, but the NAS contacts the
home server through proxies. Note that the proxies can see the EAP
session keys, thus it is not suitable for environments where proxies
cannot be trusted.
NAS Local proxy/relay agent 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) |
|<-------------------------------|<-------------------------------|
2.4. Invalid Packets
While acting as a pass-through, the NAS MUST validate the EAP header
fields (Code, Identifier, Length) prior to forwarding an EAP packet
to or from the Diameter server. On receiving an EAP packet from the
peer, the NAS checks the Code (Code 2=Response) and Length fields,
and matches the Identifier value against the current Identifier,
supplied by the Diameter server in the most recently validated EAP
Request. On receiving an EAP packet from the Diameter server
(encapsulated within a Diameter-EAP-Answer), the NAS checks the Code
(Code 1=Request) and Length fields, then updates the current
Identifier value. Pending EAP Responses that do not match the
current Identifier value are silently discarded by the NAS.
Since EAP method fields (Type, Type-Data) are typically not validated
by a NAS operating as a pass-through, despite these checks it is
possible for a NAS to forward an invalid EAP packet to or from the
Diameter server.
A Diameter server receiving an EAP-Payload AVP that it does not
understand SHOULD determine whether the error is fatal or non-fatal
based on the EAP Type. A Diameter server determining that a fatal
error has occurred MUST send a Diameter-EAP-Answer with a failure
Result-Code and an EAP-Payload AVP encapsulating an EAP Failure
packet. A Diameter server determining that a non-fatal error has
occurred MUST send a Diameter-EAP-Answer with
DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP. To
simplify RADIUS translation, this message MUST also include an
EAP-Reissued-Payload AVP encapsulating the previous EAP Request sent
by the server.
When receiving a Diameter-EAP-Answer without an EAP-Payload AVP (and
DIAMETER_MULTI_ROUND_AUTH Result-Code), the NAS SHOULD discard the
EAP-Response packet most recently transmitted to the Diameter server
and check whether additional EAP Response packets that match the
current Identifier value have been received. If so, a new EAP
Response packet, if available, MUST be sent to the Diameter server
within an Diameter-EAP-Request. If no EAP Response packet is
available, then the previous EAP Request is resent to the peer, and
the retransmission timer is reset.
In order to provide protection against Denial of Service (DoS)
attacks, it is advisable for the NAS to allocate a finite buffer for
EAP packets received from the peer, and to discard packets according
to an appropriate policy once that buffer has been exceeded. Also,
the Diameter server is advised to permit only a modest number of
invalid EAP packets within a single session, prior to terminating the
session with DIAMETER_AUTHENTICATION_REJECTED Result-Code. By
default, a value of 5 invalid EAP packets is recommended.
2.5. Retransmission
As noted in [EAP], if an EAP packet is lost in transit between the
authenticating peer and the NAS (or vice versa), the NAS will
retransmit.
It may be necessary to adjust retransmission strategies and
authentication time-outs in certain cases. For example, when a token
card is used, additional time may be required to allow the user to
find the card and enter the token. Since the NAS will typically not
have knowledge of the required parameters, these need to be provided
by the Diameter server.
If a Multi-Round-Time-Out AVP [BASE] is present in a Diameter-EAP-
Answer message that also contains an EAP-Payload AVP, that value is
used to set the EAP retransmission timer for that EAP Request and
that Request alone.
2.6. Fragmentation
Using the EAP-Payload AVP, it is possible for the Diameter server to
encapsulate an EAP packet that is larger than the MTU on the link
between the NAS and the peer. Since it is not possible for the
Diameter server to use MTU discovery to ascertain the link MTU, a
Framed-MTU AVP may be included in a Diameter-EAP-Request message in
order to provide the Diameter server with this information.
A Diameter server having received a Framed-MTU AVP in a
Diameter-EAP-Request message MUST NOT send any subsequent packet in
this EAP conversation containing EAP-Payload AVP whose length exceeds
that specified by the Framed-MTU value, taking the link type
(specified by the NAS-Port-Type AVP) into account. For example, as
noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE
802.11, the RADIUS server may send an EAP packet as large as
Framed-MTU minus four (4) octets, taking into account the additional
overhead for the IEEE 802.1X Version (1 octet), Type (1 octet) and
Body Length (2 octets) fields.
2.7. Accounting
When a user is authenticated using EAP, the NAS MAY include an
Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) in
Accounting-Request messages. This document specifies one additional
AVP for accounting messages. One or more Accounting-EAP-Auth-Method
AVPs (see Section 4.1.5) MAY be included in Accounting-Request
messages to indicate the EAP method(s) used to authenticate the user.
If the NAS has authenticated the user with a locally implemented EAP
method, it knows the method used and SHOULD include it in an
Accounting-EAP-Auth-Method AVP.
If the authentication was done using Diameter-EAP-Request/Answer
messages, the Diameter server SHOULD include one or more
Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a
successful result code. In this case, the NAS SHOULD include these
AVPs in Accounting-Request messages.
2.8. Usage Guidelines
2.8.1. User-Name AVP
Unless the access device interprets the EAP-Response/Identity packet
returned by the authenticating peer, it will not have access to the
user’s identity. Furthermore, some EAP methods support identity
protection where the user’s real identity is not included in
EAP-Response/Identity. Therefore, the Diameter Server SHOULD return
the user’s identity by inserting a User-Name AVP to
Diameter-EAP-Answer messages that have a Result-Code of
DIAMETER_SUCCESS. A separate billing identifier or pseudonym MAY be
used for privacy reasons (see Section 8.5). If the user’s identity
is not available to the NAS, the Session-Id AVP MAY be used for
accounting and billing; however operationally this could be very
difficult to manage.
2.8.2. Conflicting AVPs
A Diameter-EAP-Answer message containing an EAP-Payload of type
EAP-Success or EAP-Failure MUST NOT have the Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH.
Some lower layers assume that the authorization decision is made by
the EAP server, and thus the peer considers EAP Success as an
indication that access was granted. In this case, the Result-Code
SHOULD match the contained EAP packet: a successful Result-Code for
EAP-Success, and a failure Result-Code for EAP-Failure. If the
encapsulated EAP packet does not match the result implied by the
Result-Code AVP, the combination is likely to cause confusion,
because the NAS and peer will conclude the outcome of the
authentication differently. For example, if the NAS receives a
failure Result-Code with an encapsulated EAP Success, it will not
grant access to the peer. However, on receiving the EAP Success, the
peer will be led to believe that access was granted.
This situation can be difficult to avoid when Diameter proxy agents
make authorization decisions (that is, proxies can change the
Result-Code AVP sent by the home server). Because it is the
responsibility of the Diameter server to avoid conflicts, the NAS
MUST NOT "manufacture" EAP result packets in order to correct the
contradictory messages that it receives. This behavior, originally
mandated within [IEEE-802.1X], is now deprecated.
2.8.3. Displayable Messages
The Reply-Message AVP [NASREQ] MUST NOT be included in any Diameter
message containing an EAP-Payload AVP.
2.8.4. Role Reversal
Some environments in which EAP is used, such as PPP, support
peer-to-peer operation. Both parties act as authenticators and
authenticatees at the same time, in two simultaneous and independent
EAP conversations.
This specification is intended for communication between EAP
(passthrough) authenticator and backend authentication server. A
Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an
EAP Request packet, and a Diameter server receiving such a packet
MUST respond with a failure Result-Code.
2.8.5. Identifier Space
In EAP, each session has its own unique Identifier space. Diameter
server implementations MUST be able to distinguish between EAP
packets with the same Identifier existing within distinct EAP
sessions and originating on the same NAS. This is done by using the
Session-Id AVP.
If a Diameter NAS is in the middle of a multi-round authentication
exchange, and it detects that the EAP session between the client and
the NAS has been terminated, it MUST select a new Diameter Session-Id
for any subsequent EAP sessions. This is necessary in order to
distinguish a restarted EAP authentication process from the
continuation of an ongoing process (by the same user on the same NAS
and port).
In RADIUS, the same functionality can be achieved through the
inclusion or omission of the State attribute. Translation rules in
[NASREQ] ensure that an Access-Request without the State attribute
maps to a new Diameter Session-Id AVP value. Furthermore, a
translation agent will always include a State attribute in
Access-Challenge messages, making sure that the State attribute is
available for a RADIUS NAS.
3. Command-Codes
This section defines new Command-Code values that MUST be supported
by all Diameter implementations conforming to this specification.
The following commands are defined in this section:
Command-Name Abbrev. Code Reference
--------------------------------------------------------
Diameter-EAP-Request DER 268 3.1
Diameter-EAP-Answer DEA 268 3.2
When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used
for AUTHORIZE_ONLY messages in conjunction with EAP (see
Section 2.3.3), an Application Identifier value of 1 (NASREQ) is
used, and the commands follow the rules and ABNF defined in [NASREQ].
When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA),
Session-Termination-Request (STR), Session-Termination-Answer (STA),
Abort-Session-Request (ASR), Abort-Session-Answer (ASA),
Accounting-Request (ACR), and Accounting-Answer (ACA) commands are
used together with the Diameter EAP application, they follow the
rules in [NASREQ] and [BASE]. The accounting commands use
Application Identifier value of 3 (Diameter Base Accounting); the
others use 0 (Diameter Common Messages).
3.1. Diameter-EAP-Request (DER) Command
The Diameter-EAP-Request (DER) command, indicated by the Command-Code
field set to 268 and the ’R’ bit set in the Command Flags field, is
sent by a Diameter client to a Diameter server, and conveys an
EAP-Response from the EAP client. The Diameter-EAP-Request MUST
contain one EAP-Payload AVP containing the actual EAP payload. An
EAP-Payload AVP with no data MAY be sent to the Diameter server to
initiate an EAP authentication session.
The DER message MAY be the result of a multi-round authentication
exchange that occurs when the DEA is received with the Result-Code
AVP set to DIAMETER_MULTI_ROUND_AUTH [BASE]. A subsequent DER
message MUST include any State AVPs [NASREQ] that were present in the
DEA. For re-authentication, it is recommended that the Identity
request be skipped in order to reduce the number of authentication
round trips. This is only possible when the user’s identity is
already known by the home Diameter server.
Message format
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
[ Origin-State-Id ]
[ Port-Limit ]
[ User-Name ]
{ EAP-Payload }
[ EAP-Key-Name ]