Internet DRAFT - draft-ieft-pana-aaa-interworking
draft-ieft-pana-aaa-interworking
Network Working Group A. Lior
Internet-Draft Bridgewater Systems
Expires: January 26, 2006 A. Yegin
Samsung
July 25, 2005
PANA AAA Interworking.
draft-ieft-pana-aaa-interworking-00
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 January 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides information on the interworking of Protocol
for Carrying Authentication for Network Access (PANA) with IETF AAA
protocols -- Remote Authentication Dial In User Service (RADIUS) and
Diameter.
Lior & Yegin Expires January 26, 2006 [Page 1]
Internet-Draft PANA AAA Interworking July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Mapping of PANA Phases to AAA phases . . . . . . . . . . . 6
3.2 Call Flows . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Call flow for a single authentication . . . . . . . . 7
3.2.2 PANA ISP/NAP Authentication Call Flow . . . . . . . . 10
3.2.3 PANA Termination . . . . . . . . . . . . . . . . . . . 11
3.2.4 Re-authentication . . . . . . . . . . . . . . . . . . 15
4. PANA RADIUS Message Mapping . . . . . . . . . . . . . . . . . 16
4.1 RADIUS Access-Request . . . . . . . . . . . . . . . . . . 17
4.2 Access-Challenge . . . . . . . . . . . . . . . . . . . . . 17
4.3 Access-Accept . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Access-Reject . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Accounting-Request . . . . . . . . . . . . . . . . . . . . 19
4.6 Disconnect-Request . . . . . . . . . . . . . . . . . . . . 19
5. PANA Diameter Message Mapping . . . . . . . . . . . . . . . . 20
5.1 Diameter EAP Request (DER) . . . . . . . . . . . . . . . . 20
5.2 Diameter EAP Answer (DEA) . . . . . . . . . . . . . . . . 21
5.3 Diameter Accounting . . . . . . . . . . . . . . . . . . . 22
5.4 Abort-Session-Request . . . . . . . . . . . . . . . . . . 22
6. RADIUS Diameter Translation . . . . . . . . . . . . . . . . . 23
7. RADIUS Attributes to PANA AVP Mapping . . . . . . . . . . . . 23
7.1 Consideration for User-Name . . . . . . . . . . . . . . . 23
7.2 EAP-Message . . . . . . . . . . . . . . . . . . . . . . . 24
7.3 PANA Session . . . . . . . . . . . . . . . . . . . . . . . 24
7.4 Session-Termination . . . . . . . . . . . . . . . . . . . 24
7.5 Error-Cause Mapping . . . . . . . . . . . . . . . . . . . 25
7.6 Consideration Acct-Terminate-Cause . . . . . . . . . . . . 25
7.7 RADIUS Table of Attributes . . . . . . . . . . . . . . . . 25
8. DIAMETER AVP to PANA AVP Mapping . . . . . . . . . . . . . . . 26
8.1 Consideration for User-Name . . . . . . . . . . . . . . . 27
8.2 EAP-Payload . . . . . . . . . . . . . . . . . . . . . . . 27
8.3 PANA and Diameter Session-Identifier Mapping . . . . . . . 28
8.4 Session-Termination Mapping . . . . . . . . . . . . . . . 28
8.5 Diameter PANA Result Code Mapping . . . . . . . . . . . . 29
8.6 DIAMETER Table of Attributes . . . . . . . . . . . . . . . 29
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . 29
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1 Normative references . . . . . . . . . . . . . . . . . . . 30
12.2 Informative references . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
Lior & Yegin Expires January 26, 2006 [Page 2]
Internet-Draft PANA AAA Interworking July 2005
Intellectual Property and Copyright Statements . . . . . . . . 32
Lior & Yegin Expires January 26, 2006 [Page 3]
Internet-Draft PANA AAA Interworking July 2005
1. Introduction
The Protocol for Carrying Authentication for Network Access (PANA) is
specified in [I-D.ietf-pana-pana] and designed to carry Extensible
Authentication Protocol (EAP) [RFC3748] based authentication methods
between the client and the access network over IP.
PANA can work with AAA infrastructures such as RADIUS [RFC2865] and
Diameter [RFC3588]. PANA transports the EAP-based authentication
methods between the PANA Client (PaC) known as the EAP peer and the
PANA Authentication Agent (PAA) also known as the EAP authenticator.
When used with the AAA infrastructure, the PAA acting as a AAA client
transfers information using the AAA protocol to the AAA server acting
as an EAP backend authentication server where the EAP method is
executed.
This document describes how PANA works with IETF AAA protocols RADIUS
and Diameter. Both these protocols have an ability to carry EAP. As
specified in [RFC3579] RADIUS is able to carry EAP conversations
between the EAP Authenticator (the NAS) and the Authentication
Server. Therefore, with respect to RADIUS this document describes
the integration of [I-D.ietf-pana-pana] and [RFC3579]. Diameter has
an EAP application [I-D.ietf-aaa-eap], therefore, with respect to
Diameter this documents describe the mapping between [I-D.ietf-pana-
pana] and [I-D.ietf-aaa-eap].
As well, PANA supports other capabilities such as, PAA initiation of
session termination, and therefore this document describes how PANA
works dynamically with RADIUS Dynamic Authorization Extensions
[RFC3576] and Diameter dynamic procedures [RFC3588].
Finally, to address the period of transition from RADIUS to Diameter
where possibly both Diameter and RADIUS maybe deployed in the same
network, this document discuss issues specific to translation and
interworking with PANA.
1.1 Terminology
The document uses the PANA terms found in: [I-D.ietf-pana-pana]; the
RADIUS terms found in: [RFC2865], [RFC2866], [RFC2869], and
[RFC3576]; Diameter terms found in: [RFC3588], [I-D.ietf-aaa-eap],
[I-D.ietf-aaa-diameter-nasreq]; and EAP terms found in [RFC3579].
The term "attributes" refers to RADIUS attributes and "Attribute
Value Pair" or "AVP" refers to PANA attributes and Diameter
attributes.
The term "NAS" refers to the PANA PAA and AAA client which are
Lior & Yegin Expires January 26, 2006 [Page 4]
Internet-Draft PANA AAA Interworking July 2005
assumed to be logically co-located.
To ease in dealing with two AAA protocols each using similar names,
the document adopts the following terms:
AAA client: represents either RADIUS client or Diameter client.
AAA server: represents either RADIUS server or Diameter server.
AAA proxy: represents either RADIUS proxy or Diameter proxy.
AAA-Request: represents either RADIUS Access-Request packet or
Diameter-EAP-Request (DER).
AAA-Accept: represents either RADIUS Access-Accept packet or
Diameter-EAP-Answer(DEA) with Result-Code=Diameter_SUCCESS.
AAA-Challange: represents either RADIUS Access-Challenge or a
Diameter-EAP-Answer(DEA) with Result-
Code=DIAMETER_MULTI_ROUND_AUTH.
AAA-Reject: represents either RADIUS Access-Reject packet or
Diameter-EAP-Answer(DEA) with Result-Code=Diameter_FAIL.
The above terms are used to represent either Diameter or RADIUS
operations. Terms specific to RADIUS and Diameter will be used when
we need to address specific RADIUS and Diameter When specific
reference to Diameter operations.
1.2 Requirements Language
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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. Overview
In order to set the stage for document we present a basic PANA AAA
scenario. The basic scenario is enough to understand how to
interwork PANA with RADIUS or Diameter AAA protocols. Other
scenarios are possible. For example, AAA proxies may exist between
the AAA client and the AAA server; or, the AAA server may not be the
EAP Authentication Server
+------------------------------+
+-----+ | +-----+ +---------------+ | +---------------+
| | | | | | | | | |
| PaC +---+--+ PAA +--+ AAA client |--+-----+ AAA server |
| | | | | | | | | |
+-----+ | +-----+ +---------------+ | +---------------+
| Network Access Server(NAS) |
+------------------------------+
Figure 1: Figure 1
Lior & Yegin Expires January 26, 2006 [Page 5]
Internet-Draft PANA AAA Interworking July 2005
In the above figure, the PAA and the AAA client are collocated in a
Network Access Server (NAS). The NAS is a logical entity, and has
different functionality depending on the network technology. For
example, in 3GPP2 the NAS is a Packet Data Serving Node (PDSN), in
WLAN the NAS maybe the Access Point or the Access Router. During the
AAA interaction, the NAS will typically receive authorization
attributes from the AAA infrastructure. These attributes would be
dependant on the NAS's role in the network. In this document we are
only concerned with the AAA attributes that are implicated in PANA.
Henceforth we use the term NAS to represent the PAA/AAA client.
Roles:
o The PaC and the PAA communicate as per [I-D.ietf-pana-
pana].
o The NAS communicates with the AAA server using either the
RADIUS protocol, or Diameter protocol. In some deployments
this communication may involve one or more AAA proxies.
Since PANA is EAP-centric it is important to define the role of each
entity with respect to EAP:
o The PaC acts as an EAP Peer.
o The NAS is acting like the EAP authenticator.
o The AAA server is acting EAP authentication server.
3. Operations
3.1 Mapping of PANA Phases to AAA phases
A PANA session consist of distinct phases. This section describes
the mapping of the PANA phases to the AAA phases.
PANA discovery and handshake phase: In PANA this is the phase that
initiates a new PANA session. The PaC's answer sent in response to
an advertisement starts a new session. AAA is not involved in this
phase. However, PANA allows for the EAP execution to overlap the
discovery and handshake phase. In this case AAA authentication and
authorization is triggered in this phase.
PANA authentication and authorization phase: This phase follows PANA
discovery and handshake phase. AAA authentication and authorization
is used to carry the PANA EAP payload to the EAP Server using RADIUS
packets or Diameter messages. In addition to the EAP result, the AAA
infrastructure may deliver authorization attributes to the NAS.
PANA Access phase: After successful authentication and authorization,
IP traffic begins to flow. AAA accounting packets (when used)
indicate the start of the PANA access phase. During the PANA access
phase, AAA accounting may be used to report interim usage for the
Lior & Yegin Expires January 26, 2006 [Page 6]
Internet-Draft PANA AAA Interworking July 2005
session. At anytime during the access phase, AAA may deliver new
authorization. In RADIUS this is specified by [RFC3576] and with
Diameter this operation is specified by Diameter base [RFC3588].
PANA re-authorization phase: PANA enters this phase when to re-
authenticate the session before the PANA session lifetime expires.
This phase corresponds to a AAA authentication only exchange.
PANA termination phase: This phase is entered by PANA when the PaC or
PAA choose to discontinue the access service at any time. An
explicit disconnect message can be sent by either the PaC or the PAA.
In the case of RADIUS, if [RFC3576] is supported, then a RADIUS
server may trigger the NAS to initiate termination of the PANA
session. In the case of Diameter, the Diameter server may trigger
the NAS to initiate termination using the procedures defined in
Diameter base [RFC3588]. If accounting is used, PANA session
termination is signaled by the generation of a RADIUS Accounting
Request (Stop) packet or Diameter Accounting-Request(ACR) message.
3.2 Call Flows
The following call flows illustrate the interoperation of PANA with
AAA. For the sake of brevity the call flows utilize the abbreviated
EAP transaction supported by PANA. That is, the PANA-Auth-Answer
carries the EAP-payload.
The call-flows are derived from [I-D.ietf-pana-pana] and [RFC3579]
and [I-D.ietf-aaa-eap].
3.2.1 Call flow for a single authentication
The following is a call flow description for a PANA RADIUS single
authentication.
Lior & Yegin Expires January 26, 2006 [Page 7]
Internet-Draft PANA AAA Interworking July 2005
PaC PAA/NAS AAA
Server
a) < Discovery and handshake phase>
| | |
< Authentication Authorization phase>
|PANA-Auth-Request(x) | |
b) |<---------------------| |
|PANA-Auth-Answer(x) | |
c) |--------------------->| |
| | AAA-Request |
d) | |----------------------->|
| | AAA-Challenge |
e) | |<-----------------------|
|PANA-Auth-Request(x+1)| |
f) |<---------------------|........................|
|PANA-Auth-Answer(x+1) | |
g) |--------------------->|........................|
| | AAA-Request |
h) | |----------------------->|
| | AAA-Accept |
i) | |<-----------------------|
|PANA-Bind-Request | |
j) |<---------------------| |
|PANA-Bind-Answer | |
k) |--------------------->| |
| |AAA Accounting(Start) |
l) | |----------------------->|
| | |
< PANA access phase >
| | |
a. Except when the PANA-Start-Answer contains an EAP Response
message (discussed below), PANA Discovery and Handshake takes
place between PAA (collocated in the NAS) and PaC and does not
involve AAA.
b. PANA Authentication phase starts after the Discovery phase, when
the PAA sends a PANA-Auth-Request to the PaC containing the EAP
Request/Identity.
c. The PaC responds with a PANA-Auth-Answer containing the EAP
Response/Identity.
d. The NAS sends AAA-Request. Attributes from the PAR are
translated to AAA attributes. In particular, the User-Name
attribute/AVP is constructed as described below. The User-Name
will be used throughout the transaction. In the case of RADIUS,
if [I-D.zorn-radius-logoff] is supported, the PANA Session-id
will be sent in these and the other Access-Requests in the
Lior & Yegin Expires January 26, 2006 [Page 8]
Internet-Draft PANA AAA Interworking July 2005
Session-Id attribute. In the case of Diameter, the Diameter
Session-Id MUST be set in the DER. The session-id could be the
same as that that is used for PANA (see further discussion on
session identifier below).
e. AAA responds with a AAA-Challenge. AAA-Request and AAA-Challenge
are used in multi-step authentication scheme such as EAP. These
messages transport the EAP method in an attribute, in the case of
RADIUS EAP-Message attribute and in the case of Diameter EAP-
Payload. If the authentication required one exchange then AAA
would have responded with an AAA-Accept or an AAA-Reject.
f. Attributes/AVP from the AAA-Challenge packet are translated into
PANA attributes that are then forwarded to the PaC in a PAR. In
particular, the contents of the EAP-Message attribute(s) (RADIUS)
or EAP-Payload (Diameter) are copied in the EAP-Payload
AVP(s)(PANA).
g. The PaC response with an PAN which is then forwarded to the
PAA(as in step c).
h. As in step d, attributes in the PAN are translated to AAA
attributes and are sent to the AAA server in an AAA-Request.
i. The NAS receives a response from the AAA server. If the response
is a AAA-Challenge, then EAP method is not yet complete and steps
f) and g) are repeated. If the packet received is an AAA-Accept
or AAA-Reject, then AAA authentication and authorization phase is
over. In this case the NAS saves the authorization attributes
and the resulting AAA-KEY(if any) which is carried in EAP-Master-
Session-Key AVP (Diameter EAP) or in the case of RADIUS in the
vendor-specific RADIUS MS-MPPE-Recv-Key and/or MS-MPPE-Send-Key
attributes [RFC2548] or preferably in the attribute presented in
[I-D.zorn-radius-keywrap].
j. The PAA sends a PANA-Bind-Request(PBR) to the PaC. The PBR will
contain the EAP-Success or EAP-Failure response received in the
AAA-Accept or AAA-Reject packets respectively.
k. The PaC responds with an PANA-Bind-Answer (PBA).
l. The NAS sends a AAA Accounting-Request(Start) packet confirming
the start of the session. As the session continues, the NAS may
send AAA Accounting Request(Interims) packets as required. When
the Session terminates, the NAS will send a AAA Accounting-
Request(Stop). If the NAS supports [I-D.zorn-radius-logoff] the
NAS will send a User-Logoff-Notification packet at this time as
well. In the case of Diameter, when accounting messages (ACR)
are sent, the NAS may include Accounting-Auth-Method AVP as
defined by [I-D.ietf-aaa-diameter-nasreq] with value 5 (EAP)
indicating that EAP was used to authenticate the user. In
addition, as defined by [I-D.ietf-aaa-eap] one or more
Accounting-EAP-Auth-Method AVP(s) may be included to indicate the
EAP method(s) used to authenticate the user. In the case of
RADIUS the vendor-specific RADIUS MS-Acct-EAP-Type attribute
[RFC2548] may be included in the RADIUS Accounting-Request
Lior & Yegin Expires January 26, 2006 [Page 9]
Internet-Draft PANA AAA Interworking July 2005
packets.
For optimization reasons, PANA allows the PAA to start the EAP
conversation during the PANA Discovery Phase. In this case the PAA
will include the initial EAP Request in the PANA-Start-Request
message. The PaC will then include the EAP Response message (EAP
Response/Identity) in the PANA-Start-Answer(PSA)a message. In this
case the RADIUS Access-Request (step d) will be triggered by the
reception of the PSA message.
3.2.2 PANA ISP/NAP Authentication Call Flow
PaC PAA/NAS AAA
Server
| | |
a) |<Discovery Handshake> | |
| | |
b) |< PANA FIRST AUTHENTICATION > |
|<====================>|<======================>|
| | |
|PFER | |
c) |<---------------------| |
| PFEA | |
d) |--------------------->| |
| | |
e) |< PANA SECOND AUTHENTICATION > |
|<====================>|<======================>|
| | |
| PANA-Bind-Request | |
f) |<---------------------| |
| PANA-Bind-Answer | |
g) |--------------------->| |
| |Accounting-Request Start|
h) | |----------------------->|
| | |
| < PANA access phase >| |
a. During the discovery and handshake phase the PaC and PAA may
negotiate to perform separate NAP and ISP authentication.
b. The first authentication will either be the NAP Authentication or
the ISP authentication. Steps b) to i) described in the PANA
single authentication call flow are executed. The AAA
authorization attributes received in the AAA-Accept if any are
saved. The keys that are the result of the EAP method if
received in the AAA-Accept must be saved.
Lior & Yegin Expires January 26, 2006 [Page 10]
Internet-Draft PANA AAA Interworking July 2005
c. Upon receiving an AAA-Accept or AAA-Reject the PAA sends a PFER
to the PaC. The PFER contains the EAP Success/Failure message
received in the AAA-Accept/AAA-Reject packet respectively.
d. The PFEA is received from the PaC.
e. The PANA second authentication starts. Note that the second
authentication may start even though the first authentication
phase has failed (matter of local policy). Steps b) to i)
described in the PANA single authentication call flow are
executed. The AAA authorization attributes received in the
Access-Accept if any are saved. Any key if received in the AAA-
Accept is saved.
f. The PAA sends a PBR containing the EAP Success/Failure message
carried in the AAA-Accept/AAA-Reject.
g. The PaC responds with a PBA.
h. The session begins. This is signaled by sending of a AAA
Accounting(Start) packet. As the session continues, the NAS may
send AAA Accounting Request(Interims) as required. When the
Session terminates, the NAS will send a AAA Accounting-
Request(Stop).
When two PANA authentication are used, there are two distinct AAA
Authentication and Authorization conversations typically with
different NAIs. The same AAA server may participate in both
conversations, however, the endpoint will typically be different.
Each AAA Authorization may deliver AAA authorization attributes to
the NAS. It's a matter of local policies how these collection of
authorization attributes (which may overlap) are acted upon by the
NAS.
Multiple-authentications may result with the reception of two keys
(or key pair) by the NAS. When there are two keys, the PAA and the
PaC create a compound key following the procedure defined in
[I-D.ietf-pana-pana].
Based on local policies the NAS may need to send two AAA Accounting-
Request (Start) packets one for each AAA authentication authorization
conversation.
3.2.3 PANA Termination
Explicit termination can be initiated either from the PaC or from the
PAA. The call flows are slightly different between the Diameter and
RADIUS based AAA deployments. The following diagram illustrates the
RADIUS based call flow.
Lior & Yegin Expires January 26, 2006 [Page 11]
Internet-Draft PANA AAA Interworking July 2005
PaC PAA/NAS RADIUS
Server
| | |
|< PANA access phase> | |
| PTR | |
a) |--------------------->| |
|PTA |Accounting-Request(Stop)|
b) |<---------------------|----------------------->|
| | |
a. When the PaC initiates explicit termination, it sends the PAA a
PTR message.
b. The PAA acknowledges with a PTA message and at the same time it
sends the RADIUS server an Accounting-Request(Stop) message.
The following figure illustrates the call flow when the NAS is a
Diameter client.
PaC PAA/NAS Diameter
Server
| | |
|< PANA access phase> | |
| PTR | |
a) |--------------------->| |
| PTA | STR |
b) |<---------------------|----------------------->|
| | STA |
c) | |<-----------------------|
| |Accounting-Request(Stop)|
d) | |----------------------->|
a. When the PaC initiates explicit termination, it sends the PAA a
PTR message.
b. The PAA responds back and at the same time the NAS sends a
Diameter Session-Termination-Request (STR) message to the
Diameter Server.
c. The Diameter server replies with a Diameter Session-Termination-
Answer (STA) message indicating that the server has released all
resources for the session indicated by the Diameter Session-Id
AVP.
d. The NAS sends a Diameter Accounting-Request (ACR) (Stop) packet
indicating the end of the session.
The termination maybe initiation from the PAA/NAS as a result of
several events:
Lior & Yegin Expires January 26, 2006 [Page 12]
Internet-Draft PANA AAA Interworking July 2005
o A local command was received by the PAA/NAS to trigger the
termination;
o A Session-Timeout , for example, received as part of the RADIUS
authorization attributes has expired.
o If the NAS is metering resources, and these resources have
expired, then the NAS may terminate the session.
In the case where the NAS initiates the termination and the NAS is a
RADIUS client then the call flow is similar to the RADIUS call flow
above except that the PTR message is sent from the PAA to the PaC.
However, when the NAS is a Diameter client the call flow is given
below.
PaC PAA/NAS Diameter
Server
| | |
|< PANA access phase> | |
| PTR | STR |
a) |<---------------------|----------------------->|
| PTA | STA |
b) |--------------------->|<-----------------------|
| |Accounting-Request(Stop)|
c) | |----------------------->|
a. When the PAA/NAS initiates explicit termination, the PAA sends a
PTR message to the PaC and at the same time it sends the Diameter
Server a Diameter STR message.
b. The PaC responds back with a PTA and the Diameter Server responds
back with a STA.
c. Once the NAS receives the STA it replies back to the Diameter
Server with an Accounting-Request(ACR) with Accounting-Record-
Type value of 'Stop' message.
Another source of termination is the result of the NAS receiving a
disconnection request from the AAA-server. In the case the NAS being
a RADIUS client, if the NAS supports [RFC3576], the arrival of a
RADIUS disconnect-request (DR) packet causes the NAS to initiate the
PANA termination phase. If the NAS is a Diameter client then the
arrival of a Diameter Abort-Session-Request (ASR) will cause the NAS
to terminate the session.
The figure below illustrates the call flow for both RADIUS and
Diameter.
Lior & Yegin Expires January 26, 2006 [Page 13]
Internet-Draft PANA AAA Interworking July 2005
PaC PAA/NAS AAA
Server
| | |
|<PANA access phase> | |
| |RADIUS DR or Diam. ASR |
a) | |<-----------------------|
| |RAD. D-ACK or Diam. ASA |
b) | |----------------------->|
| |Accounting-Request(Stop)|
c) | |----------------------->|
| | STR |
d) | |----------------------->|
| | STA |
e) | |<-----------------------|
| PTR | |
f) |<---------------------| |
| PTA | |
g) |--------------------->| |
a. The NAS receives a RADIUS Disconnect-Request packet[RFC3576]
containing session identifiers. Or a NAS receives an Diameter
Abort-Session-Request (ASR). At this point the NAS stops the
session for the user.
b. The NAS responds with a Disconnect-ACK (D-ACK) packet[RFC3576] or
a Diameter Abort-Session-Answer(ASA).
c. The NAS immediately sends an Accounting-Request (Stop) packet to
signal the termination of the session and deliver final usage
data for the session.
d. Diameter only. The NAS sends an STR message to the authorizing
Diameter Server
e. Diameter only. The authorizing Diameter server responds back
with a STA message acknowledging the receipt of the STR.
f. The PAA sends a PANA termination requests to the PaC.
g. The PaC acknowledges the termination request.
Note: in the above call flow, the order of the PTR/PTA and STR/STA is
arbitrary.
Note: if PANA multi-authentication was performed based on local
policies the NAS MAY send two Accounting-Request (Stop) packets. If
the NAS is a Diameter client, it will have to send an STR to both
Diameter servers.
If [I-D.zorn-radius-logoff] is supported, then depending on whether
single or multiple authentication was performed, the NAS will send
one or two User-Logoff-Notification packets.
Lior & Yegin Expires January 26, 2006 [Page 14]
Internet-Draft PANA AAA Interworking July 2005
3.2.4 Re-authentication
The PANA session in the access phase can enter the re-authentication
phase. Once re-authentication is completed successfully, PANA enters
the PANA access phase again.
Either the PaC, the PAA/NAS, or the AAA server may initiate re-
authentication phase. The following call flow illustrates the PaC
initiating.
PaC PAA/NAS AAA
Server
| | |
|< PANA access phase > | |
|PRAR | |
a) |--------------------->| |
| PRAA | |
b) |<---------------------| |
| | |
|< PANA authentication phase > |
| | |
c) |<====================>|<======================>|
| | |
|< PANA access phase > | |
| | |
a. The PaC initiates re-authentication by sending a PANA-Reauth-
Request
b. The PAA responds a PANA-Reauth-Answer and enters the PANA
authentication phase.
c. The PANA authentication phase proceeds as described above. The
result will either be success and indicated by the reception of a
AAA-Accept containing an EAP Success message and potentially a
Key (or key pair); or the result may be reject as indicated by
the reception of an AAA-Reject packet contains the EAP Failure
message.
In the case of Diameter, a Diameter server may request a re-
authorization by sending a Diameter Re-Auth-Request (RAR) message to
the NAS. This will cause the PAA/NAS to start the re-authentication
procedure above.
In the case of RADIUS, a RADIUS server may initiate re-authorization
by sending a COA message to the NAS with Service-Type set to
"Authorize Only". The full procedure is given in [RFC3576]. The NAS
then initiates the PANA reauthorization procedure given above.
RADIUS and Diameter can instruct the NAS to initiate re-
Lior & Yegin Expires January 26, 2006 [Page 15]
Internet-Draft PANA AAA Interworking July 2005
authentication after a period of time by sending Session-Timeout
attribute indicating the time in seconds until reauthentication with
and Terminate-Action set to "RADIUS".
Some authorization attributes maybe received from the AAA
infrastructure.
If multiple re-authentication are indicated then (as described
above), these are conducted back to back. The disposition of the
session if one of the re-authentication fails is a matter of local
policies.
Note: Accounting packets are not exchanged because the data session
is not terminated.
If the PANA authentication phase results in a failure. Then the
session will be terminated and an Accounting-Request (Stop) packet
will be sent.
4. PANA RADIUS Message Mapping
The following table lists the mapping between PANA messages and
RADIUS packets.
PANA message name RADIUS packet name
PANA-Start-Answer ----> RADIUS Access-Request [Note 1]
PANA-Auth-Answer ----> RADIUS Access-Request [Note 2]
PANA-Auth-Request ----> RADIUS Access-Request [Note 3]
PANA-Auth-Request <---- RADIUS Access-Challenge
PANA-Bind-Request <---- RADIUS Access-Accept, Access-Reject
PANA-Bind-Answer ----> RADIUS Accounting-Request (Start)
PANA-FirstAuth-End-Request <---- RADIUS Access-Accept, Access-Reject
PANA-Termination-Request <---- RADIUS Disconnect-Request
PANA-Termination-Answer -----> RADIUS Accounting-Request (Stop)
PANA-Error-Request <---- RADIUS Challenge
PANA-Error-Request <---- RADIUS Access-Reject
Lior & Yegin Expires January 26, 2006 [Page 16]
Internet-Draft PANA AAA Interworking July 2005
[Note 1] PANA-Start-Answer triggers a RADIUS Access-Request packet if
and only if the PANA-Start-Answer carries EAP-payload.
[Note 2] PANA-Auth-Answer triggers a RADIUS Access-Request if the
PANA-Auth-Answer carries EAP-payload.
[Note 3] PANA-Auth-Request triggers a RADIUS Access-Request packet if
the PANA-Auth-Request carries EAP-payload.
4.1 RADIUS Access-Request
Any PANA-Auth-Request, and a PANA-Auth-Answer or a PANA-Start-Answer
that contain the EAP-payload trigger a RADIUS Access-Request packet.
The RADIUS Access-Request packets SHOULD contain a User-Name(1)
attribute. User-Name will be set as described below to ensure that
the Access-Request can be routed appropriately.
Since the authentication is based on EAP, the Access-Request packet
MUST NOT contain User-Password(2), CHAP-Password(3), CHAP-
Challenge(60) or ARAP-Password(70). Instead, the Access-Request MUST
contain one or more EAP-Message(79) and the Message-Authenticator(80)
attribute. The EAP-Message attribute will contain the contents of
the PANA EAP-Payload attribute. If the EAP-Payload is larger then
253 octets, then the NAS will fragment the EAP-Payload into several
EAP-Message(79) attributes. The Message-Authenticator is computed as
described in [RFC3579].
The RADIUS Service-Type (6) attribute will be typically set to
"Framed"(2). If the receipt of the PANA-Auth-Answer arrives in the
PANA re-authentication phase, then Service-Type(6) MUST be set to
"Authenticate Only".
Note: PANA-Auth-Answer contains a Session-Id AVP, which will be
included in the RADUIS Access-Request packet in the Session-Id
attribute (if [I-D.zorn-radius-logoff] is supported). However, when
the Access-Request packet is triggered by the PANA-Start-Answer
message, the Session-Id AVP is not present and therefore Session-Id
attribute should be pre-allocated by the PAA/NAS.
Note: there is no attribute in RADIUS to carry the contents of the
Notification AVP in an Access-Request packet.
4.2 Access-Challenge
EAP based authentication typically require several exchanges between
the EAP peer and the EAP authentication server. As described in
[RFC3579], a RADIUS server wishing to authenticate with EAP MUST
respond with an Access-Challenge packet containing EAP-Message(79)
attribute(s).
Lior & Yegin Expires January 26, 2006 [Page 17]
Internet-Draft PANA AAA Interworking July 2005
Access-Challenge packets map to PANA-Auth-Request message. The NAS
MUST validate the Message-Authenticator(80) as described in
[RFC3579]. If the packet is authentic the NAS will copy the contents
of the EAP-Message(79) attribute to the EAP-Payload AVP included in
the PANA-Auth-Request message to be sent to the PaC. If the Access-
Challenge contains more then one EAP-Message(79) attribute the NAS
will concatenate in the order received the values into the PANA EAP-
Payload AVP
As per [RFC3579] if Session-Timeout(27) is present in an Access-
Challenge packet that also contains an EAP-Message, the value of the
Session-Timeout is used to set the EAP retransmission timer for that
EAP Request, and that Request alone. Once the EAP-Request has been
sent, the NAS sets the retransmission timer, and if it expires
without having received an EAP-Response corresponding to the Request,
then the EAP-Request is retransmitted.
As noted in [RFC3579] a RADIUS server determining that a non-fatal
error has occurred MAY send an Access-Challenge to the NAS including
EAP-Message attribute(s) as well as an Error-Cause attribute
[RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)".
[RFC3579] describes the recommended action to be taken by the NAS.
See discussion below on Error-Cause mapping.
4.3 Access-Accept
The successful result of EAP authentication is carried in a RADIUS
Access-Accept packet. As per the call flows, the arrival of an
Access-Accept packet triggers a PANA-Bind-Request, or a PANA-
FirstAuth-End-Request.
Upon receiving the Access-Accept, the NAS MUST validate the Message-
Authenticator(80) as described in [RFC3579].
The Access-Accept will contain the EAP-Success message in the EAP-
Message(79) attribute, which is copied to the EAP-Payload AVP to be
sent to the PaC. As well, the Result-Code AVP will be set to
PANA_SUCCESS (2001).
4.4 Access-Reject
When the EAP method fails the RADIUS server will reply with an
Access-Reject packet. The arrival of an Access-Accept packet
triggers a PANA-Bind-Request, or a PANA-FirstAuth-End-Request.
The Access-Reject packet will contain an EAP-Message(79) attribute
encapsulating EAP-Failure and MAY also contain Error-Cause(101). The
Access-Reject MUST also be protected with the RADIUS Message-
Lior & Yegin Expires January 26, 2006 [Page 18]
Internet-Draft PANA AAA Interworking July 2005
Authenticator(80) attribute.
Upon receiving the Access-Reject, the NAS MUST validate the Message-
Authenticator(80) as described in [RFC3579].
If the Access-Reject packet is authentic, it will set the Result-Code
AVP to PANA_AUTHENTICATION_REJECTED(4001) and respond with a PANA-
Bind-Request, or PANA-FirstAuth-End-Request as appropriate.
[EDITOR's NOTE: while RFC3579 indicates that the Access-Reject packet
contains Error-Cause it does not specify why or what values will be
set in it. ]
4.5 Accounting-Request
The attributes contained in the Accounting-Request packets are
dependant on the deployment.
RADIUS Accounting-Request(Start) packet is used to indicate the start
of the session. The NAS will generate a RADIUS Accounting-
Request(Start) packet upon the receipt of an PANA-Bind-Answer
message.
RADIUS Accounting-Request(Stop) packet is used to indicate the end of
the session. The Accounting Request (Stop) will be generated when
the NAS receives a PANA-Termination-Answer message; or when the NAS
sends a PANA-Termination-Answer to the PaC. Acct-Terminate-Cause
will be set as described below.
RADIUS Accounting-Request(Interim) packets are used to deliver
interim accounting information to the RADIUS accounting
infrastructure. One possible PANA trigger for a Access-Request
(Interim-Update) is the reception of PANA-Ping-Answer message from
the PaC.
As well, it is also possible to use the RADIUS Acct-Interim-
Interval(85) [RFC2869] to specify how often should the NAS generate
the PANA-Ping-Request messages.
4.6 Disconnect-Request
The reception of a RADIUS Disconnect-Request packet that identify a
PANA session MUST trigger a RADIUS Disconnect-ACK packet followed by
PANA-Termination-Request message to be sent from the NAS to the PaC.
As per [RFC3576] Disconnect-Request requires that the session be
identified. In this case the session identifier could be User-
Name(1). However, in certain EAP methods, the User-Name(1) will not
Lior & Yegin Expires January 26, 2006 [Page 19]
Internet-Draft PANA AAA Interworking July 2005
suffice as a session identifier because it is not specific enough.
That is it may only contain enough information to route the packet to
the home network (see discussion on User-Name below). Therefore
other attributes such as Acct-Session-Id(31) or
Acct-Multi-Session-Id, or Session-Id [I-D.zorn-radius-logoff] may be
used to as a session-identifier for the Disconnect-Request packet.
5. PANA Diameter Message Mapping
The following table lists the mapping between PANA messages and
Diameter messages.
PANA message name Diameter message name
PANA-Start-Answer ----> Diameter EAP Request (DER) [Note 1]
PANA-Auth-Answer ----> Diameter EAP Request (DER) [Note 2]
PANA-Auth-Request ----> Diameter EAP Request (DER)
PANA-Auth-Request <---- Diameter EAP Answer (DEA) Multi-Round
PANA-Bind-Request <---- Diameter EAP Answer (DEA)
Result code = success or fail
PANA-Bind-Answer ----> RADIUS Accounting-Request (Start)
PANA-FirstAuth-End-Request <---- Diameter EAP Answer (DEA)
Result cod = success or fail
PANA-Termination-Request <---- Diameter Abort-Session-Request (ASR)
PANA-Termination-Answer -----> Diameter Session-Termination-Request [Note 3]
PANA-Error-Request <---- Dimeter EAP Answer (DEA) Multi-Round
[Note 1] PANA-Start-Answer triggers a Diameter EAP Request (DER) if
and only if the PANA-Start-Answer carries EAP-payload.
[Note 2] PANA-Auth-Answer triggers a Diameter EAP Request if the
PANA-Auth-Answer carries EAP-payload.
[Note 3] Diameter Session-Termination (STR) is not strictly mapped to
PANA-Termination-Answer. Diameter STR should be sent as soon as
possible to the Diameter server. Implementation should not
lockstep these messages.
5.1 Diameter EAP Request (DER)
Any PANA-Auth-Request, and a PANA-Auth-Answer or PANA-Start-Answer
that contains the EAP-payload trigger a DER packet.
The DER SHOULD contain a User-Name attribute. User-Name will be set
as described below to ensure that the Access-Request can be routed
appropriately.
Lior & Yegin Expires January 26, 2006 [Page 20]
Internet-Draft PANA AAA Interworking July 2005
DER MUST contain EAP-Payload AVP which is set to the value contained
in the PANA EAP-Payload attribute. Note there are no fragmentation
issues to be concerned about.
Auth-Request-Type can be set to AUTHORIZE_AUTHENTICATE or to just
AUTHENTICATE and MUST NOT be set to AUTHORIZE_ONLY.
Note: there is no attribute in Diameter EAP Application to carry the
contents of the Notification AVP in an Access-Request packet.
Note: PANA-Auth-Answer contains a Session-Id AVP, which SHOULD be
included in the DER message in the Session-Id AVP. However, when the
DER packet is triggered by the PANA-Start-Answer message, the
Session-Id AVP which is generated by the NAS need to be pre-allocaed
and included in the DER.
5.2 Diameter EAP Answer (DEA)
EAP based authentication typically require several exchanges between
the EAP peer and the EAP authentication server. As described in
[I-D.ietf-aaa-eap], a DEA server wishing to authenticate with EAP
responds with an DEA message with Result-
Code=DIAMETER_MULTI_ROUND_AUTH until the EAP authentication is
resolved in which case the Result-Code witll be set to
DIAMETER_SUCCESS or DIAMETER-FAIL.
DEA packets with Result-Code=DIAMETER_MULTI_ROUND_AUTH map to PANA-
Auth-Request message. The NAS MUST copies the contents of the EAP-
Payload received in the messaged into the EAP-Payload AVP included in
the PANA-Auth-Request message to be sent to the PaC. Note there are
no fragmentation issues to be concerned about.
If the PaC has been successfully authenticated then the Result-Code
AVP will indicate success and as per [I-D.ietf-aaa-eap] the DEA
SHOULD contain EAP-Payload indicate EAP-Success. The PAA/NAS will
respond to the PaC with a PANA-Bind-Request (PBR) or PANA-FirstAuth-
End-Request (PFER) including the EAP-Payload set to the value
received from the Diameter server. The Result-Code MUST be set to
PANA-SUCCESS. As with DEA, PBR and PFER do not required to have an
EAP-Payload.
If the PaC fails to authenticate the Diameter server will reply with
a DEA with Result-Code AVP indicated diameter failure. As with EAP-
Success, this will trigger the PAA/NAS to send the PaC a PANA-Bind-
Request (PBR) or PANA-FirstAuth-End-Request (PFER) including the EAP-
Payload set to the value received from the Diameter server. The
Result-Code MUST be set to PANA_AUTHENTICATION_REJECTED(4001). As
with DEA, PBR and PFER do not required to have an EAP-Payload.
Lior & Yegin Expires January 26, 2006 [Page 21]
Internet-Draft PANA AAA Interworking July 2005
As per [I-D.ietf-aaa-eap] if Multi-Round-Time-Out AVP is present in
an DEA message that also contains an EAP-Message, the value of the
Multi-Round-Time-Out is used to set the EAP retransmission timer for
that EAP Request, and that Request alone. Once the EAP-Request has
been sent, the NAS sets the retransmission timer, and if it expires
without having received an EAP-Response corresponding to the Request,
then the EAP-Request is retransmitted.
5.3 Diameter Accounting
The attributes contained in the Accounting-Request packets are
dependant on the deployment.
Diameter Accounting Request (ACR) Start is used to indicate the start
of the session. The NAS will generate an ACR upon the receipt of an
PANA-Bind-Answer message. The NAS may include an Accounting-Auth-
Method AVP [NASREQ] with value 5 (EAP) in ACR messages. As per
[I-D.ietf-aaa-eap] the NAS MAY include one or more Accounting-EAP-
Auth-Method AVPs to indicate the EAP method(s) used to authenticate
the user.
Accounting-Request(Stop) packet is used to indicate the end of the
session. The Accounting Request (Stop) will be generated when the
NAS receives a PANA-Termination-Answer message; or when the NAS sends
a PANA-Termination-Answer to the PaC. Acct-Terminate-Cause will be
set as described below.
In Diameter deployments the NAS needs to send the authorizing
Diaemter Server an indication that session is being terminated so
that the Diameter server can release any state information or
resources that it may be holding for that session. Therefore when
the NAS receives a PANA-Termination-Answer message; or when the NAS
sends a PANA-Termination-Answer to the PaC it MUST also send a
Diameter Session Termination Request to the Diameter server.
Accounting-Request(Interim) packets are used to deliver interim
accounting information to the Diameter accounting infrastructure.
One possible PANA trigger for a Access-Request (Interim-Update) is
the reception of PANA-Ping-Answer message from the PaC.
5.4 Abort-Session-Request
The reception of a Diameter Abort-Session-Request (ASR) with the
correct session id MUST trigger the PAA/NAS to respond back to the
Diameter Server with a Abort-Session-Answer (ASA) followed by PANA-
Termination-Request message to be sent from the NAS to the PaC
followed by a Diameter Session-Termination-Request sent to the
authorizing Diameter server singaling it that the session is
Lior & Yegin Expires January 26, 2006 [Page 22]
Internet-Draft PANA AAA Interworking July 2005
terminating and finally followed by an Accounting-Request (ACR) Stop
message.
6. RADIUS Diameter Translation
In certain deployments the NAS and the AAA server may not be protocol
aligned. That is, the NAS may be a RADIUS client and the AAA server
may only support Diameter protocol. As described in [I-D.ietf-aaa-
diameter-nasreq] and in [I-D.ietf-aaa-eap] a translation function is
deployed to translate between RADIUS and DIAMETER. [I-D.ietf-aaa-
diameter-nasreq] describes the basic translation procedures while
[I-D.ietf-aaa-eap] delves into the EAP specific translation
procedures. Since there are no specific PANA considerations
implementers should refer to these RFCs for details.
7. RADIUS Attributes to PANA AVP Mapping
This section describes the mapping between the PANA AVP and RADIUS
attributes. The following table lists that PANA attributes and their
corresponding RADIUS attributes
PANA AVP RADIUS attribute
======== =================
N/A User-Name(1)
EAP-Payload EAP-Message(79)
Session-Id Acct-Multi-Session-Id(50)
Session-Id(TBD) [Note 1]
Session-Lifetime Session-Timeout(27)
Error-Cause
Termination-Cause Acct-Terminate-Cause(49)
[Note 1]: Defined by [I-D.zorn-radius-logoff]
7.1 Consideration for User-Name
In PANA, the PaC typically provides its identity via an EAP-Response/
Identity message. In order to permit RADIUS proxies to forward the
Access-Request packet, the NAS MUST copy the contents of the Typed-
Data field of the EAP-Response/Identity received from the PaC into
the User-Name(1) attribute and MUST include the Type-Data field of
the EAP-Response/Identity in the User-Name(1) attribute in very
subsequent Access-Request.
Lior & Yegin Expires January 26, 2006 [Page 23]
Internet-Draft PANA AAA Interworking July 2005
If the peer identity cannot be determined from the EAP-Response, then
the User-Name attribute SHOULD be determined by another means.
The NAS SHOULD use the ISP-Information or NAP-Information received in
the PANA-Start-Answer to construct a value of the User-Name(1)
attribute. The construction which SHOULD follow [I-D.ietf-radext-
rfc2486bis] and SHOULD ensure that the Access-Request is routed to
the ISP or NAP identified by the ISP-Information or NAP-Information
respectively that was included in the PANA-Start-Answer message
received by the NAS from the PaC.
7.2 EAP-Message
In RADIUS EAP packets, as defined in [RFC3748] are carried in the
EAP-Message(79). In PANA, EAP packets are carried in the EAP-Payload
AVP. RADIUS attributes are limited to 253 octets and therefore when
copying the EAP packet from the EAP-Payload AVP to the EAP-Message
attribute, the contents of the EAP-Payload may have to be split at
253 octet boundaries before sending the attribute. The receiving
end, will be able to reconstruct the EAP payload by concatenating the
EAP-Message(79) attributes in the order that they are received
(RADIUS maintains order of a given attribute).
[RFC3579] Section 2.2. describes how the RADIUS server handles
invalid EAP packets passed to it by the NAS.
7.3 PANA Session
A PANA session begins with the handshake between the PaC and the PAA.
During the creation of a PANA session, the PAA creates a PANA Session
Identifier.
On the other hand RADIUS as described in [RFC2865] being stateless
does not require a session identifier. RADIUS accounting does
utilize a session identifier to help correlate accounting packets to
a single user session. We recommend therefore that the PANA
Session-Id AVP SHOULD be mapped to RADIUS Acct-Multi-Session-Id(50).
In many cases today, RADIUS is required to maintain a session state.
Therefore, in this case the PANA Session-Id AVP SHOULD be mapped in
the Session-Id as defined by [I-D.zorn-radius-logoff].
7.4 Session-Termination
TBD
Lior & Yegin Expires January 26, 2006 [Page 24]
Internet-Draft PANA AAA Interworking July 2005
7.5 Error-Cause Mapping
The following Error-Cause [RFC3576] values may occur specifically due
to EAP:
Invalid EAP Packet(202): A RADIUS server determining that a non-fatal
error has occurred MAY send an Access-Challenge to the PAA/NAS
include EAP-Message attributes(s) as well as this error code. The
PAA/NAS shall respond back with a PANA-Error-Request message with
Result-Code set to PANA_INVALID_AVP_DATA and SHALL set the Failed-
AVP AVP to the EAP-message.
Unsupported Attribute(401): This implies that the RADIUS server
received a request with an attribute that it recognizes but does
not support. It is not clear which attribute is not supported, it
could be the EAP attribute. The PAA/NAS should send a PANA-Error-
Request to the PaC. The value of the Result-Code AVP set to
PANA_AVP_UNSUPPORTED. The PAA/NAS must include the offending AVP
but since it does not know which one this creates a problem.
EDITORS note: what is a reasonable action when receiving Unsupported
attribute? Note that there is a new draft (Aboba) that may help
here.
7.6 Consideration Acct-Terminate-Cause
This attribute is included in the RADIUS Accounting-Request (Stop)
packets and indicates how the session was terminated[RFC2866]
PANA Termination-Cause AVP RADIUS Acct-Terminate-Cause(49)
========================== ===========================
LOGOUT(1) "User Request" (1)
ADMINSITRATIVE "Admin Reset" (6)
SESSION_TIMEOUT "Session Timeout" (5)
7.7 RADIUS Table of Attributes
The following table provides a guide to which attributes may be found
in packets including EAP-Message attribute(s), and in what quantity
as they pertain to PANA interoperability. If a table entry is
omitted, the values found in [RFC2548], [RFC2865], [RFC2868],
[RFC2869], [RFC3162], [RFC3576] and [RFC3579] should be assumed.
Lior & Yegin Expires January 26, 2006 [Page 25]
Internet-Draft PANA AAA Interworking July 2005
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0 0 0 0 2 User-Password [Note 1]
0 0 0 0 3 CHAP-Password [Note 1]
0-1 0-1 0 0 6 Service-Type
0 0 0 0 18 Reply-Message
0 0-1 0 0-1 27 Session-Timeout
0 0-1 0 0-1 28 Idle-Timeout
0 0-1 0 0 29 Termination-Action
0 0 0 0 60 CHAP-Challenge [Note 1]
0 0 0 0 70 ARAP-Password [Note 1]
1+ 1+ 1+ 1+ 79 EAP-Message [Note 1]
1 1 1 1 80 Message-Authenticator[Note 1]
0 0 0-1 0-1 101 Error-Cause [Note 2]
[Note 1] An Access-Request that contains either a User-Password or
CHAP-Password or ARAP-Password or one or more EAP-Message
attributes MUST NOT contain more than one type of those four
attributes. If it does not contain any of those four attributes,
it SHOULD contain a Message-Authenticator. If any packet type
contains an EAP-Message attribute it MUST also contain a Message-
Authenticator. A RADIUS server receiving an Access-Request not
containing any of those four attributes and also not containing a
Message-Authenticator attribute SHOULD silently discard it.
[Note 2] The Error-Cause attribute is defined in [RFC3576].
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present.
0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present.
1+ One or more of these attributes MUST be present.
8. DIAMETER AVP to PANA AVP Mapping
This section describes the mapping between the PANA AVP and RADIUS
attributes. The following table lists that PANA attributes and their
corresponding RADIUS attributes
Lior & Yegin Expires January 26, 2006 [Page 26]
Internet-Draft PANA AAA Interworking July 2005
PANA AVP Diameter AVP
======== =================
N/A User-Name
EAP-Payload EAP-Payload
Session-Id Session-Id
Session-Lifetime Session-Timeout
Termination-Cause Acct-Terminate-Cause(49)
Failed-AVP Failed-AVP
Key-Id EAP-Key-Name
Notification Reply-Message
Result-Code Result-Code
Termination-Cause Termination-Cause
8.1 Consideration for User-Name
In PANA, the PaC typically provides its identity via an EAP-Response/
Identity message. In order to permit Diameter to forward the DER
packet, the NAS MUST copy the contents of the Typed-Data field of the
EAP-Response/Identity received from the PaC into the User-Name(1)
attribute and MUST include the Type-Data field of the EAP-Response/
Identity in the User-Name AVP in very subsequent DER message.
If the peer identity cannot be determined from the EAP-Response, then
the User-Name attribute SHOULD be determined by another means.
The NAS SHOULD use the ISP-Information or NAP-Information received in
the PANA-Start-Answer to construct a value of the User-Name
attribute. The construction which SHOULD follow [I-D.ietf-radext-
rfc2486bis] and SHOULD ensure that the DER is routed to the ISP or
NAP identified by the ISP-Information or NAP-Information respectively
that was included in the PANA-Start-Answer message received by the
NAS from the PaC.
EDITOR's question: Is the User-Name strictly used for realm
forwarding? If so, when present the NAP and ISP info must override
whatever is used with the EAP-Req/ID.
8.2 EAP-Payload
In Diameter EAP packets, as defined in [RFC3748] are carried in the
EAP-Payload. In PANA, EAP packets are carried in the EAP-Payload
AVP. Since both these attributes can carry the same amount of data,
Lior & Yegin Expires January 26, 2006 [Page 27]
Internet-Draft PANA AAA Interworking July 2005
the PAA/NAS can simply copy the payload of one AVP to the other AVP.
8.3 PANA and Diameter Session-Identifier Mapping
A PANA session begins with the handshake between the PaC and the PAA.
During the creation of a PANA session, the PAA creates a PANA Session
Identifier. The Session identifier relates the User to the PaC and
the PAA. The format of the PANA Session Identifier is the same as
the format of the Diameter Session Identifier.
When Diameter is used to authenticate a user, the NAS must create a
Session Identifier for the session and includes it in all messages
exchanged for that user, for that access device. A session is a
logical concept at the application layer, and is shared between an
access device and a server, and is identified via the Session-Id AVP.
When single authentication is used it is possible to use the PANA
Session id as the Diameter session id.
When multiple authentications are used since both authentication
conversation may pass through one or more common stateful agent, it
is required that each Diameter Session be unique. Therefore the PANA
session id may only be shared with one of the Diameter conversations
and a different session id needs to be crafted for the other
conversation.
8.4 Session-Termination Mapping
The Termination-Cause AVP describes the reason for termination of the
PANA session. This PANA Termination-Cause AVP maps to the Diameter
Termination-Cause AVP and MUST appear in the Diameter Session-
Termination-Request message and may appear in the Diameter
Accounting-Request(ACR) and Diameter Accounting-Answer(ACA) messages.
The following table shows the mapping between the PANA Termination-
Cause AVP and the Diameter Termination-Cause AVP.
PANA Termination-Cause AVP Diameter Termination-Cause
========================== ===========================
LOGOUT(1) DIAMETER_LOGOUT (1)
ADMINSITRATIVE DIAMETER_ADMINISTRATIVE (4)
SESSION_TIMEOUT DIAMETER_SESSION_TIMEOUT (5)
Lior & Yegin Expires January 26, 2006 [Page 28]
Internet-Draft PANA AAA Interworking July 2005
8.5 Diameter PANA Result Code Mapping
When receiving a DEA message the following values of the Result-Code
are of interest:
DIAMETER_MULTI_ROUND_AUTH: Indicates that the EAP method is not
completed yet.
DIAMETER_SUCCESS: Indicates that the user has been authenticated.
The EAP-Payload SHOULD be included and SHOULD indicate EAP-
Success. This maps to PANA-SUCCESS
DIAMETER_APPLICATION-UNSUPPORTED Indicates that the Diameter server
does not support EAP. THis is mapped to PANA_UNABLE_TO_DELIVER
result code.
DIAMETER_AUTHENTICATION_REJECTED Indicates that the user has failed
authentication. The EAP-Payload SHOULD be included and SHOULD
indicate EAP-Failure. This maps to PANA_AUTHENTICATION_REJECTED
8.6 DIAMETER Table of Attributes
TBD
9. Error Handling
[EDITOR's NOTE: Need to go through all the PANA error conditions and
map them onto RADIUS etc.]
10. Security Considerations
For security consideration between the PaC and the PAA please refer
to [I-D.ietf-pana-pana].
For security consideration between the NAS and the RADIUS server
refer to [RFC3579], which specifically addresses security concerns
regarding the use of EAP over RADIUS.
For security consideration when Diameter is being used and when
Diameter/RADIUS translation agent is being used refer to [I-D.ietf-
aaa-eap].
[EDITOR's NOTE: Are there new security considerations that we need to
look at because of PANA and RADIUS?]
11. Acknowledgement
The authors would like to thank ...
12. References
Lior & Yegin Expires January 26, 2006 [Page 29]
Internet-Draft PANA AAA Interworking July 2005
12.1 Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-10 (work in
progress), July 2005.
[I-D.ietf-radext-rfc2486bis]
Aboba, B., "The Network Access Identifier",
draft-ietf-radext-rfc2486bis-06 (work in progress),
July 2005.
[I-D.zorn-radius-logoff]
Zorn, G., "User Session Tracking in RADIUS",
draft-zorn-radius-logoff-04 (work in progress),
January 2005.
[I-D.zorn-radius-keywrap]
Zorn, G., "RADIUS Attributes for Key Delivery",
draft-zorn-radius-keywrap-07 (work in progress),
July 2005.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Lior & Yegin Expires January 26, 2006 [Page 30]
Internet-Draft PANA AAA Interworking July 2005
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-10 (work in progress), November 2004.
12.2 Informative references
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[I-D.ietf-aaa-diameter-nasreq]
Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application",
draft-ietf-aaa-diameter-nasreq-17 (work in progress),
July 2004.
Authors' Addresses
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Ottawa, Ontario K2K 3J1
Canada
Phone: +1 613-591-6655
Email: avi@bridgewatersystems.com
Alper Yegin
Samsung Advanced Institute of Technology
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544 5656
Email: alper.yegin@samsung.com
Lior & Yegin Expires January 26, 2006 [Page 31]
Internet-Draft PANA AAA Interworking July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lior & Yegin Expires January 26, 2006 [Page 32]
