INTERNET Draft Basavaraj Patil Expires: August 2001 Nokia Hesham Soliman, Karim ElMalki, Tomas Goldbeck-Lowe, Ericsson February 2001 Basic User Registration Protocol (BURP) Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft provides the reasons that motivate the development of an access independent user registration protocol. It provides a few scenarios wherein such a protocol would be applicable as well as include some initial requirements. Patil,Soliman,ElMalki,Goldbeck-Lowe BURP [Page 1] INTERNET-DRAFT February 2001 1.0 Introduction and motivation Most of today's access technologies rely on an access specific mechanism or the functions provided by PPP to be able to authenticate a user to the network and authorise them for access. However, PPP may not be suited to many wireless technolgies, especially the ones providing shared media, like many Ethernet based wireless technologies. Access control and user identification is usually based on the security credentials provided by these authentication mechanisms. PPP as a legacy protocol has worked exteremely well and is widely deployed, but there is a need to address user registration and authentication in a more access independent manner. Most of these mechanisms are well suited to non-mobile users. In addition, since such authentication mechanisms are in many cases based on L2 credentials, a user's identity becomes associated to these L2 credentials. To allow users to use different networks with different access technologies, a generic, access independent mechanism is needed to identify users and be able to authenticate them to their "Home" service providers. Furthermore, charging of such roaming users is usually associated with some knowledge or profiles provided by their "Home" domains. To allow charging to be done per-user and not per- device or access technology, a generic and access independent user identity is required. Access control in most current wireless technologies is performed on L2 based on device identification combined with L2 security. However, as wireless routers become more common, a mobile wireless router may have two interfaces having two different wireless technologies. The use of L2 access control would not stop other malicious nodes from using such wireless routers to send their traffic over the secured radio link. Hence, L3 access control based on a generic user identity is would be required for tighter access control enforcement. It should be noted that the arguments shown above do not eliminate the need for L2 security or access control, but complement the existing standards by utilising L3 information to allow tight access control and simpler charging per user. A generic application layer protocol would provide greater flexibility and access independence for user and simplify charging for network operators. This protocol is applicable to several scenarios where hot spot areas such as hotels, airports, shopping malls and sports arenas may provide wired and wireless network connectivity to users as a service that can be charged. However the network operator would need to have the user authenticate him/her self before being authorised to continue using the network or providing external connectivity. A Patil,Soliman,ElMalki,Goldbeck-Lowe BURP [Page 2] INTERNET-DRAFT February 2001 common registration protocol would allow the user to access different types of access networks operated by different operators without having to have subscriptions or specialized software from each of them. A user-network registration protocol that is as ubiquitous as DNS would make network devices and networks simpler to use and operate. The network operator in this example would have a AAA infrastructure which would allow the verification of the users credentials as well as provide the ability to charge the user. It should be noted that a user who accesses a network may or may not have any ISP as his "home" service provider. The user may just be authorized to use the network based on some e-cash or other methods. Patil,Soliman,ElMalki,Goldbeck-Lowe BURP [Page 3] INTERNET-DRAFT February 2001 2.0 BURP Requirements 2.1 Access dependence BURP MUST be access independent. Since the protocol is intended to be an application layer protocol, it MUST not be associated with any specific link types. The protocol should be able to work with IPv4 as well as IPv6. 2.2 User authentication and identification BURP MUST allow a network to authenticate the user and the user to authenticate the network. The latter requirement is to prevent fraud networks from getting hold of user credentials. BURP interaction SHOULD be done once per user (e.g. when first attaching to a network or when resources on the network require the user to register). It SHOULD NOT be done per application, per port, per stack (e.g. IPv4/IPv6), per interface (e.g. eth0/eth1), nor per node (if a user has multiple nodes). A user should be authenticated to the network based on a higher level identifier and not an IP address. BURP MUST allow various ways of identifying a user, such as NAI, FQDN, IMSI or DHCPv6 Universal Unique ID. However, one default globally unique identifier (specific to this protocol) MUST be supported. BURP MUST be able to provide the user with a Temporary Local Security Association (TLSA). The TLSA SHOULD be used by users to authenticate themselves to other IP-layer services within the administrative domain. The TLSA MAY also be used to authenticate the user to other application-layer services. The generation of the TLSA MUST NOT be associated to the case where a user is in a "visited" domain. Ie. it should also be used when users are in their "home" domain. The distribution of the TLSA to such IP- layer services or application-layer services MUST be outside the scope of BURP. BURP MUST NOT allow clients to obtain information about other clients. 2.2 Access Control Access control is essential for networks to ensure that only authorised users can gain access to the network. There may be different levels of access depending on a user's profile. The BURP protocol MUST provide the necessary information required for access control. This may include: user identificaion, TLSA, user's IP Patil,Soliman,ElMalki,Goldbeck-Lowe BURP [Page 4] INTERNET-DRAFT February 2001 addresses and other attributes of a user profile. The access control information may be sent to access control points using DIAMETER. 2.3 Relationship with configuration BURP SHOULD assume IP configuration is complete before it begins. BURP does need to be tied to IP configuration, but should work with any configuration protocol (e.g. DHCP, IPv6 stateless autoconfiguration, or manual configuration). The BURP server can be shared among links and placed anywhere in the local domain. It MAY be desirable to put a BURP server or relay on each link. Doing this, a node on the local link eliminates the need to allow BURP packets through the firewall and subsequently the network can use the BURP TLSA for access control. To discover the server location the local server can use well-known link/Site-local address while a non-local server must exploit existing configuration protocols, such as DHCP, IPv6 stateless autoconfiguration, anycast addresses or other service discovery protocols (eg. SLP). On the other hand, if this service is not available, the client may have a fall-back capability to discover the server location. 2.4 Protocol issues BURP MUST be designed in a way that allows protection against replay attacks. The final protocol MUST specify mechanisms to allow for encryption nd data integrity between BURP clients and servers. BURP MUST NOT assume any pre-shared security associations between clients and servers. However, the final protocol should allow for this scenario. In addition, BURP MAY allow for or specify security algorithm negotiation between clients and servers or between two clients. BURP MAY also specify some default algorithms that MUST be supported to ensure inter-operability. BURP SHOULD allow users to disconnect from the AAA domain, either explicitly or silently (implies soft state). The network does not have to immediately detect a node leaving the AAA domain. BURP MUST provide a mechanism for deregistration. A user should be able to indicate to the network that he/she is leaving the network. This MUST be done in a secure manner. This might be needed in cases where the user is paying for a given _air time_ or a requested QoS. 2.5 Mobility issues BURP does not provide mobility support, but should work with any Patil,Soliman,ElMalki,Goldbeck-Lowe BURP [Page 5] INTERNET-DRAFT February 2001 mobility protocol, such as Mobile IP. More mobility requiements may be added in future revisions of the draft. 2.6 Interaction with AAA The registration protocol provides the users credentials to the network. The network or the registration agent is then able to interact with AAA in the network to authenticate the user or authorize usage of certain resources or provide accounting capability. 3. Author's Addresses Basavaraj Patil Nokia Corporation 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972-894-6709 EMail: Raj.Patil@nokia.com Fax : +1 972-894-5349 Hesham Soliman Ericsson Australia 61 Rigall St., Broadmeadows Melbourne, Victoria 3047 AUSTRALIA Phone: +61 3 93012049 Fax: +61 3 93014280 E-mail: Hesham.Soliman@ericsson.com.au Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 E-mail: Karim.El-Malki@era.ericsson.se Tomas Goldbeck-Lowe Ericsson Radio Systems AB Patil,Soliman,ElMalki,Goldbeck-Lowe BURP [Page 6] INTERNET-DRAFT February 2001 Networks and Systems Research SE-164 80 Stockholm SWEDEN Phone: +46 8 764 1467 Fax: +46 8 404 7020 E-mail: Tomas.Goldbeck-Lowe@era.ericsson.se 4. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. This Internet-Draft expires in August 2001. Patil,Soliman,ElMalki,Goldbeck-Lowe BURP [Page 7]