idnits 2.17.1 draft-soliman-burp-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'KEYWORDS' is defined on line 256, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET Draft Basavaraj Patil 2 Expires: August 2001 Nokia 3 Hesham Soliman, 4 Karim ElMalki, 5 Tomas Goldbeck-Lowe, 6 Ericsson 7 February 2001 9 Basic User Registration Protocol (BURP) 10 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This draft provides the reasons that motivate the development of an 34 access independent user registration protocol. It provides a few 35 scenarios wherein such a protocol would be applicable as well as 36 include some initial requirements. 38 1.0 Introduction and motivation 40 Most of today's access technologies rely on an access specific 41 mechanism or the functions provided by PPP to be able to authenticate 42 a user to the network and authorise them for access. However, PPP may 43 not be suited to many wireless technolgies, especially the ones 44 providing shared media, like many Ethernet based wireless 45 technologies. Access control and user identification is usually based 46 on the security credentials provided by these authentication 47 mechanisms. PPP as a legacy protocol has worked exteremely well and 48 is widely deployed, but there is a need to address user registration 49 and authentication in a more access independent manner. 51 Most of these mechanisms are well suited to non-mobile users. In 52 addition, since such authentication mechanisms are in many cases 53 based on L2 credentials, a user's identity becomes associated to 54 these L2 credentials. 55 To allow users to use different networks with different access 56 technologies, a generic, access independent mechanism is needed to 57 identify users and be able to authenticate them to their "Home" 58 service providers. Furthermore, charging of such roaming users is 59 usually associated with some knowledge or profiles provided by their 60 "Home" domains. To allow charging to be done per-user and not per- 61 device or access technology, a generic and access independent user 62 identity is required. 64 Access control in most current wireless technologies is performed on 65 L2 based on device identification combined with L2 security. However, 66 as wireless routers become more common, a mobile wireless router may 67 have two interfaces having two different wireless technologies. The 68 use of L2 access control would not stop other malicious nodes from 69 using such wireless routers to send their traffic over the secured 70 radio link. Hence, L3 access control based on a generic user identity 71 is would be required for tighter access control enforcement. 73 It should be noted that the arguments shown above do not eliminate 74 the need for L2 security or access control, but complement the 75 existing standards by utilising L3 information to allow tight access 76 control and simpler charging per user. 78 A generic application layer protocol would provide greater 79 flexibility and access independence for user and simplify charging 80 for network operators. 82 This protocol is applicable to several scenarios where hot spot areas 83 such as hotels, airports, shopping malls and sports arenas may 84 provide wired and wireless network connectivity to users as a service 85 that can be charged. However the network operator would need to have 86 the user authenticate him/her self before being authorised to 87 continue using the network or providing external connectivity. A 88 common registration protocol would allow the user to access different 89 types of access networks operated by different operators without 90 having to have subscriptions or specialized software from each of 91 them. A user-network registration protocol that is as ubiquitous as 92 DNS would make network devices and networks simpler to use and 93 operate. The network operator in this example would have a AAA 94 infrastructure which would allow the verification of the users 95 credentials as well as provide the ability to charge the user. 97 It should be noted that a user who accesses a network may or may not 98 have any ISP as his "home" service provider. The user may just be 99 authorized to use the network based on some e-cash or other methods. 101 2.0 BURP Requirements 103 2.1 Access dependence 105 BURP MUST be access independent. Since the protocol is intended to be 106 an application layer protocol, it MUST not be associated with any 107 specific link types. The protocol should be able to work with IPv4 as 108 well as IPv6. 110 2.2 User authentication and identification 112 BURP MUST allow a network to authenticate the user and the user to 113 authenticate the network. The latter requirement is to prevent fraud 114 networks from getting hold of user credentials. 116 BURP interaction SHOULD be done once per user (e.g. when first 117 attaching to a network or when resources on the network require the 118 user to register). It SHOULD NOT be done per application, 119 per port, per stack (e.g. IPv4/IPv6), per interface (e.g. eth0/eth1), 120 nor per node (if a user has multiple nodes). A user should be 121 authenticated to the network based on a higher level identifier and 122 not an IP address. 124 BURP MUST allow various ways of identifying a user, such as NAI, 125 FQDN, IMSI or DHCPv6 Universal Unique ID. However, one default 126 globally unique identifier (specific to this protocol) MUST be 127 supported. 129 BURP MUST be able to provide the user with a Temporary Local Security 130 Association (TLSA). The TLSA SHOULD be used by users to authenticate 131 themselves to other IP-layer services within the administrative 132 domain. The TLSA MAY also be used to authenticate the user to other 133 application-layer services. 134 The generation of the TLSA MUST NOT be associated to the case where a 135 user is in a "visited" domain. Ie. it should also be used when users 136 are in their "home" domain. The distribution of the TLSA to such IP- 137 layer services or application-layer services MUST be outside the 138 scope of BURP. 140 BURP MUST NOT allow clients to obtain information about other 141 clients. 143 2.2 Access Control 145 Access control is essential for networks to ensure that only 146 authorised users can gain access to the network. There may be 147 different levels of access depending on a user's profile. 148 The BURP protocol MUST provide the necessary information required for 149 access control. This may include: user identificaion, TLSA, user's IP 150 addresses and other attributes of a user profile. The access control 151 information may be sent to access control points using DIAMETER. 153 2.3 Relationship with configuration 155 BURP SHOULD assume IP configuration is complete before it begins. 156 BURP does need to be tied to IP configuration, but should work with 157 any configuration protocol (e.g. DHCP, IPv6 stateless 158 autoconfiguration, or manual configuration). 160 The BURP server can be shared among links and placed anywhere in 161 the local domain. It MAY be desirable to put a BURP server or 162 relay on each link. Doing this, a node on the local link eliminates 163 the need to allow BURP packets through the firewall and subsequently 164 the network can use the BURP TLSA for access control. To discover the 165 server location the local server can use well-known link/Site-local 166 address while a non-local server must exploit existing configuration 167 protocols, such as DHCP, IPv6 stateless autoconfiguration, anycast 168 addresses or other service discovery protocols (eg. SLP). On the 169 other hand, if this service is not available, the client may have a 170 fall-back capability to discover the server location. 172 2.4 Protocol issues 174 BURP MUST be designed in a way that allows protection against replay 175 attacks. 177 The final protocol MUST specify mechanisms to allow for encryption nd 178 data integrity between BURP clients and servers. 180 BURP MUST NOT assume any pre-shared security associations between 181 clients and servers. However, the final protocol should allow for 182 this scenario. In addition, BURP MAY allow for or specify security 183 algorithm negotiation between clients and servers or between two 184 clients. BURP MAY also specify some default algorithms that MUST be 185 supported to ensure inter-operability. 187 BURP SHOULD allow users to disconnect from the AAA domain, either 188 explicitly or silently (implies soft state). The network does not 189 have to immediately detect a node leaving the AAA domain. 191 BURP MUST provide a mechanism for deregistration. A user should be 192 able to indicate to the network that he/she is leaving the network. 193 This MUST be done in a secure manner. This might be needed in cases 194 where the user is paying for a given _air time_ or a requested QoS. 196 2.5 Mobility issues 198 BURP does not provide mobility support, but should work with any 199 mobility protocol, such as Mobile IP. 200 More mobility requiements may be added in future revisions of the 201 draft. 203 2.6 Interaction with AAA 205 The registration protocol provides the users credentials to the 206 network. The network or the registration agent is then able to 207 interact with AAA in the network to authenticate the user or 208 authorize usage of certain resources or provide accounting 209 capability. 211 3. Author's Addresses 213 Basavaraj Patil 214 Nokia Corporation 215 6000 Connection Drive 216 Irving, TX 75039 217 USA 219 Phone: +1 972-894-6709 220 EMail: Raj.Patil@nokia.com 221 Fax : +1 972-894-5349 223 Hesham Soliman 224 Ericsson Australia 225 61 Rigall St., Broadmeadows 226 Melbourne, Victoria 3047 227 AUSTRALIA 229 Phone: +61 3 93012049 230 Fax: +61 3 93014280 231 E-mail: Hesham.Soliman@ericsson.com.au 233 Karim El Malki 234 Ericsson Radio Systems AB 236 LM Ericssons Vag. 8 237 126 25 Stockholm 238 SWEDEN 240 Phone: +46 8 7195803 241 Fax: +46 8 7190170 242 E-mail: Karim.El-Malki@era.ericsson.se 244 Tomas Goldbeck-Lowe 245 Ericsson Radio Systems AB 246 Networks and Systems Research 247 SE-164 80 Stockholm 248 SWEDEN 250 Phone: +46 8 764 1467 251 Fax: +46 8 404 7020 252 E-mail: Tomas.Goldbeck-Lowe@era.ericsson.se 254 4. References 256 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 This Internet-Draft expires in August 2001.