Internet DRAFT - draft-lior-pana-radius
draft-lior-pana-radius
Network Working Group A. Lior
Internet-Draft Bridgewater Systems
Expires: August 13, 2005 A. Yegin
Samsung
February 9, 2005
Interworking of Protocol for Carrying authentication for Network
Access (PANA) and Remote Authentication Dial In User Service
(RADIUS).
draft-lior-pana-radius-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides information on the use of Remote
Authentication Dial In User Service (RADIUS) with the Protocol for
Carrying Authentication for Network Access (PANA).
Lior & Yegin Expires August 13, 2005 [Page 1]
Internet-Draft Interwokring of PANA and RADIUS February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Mapping of PANA Phases to RADIUS . . . . . . . . . . . . . 4
3.2 Call Flows . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Call flow for a single authentication . . . . . . . . 5
3.2.2 PANA Multi-Authentication Call Flow . . . . . . . . . 8
3.2.3 PANA Termination . . . . . . . . . . . . . . . . . . . 9
3.2.4 Re-authentication . . . . . . . . . . . . . . . . . . 11
4. PANA RADIUS Message Mapping . . . . . . . . . . . . . . . . . 13
4.1 RADIUS Access-Request . . . . . . . . . . . . . . . . . . 13
4.2 Access-Challenge . . . . . . . . . . . . . . . . . . . . . 14
4.3 Access-Accept . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Access-Reject . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Accounting-Request . . . . . . . . . . . . . . . . . . . . 16
4.6 Disconnect-Request . . . . . . . . . . . . . . . . . . . . 16
5. RADIUS Attributes to PANA AVP Mapping . . . . . . . . . . . . 16
5.1 Consideration for User-Name . . . . . . . . . . . . . . . 17
5.2 EAP-Message . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 PANA Session . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Session-Termination . . . . . . . . . . . . . . . . . . . 18
5.5 Consideration Acct-Terminate-Cause . . . . . . . . . . . . 18
5.6 RADIUS Table of Attributes . . . . . . . . . . . . . . . . 19
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1 Normative references . . . . . . . . . . . . . . . . . . . 20
9.2 Informative references . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
Lior & Yegin Expires August 13, 2005 [Page 2]
Internet-Draft Interwokring of PANA and RADIUS February 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 RADIUS. As specified in
[RFC3579] RADIUS is able to carry EAP conversations between the EAP
Authenticator (the NAS) and the Authentication Server. Therefore,
this document describes the integration of [I-D.ietf-pana-pana] and
[RFC3579]. As well, PANA supports other capabilities such as, PAA
initiation of session termination, and therefore this document
describes how PANA works with RADIUS Dynamic Authorization Extensions
[RFC3576].
1.1 Terminology
The document uses the PANA terms found in [I-D.ietf-pana-pana] and
the RADIUS terms found in [RFC2865], [RFC2866], [RFC2869], and
[RFC3576] and EAP terms found in [RFC3579].
In this document "attributes" refers to RADIUS attributes and
"Attribute Value Pair" or "AVP" refers to PANA attributes.
In this document the term "NAS" refers to the PANA PAA and RADIUS
client which are logically co-located.
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 RADIUS
Lior & Yegin Expires August 13, 2005 [Page 3]
Internet-Draft Interwokring of PANA and RADIUS February 2005
scenario. The basic scenario is enough to understand how to operate
PANA with RADIUS. Other scenarios are possible. For example, RADIUS
proxies may exist between the RADIUS client and the RADIUS server;
or, the RADIUS server may not be the EAP Authentication Server
+------------------------------+
+-----+ | +-----+ +---------------+ | +---------------+
| | | | | | | | | |
| PaC +---+--+ PAA +--+ RADIUS client |--+-----+ RADIUS server |
| | | | | | | | | |
+-----+ | +-----+ +---------------+ | +---------------+
| Network Access Server(NAS) |
+------------------------------+
Figure 1
In the above figure, the PAA and the RADIUS 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
RADIUS 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 RADIUS attributes that are implicated in
PANA. Henceforth we use the term NAS to represent the PAA/RADIUS
client.
Roles:
o The PaC and the PAA communicate as per
[I-D.ietf-pana-pana].
o The NAS communicates with the RADIUS server using the
RADIUS protocol. In some deployments this communication
may involve one or more RADIUS 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 RADIUS Server is acting EAP authentication server.
3. Operations
3.1 Mapping of PANA Phases to RADIUS
A PANA session consist of distinct phases. This section describes
the mapping of the PANA phases to the RADIUS phases.
Lior & Yegin Expires August 13, 2005 [Page 4]
Internet-Draft Interwokring of PANA and RADIUS February 2005
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. RADIUS is not involved in
this phase. However, PANA allows for the EAP execution to overlap
the discovery and handshake phase. In this case RADIUS
authentication and authorization is triggered in this phase.
PANA authentication and authorization phase: This phase follows PANA
discovery and handshake phase. RADIUS authentication and
authorization is used to carry the PANA EAP payload to the EAP Server
using RADIUS packets. In addition to the EAP result, the RADIUS
infrastructure may deliver authorization attributes to the NAS.
PANA Access phase: After successful authentication and authorization,
IP traffic begins to flow. RADIUS accounting packets (when used)
indicate the start of the PANA access phase. During the PANA access
phase, RADIUS accounting may be used to report interim usage for the
session. At anytime during the access phase, RADIUS may deliver new
authorization attributes as specified by [RFC3576].
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 RADIUS 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.
If [RFC3576] is supported, then a RADIUS server may trigger the NAS
to initiate termination of the PANA session. If RADIUS accounting is
used, PANA session termination is signaled by the generation of a
RADIUS Accounting Request (Stop) packet.
3.2 Call Flows
The following call flows illustrate the interoperation of PANA with
RADIUS. 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].
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 August 13, 2005 [Page 5]
Internet-Draft Interwokring of PANA and RADIUS February 2005
PaC NAS RADIUS
Server
a) < Discovery and handshake phase>
| | |
< Authentication Authorization phase>
|PANA-Auth-Request(x) | |
b) |<---------------------| |
|PANA-Auth-Answer(x) | |
c) |--------------------->| |
| |RADIUS Access-Request |
d) | |----------------------->|
| |RADIUS Challenge |
e) | |<-----------------------|
|PANA-Auth-Request(x+1)| |
f) |<---------------------|........................|
|PANA-Auth-Answer(x+1) | |
g) |--------------------->|........................|
| | RADIUS Access-Request |
h) | |----------------------->|
| | RADIUS Access-Accept |
i) | |<-----------------------|
|PANA-Bind-Request | |
j) |<---------------------| |
|PANA-Bind-Answer | |
k) |--------------------->| |
| |RADIUS 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 RADIUS.
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 RADIUS an Access-Request. Attributes from the PAR
are translated to RADIUS attributes. In particular, the
User-Name(1) attribute is constructed as described below. The
User-Name(1) will be used throughout the transaction. If
[I-D.zorn-radius-logoff] is supported, the PANA Session-id will
be sent in these and the other Access-Requests in the Session-Id
Lior & Yegin Expires August 13, 2005 [Page 6]
Internet-Draft Interwokring of PANA and RADIUS February 2005
attribute.
e. RADIUS responds with a RADIUS Access-Challenge. RADIUS
Access-Request and RADIUS Access-Challenge packets are used in
multi-step authentication scheme such as EAP. If the
authentication required one packet exchange then RADIUS would
have responded with an Access-Accept or an Access-Reject. These
packets include the EAP-Message(79) attribute(s) which contain
the EAP method.
f. Attributes from the RADIUS Access-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(79) attribute(s)
are copied in the EAP-Payload AVP(s).
g. The PaC response with an PAR which is then forwarded to the
RADIUS server in an Access request (as in step d).
h. As in step d, attributes in the PAR are translated to RADIUS
attributes and are sent to the RADIUS server in an
Access-Request.
i. The NAS receives a response from the RADIUS server. If the
response is a Access-Challenge packet, then Authentication is not
yet complete and steps f) and g) are repeated. If the packet
received is an Access-Accept or Access-Reject, then RADIUS
authentication and Authorization phase are over. In this case
the NAS saves the authorization attributes and the resulting
AAA-KEY(if any) which is carried in TBD or preferably in [KEY].
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
Access-Accept or Access-Reject packets respectively.
k. The PaC responds with an PANA-Bind-Answer (PBA).
l. The NAS sends a RADIUS Accounting-Request(Start) packet
confirming the start of the session. As the session continues,
the NAS may send RADIUS Accounting Request(Interims) packets as
required. When the Session terminates, the NAS will send a
RADIUS 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.
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.
Lior & Yegin Expires August 13, 2005 [Page 7]
Internet-Draft Interwokring of PANA and RADIUS February 2005
3.2.2 PANA Multi-Authentication Call Flow
PaC NAS RADIUS
Server
| | |
a) |<Discovery Handshake> | |
| | |
b) |< PANA FIRST AUTHENTICATION > |
|<====================>|<======================>|
| | |
|PFER | |
c) |<---------------------| |
| PFEA | |
d) |--------------------->| |
| | |
e) |< PANA SECOND AUTHENTICATION > |
|<====================>|<======================>|
| | |
| PANA-Bind-Request | |
f) |<---------------------| |
| PANA-Bind-Answer | |
g) |--------------------->| |
| |RADIUS Accounting(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 RADIUS
authorization attributes received in the Access-Accept if any are
saved. The Keys that are the result of the EAP method if
received in the Access-Accept must be saved. Keys are delivered
in the Access-Accept using MS-MPPE-Send-Key and MS-MPPE-Recv-Key
attributes [RFC2548]; or preferably, the Key attribute as defined
in [I-D.zorn-radius-keywrap].
c. Upon receiving an Access-Accept or Access-Reject the PAA sends a
PFER to the PaC. The PFER will contain the EAP Success/Failure
message received in the Access-Accept/Access-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
Lior & Yegin Expires August 13, 2005 [Page 8]
Internet-Draft Interwokring of PANA and RADIUS February 2005
executed. The RADIUS authorization attributes received in the
Access-Accept if any are saved. Any Key if received in the
Access-Accept is saved.
f. The PAA sends a PBR containing the EAP Success/Failure message
carried in the Access-Accept/Access-Reject.
g. The PaC responds with a PBA.
h. The session begins. This is signaled by sending of a RADIUS
Accounting(Start) packet. As the session continues, the NAS may
send RADIUS Accounting Request(Interims) as required. When the
Session terminates, the NAS will send a RADIUS
Accounting-Request(Stop).
When two PANA authentication are used, there are two distinct RADIUS
Authentication and Authorization conversations typically with
different NAIs. The same RADIUS server may participate in both
conversations, however, the endpoint will typically be different.
Each RADIUS Authorization may deliver RADIUS 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
Accounting-Request (Start) packets one for each RADIUS authentication
authorization conversation.
3.2.3 PANA Termination
Explicit termination can be initiated either from the PaC or from the
PAA.
PaC NAS RADIUS
Server
| | |
|< PANA access phase> | |
| PTR | |
a) |--------------------->| |
|PTA | |
b) |<---------------------| |
| |Accounting-Request(Stop)|
c) | |----------------------->|
Lior & Yegin Expires August 13, 2005 [Page 9]
Internet-Draft Interwokring of PANA and RADIUS February 2005
a. When the PaC initiates explicit termination, it sends the PAA a
PTR message.
b. The PAA acknowledges with a PTA message.
c. The NAS sends a RADIUS Accounting-Request (Stop) packet
indicating the end of the session.
[EDITOR'S NOTES: We can probably combine the above and below call
flow since there is no added value from the RADIUS perspective]
PaC NAS RADIUS
Server
| | |
| <PANA access phase> | |
| | |
a) [Termination-Trigger]
| PTR | |
b) |<---------------------| |
| PTA | |
c) |--------------------->| |
| |Accounting-Request(Stop)|
d) | |----------------------->|
| | |
In the case of the initiation from the PAA that can be as a result of
several events:
A local command was received by the NAS to trigger the termination;
A Session-Timeout , for example, received as part of the RADIUS
authorization attributes has expired.
If the NAS is metering resources, and these resources have expired,
then the NAS may terminate the session.
If the NAS supports [RFC3576], the arrival of a RADIUS disconnect
packet may cause the NAS to initiate the PANA termination phase.
Lior & Yegin Expires August 13, 2005 [Page 10]
Internet-Draft Interwokring of PANA and RADIUS February 2005
PaC NAS RADIUS
Server
| | |
|<PANA access phase> | |
| | DR |
a) | |<-----------------------|
| | D-ACK |
b) | |----------------------->|
| PTR | |
c) |<---------------------| |
| PTA | |
d) |--------------------->| |
| |Accounting-Request(Stop)|
e) | |----------------------->|
| | |
a. The NAS receives a RADIUS Disconnect-Request packet[RFC3576]
containing session identifiers.
b. The NAS responds with a Disconnect-ACK (D-ACK) packet[RFC3576].
c. The PAA sends a PANA termination requests to the PaC.
d. The PaC acknowledges the termination request.
e. The NAS sends an Accounting-Request (Stop) packet to signal the
termination of the session and deliver final usage data for the
session.
Note, if PANA multi-authentication was performed based on local
policies the NAS MAY send two Accounting-Request (Stop) packets.
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.
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 or the PAA may initiate re-authentication phase. The
following call flow illustrates the PaC initiating.
Lior & Yegin Expires August 13, 2005 [Page 11]
Internet-Draft Interwokring of PANA and RADIUS February 2005
PaC NAS RADIUS
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
RADIUS Access-Accept packet 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 Access-Reject packet contains
the EAP Failure message.
Some authorization attributes maybe received from RADIUS. RADIUS
Session-Timeout maybe sent to change the lifetime of the session.
It's a matter of local policies.
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 to the RADIUS server.
The RADIUS can instruct the NAS to initiate re-authentication after a
period of time by sending Session-Timeout and Terminate-Action set to
"RADIUS".
Lior & Yegin Expires August 13, 2005 [Page 12]
Internet-Draft Interwokring of PANA and RADIUS February 2005
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)
[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] RADIUS Access-Request is mapped to PANA-Auth-Request when
the PANA-Auth-Answer is strictly used as an acknowledgement to
PANA-Auth-Request. That is, when PANA-Auth-Answer is not carrying
any EAP payload.
4.1 RADIUS Access-Request
A RADIUS Access-Request packet is mapped to PANA-Auth-Answer message
and a PANA-Start-Answer (if the PANA-Start-Answer contains the
EAP-Payload).
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. How the value for
the User-Name is derived is discussed below.
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. The
Message-Authenticator is computed as described in [RFC3579].
The RADIUS Service-Type (6) attribute will be typically set to
Lior & Yegin Expires August 13, 2005 [Page 13]
Internet-Draft Interwokring of PANA and RADIUS February 2005
"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 will not be carried in the RADIUS Access-Request packet.
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).
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) attributes to the EAP-Payload AVP included in
the PANA-Auth-Request message to be sent to the PaC.
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.
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.
Lior & Yegin Expires August 13, 2005 [Page 14]
Internet-Draft Interwokring of PANA and RADIUS February 2005
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-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. ]
[EDITOR's NOTE: There seems to be a conflict between RFC3579 and PANA
when multiple authentication is used.
This is what RFC 3579 says:
The conversation continues until either a RADIUS Access-Reject or
Access-Accept packet is received from the RADIUS server. Reception
of a RADIUS Access-Reject packet MUST result in the NAS denying
access to the authenticating peer. A RADIUS Access-Accept packet
successfully ends the authentication phase. The NAS MUST NOT
"manufacture" a Success or Failure packet as the result of a timeout.
After a suitable number of timeouts have elapsed, the NAS SHOULD
instead end the EAP conversation.
This is clearly against the PANA specification. Which allows one AAA
authentication to fail and the other to succeed. ]
Lior & Yegin Expires August 13, 2005 [Page 15]
Internet-Draft Interwokring of PANA and RADIUS February 2005
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 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. 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
Lior & Yegin Expires August 13, 2005 [Page 16]
Internet-Draft Interwokring of PANA and RADIUS February 2005
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 a]
Session-Lifetime Session-Timeout(27)
Termination-Cause Acct-Terminate-Cause(49)
[Note 1]: Defined by [I-D.zorn-radius-logoff]
5.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.
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.
5.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, you may have to split the attribute 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).
Lior & Yegin Expires August 13, 2005 [Page 17]
Internet-Draft Interwokring of PANA and RADIUS February 2005
[RFC3579] Section 2.2. describes how the RADIUS server handles
invalid EAP packets passed to it by the NAS.
5.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].
5.4 Session-Termination
Upon receipt of an Access-Accept message, that contains a
Session-Timeout(27) attribute without a Termination-Action(29)
attribute or with a Termination-Action attribute set to "Default",
the Session-Timeout(27) attribute specifies the maximum number of
seconds of service provided prior to session termination. The
Session-Timeout will then be copied into the Session-Lifetime AVP of
the PANA Bind-Request message. If the Session-Timeout(27) is equal
to zero, then the NAS SHALL immediately terminate the session.
When the Access-Accept packet contains a Session-Timeout(27)
attribute with a Termination-Action(29) attribute set to
RADIUS-Request, the Session-Timeout attribute specified the maximum
number of seconds of service provided prior to re-authentication. In
this case, the Session-Timeout value is used to instruct the NAS when
to initiate PANA Re-authentication. Therefore in this case the
Session-Lifetime AVP must be set longer then the value specified in
Session-Timeout(27) attribute. When sent with a Termination-Action
value of RADIUS-Request, a Session-Timeout value of zero indicates
the desire to perform another authentication (possibly of a different
type) immediately after the first authentication has successfully
completed.
5.5 Consideration Acct-Terminate-Cause
This attribute is included in the RADIUS Accounting-Request (Stop)
packets and indicates how the session was terminated[RFC2866]
Lior & Yegin Expires August 13, 2005 [Page 18]
Internet-Draft Interwokring of PANA and RADIUS February 2005
PANA Termination-Cause AVP RADIUS Acct-Terminate-Cause(49)
========================== ===========================
LOGOUT(1) "User Request" (1)
ADMINSITRATIVE "Admin Reset" (6)
SESSION_TIMEOUT "Session Timeout" (5)
5.6 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.
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].
Lior & Yegin Expires August 13, 2005 [Page 19]
Internet-Draft Interwokring of PANA and RADIUS February 2005
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.
6. Error Handling
[EDITOR's NOTE: Need to go through all the PANA error conditions and
map them onto RADIUS etc.]
7. 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.
[EDITOR's NOTE: Are there new security considerations that we need to
look at because of PANA and RADIUS?]
8. Acknowledgement
The authors would like to thank ...
9. References
9.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.
Lior & Yegin Expires August 13, 2005 [Page 20]
Internet-Draft Interwokring of PANA and RADIUS February 2005
[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., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", Internet-Draft draft-ietf-pana-pana-07,
December 2004.
[I-D.ietf-radext-rfc2486bis]
Aboba, B., "The Network Access Identifier",
Internet-Draft draft-ietf-radext-rfc2486bis-03, December
2004.
[I-D.zorn-radius-logoff]
Zorn, G., "User Session Tracking in RADIUS",
Internet-Draft draft-zorn-radius-logoff-04, January 2005.
[I-D.zorn-radius-keywrap]
Zorn, G., "RADIUS Attributes for Key Delivery",
Internet-Draft draft-zorn-radius-keywrap-02, January 2005.
9.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.
Lior & Yegin Expires August 13, 2005 [Page 21]
Internet-Draft Interwokring of PANA and RADIUS February 2005
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 August 13, 2005 [Page 22]
Internet-Draft Interwokring of PANA and RADIUS February 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 August 13, 2005 [Page 23]
