idnits 2.17.1 draft-ietf-roamops-roamreq-10.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 145 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...This document...' == Line 12 has weird spacing: '...as, and its...' == Line 17 has weird spacing: '...MAY be updat...' == Line 18 has weird spacing: '...ference mater...' == Line 21 has weird spacing: '...To learn the...' == (140 more instances...) == 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). -- 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 (August 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2138 (ref. '2') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '3') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 2002 (ref. '5') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1825 (ref. '6') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2284 (ref. '7') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 1334 (ref. '9') (Obsoleted by RFC 1994) Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Glen Zorn 4 Category: Informational Microsoft Corporation 5 August 1998 7 Requirements for Internet Roaming 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups MAY also distribute working doc- 14 uments as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and MAY be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires February 7, 1999. Please send com- 28 ments to the authors. 30 2. Abstract 32 This document describes requirements for the provisioning of "roaming 33 capability" for dialup Internet users. "Roaming capability" is defined 34 as the ability to use multiple Internet service providers (ISPs), while 35 maintaining a formal, customer-vendor relationship with only one. 37 3. Introduction 39 Operational roaming services are currently providing worldwide roaming 40 capabilities, and these services continue to grow in popularity [1]. 41 Interested parties have included: 43 Regional Internet Service Providers (ISPs) operating within a par- 44 ticular state or province, looking to combine their efforts with 45 those of other regional providers to offer services over a wider 46 area. 48 National ISPs wishing to combine their operations with those of one 49 or more ISPs in another nation to provide greater coverage in a 50 group of countries or on a continent. 52 Businesses desiring to offer their employees a comprehensive pack- 53 age of dialup services on a global basis. Those services can 54 include Internet access as well as secure access to corporate 55 intranets via a Virtual Private Network (VPN). 57 This document provides an architectural framework for the provisioning 58 of roaming capabilities, as well as describing the requirements that 59 must be met by elements of the architecture. 61 3.1. Requirements language 63 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 64 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 65 described in [4]. 67 Please note that the requirements specified in this document are to be 68 used in evaluating protocol submissions. As such, the requirements lan- 69 guage refers to capabilities of these protocols; the protocol documents 70 will specify whether these features are required, recommended, or 71 optional for use in roaming. For example, requiring that a protocol 72 support confidentiality is NOT the same thing as requiring that all pro- 73 tocol traffic be encrypted. 75 A protocol submission is not compliant if it fails to satisfy one or 76 more of the must or must not requirements for the capabilities that it 77 implements. A protocol submission that satisfies all the must, must 78 not, should and should not requirements for its capabilities is said to 79 be "unconditionally compliant"; one that satisfies all the must and must 80 not requirements but not all the should or should not requirements for 81 its protocols is said to be "conditionally compliant." 83 3.2. Terminology 85 This document frequently uses the following terms: 87 phone book 88 This is a database or document containing data pertaining to 89 dialup access, including phone numbers and any associated 90 attributes. 92 phone book server 93 This is a server that maintains the latest version of the 94 phone book. Clients communicate with phone book servers in 95 order to keep their phone books up to date. 97 Network Access Server 98 The Network Access Server (NAS) is the device that clients 99 dial in order to get access to the network. 101 Authentication server 102 This is a server which provides for authentication/authoriza- 103 tion within the roaming architecture. 105 Accounting server 106 This is a server which provides for accounting within the 107 roaming architecture. 109 Authentication proxy 110 Authentication proxies may be deployed within the roaming 111 architecture for several purposes, including authentication 112 forwarding, policy implementation, shared secret management, 113 and attribute editing. To the NAS, the authentication proxy 114 appears to act as an authentication server; to the authentica- 115 tion server, the proxy appears to act as an authentication 116 client. 118 Accounting proxy 119 Accounting proxies may be deployed within the roaming archi- 120 tecture for several purposes, including accounting forwarding, 121 reliability improvement, auditing, and "pseudo-transactional" 122 capability. To the NAS, the accounting proxy appears to act 123 as an accounting server; to the accounting server, the proxy 124 appears to act as an accounting client. 126 Network Access Identifier 127 In order to provide for the routing of authentication and 128 accounting packets, user name MAY contain structure. This 129 structure provides a means by which the authentication or 130 accounting proxies will locate the authentication or account- 131 ing server that is to receive the request. 133 4. Architectural framework 135 The roaming architecture consists of three major subsystems: 137 Phone book Subsystem 138 Authentication Subsystem 139 Accounting Subsystem 141 The phone book subsystem is concerned with the maintenance and updating 142 of the user phone book. The phone book provides the user with informa- 143 tion on the location and phone numbers of Points of Presence (POPs) that 144 are roaming enabled. The function of the authentication subsystem is to 145 provide authorized users with access to the POPs in the phonebook, and 146 to deny access to unauthorized users. The goal of the accounting sub- 147 system is to provide information on the resources utilized during the 148 user's session. 150 4.1. Phone Book Subsystem 152 The phone book subsystem provides for the following: 154 Phone number presentation 155 Phone number exchange 156 Phone book compilation 157 Phone book update 159 Phone number presentation 160 Phone number presentation involves the display of available phone 161 numbers to the user, and culminates in the choosing of a number. 162 Since the user interface and sequence of events involved in phone 163 number presentation is a function of the connection management 164 software being used, it is likely that individual vendors will take 165 different approaches to the problem. These differences can include 166 variances in the format of the client phone books, varying 167 approaches to presentation, etc. There is no inherent problem with 168 this. As a result, phone number presentation need not be standard- 169 ized. 171 Phone number exchange 172 Phone number exchange involves propagation of phone number changes 173 between providers in a roaming association. Current roaming imple- 174 mentations do not provide for complete automation of the phone num- 175 ber exchange process [1]. As a result, phone number exchange need 176 not be standardized at this time. 178 Phone book compilation 179 Once an ISP's phone book server has received its updates it needs 180 to compile a new phone book and propagate this phone book to all 181 the phone book servers operated by that ISP. Given that the compi- 182 lation process does not affect protocol interoperability, it need 183 not be standardized. 185 Phone book update 186 Once the phone book is compiled, it needs to be propagated to 187 users. Standardization of the phone book update process allows for 188 providers to update user phone books, independent of their client 189 software or operating system. 191 4.2. Authentication Subsystem 193 The authentication subsystem provides for the following: 195 Connection management 196 Authentication 197 NAS Configuration/Authorization 198 Address Assignment/Routing 199 Security 201 Connection management 202 In order to be able to use the POPs of the local provider, it is 203 first necessary to bring up a connection. 205 Identification 206 Authentication consists of two parts: the claim of identity (or 207 identification) and the proof of the claim (or verification). As 208 part of the authentication process, users identify themselves to 209 the Network Access Server (NAS) in a manner that allows the authen- 210 tication request to be routed its home destination. 212 Authentication 213 Authentication is typically required prior to allowing access to 214 the network. CHAP [8] and PAP [9] are the two authentication pro- 215 tocols most commonly used within the PPP [10] framework today. 216 Some groups of users are requiring different forms of proof of 217 identity (e.g., token or smart cards, Kerberos credentials, etc.) 218 for special purposes (such as acquiring access to corporate 219 intranets). The Extensible Authentication Protocol (EAP) [7] was 220 created in order to provide a general mechanism for support of 221 these methods. 223 NAS configuration/authorization 224 In order to set up the session, authorization parameters need to be 225 sent to from the home authentication server to the local ISP's NAS. 227 Address assignment/routing 228 If it is desired that the user be able to communicate with the rest 229 of the Internet, then the session will be assigned a routable IP 230 address by the NAS. 232 Security 233 In the process of authenticating and authorizing the user session, 234 it may be desirable to provide protection against a variety of 235 security threats. 237 4.3. Accounting Subsystem 239 The function of the accounting subsystem is to enable the participants 240 in the roaming consortium to keep track of what resources are used dur- 241 ing a session. Relevant information includes how long the user was con- 242 nected to the service, connection speed, port type, etc. 244 5. Roaming Requirements 246 5.1. Phonebook requirements 248 5.1.1. Phone book update protocol 250 Portability 251 The update protocol MUST allow for updating of clients on a range 252 of platforms and operating systems. Therefore the update mechanism 253 MUST NOT impose any operating system-specific requirements. 255 Authentication 256 The client MUST be able to determine the authenticity of the server 257 sending the phone book update. The server MAY also be able to 258 authenticate the client. 260 Versioning 261 The update protocol MUST provide for updating of the phone book 262 from an arbitrary previous version to the latest available version. 264 Integrity Checking 265 The client MUST be able to determine the integrity of the received 266 update before applying it, and MUST be able to determine the 267 integrity of the newly produced phone book after updating it. 269 Light weight transfers 270 Since the client may be a low-end machine or internet appliance, 271 the update protocol MUST be lightweight. 273 Language support 274 The phone book update mechanism MUST support the ability to request 275 that the phone book be transmitted in a particular language and 276 character set. For example, if the customer has a Russian language 277 software package, then the propagation and update protocols MUST 278 provide a mechanism for the user to request a Russian language 279 phone book. 281 5.1.2. Phone book format 283 Phone number attributes 284 The phone book format MUST support phone number attributes commonly 285 used by Internet service providers. These attributes are required 286 in order to provide users with information on the capabilities of 287 the available phone numbers. 289 Provider attributes 290 In addition to providing information relating to a given phone num- 291 ber, the phone book MUST provide information on the individual 292 roaming consortium members. These attributes are required in order 293 to provide users with information about the individual providers in 294 the roaming consortium. 296 Service attributes 297 In addition to providing information relating to a given phone num- 298 ber, and service provider, the phone book MUST provide information 299 relevant to configuration of the service. These attributes are 300 necessary to provide the client with information relating to the 301 operation of the service. 303 Extensibility 304 Since it will frequently be necessary to add phone book attributes, 305 the phone book format MUST support the addition of phone number, 306 provider and service attributes without modification to the update 307 protocol. Registration of new phone book attributes will be han- 308 dled by IANA. The attribute space MUST be sufficiently large to 309 accomodate growth. 311 Compactness 312 Since phone book will typically be frequently updated, the phone 313 book format MUST be compact so as to minimize the bandwidth used in 314 updating it. 316 5.2. Authentication requirements 317 5.2.1. Connection Management 319 Given the current popularity and near ubiquity of PPP, a roaming stan- 320 dard MUST provide support for PPP and IP. A roaming standard MAY provide 321 support for other framing protocols such as SLIP. However, SLIP support 322 is expected to prove difficult since SLIP does not support negotiation 323 of connection parameters and lacks support for protocols other than IP. 325 A roaming standard MAY provide support for non-IP protocols (e.g., IPX 326 or AppleTalk) since these may be useful for the provision of corporate 327 intranet access via the Internet. Since it is intended that the client 328 will begin PPP negotiation immediately on connection, support for 329 scripting SHOULD NOT be part of a roaming standard. 331 5.2.2. Identification 333 A roaming standard MUST provide a standardized format for the userID and 334 realm presented to the NAS. 336 5.2.3. Verification of Identity 338 Authentication types 339 A roaming standard MUST support CHAP, and SHOULD support EAP. Due 340 to security concerns, PAP authentication SHOULD NOT be supported. 341 A possible exception is where PAP is used to support a one time 342 password or token. 344 Scalability 345 A roaming standard, once available, is likely to be widely deployed 346 on the Internet. A roaming standard MUST therefore provide suffi- 347 cient scalability to allow for the formation of roaming associa- 348 tions with thousands of ISP members. 350 RADIUS Support 351 Given the current popularity and near ubiquity of RADIUS [2,3] as 352 an authentication, authorization and accounting solution, a roaming 353 standard MUST be able to incorporate RADIUS-enabled devices within 354 the roaming architecture. It is expected that this will be accom- 355 plished by development of gateways between RADIUS and the roaming 356 standard authentication, authorization, and accounting protocol. 358 5.2.4. NAS Configuration/Authorization 360 In order to ensure compatibility with the NAS or the local network, 361 authentication/authorization proxies often will add, delete, or modify 362 attributes returned by the home authentication server. In addition, an 363 authentication proxy will often carry out resource management and policy 364 functions. As a result, a roaming standard MUST support the ability of 365 proxies to perform attribute editing and implement policy. 367 5.2.5. Address assignment/routing 369 A roaming standard MUST support dynamic address assignment. Static 370 address assignment MAY be supported, most likely via layer 2 or layer 3 371 tunneling. 373 Layer 2 tunneling protocols 374 Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold great 375 promise for the implementation of Virtual Private Networks as a 376 means for inexpensive access to remote networks. Therefore proxy 377 implementations MUST NOT preclude use of layer 2 tunneling. 379 Layer 3 tunneling protocols 380 Layer-3 tunneling protocols as embodied in Mobile IP [5], hold 381 great promise for providing "live", transparent mobility on the 382 part of mobile nodes on the Internet. Therefore, a roaming stan- 383 dard MUST NOT preclude the provisioning of Mobile IP Foreign Agents 384 or other Mobile IP functionality on the part of service providers. 386 5.2.6. Security 388 Security analysis 389 A roaming standard MUST include a thorough security analysis, 390 including a description of security threats and countermeasures. 391 This includes specification of mechanisms for fraud prevention and 392 detection. 394 Hop by hop security 395 A roaming standard MUST provide for hop-by-hop integrity protection 396 and confidentiality. This MAY be accomplished through support of 397 network layer security (IPSEC) [6]. 399 End-to-end security 400 As policy implementation and attribute editing are common in roam- 401 ing systems, proxies may need to modify packets in transit between 402 a local NAS and the home server. In order to permit authorized 403 modifications while at the same time guarding against attacks by 404 rogue proxies, it is necessary for a roaming standard to support 405 data object security. As a result, a roaming standard MUST provide 406 end-to-end confidentiality and integrity protection on an 407 attribute-by-attribute basis. However, non-repudiation is NOT a 408 requirement for a roaming standard. 410 5.3. Accounting requirements 412 Real-time accounting 413 In today's roaming implementations, real-time accounting is a prac- 414 tical necessity in order to support fraud detection and risk man- 415 agement. As a result, a roaming standard MUST provide support for 416 real-time accounting. 418 Accounting record formats 419 Today there is no proposed standard for NAS accounting, and there 420 is wide variation in the protocols used by providers to communicate 421 accounting information within their own organizations. Therefore, 422 a roaming standard MUST prescribe a standardized format for 423 accounting records. For the sake of efficiency, the record format 424 MUST be compact. 426 Extensibility 427 A standard accounting record format MUST be able to encode metrics 428 commonly used to determine the user's bill. Since these metrics 429 change over time, the accounting record format MUST be extensible 430 so as to be able to add future metrics as they come along. The 431 record format MUST support both standard metrics as well as vendor- 432 specific metrics. 434 6. References 436 [1] Aboba, B., Lu, J., Alsop, J., Ding, J., Wang, W. "Review of Roam- 437 ing Implementations", RFC 2194, September 1997 439 [2] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authenti- 440 cation Dial In User Service (RADIUS)", RFC 2138, April 1997. 442 [3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997 444 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 445 Levels", RFC 2119, March 1997 447 [5] Perkins, C., "IP Mobility Support", RFC 2002, October 1996 449 [6] Atkinson, R., "Security Architecture for the Internet Protocol", 450 RFC 1825, August 1995 452 [7] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Proto- 453 col (EAP)", RFC 2284, March 1998 455 [8] Simpson, W., "PPP Challenge Handshake Authentication Protocol 456 (CHAP)", RFC 1994, August 1996 458 [9] Lloyd, B. and Simpson, W., "PPP Authentication Protocols", RFC 459 1334, October 1992 461 [10] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 462 July 1994 464 7. Security considerations 466 This document, being a requirements document, does not have any security 467 concerns. The security requirements on protocols to be evaluated using 468 this document are mainly described in section 5.2 470 8. Acknowledgements 472 Thanks to Pat Calhoun (pcalhoun@eng.sun.com), Butch Anton 473 (butch@ipass.com) and John Vollbrecht (jrv@merit.edu) for many useful 474 discussions of this problem space. 476 9. Authors' Addresses 478 Bernard Aboba 479 Microsoft Corporation 480 One Microsoft Way 481 Redmond, WA 98052 483 Phone: 425-936-6605 484 EMail: bernarda@microsoft.com 486 Glen Zorn 487 Microsoft Corporation 488 One Microsoft Way 489 Redmond, WA 98052 490 Phone: 425-703-1559 491 EMail: glennz@microsoft.com 493 10. Expiration Date 495 This memo is filed as , and expires 496 February 7, 1999.