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