One document matched: draft-ohba-aaaarch-authorization-delegation-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 03:04:38 |