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,"
<draft-ietf-aaa-authorization-reqs-01.txt>, October 1999.
[2] J. Arkko, "Requirements for Internet-scale Accounting
Management," <draft-arkko-acctreq-00.txt>, 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,"
<draft-ietf-mobileip-aaa-reqs-00.txt>, 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)," <draft-itsumo-drcp-00.txt>,
October, 1999.
ITSUMO Group Expires August 2000 [Page 6]
Internet Draft AAA Requirements using DHCP March 2000
[7] R. Droms, "Authentication for DHCP Messages," <draft-gupta-dhcp-
auth-12.txt>, October, 1999.
[8] V. Gupta, "Flexible Authentication for DHCP Messages,"
<draft-ietf-dhc-authentication-12.txt>, October, 1998.
[9] A. Gustafsson, "A DNS RR for encoding DHCP information,"
<draft-ietf-dnsind-dhcp-rr.00.txt>, October, 1999.
[10] M. Stapp, Y. Rekhter, "Interaction between DHCP and DNS,"
<draft-ietf-dhc-dhcp-dns-11.txt>, 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,"
<draft-wang-aaa-cel-req-00.txt>, October, 1999.
[14] M. Beadles and et.al., "Criteria for evaluating AAA protocols
for network access", <draft-ietf-aaa-na-reqts-01.txt>, 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,"
<draft-dhc-enhance-requirements-00.txt>, 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]
