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) | | | | | | 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 | | | | | | | | | 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 | | | | | | | | 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]