INTERNET Draft Basavaraj Patil
Expires: August 2001 Nokia
Hesham Soliman,
Karim ElMalki,
Tomas Goldbeck-Lowe,
Ericsson
February 2001
Basic User Registration Protocol (BURP)
<draft-soliman-burp-requirements-00.txt>
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]