Network Working Group Subir Das INTERNET-DRAFT Anthony McAuley Internet Engineering Task Force Telcordia Technologies draft-ietf-dhc-aaa-requirements-00.txt Shinichi Baba Date: March 8, 2000 Yasuro Shobatake Expires: August, 2000 Toshiba America Research Inc. Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of sections 10 of RFC 2026. 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. Abstract The AAA working group is currently defining the requirements for Authentication, Authorization, and Accounting (AAA). This draft lists the AAA requirements to aid roaming nodes using a dynamic address configuration protocol such as DHCP. The node may or may not be using Mobile IP [3] (with co-located care-of-address) or other dynamic address binding protocol. ITSUMO Group Expires August 2000 [Page 1] Internet Draft AAA Requirements using DHCP March 2000 1. Introduction A network providing communication services to nodes from foreign domains, must use Authorization, Authentication, and Accounting (AAA) services [1,2]. A dynamically roaming node places stronger requirements on AAA than a static node. Moreover, next generation network applications will raise the requirements on IP network even higher. The Mobile IP [3] Working Group is currently specifying the requirements for a roaming node using Mobile IP with Foreign Agents [4]. This document specifies the requirements for a roaming node who obtains an address using DHCP [5] [17] or similar node configuration protocol (e.g., DRCP [6]). Recent drafts [7,8] specify how to add authentication to DHCP messages. This allows clients to verify DHCP servers or servers to verify DHCP clients. It does not, however, specify the interaction with a AAA protocol to allow roaming users to access networks in multiple administrative domains. The document is independent of whether the roaming node uses dynamic address binding. The roaming node getting an address through DHCP [5] and once authenticated via AAA [1, 13,14] may also use Mobile IP with co-located addresses, dynamic DNS updates [9,10], or any other dynamic address binding techniques [15,16]. The document does not discuss the pros and cons of how best to support roaming users, only to ensure that the AAA protocol is sufficiently flexible to support both nodes using Mobile IP with Foreign Agents and nodes using DHCP (with or without Mobile IP). Since many of the requirements for DHCP are similar to those for Mobile IP with Foreign Agents, we borrow heavily from the Mobile IP requirements document [3, 4]. 1.1 Requirements Terminology 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 RFC 2119 [REQ]. ITSUMO Group Expires August 2000 [Page 2] Internet Draft AAA Requirements using DHCP March 2000 2. Basic Model Figure 2 shows that our general model is very much similar to that described in [4]. The only change is that we do not assume the AAA authentication is necessarily done in a home domain. We assume, more generally, that the roaming node authentication is done in a (possibly distributed) Public AAA (AAAP), which is similar to AAA broker model. The reasons for using the AAAP are discussed in section 4. Each DHCP client might use a different AAAP that can check its credentials, or they may share the same AAAP (even if they are from different domains). Local Domain Internet +-------------+ +----------------+ | +------+ | | +------+ | | | AAAL | | AAA Protocol | | AAAP | | | | +----------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------+ | | | | | | +--------+ | +---+---+ | | DHCP | DHCP | | DHCP | | | Client |-------|--| Server| | +--------+ | +-------+ | AAAP = Public authority | | AAAL = local authority +-------------+ Figure 1: AAA Servers Model DHCP server does not have direct access to the data needed for authentication. So it is expected that the server will consult the local authority (AAAL) for verification. Since the server and the local authority are in the same domain it is assumed that they will have strong security associations. Alternatively, they may be co-located. On the other hand, AAAL itself may not have enough information stored locally to complete the transaction. However, AAAL is expected to be configured with enough information to negotiate the client's verification with corresponding AAAP. Sometimes client may notify its own AAAP for verification via its registration message (e.g., Client's NAI [11]). The local AAA and public AAA should have sufficient security relationships and access control so that they can negotiate the authorization and enable the client to have the requested resources. Once this is over, DHCP ITSUMO Group Expires August 2000 [Page 3] Internet Draft AAA Requirements using DHCP March 2000 server will be notified about the successful negotiation and the server can provide the requested resources to the client. If it is not authorized, server will be informed to terminate the service to the client. 3. Requirements Based on the above scenarios, the following specific requirements for AAA can be ascertained. - Either the DHCP Server and AAAL are co-located or they share a security relationship. - The DHCP server should be configured to obtain authorization from a trusted local AAA server (AAAL). - The local authority (AAAL) has to share, or dynamically establish, security relationships with public authorities (AAAP) that are able to check client credentials. - The client must have a security association with its public authority (AAAP). - Nobody can reconstruct and reuse the credentials that the client uses. - The DHCP server MUST be able to terminate service to the client based on policy determination by the AAA server. - The DHCP server should be able to handle requests for many clients simultaneously. - The client may resend a request if it does not get a reply in some time, so the AAA entities must be designed to operate correctly and efficiently with multiple requests for the same client. - The DHCP server has to keep state for pending client requests while the local authority contacts the appropriate external authority. - Support replay protection and optional non-repudiation capabilities for all authorization and accounting messages. - AAA server need not know any IP address of the client and it identifies clients by other means, e.g., Network Access ITSUMO Group Expires August 2000 [Page 4] Internet Draft AAA Requirements using DHCP March 2000 Identifier (NAI). - Client NAI domain allows AAAL to easily determine the AAAP. - The local AAA server MUST support anonymous access. - There is no requirement for AAA to transport `DHCP or other node configuration messages'. - AAA must complete in one round trip. A major component of the setup latency is the time taken to traverse the wide-area Internet that is likely to separate the AAAL and the AAAP. - AAA must allow a node to register once in its domain and move among subnets in the same domain without requiring more AAA. After the initial registration, the AAAP and AAAL would not be needed. - Support accounting information via AAAP servers providing accounting clearinghouse and reconciliation between serving and home networks. - AAA MUST support message privacy and integrity. 4. Reasons for using Public AAA AAA servers model in [4] shows a configuration in which the local and the home authority have to share trust. This configuration causes a quadratic growth in the number of trust relationships as the number of AAA authorities (local AAA and home AAA) increases. This has been identified as a problem by the roamops working group [12], and any AAA proposal MUST solve this problem. Using public AAA (AAAP) solves many of the scalability problems associated with requiring direct business/roaming relationships between every two administrative domains. A public AAA may play the role of a proxy between two administrative domains which have security associations with the AAAP, and relay AAA messages back and forth securely. The AAAP enables the local and home domains to cooperate without requiring each of the networks to have a direct business or security relationship with all the other networks. Thus, AAAPs offer the needed scalability for managing trust relationships between otherwise independent network domains. Use of the AAAP does not preclude managing separate trust relationships between domains, but it does offer an alternative suitable for commercial environments. ITSUMO Group Expires August 2000 [Page 5] Internet Draft AAA Requirements using DHCP March 2000 5. Security Considerations This draft defines the AAA requirements for roaming nodes using DHCP or similar type of node configuration protocol. Since AAA is security driven, most of this documents addresses the security considerations AAA must make on behalf of roaming nodes using node configuration protocols. 6. Acknowledgements The requirements in section 3 were taken from a draft submitted by S. Glass, S. Jacobs, and C. Perkins of the Mobile IP working group. We would like to acknowledge their work. The authors acknowledge the contributions of other members of the ITSUMO (Internet Technologies Supporting Universal Mobile Operation) team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, D. Famolari, S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and Toshiba America Research Incorporated (T. Kodama). References [1] S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege and D. Spence, "AAA Authorizatiopn Requirements," , October 1999. [2] J. Arkko, "Requirements for Internet-scale Accounting Management," , August, 1998. [3] C. Perkins, "IP Mobility Support," RFC 2002, October 1996. [4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements," , October, 1999. [5] R. Droms, "Dynamic Host Configuration Protocol," Request for Comments 2131, March, 1997. [6] A. McAuley, S. Das, S. Baba, Y. Shobatake, "Dynamic Registration and Configuration Protocol (DRCP)," , October, 1999. ITSUMO Group Expires August 2000 [Page 6] Internet Draft AAA Requirements using DHCP March 2000 [7] R. Droms, "Authentication for DHCP Messages," , October, 1999. [8] V. Gupta, "Flexible Authentication for DHCP Messages," , October, 1998. [9] A. Gustafsson, "A DNS RR for encoding DHCP information," , October, 1999. [10] M. Stapp, Y. Rekhter, "Interaction between DHCP and DNS," , October, 1999. [11] B. Aboba and M. A. Beadles, "The network access identifier," RFC 2486, January 1999. [12] B. Adoba and G. Zorn, "Criteria for evaluating roaming protocols," RFC 2477, December 1998. [13] J. Wang and R. Wang, "Cellular network Authentication, Authorization, and Accounting requirements," , October, 1999. [14] M. Beadles and et.al., "Criteria for evaluating AAA protocols for network access", , October 1999. [15] H. Schulzrinne and et. al., "SIP: Session initiation protocol," RFC 2543, March 1999. [16] E. Wedlund and H. Schulzrinne, "Mobility support using SIP", Proc. The second ACM International workshop on Wireless Mobile Multimedia, ACM/IEEE, pp 76-82, August, 1999. [17] A. McAuley, S. Das, S. Baba, Y. Shobatake, " Requirements for Extending DHCP into New Environments," , March, 2000. 7. Authors' Addresses Subir Das MCC 1D210R, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4959 email: subir@research.telcordia.com ITSUMO Group Expires August 2000 [Page 7] Internet Draft AAA Requirements using DHCP March 2000 Anthony J. McAuley MCC 1C235B, Telcordia 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4698 email: mcauley@research.telcordia.com Shinichi Baba Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 4759 email: sbaba@tari.toshiba.com Yasuro Shobatake Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Phone: +1 973 829 3951 email: yasuro.shobatake@toshiba.co.jp ITSUMO Group Expires August 2000 [Page 8]