INTERNET-DRAFT Subir Das/Anthony McAuley Internet Engineering Task Force Telcordia Technologies draft-das-burp-requirements-00.txt Basavaraj Patil/Henry Haverinen Date: January 2001 Nokia Expires: July 2001 Yoshihiro Ohba/Shinichi Baba Toshiba America Research Inc. Basic User Registration Protocol (BURP) Requirements 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 This documents describes a set of requirements for an application layer registration protocol that allows a user to register in the network by providing its identity and authentication information to the local network. The local network then validates the user, charge him and, authorize use of resources with the help of a AAA infrastructure. Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 1] Internet Draft BURP Requirements July 2001 1. Introduction The vision of pervasive computing includes constantly being able to access the Internet or an enterprise network. The road warriors using this facility will frequently access the network from places like airports, hotels, malls and sports complexes. These environments typically offer access over wireless LANs or via Ethernet LAN ports or other mediums. In such scenarios DHCP [DHCv4], [DHCv6] is preferred to PPP [PPP], since it can provide configuration parameters (e.g., a valid IP address) without any unnecessary framing overhead; but there is no standard way for service providers to obtain user information to perform AAA functions. For users who do not have Mobile IP [MIP] clients on their devices but would like to access the network, they need to register and be authenticated by the local network service provider before being authorized to use the resources. Thus it is essential to develop an application layer protocol that allows a user to register in the network by providing identity and authentication information to the local network which then uses a AAA infrastructure to validate the user, charge him and, authorize use of resources. Current mobility management solutions, such as Mobile IP, integrate registration, configuration and binding. There are however, in future pervasive networks, where such Mobile IP based continuous reachability may not be required. A different form of untethered and roaming access to network resources will become equally important in such scenarios, especially in environments such as airports, hotels, shopping malls and sports stadiums. In these scenarios, users simply access (pull) network services using local LANs and borrowed nodes; only configuration and registration are necessary in such cases. Also there is no need for the user to be locatable. Configuration can be achieved with existing protocols, such as, DHCP, however, it has no user registration capabilities to allow the network providers to authenticate users. Also current efforts at defining standard AAA functionality concentrate on the Network-Network Interface (NNI), such as DIAMETER [AAAD]. A common User Network Interface (UNI) for user registration, which is independent of a specific access technologies, configuration or binding protocols, is thus necessary. 2. Requirements This section describes the requirements for a Basic User Registration Protocol (BURP), which will provide a way for users to offer credentials to a local server in order to be granted access to the local network. I. It MUST be an application layer client-server protocol, using a well-known (defined) port. Server can be anywhere in local domain and not require protocol entities on clients link. Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 2] Internet Draft BURP Requirements July 2001 II. It SHOULD be simple user-network registration that works with both IPv4 and IPv6. - It MUST not do IP configuration, but should work with any configuration protocol such as DHCP, IPv6 stateless autoconfiguration [AUTOv6], or manual configuration. - It MUST not provide mobility support, but should work with any mobility protocol, such as Mobile IP. - It MUST not exchange any inter-domain AAA message, but should work with any AAA protocol such as DIAMETER (only server talks with AAA protocol). - It MUST not do firewall/policer control to limit packets forwarding, but should work with any policing protocol such as COPS. - Where possible, it MUST use existing configuration protocols, such as DHCP, IPv6 stateless autoconfiguration, etc, to discover the server location. Where this service is not available, the client MUST have a fall-back capability to discover the server location. III. It MUST create a Local Security Association (LSA) between client (e.g., visiting user) and server (e.g., visited network). MAY support sharing of LSA among members of a specific group, so that application data can be securely shared among the group. - It MUST not assume client and server share pre-established LSA or public key certificates. - It MUST not define how to generate the keys to establish the LSA. However, one example method could be to use DIAMETER's pre-established security association between user and user's "home" AAA domain. - It MUST not define how user authenticates itself with its "home" AAA server. "Home" authentication token is passed transparently to the AAA protocol. IV. It MUST have authentication and replay protection mechanisms for both client and server. MAY also encrypt BURP packets to prevent gathering information. V. It MUST allow various ways of identifying a user, such as NAI [NAI], FQDN, or DHCPv6 Universal Unique ID [DHCv6]. However, one default globally unique identifier (specific to this protocol) MUST be supported. Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 3] Internet Draft BURP Requirements July 2001 - It MUST not use link specific identifiers such as IP address. VI. It MUST deliver all the user parameters required by an AAA protocol. It SHOULD support delivery of "static" profiles. - It MUST not support dynamic negotiation of user profiles. VII. It SHOULD be able to carry application data from network to user (e.g., welcome message, receipt and/or area guide information). VIII. It SHOULD provide information on who is using the network, their LSA, and what their "static" profiles in a secure manner to other network entities. For example, the information could be used by: Local SIP proxy [SIP] or LDAP [LDAP] server. Other local entities do not therefore have to establish their own LSA. - It MUST not allow clients to obtain information about other clients. IX. If a user moves from one server's territory to another server's territory in the same AAA domain, then it MUST be possible to use the LSA obtained from the first server to circumvent the need to interact with the home AAA server. X. It SHOULD allow users to disconnect from the AAA domain, either explicitly or silently (implies soft state). - Network does not have to immediately detect a node going out of the visiting AAA domain. Implies that accounting, based on exact time in network, is beyond the scope of BURP. APPENDIX A. Proposal Scenario This section describes a proposal scenario for using BURP. This is for ease of understanding the requirements and does meant to be BURP protocol architecture. As defined in the requirements section, BURP is a client-server application layer protocol with two components: the BURP Client and the BURP Server. The BURP client will be on the User Terminal while the server will be on a node in the visited domain we call the Registration Agent (RA). Figure 1 represents a typical scenario that uses DIAMETER for AAA. Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 4] Internet Draft BURP Requirements July 2001 Visited Domain Home Domain | +------------+ | | | Broker AAA | | | | (AAAB) | | +--------------+ | +-----^------+ | +-----------+ | Local AAA | DIAMETER | DIAMETER | Home AAA | | (AAAL) |<--------+ | +---------->| (AAAH) | +-------^------+ | v------v-----v | +-----------+ | | / \ | DIAMETER | | / INTERNET \ | | | \ / | +-------v------+ | \ / | | Registration | | \-----------/ | | Agent(RA) | | | +-------^------+ | | | | | BURP | | | | | | +-------v------+ | | | User | | | | Terminal | | | +--------------+ | | Figure 1. An Example Scenario B. Terminology Client: The client is the BURP code that runs on behalf of the user on the user terminal. AAAL: Local AAA server in the visited domain that interacts to the AAAH or AAAB. AAAB: Broker AAA server which is able to authorize clients. AAAH: Home AAA server in the home domain which is able to authorize its clients. Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 5] Internet Draft BURP Requirements July 2001 Registration Agent (RA): It is responsible for creating a Local Security Association (LSA) with the user. It extracts the identification and authorization information from the BURP messages sent by the client and forwards this information to the local AAA for verification. Once the client is authenticated by the AAA infrastructure it establishes the LSA with the user and forwards other network messages to the client. It is not necessary that this message exchanges are to be performed in one roundtrip. If necessary, it also securely provides LSA and user information to other network entities. Server: The server is the BURP code that runs on behalf of the network on the Registration Agent. User Terminal: The node which the user is employing to access the network. User: The entity whose identity is being verified or checked. C. Description In this section, we show some example message flow but this may not represent all BURP messages or functionalities. In Figure 1, we consider that one interface of the RA will logically understand BURP messages and the other will communicate with the AAA protocol such as DIAMETER. BURP does not mandate the location or number of RAs, other than one has to be somewhere in the visited domain. At the extremes one could be located on each access link (subnet) or, to provide better scalability and control a single RA could handle an entire domain. Figure 2 describes an example message flow during initial BURP registration. User Terminal DHCP Sever RA/AAAL AAAH/AAAB | DHCP_REQUEST | | | |----------------> | | | DHCP_OFFER | | | <----------------| | | | DHCP_ACK | | | |----------------> | | | | | | | BURP_GREETING | | | |---------------------------------> | | | | AAA Request | | | <================> Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 6] Internet Draft BURP Requirements July 2001 | | | | | BURP_ACK/BURP_NACK | | <---------------------------------| | | | | | Figure 2. BURP and AAA flow diagram for a new user After receiving an IP address and obtaining the address of the RA from a configuration protocol, such as DHCP, the BURP client will send a BURP_GREETING to the RA. If the configuration protocol is not able to supply the IP address of the registration server (e.g., has not been upgraded), then the BURP protocol can fall-back on its own discovery protocol. This discovery protocol, however, will be an option that will only be used if other means are not available. The BURP_GREETING MAY include an authentication token using a pre-established Security Association with its AAAH or AAAB. The RA will then contact the AAAL for authentication. Receiving a AAA request from RA, AAAL will do the network-to-network AAA using a protocol, such as DIAMETER and obtains the keys to establish a LSA with the client (from the AAAH or AAAB). It may be possible for the AAAH to send challenges or other request which may trigger a BURP_AAA_CHALLENGE message from the RA to the user. Once RA receives a response from AAAL it sends a BURP_REPLY to the client. There are two types of BURP reply: BURP_ACK and BURP_NACK. BURP_ACK allows the access to the network; while a BURP_NACK declines the access to the network. 7. References [AAAD] P. Calhoun, A. Rubens, H. Akhtar and E. Guttman "DIAMETER Base Protocol, draft-calhoun-diameter-17.txt, Work in Progress, September 2000. [AUTOv6] S. Thomson and T. Narten "IPv6 Stateless Address Autoconfiguration" Request for Comments 2462, December 1998. [DHCv4] R. Droms, "Dynamic Host Configuration Protocol," Request for Comments 2131, March 1997. [DHCv6] J. Bound, M. Carney, C. Perkins and R. Droms, "Dynamic Host Configuration Protocol for IPv6", draft-ietf-dhc-dhcpv6-16.txt, November 2000, Work in Progress. [LDAP] M. Wahl, T. Howes and S. Kille , "Lightweight Directory Access Protocol (v3)" Request for Comments 2251, December 1997 [MIPv4] C. Perkins, "IP Mobility Support for IPv4, revised", Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 7] Internet Draft BURP Requirements July 2001 draft-ietf-mobileip -rfc2002-bis-03.txt, September 2000. [NAI] B. Aboba and M. A. Beadles, "The network access identifier," RFC 2486, January 1999. [PPP] W. Simpson, "The Point to Point Protocol (PPP),: Internet STD 51, July 1994. [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol," draft-ietf-sip-rfc2543bis-02.txt, November 2000. 7. Authors' Addresses Subir Das MCC 1D210R, Telcordia Technologies 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4959 email: subir@research.telcordia.com Anthony J. McAuley MCC 1C235B, Telcordia Technologies 445 South Street, Morristown, NJ 07960 Phone: +1 973 829 4698 email: mcauley@research.telcordia.com Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 Phone: +1 972 894 6709 email: Basavaraj.Patil@nokia.com Henry Haverinen Nokia Tieteenkatu 1 FIn-33721 Tampere Finland Phone: +358 50 594 4899 email: Henry.haverinen@nokia.com Yoshihiro Ohba Toshiba America Research Inc. P.O. Box 136 Convent Station, NJ 07961-0136 Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 8] Internet Draft BURP Requirements July 2001 Phone: +1 973 829 5174 email: yohba@tari.toshiba.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 Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 9] Internet Draft BURP Requirements July 2001 [Page 9] Das, McAuley, Patil, Haverinen, Ohba, Baba Expires July 2001 [Page 10]