AAA Architecture Research Group Y. Ohba Internet-Draft TARI Expires: March 11, 2005 R. Lopez Univ. of Murcia September 10, 2004 An Extended AAA Authorization Framework with Delegation draft-ohba-aaaarch-authorization-delegation-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 March 11, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document extends the AAA authorization framework described in RFC 2904 in that some or all of the authorization task is delegated from the AAA server to a local network entity. The extension considers new AAA services such as PANA network access service and dynamic host configuration service that have different characteristics from legacy AAA services such as PPP service and IEEE 802.1X network access service. Ohba & Lopez Expires March 11, 2005 [Page 1] Internet-Draft Authorization Delegation Framework September 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Direct Authorization Model . . . . . . . . . . . . . . . . . . 6 4. Delegated Authorization Model . . . . . . . . . . . . . . . . 7 5. Examples of the Delegated Authorization Model . . . . . . . . 8 5.1 PANA Network Access Service . . . . . . . . . . . . . . . 8 5.2 DHCP Service . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1 NAS as Authorization Delegation Point . . . . . . . . 9 5.2.2 AAA Proxy as Authorization Delegation Point . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Ohba & Lopez Expires March 11, 2005 [Page 2] Internet-Draft Authorization Delegation Framework September 2004 1. Introduction In authorization task of AAA, authorization parameters are carried by AAA protocols such as RADIUS and Diameter, including packet filtering information, QoS parameters, keys exported by EAP authentication methods, IP address, on-link/delegated IP prefix and home agent address. This document extends the AAA authorization framework described in [RFC2904] in that some or all of the authorization task is delegated from the AAA server to a local network entity, considering new AAA services such as PANA [I-D.ietf-pana-pana] network access service and dynamic host configuration service that have different characteristics from legacy AAA services such as PPP service and IEEE 802.1X network access service. Furthermore it shows an extended pull sequences defined in [RFC2904] based on this new entity: authorization delegation point. Ohba & Lopez Expires March 11, 2005 [Page 3] Internet-Draft Authorization Delegation Framework September 2004 2. Terminology The terms "AAA Server" and "Service Equipment" are originally defined in [RFC2904]. The terms "Authorization Delegation Point" and "Supplemental Service Equipment" are newly defined in this document. AAA Server A server which authorizes a service based on an agreement with the User Home Organization without specific knowledge about the individual User. This agreement may contain elements that are not relevant to an individual user (e.g., the total agreed bandwidth between the User Home Organization and the Service Provider). AAA Proxy An agent that functions as a AAA server in one side and as a AAA client in other side and AAA messages are exchanged between the two sides with or without inserting, deleting and modifying some attributes. This might be, for example, a translation agent, or a local AAA server that communicates with a remote AAA server of other service provider in a roaming agreement. Service Equipment Equipment which provides the service itself. This might, for example, be a NAS in dial service, a BAS (Broadband Access Server) in DSL service, an IEEE 802.1X authenticator in IEEE 802 LAN service, a home agent in mobility service based on Mobile IPv4/v6, a DHCP server in host configuration service, an enforcement point in PANA network access service, or a print server in the Internet printing service. Supplemental Service Equipment Equipment which does not provide the service itself unlike Service Equipment but communicates with the User as part of the authorization procedure to provide the service to the User. The Supplemental Service Equipment is defined for the extended AAA authorization framework to be aligned with the framework defined in [RFC2904]. Specifically the Supplemental Service Equipment is defined to be co-located with the network entity such as a NAS with which the User directly communicates in the authorization procedure when the Service Equipment itself does not directly communicate with the User in the procedure. Ohba & Lopez Expires March 11, 2005 [Page 4] Internet-Draft Authorization Delegation Framework September 2004 Authorization Delegation Point A point where some or all of the authorization task for a service is delegated from the AAA server. A AAA proxy or a AAA client can be an authorization delegation points. An authorization delegation points is used when the service equipment is not directly visible to or controlled by the AAA server. An authorization delegation point may further delegate the authorization task to other authorization delegation points to form a hierarchy of authorization delegation points. Network Configuration Protocol Protocol used for sending configuration information to a network entity (i.e. service equipment). An example of this protocol is SNMP. Ohba & Lopez Expires March 11, 2005 [Page 5] Internet-Draft Authorization Delegation Framework September 2004 3. Direct Authorization Model This model is classic authorization model defined by [RFC2904]. In this model the same entity (the AAA Server) is in charge of carrying out whole authorization process. Normally, this model is used when a single administrative domain is considered. For example, the AAA server derives all session keys needed to provide a service and send all needed authorization information to either Service Equipment (pull sequence, agent sequence) or User (push sequence) to get the service. Ohba & Lopez Expires March 11, 2005 [Page 6] Internet-Draft Authorization Delegation Framework September 2004 4. Delegated Authorization Model The following model that is an extension of RFC 2904 model is applicable to any scheme described in [RFC2904] (i.e., the push or pull sequence in a single domain case, a roaming case or a distributed case). This model may be used when the service equipment itself does not speak a AAA protocol. +------+ +-------------------------+ | | | User Home Organization | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | | | | | | | +-------------------------+ | | | Service Provider | | | | +-------------------+ | | User | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Authorization | | | | | | Delegation Point | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Service | | | | | | Equipment | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Figure 1: The Delegated Authorization Model Ohba & Lopez Expires March 11, 2005 [Page 7] Internet-Draft Authorization Delegation Framework September 2004 5. Examples of the Delegated Authorization Model In the following examples, it is assumed for simplity that the user home organization and the service provider are integrated. The examples can be easily extended to the cases where the two entities are separated. All examples shown in the subsequent sections are based on the pull sequence that is defined in [RFC2904]. 5.1 PANA Network Access Service The PANA framework [I-D.ietf-pana-framework] allows a PANA authentication agent (PAA) and enforcement points (EPs) to be implemented in physically separate devices. Depending on the authentication and authorization of result of PANA, the PAA installs the cryptographic or non-cryptographic filtering parameters to EPs so that data packets only for authorized PaCs can pass through the EPs by using SNMP as the configuration protocol [I-D.ietf-pana-framework]. An example PANA network access service is shown in Figure 2. The PAA also functions as the supplemental service equipment that communicates with the PaC as part of the authorization procedure. Ohba & Lopez Expires March 11, 2005 [Page 8] Internet-Draft Authorization Delegation Framework September 2004 +------+ +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | ^ | | | | | AAA | | | | v | | | | +-------------------+ | | | | | PAA | | | | PANA | | (Authorization | | | PaC |<- - - - >| Delegation Point | | | | | | and Supplemental | | | | | | Service Equipment)| | | | | +-------------------+ | | | | | SNMP | | | | v | | |Data | +-------------------+ | | |Packets| | EP | | | |<- - - - >| (Service | | | | | | Equipment) | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Figure 2: PANA Network Access Service 5.2 DHCP Service 5.2.1 NAS as Authorization Delegation Point When PANA or IEEE 802.1X is used for the network access authentication in the access network and the PAA or the IEEE 802.1X Authenticator (i.e., the NAS) is physically co-located on the DHCP relay agent, a method described in [I-D.ietf-dhc-agentopt-radius] can be used for carrying RADIUS authorization attributes from the NAS to the DHCP server where the attributes are carried in DHCP relay agent options and used by the DHCP server as DHCP service parameters. However, [I-D.ietf-dhc-agentopt-radius] limits the types of RADIUS attributes that are allowed to be carried in DHCP relay agent options to User-Name, Service-Type, Class, Vendor-Specific, Session-Timeout, Framed-Pool and Framed-IPv6-Pool. An example DHCP service where a NAS functions as an authorization delegation point and DHCP relay agent option is used for carrying authorization parameters is shown in Figure 3. Ohba & Lopez Expires March 11, 2005 [Page 9] Internet-Draft Authorization Delegation Framework September 2004 Alternatively, if the NAS is not physically co-located with the DHCP server or the DHCP relay agent, a configuration protocol such as SNMP is used for carrying the DHCP parameters to the DHCP server. An example DHCP service where a NAS functions as an authorization delegation point and SNMP is used for carrying authorization parameters is shown in Figure 4. In both Figure 3 and Figure 4, the NAS also functions as the supplemental service equipment that communicates with the user as part of the authorization procedure. Also, when PANA is used for the network access authentication in the access network, the NAS (i.e., PAA) may be separated from the EPs and the PAA may also act as an authorization delegation point for the PANA network access service described in Section 5.1. Additionally, the PAA could also be considered as an authorization delegation point for DHCP Service if the PAA is not co-located with EPs. Ohba & Lopez Expires March 11, 2005 [Page 10] Internet-Draft Authorization Delegation Framework September 2004 +-------------+ +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | ^ | | | | | AAA | | |PANA or| v | | |IEEE | +--------------------+ | | |802.1X | | NAS and | | | | | | DHCP relay agent | | | User |<- - - - >| (Authorization | | | | | | Delegation Point | | | | | | and Supplemental | | | | | | Service Equipment) | | | | | +--------------------+ | | | | | DHCP | | | | | relay agent | | | | v option | | |DHCP | +-------------------+ | | |Packets| | DHCP Server | | | |<- - - - >| (Service | | | | | | Equipment) | | | | | +-------------------+ | | | | | +-------------+ +-------------------------+ Figure 3: DHCP Service with NAS as Authorization Delegation Point (DHCP Relay Agent option is used for carrying authorization parameters) Ohba & Lopez Expires March 11, 2005 [Page 11] Internet-Draft Authorization Delegation Framework September 2004 +-------------+ +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | ^ | | | | | AAA | | |PANA or| v | | |IEEE | +--------------------+ | | |802.1X | | NAS | | | User |<- - - - >| (Authorization | | | | | | Delegation Point | | | | | | and Supplemental | | | | | | Service Equipment) | | | | | +--------------------+ | | | | | | | | | | SNMP | | | | v | | |DHCP | +-------------------+ | | |Packets| | DHCP Server | | | |<- - - - >| (Service | | | | | | Equipment) | | | | | +-------------------+ | | | | | +-------------+ +-------------------------+ Figure 4: DHCP Service with NAS as Authorization Delegation Point (SNMP is used for carrying authorization parameters) 5.2.2 AAA Proxy as Authorization Delegation Point When AAA messaging between the NAS and the AAA server is proxied by a AAA proxy, the AAA proxy may become the authorization delegation point which installs the DHCP service parameters assigned by the AAA server or by the proxy itself to the DHCP server by using a configuration protocol such as SNMP. An example DHCP service where a AAA proxy functions as an authorization delegation point is shown in Figure 5. In Figure 5, the NAS also functions as the supplemental service equipment that communicates with the user as part of the authorization procedure. When PANA is used for the network access authentication in the access network, the PAA may be separated from the EPs and the PAA may also function as an authorization delegation point for the PANA network Ohba & Lopez Expires March 11, 2005 [Page 12] Internet-Draft Authorization Delegation Framework September 2004 access service described in Section 5.1. +-------------+ +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | ^ | | | | AAA | | | | | v | | | | +-------------------+ | | | | | AAA Proxy | | | | | | (Authorization | | | | | | Delegation Point) | | | | | +-------------------+ | | User | | ^ | | | | | AAA| | | | |PANA or| v | | | |IEEE | +---------------+ | | | |802.1X | | NAS | |SNMP| | |<- - - - >| (Supplemental | | | | | | | Service | | | | | | | Equipment) | | | | | | +---------------+ | | | | | v | | |DHCP | +-------------------+ | | |Packets| | DHCP Server | | | |<- - - - >| (Service | | | | | | Equipment) | | | | | +-------------------+ | | | | | +-------------+ +-------------------------+ Figure 5: DHCP Service with AAA Proxy as Authorization Delegation Point Ohba & Lopez Expires March 11, 2005 [Page 13] Internet-Draft Authorization Delegation Framework September 2004 6. Security Considerations Authorization is itself a security mechanism. As such, it is important that authorization protocols cannot easily be abused to circumvent the protection they are intended to ensure. It is the responsibility of protocol designers to design their protocols to be resilient against well-known types of attacks. The same security considerations as [RFC2904] apply to this document. Ohba & Lopez Expires March 11, 2005 [Page 14] Internet-Draft Authorization Delegation Framework September 2004 7. Acknowledgments The authors would like to thank Mayumi Yanagiya for reviewing the document. Ohba & Lopez Expires March 11, 2005 [Page 15] Internet-Draft Authorization Delegation Framework September 2004 8. References 8.1 Normative References [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000. 8.2 Informative References [RFC2905] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000. [RFC2906] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Requirements", RFC 2906, August 2000. [I-D.ietf-pana-pana] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-05 (work in progress), July 2004. [I-D.ietf-mip6-bootstrap-ps] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. [I-D.ietf-pana-framework] Jayaraman, P., "PANA Framework", draft-ietf-pana-framework-01 (work in progress), July 2004. [I-D.ietf-dhc-agentopt-radius] Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option", draft-ietf-dhc-agentopt-radius-08 (work in progress), September 2004. Ohba & Lopez Expires March 11, 2005 [Page 16] Internet-Draft Authorization Delegation Framework September 2004 Authors' Addresses Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5305 EMail: yohba@tari.toshiba.com Rafael Marin Lopez University of Murcia 30071 Murcia Spain EMail: rafa@dif.um.es Ohba & Lopez Expires March 11, 2005 [Page 17] Internet-Draft Authorization Delegation Framework September 2004 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 (2004). 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. Ohba & Lopez Expires March 11, 2005 [Page 18]