idnits 2.17.1 draft-ietf-dhc-aaa-requirements-00.txt: 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: ---------------------------------------------------------------------------- == 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 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. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 152: '...The DHCP server MUST be able to termi...' RFC 2119 keyword, line 176: '...local AAA server MUST support anonymou...' RFC 2119 keyword, line 194: '... - AAA MUST support message privac...' RFC 2119 keyword, line 203: '... [12], and any AAA proposal MUST solve this problem. Using public AAA...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 245 has weird spacing: '...rements for I...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'REQ' on line 80 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2002 (ref. '3') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2486 (ref. '11') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 2543 (ref. '15') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Subir Das 2 INTERNET-DRAFT Anthony McAuley 3 Internet Engineering Task Force Telcordia Technologies 4 draft-ietf-dhc-aaa-requirements-00.txt Shinichi Baba 5 Date: March 8, 2000 Yasuro Shobatake 6 Expires: August, 2000 Toshiba America Research Inc. 8 Authentication, Authorization, and Accounting Requirements for 9 Roaming Nodes using DHCP 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of sections 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The AAA working group is currently defining the requirements for 36 Authentication, Authorization, and Accounting (AAA). This draft 37 lists the AAA requirements to aid roaming nodes using a dynamic 38 address configuration protocol such as DHCP. The node may or may 39 not be using Mobile IP [3] (with co-located care-of-address) or other 40 dynamic address binding protocol. 42 1. Introduction 44 A network providing communication services to nodes from foreign 45 domains, must use Authorization, Authentication, and Accounting (AAA) 46 services [1,2]. A dynamically roaming node places stronger 47 requirements on AAA than a static node. Moreover, next generation 48 network applications will raise the requirements on IP network even 49 higher. The Mobile IP [3] Working Group is currently specifying the 50 requirements for a roaming node using Mobile IP with Foreign Agents 51 [4]. This document specifies the requirements for a roaming node who 52 obtains an address using DHCP [5] [17] or similar node configuration 53 protocol (e.g., DRCP [6]). 55 Recent drafts [7,8] specify how to add authentication to DHCP 56 messages. This allows clients to verify DHCP servers or servers to 57 verify DHCP clients. It does not, however, specify the interaction 58 with a AAA protocol to allow roaming users to access networks in 59 multiple administrative domains. 61 The document is independent of whether the roaming node uses dynamic 62 address binding. The roaming node getting an address through DHCP [5] 63 and once authenticated via AAA [1, 13,14] may also use Mobile IP with 64 co-located addresses, dynamic DNS updates [9,10], or any other 65 dynamic address binding techniques [15,16]. The document does not 66 discuss the pros and cons of how best to support roaming users, only 67 to ensure that the AAA protocol is sufficiently flexible to support 68 both nodes using Mobile IP with Foreign Agents and nodes using DHCP 69 (with or without Mobile IP). 71 Since many of the requirements for DHCP are similar to those for 72 Mobile IP with Foreign Agents, we borrow heavily from the Mobile IP 73 requirements document [3, 4]. 75 1.1 Requirements Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [REQ]. 81 2. Basic Model 83 Figure 2 shows that our general model is very much similar to that 84 described in [4]. The only change is that we do not assume the AAA 85 authentication is necessarily done in a home domain. We assume, more 86 generally, that the roaming node authentication is done in a 87 (possibly distributed) Public AAA (AAAP), which is similar to AAA 88 broker model. The reasons for using the AAAP are discussed in section 89 4. Each DHCP client might use a different AAAP that can check its 90 credentials, or they may share the same AAAP (even if they are from 91 different domains). 93 Local Domain Internet 94 +-------------+ +----------------+ 95 | +------+ | | +------+ | 96 | | AAAL | | AAA Protocol | | AAAP | | 97 | | +----------------------+ | | 98 | +---+--+ | | +------+ | 99 | | | | | 100 | | | +----------------+ 101 | | | 102 | | | 103 +--------+ | +---+---+ | 104 | DHCP | DHCP | | DHCP | | 105 | Client |-------|--| Server| | 106 +--------+ | +-------+ | AAAP = Public authority 107 | | AAAL = local authority 108 +-------------+ 110 Figure 1: AAA Servers Model 112 DHCP server does not have direct access to the data needed for 113 authentication. So it is expected that the server will consult the 114 local authority (AAAL) for verification. Since the server and the 115 local authority are in the same domain it is assumed that they will 116 have strong security associations. Alternatively, they may be 117 co-located. On the other hand, AAAL itself may not have enough 118 information stored locally to complete the transaction. However, 119 AAAL is expected to be configured with enough information to 120 negotiate the client's verification with corresponding AAAP. 121 Sometimes client may notify its own AAAP for verification via its 122 registration message (e.g., Client's NAI [11]). The local AAA and 123 public AAA should have sufficient security relationships and access 124 control so that they can negotiate the authorization and enable the 125 client to have the requested resources. Once this is over, DHCP 126 server will be notified about the successful negotiation and the 127 server can provide the requested resources to the client. If it is 128 not authorized, server will be informed to terminate the service to 129 the client. 131 3. Requirements 133 Based on the above scenarios, the following specific requirements 134 for AAA can be ascertained. 136 - Either the DHCP Server and AAAL are co-located or they share a 137 security relationship. 139 - The DHCP server should be configured to obtain authorization from 140 a trusted local AAA server (AAAL). 142 - The local authority (AAAL) has to share, or dynamically 143 establish, security relationships with public authorities (AAAP) 144 that are able to check client credentials. 146 - The client must have a security association with its public 147 authority (AAAP). 149 - Nobody can reconstruct and reuse the credentials that the client 150 uses. 152 - The DHCP server MUST be able to terminate service to the 153 client based on policy determination by the AAA server. 155 - The DHCP server should be able to handle requests for many 156 clients simultaneously. 158 - The client may resend a request if it does not get a reply in 159 some time, so the AAA entities must be designed to operate 160 correctly and efficiently with multiple requests for the same 161 client. 163 - The DHCP server has to keep state for pending client requests 164 while the local authority contacts the appropriate external 165 authority. 167 - Support replay protection and optional non-repudiation 168 capabilities for all authorization and accounting messages. 170 - AAA server need not know any IP address of the client and it 171 identifies clients by other means, e.g., Network Access 172 Identifier (NAI). 174 - Client NAI domain allows AAAL to easily determine the AAAP. 176 - The local AAA server MUST support anonymous access. 178 - There is no requirement for AAA to transport `DHCP or other 179 node configuration messages'. 181 - AAA must complete in one round trip. A major component of the 182 setup latency is the time taken to traverse the wide-area 183 Internet that is likely to separate the AAAL and the AAAP. 185 - AAA must allow a node to register once in its domain and move 186 among subnets in the same domain without requiring more AAA. 187 After the initial registration, the AAAP and AAAL would not 188 be needed. 190 - Support accounting information via AAAP servers providing 191 accounting clearinghouse and reconciliation between serving and 192 home networks. 194 - AAA MUST support message privacy and integrity. 196 4. Reasons for using Public AAA 198 AAA servers model in [4] shows a configuration in which the local 199 and the home authority have to share trust. This configuration 200 causes a quadratic growth in the number of trust relationships as 201 the number of AAA authorities (local AAA and home AAA) increases. 202 This has been identified as a problem by the roamops working group 203 [12], and any AAA proposal MUST solve this problem. Using public AAA 204 (AAAP) solves many of the scalability problems associated with 205 requiring direct business/roaming relationships between every two 206 administrative domains. A public AAA may play the role of a proxy 207 between two administrative domains which have security associations 208 with the AAAP, and relay AAA messages back and forth securely. 210 The AAAP enables the local and home domains to cooperate without 211 requiring each of the networks to have a direct business or security 212 relationship with all the other networks. Thus, AAAPs offer the 213 needed scalability for managing trust relationships between otherwise 214 independent network domains. Use of the AAAP does not preclude 215 managing separate trust relationships between domains, but it does 216 offer an alternative suitable for commercial environments. 218 5. Security Considerations 220 This draft defines the AAA requirements for roaming nodes using 221 DHCP or similar type of node configuration protocol. Since AAA is 222 security driven, most of this documents addresses the security 223 considerations AAA must make on behalf of roaming nodes using node 224 configuration protocols. 226 6. Acknowledgements 228 The requirements in section 3 were taken from a draft submitted by 229 S. Glass, S. Jacobs, and C. Perkins of the Mobile IP working group. 230 We would like to acknowledge their work. 232 The authors acknowledge the contributions of other members of the 233 ITSUMO (Internet Technologies Supporting Universal Mobile Operation) 234 team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, D. Famolari, 235 S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and 236 Toshiba America Research Incorporated (T. Kodama). 238 References 240 [1] S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, 241 B. de Bruijn, C. de Laat, M. Holdrege and D. Spence, "AAA 242 Authorizatiopn Requirements," 243 , October 1999. 245 [2] J. Arkko, "Requirements for Internet-scale Accounting 246 Management," , August, 1998. 248 [3] C. Perkins, "IP Mobility Support," RFC 2002, October 1996. 250 [4] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 251 Authorization, and Accounting Requirements," 252 , October, 1999. 254 [5] R. Droms, "Dynamic Host Configuration Protocol," Request for 255 Comments 2131, March, 1997. 257 [6] A. McAuley, S. Das, S. Baba, Y. Shobatake, "Dynamic Registration 258 and Configuration Protocol (DRCP)," , 259 October, 1999. 261 [7] R. Droms, "Authentication for DHCP Messages," , October, 1999. 264 [8] V. Gupta, "Flexible Authentication for DHCP Messages," 265 , October, 1998. 267 [9] A. Gustafsson, "A DNS RR for encoding DHCP information," 268 , October, 1999. 270 [10] M. Stapp, Y. Rekhter, "Interaction between DHCP and DNS," 271 , October, 1999. 273 [11] B. Aboba and M. A. Beadles, "The network access identifier," 274 RFC 2486, January 1999. 276 [12] B. Adoba and G. Zorn, "Criteria for evaluating roaming 277 protocols," RFC 2477, December 1998. 279 [13] J. Wang and R. Wang, "Cellular network Authentication, 280 Authorization, and Accounting requirements," 281 , October, 1999. 283 [14] M. Beadles and et.al., "Criteria for evaluating AAA protocols 284 for network access", , October 285 1999. 287 [15] H. Schulzrinne and et. al., "SIP: Session initiation protocol," 288 RFC 2543, March 1999. 290 [16] E. Wedlund and H. Schulzrinne, "Mobility support using SIP", 291 Proc. The second ACM International workshop on Wireless Mobile 292 Multimedia, ACM/IEEE, pp 76-82, August, 1999. 294 [17] A. McAuley, S. Das, S. Baba, Y. Shobatake, " Requirements for 295 Extending DHCP into New Environments," 296 , March, 2000. 298 7. Authors' Addresses 300 Subir Das 301 MCC 1D210R, Telcordia 302 445 South Street, Morristown, NJ 07960 303 Phone: +1 973 829 4959 304 email: subir@research.telcordia.com 305 Anthony J. McAuley 306 MCC 1C235B, Telcordia 307 445 South Street, Morristown, NJ 07960 308 Phone: +1 973 829 4698 309 email: mcauley@research.telcordia.com 311 Shinichi Baba 312 Toshiba America Research Inc. 313 P.O. Box 136 Convent Station, NJ 07961-0136 314 Phone: +1 973 829 4759 315 email: sbaba@tari.toshiba.com 317 Yasuro Shobatake 318 Toshiba America Research Inc. 319 P.O. Box 136 Convent Station, NJ 07961-0136 320 Phone: +1 973 829 3951 321 email: yasuro.shobatake@toshiba.co.jp