idnits 2.17.1 draft-ietf-dhc-aaa-ra-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. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 392 lines 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 ([DHC-ENHANCE], [DHC-AAA], [DHC-AGENT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 2001) is 8499 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) -- Looks like a reference, but probably isn't: '1' on line 15 -- Possible downref: Normative reference to a draft: ref. 'DHC-AAA' ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. 'MOBILEIP-AAA') -- Unexpected draft version: The latest known version of draft-ietf-dhc-agent-options is -11, but you're referring to -12. -- Possible downref: Normative reference to a draft: ref. 'DHC-ENHANCE' == Outdated reference: A later version (-16) exists of draft-ietf-dhc-authentication-15 Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC WG G. Tsirtsis 2 Flarion Technologies 3 Internet Draft J. Privat 4 Northstream 5 Title: draft-ietf-dhc-aaa-ra-00.txt 6 Expires : June 2001 January 2001 8 Triggering AAA from DHCP Relay Agents 9 draft-ietf-dhc-aaa-ra-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 Recently there has been interest in using DHCP for configuring 31 clients accessing the Internet through some form of high-speed access 32 technology such as cable or ADSL [DHC-AGENT]. In addition, although 33 DHCP was initially designed for configuring fixed hosts, proposals 34 are being made to enhance DHCP to support roaming/mobile clients 35 [DHC-ENHANCE]. These two trends have put in evidence the need for a 36 coupling between AAA and DHCP. Some initial requirements for DHCP/AAA 37 have been proposed in [DHC-AAA]. 39 This document proposes a different model in which AAA procedures are 40 invoked not from a DHCP server but from a DHCP relay agent to make 41 sure that ALL the Internet Access features supported by the PPP model 42 can be replicated in a DHCP based Internet Access environment. 44 Tsirtsis, Privat 1 45 1. Introduction 47 Traditionally DHCP has mainly been used in intranets such as 48 corporate or campus networks. Recently there has been interest in 49 using DHCP for configuring clients accessing the Internet through 50 some form of high-speed access technology such as cable or ADSL [DHC- 51 AGENT]. 53 In addition, although DHCP was initially designed for configuring 54 fixed hosts, proposals are being made to enhance DHCP to support 55 roaming/mobile clients [DHC-ENHANCE]. These two trends have put in 56 evidence the need for a coupling between AAA and DHCP. Some initial 57 requirements for DHCP/AAA have been proposed in [DHC-AAA]. 59 This document proposes a different model in which AAA procedures are 60 invoked not from a DHCP server but from a DHCP relay agent. The 61 reason is that if DHCP is to replace PPP in some environments, there 62 will be a strong requirement to make sure that ALL the Internet 63 Access features supported by the PPP model can be replicated in DHCP- 64 based Internet Access scenarios. 66 However, there are fundamental differences between PPP-based and 67 DHCP-based Internet access. 68 On the one hand, PPP terminates on the Access Router (or Network 69 Access Server-NAS) which becomes the Policy Enforcement Point between 70 the network and the client. Typically the NAS is at the same time a 71 PPP terminator, AAA client and possibly DHCP relay agent. This is a 72 very powerful model since the NAS is the most sensible point at which 73 to apply services such as Accounting, Resource Allocation, 74 Authentication and many others. 75 On the other hand, DHCP runs from the client to the DHCP server which 76 is inside the Access Network and possibly several routers away from 77 the Access Router. In the absence of PPP, the Access Router, as it 78 stands at the moment, does not have a way to trigger the AAA 79 functions that PPP based networks have. Although, DHCP relay agents 80 will typically be operating in the Access Routers, these are 81 considered to be very simple, and most importantly transparent, 82 devices. 84 We propose in this document that DHCP relay agents be used as AAA 85 triggers intercepting and conveying relevant information from clients 86 to AAA servers. This allows the PPP Internet Access model to be 87 replicated in a non-PPP environment. 89 Tsirtsis, Privat 2 90 2. Currently proposed model: AAA from DHCP server 92 2.1 Description 94 The currently proposed model for DHCP based roaming and mobile IP as 95 described in [DHC-AAA] and [MOBILEIP-AAA] is shown in Figure 1. In 96 this model the AAA procedure is invoked from the DHCP server. 98 Local Domain Internet 99 +-------------+ +----------------+ 100 | +------+ | | +------+ | 101 | | AAAL | | AAA Protocol | | AAAP | | 102 | | +----------------------+ | | 103 | +---+--+ | | +------+ | 104 | | | | | 105 | | | +----------------+ 106 | | | 107 | | | 108 +--------+ | +---+---+ | 109 | DHCP | DHCP | | DHCP | | 110 | Client |-------|--| Server| | 111 +--------+ | +-------+ | AAAP = Public authority 112 | | AAAL = local authority 113 +-------------+ 115 Figure 1: DHCP/AAA Current Model 117 Even with the use of a DHCP Relay Agent the above picture does not 118 change fundamentally but only becomes Figure 2. 120 Local Domain Internet 121 +-------------+ +----------------+ 122 | +------+ | | +------+ | 123 | | AAAL | | AAA Protocol | | AAAP | | 124 | | +----------------------+ | | 125 | +---+--+ | | +------+ | 126 | | | | | 127 | | | +----------------+ 128 | | | 129 | | | 130 +------+ +-----+ | +---+---+ | 131 |DHCP | |DHCP | | | DHCP | | 132 |Client|--|Relay|--|--| Server| | 133 +------+ +-----+ | +-------+ | AAAP = Public authority 134 | | AAAL = local authority 135 +-------------+ 136 Figure 2: DHCP/AAA Servers Model with Relay Agent 138 Tsirtsis, Privat 3 139 2.2 Limitations 141 The above model is fine for traditional use of DHCP in corporate and 142 other such networks were a level of trust already exists between the 143 clients and the network. DHCP is, however, increasingly being used in 144 other environments such as residential access over Cable modems or 145 possibly xDSL and mobile networks. 146 These new types of applications for DHCP have different requirements 147 and characteristics in terms of security and trust. Before DHCP was 148 considered in the above types of networks, PPP had been applied 149 successfully providing similar functionality. PPP has a fundamental 150 difference to DHCP in the way it treats new clients. All checks 151 happen from the Access Point, i.e: the first point of attachment for 152 the client, for example the NAS. Figure 3 shows this PPP model. 154 Local Domain Internet 155 +-------------+ +----------------+ 156 | +------+ | | +------+ | 157 | | AAAL | | AAA Protocol | | AAAP | | 158 | | +----------------------+ | | 159 | +---+--+ | | +------+ | 160 | | | | | 161 | | | +----------------+ 162 | | | 163 | | | 164 +--------+ | +---+---+ | 165 | PPP | PPP | |NAS/AAA| | 166 | Client |-------|--| Client| | 167 +--------+ | +-------+ | AAAP = Public authority 168 | | AAAL = local authority 169 +-------------+ 171 Figure 3: PPP Model 173 3 New model: AAA from DHCP Relay Agent 175 3.1 Description 177 If DHCP is to replace PPP in some environments, a similar model is 178 needed so the client details are checked on the first node of 179 attachment (CMTS, DSLAM, etc...). This would produce the layout of 180 Figure 4. This is consistent with the approach followed in [DHC- 181 AGENT] in that the access point is the first trusted point in the 182 provider network. 184 Tsirtsis, Privat 4 185 Local Domain Internet 186 +-------------+ +----------------+ 187 | +------+ | | +------+ | 188 | | AAAL | | AAA Protocol | | AAAP | | 189 | | +----------------------+ | | 190 | +---+--+ | | +------+ | 191 | | | | | 192 | | | +----------------+ 193 | | | 194 | | +----------------+ 195 +--------+ | +---+---+ +--------+ | 196 | DHCP | DHCP | | DHCP | | DHCP | | 197 | Client |-------|--| Relay |-------| Server | | 198 +--------+ | +-------+ +--------+ | 199 | | 200 +------------------------------+ 202 Figure 4: DHCP Relay Agent Model 204 3.2 Advantages 206 The major benefit from this new model is the ability to enforce 207 policy. In Figure 2, the DHCP server can only Authenticate the client 208 details but not much else. In the PPP model, because the AAA check 209 takes place at the NAS, it is possible to get detailed, customized 210 configuration for the client and dynamically configure an access list 211 on the NAS's interface to restrict/allow certain functions and 212 resources. 213 It could be argued that this customization is also possible in the 214 currently proposed model (AAA from DHCP server). Once a user identity 215 has been established using AAA, looking up access control lists and 216 storing usage information could be done using LDAP or other existing 217 means to communicate with databases/directories. However there is 218 value for a provider in reusing as much as possible the same existing 219 AAA mechanisms as currently deployed. 221 4. Impact on DHCP 223 4.1 Authenticating a user 225 Discussion: 226 In order to authenticate a user, a AAA server needs to be passed some 227 information of the form username/password. How does the AAA client 228 get this information? Does it get it through DHCP (either through 229 existing options or through a new one) or does it get it through a 230 separate challenge sent by the access point? 231 Note that once an access point gets the username/password 232 information, it can use it for the Agent Remote ID sub-option 233 proposed in [DHC-AGENT]. 235 Tsirtsis, Privat 5 236 4.2 Relay Agent behavior 238 Discussion: 239 Clearly, the relay agent behavior needs to be specified when 240 triggering AAA from DHCP messages. 241 The relay agent needs to know: 242 Which DHCP message triggers a AAA check. 243 Which DHCP message triggers the download of policies (such as an 244 access list) on the access point? Note that in order to install 245 access lists, some information is required such as the IP address 246 given to the client. 247 What action to take if no response is received from the AAA server 248 (timer, notification sent back to client). 250 The Relay agent must be able to terminate service to a client if not 251 authorized by a AAA server. 253 5 Security considerations 255 Authentication is presently being added to the DHCP protocol [DHC- 256 AUTH]. This allows DHCP clients and servers to authenticate each 257 other. Our purpose differs in that we want to authenticate and 258 authorize a user before he accesses a provider network, to apply 259 policy to customize this access connection and to account for the 260 service. However it may be possible to re-use some elements of this 261 authentication framework when coupling AAA to DHCP. 263 6. Acknowledgements 265 The authors would like to thank Alan O'Neill, who initiated this 266 work. 268 7. References 270 [DHC-AAA] draft-ietf-dhc-aaa-requirements-00.txt 271 [MOBILEIP-AAA] RFC 2977, Mobile IP Authentication, Authorization and 272 Accounting Requirements 273 [DHC-AGENT] draft-ietf-dhc-agent-options-12.txt 274 [DHC-ENHANCE] draft-ietf-dhc-enhance-requirements-00.txt 275 [DHC-AUTH] draft-ietf-dhc-authentication-15.txt 277 8. Authors 279 George Tsirtsis 280 Flarion Technologies 281 Phone: +44 20 88260073 282 Email: G.Tsirtsis@Flarion.com 284 Tsirtsis, Privat 6 285 Jerome Privat 286 Northstream 287 Phone: +33 4 97 23 40 45 288 Email: jerome.privat@northstream.se 290 Copyright Statement 292 Copyright (c) The Internet Society (1999). All Rights Reserved. 293 This document and translations of it may be copied and furnished to 294 others, and derivative works that comment on or otherwise explain it 295 or assist in its implementation may be prepared, copied, published 296 and distributed, in whole or in part, without restriction of any 297 kind, provided that the above copyright notice and this paragraph are 298 included on all such copies and derivative works. However, this 299 document itself may not be modified in any way, such as by removing 300 the copyright notice or references to the Internet Society or other 301 Internet organizations, except as needed for the purpose of 302 developing Internet standards in which case the procedures for 303 copyrights defined in the Internet Standards process must be 304 followed, or as required to translate it into languages other than 305 English. 307 The limited permissions granted above are perpetual and will not be 308 revoked by the Internet Society or its successors or assigns. 310 This document and the information contained herein is provided on an 311 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 312 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 313 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 314 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 315 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 Tsirtsis, Privat 7