idnits 2.17.1 draft-tsirtsis-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? == 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 344 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. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 2000) is 8746 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC-AAA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MOBILEIP-AAA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC-AGENT' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC-ENHANCE' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC-AUTH' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT George Tsirtsis 2 Expires in November 2000 Jerome Privat 3 BT 4 May 2000 6 Triggering AAA from DHCP Relay Agents 7 draft-tsirtsis-dhc-aaa-ra-00.txt 9 Abstract 11 Recently there has been interest in using DHCP for configuring 12 clients accessing the Internet through some form of high-speed 13 access technology such as cable or ADSL [DHC-AGENT]. In addition, 14 although DHCP was initially designed for configuring fixed hosts, 15 proposals are being made to enhance DHCP to support roaming/mobile 16 clients [DHC-ENHANCE]. These two trends have put in evidence the 17 need for a coupling between AAA and DHCP. Some initial requirements 18 for DHCP/AAA have been proposed in [DHC-AAA]. 19 This document proposes a different model in which AAA procedures are 20 invoked not from a DHCP server but from a DHCP relay agent to make 21 sure that ALL the Internet Access features supported by the PPP model 22 can be replicated in a DHCP based Internet Access environment. 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet- Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 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 51 [DHC-AGENT]. In addition, although DHCP was initially designed for 52 configuring fixed hosts, proposals are being made to enhance DHCP 53 to support roaming/mobile clients [DHC-ENHANCE]. These two trends 54 have put in evidence the need for a coupling between AAA and DHCP. 55 Some initial requirements for DHCP/AAA have been proposed in 56 [DHC-AAA]. 58 This document proposes a different model in which AAA procedures are 59 invoked not from a DHCP server but from a DHCP relay agent. The 60 reason is that if DHCP is to replace PPP in some environments, there 61 will be a strong requirement to make sure that ALL the Internet 62 Access features supported by the PPP model can be replicated in 63 DHCP-based Internet Access scenarios. 65 However, there are fundamental differences between PPP-based and 66 DHCP-based Internet access. On the one hand, PPP terminates on the 67 Access Router (or Network Access Server-NAS) which becomes the Policy 68 Enforcement Point between the network and the client. Typically the 69 NAS is at the same time a PPP terminator, AAA client and possibly 70 DHCP relay agent. This is a very powerful model since the NAS is the 71 most sensible point at which to apply services such as Accounting, 72 Resource Allocation, Authentication and many others. 74 On the other hand, DHCP runs from the client to the DHCP server which 75 is inside the Access Network and possibly several routers away from 76 the Access Router. In the absence of PPP, the Access Router, as it 77 stands at the moment, does not have a way to trigger the AAA 78 functions that PPP based networks have. Although, DHCP relay agents 79 will typically be operating in the Access Routers, these are 80 considered to be very simple, and most importantly transparent, 81 devices. 83 In this document, we propose, that DHCP relay agents be used as AAA 84 triggers intercepting and conveying relevant information from clients 85 to AAA servers. This allows the PPP Internet Access model to be 86 replicated in a non-PPP environment. 88 2. Currently proposed model: AAA from DHCP server 90 2.1 Description 92 The currently proposed model for DHCP based roaming and mobile IP as 93 described in [DHC-AAA] and [MOBILEIP-AAA] is shown in Figure 1. In 94 this model the AAA procedure is invoked from the DHCP server. 96 Local Domain Internet 97 +-------------+ +----------------+ 98 | +------+ | | +------+ | 99 | | AAAL | | AAA Protocol | | AAAP | | 100 | | +----------------------+ | | 101 | +---+--+ | | +------+ | 102 | | | | | 103 | | | +----------------+ 104 | | | 105 | | | 106 +--------+ | +---+---+ | 107 | DHCP | DHCP | | DHCP | | 108 | Client |-------|--| Server| | 109 +--------+ | +-------+ | AAAP = Public authority 110 | | AAAL = local authority 111 +-------------+ 113 Figure 1: DHCP/AAA Current Model 115 Even with the use of a DHCP Relay Agent the above picture does not 116 change fundamentally but only becomes Figure 2. 118 Local Domain Internet 119 +-------------+ +----------------+ 120 | +------+ | | +------+ | 121 | | AAAL | | AAA Protocol | | AAAP | | 122 | | +----------------------+ | | 123 | +---+--+ | | +------+ | 124 | | | | | 125 | | | +----------------+ 126 | | | 127 | | | 128 +------+ +-----+ | +---+---+ | 129 |DHCP | |DHCP | | | DHCP | | 130 |Client|--|Relay|--|--| Server| | 131 +------+ +-----+ | +-------+ | AAAP = Public authority 132 | | AAAL = local authority 133 +-------------+ 134 Figure 2: DHCP/AAA Servers Model with Relay Agent 136 2.2 Limitations 138 The above model is fine for traditional use of DHCP in corporate and 139 other such networks where a level of trust already exists between the 140 clients and the network. DHCP is, however, increasingly being used in 141 other environments such as residential access over Cable modems or 142 possibly xDSL and mobile networks. 144 These new types of applications for DHCP have different requirements 145 and characteristics in terms of security and trust. Before DHCP was 146 considered in the above types of networks, PPP had been applied 147 successfully providing similar functionality. PPP has a fundamental 148 difference to DHCP in the way it treats new clients. All checks 149 happen from the Access Point, i.e: the first point of attachment for 150 the client, for example the NAS. Figure 3 shows this PPP model. 152 Local Domain Internet 153 +-------------+ +----------------+ 154 | +------+ | | +------+ | 155 | | AAAL | | AAA Protocol | | AAAP | | 156 | | +----------------------+ | | 157 | +---+--+ | | +------+ | 158 | | | | | 159 | | | +----------------+ 160 | | | 161 | | | 162 +--------+ | +---+---+ | 163 | PPP | PPP | |NAS/AAA| | 164 | Client |-------|--| Client| | 165 +--------+ | +-------+ | AAAP = Public authority 166 | | AAAL = local authority 167 +-------------+ 169 Figure 3: PPP Model 171 3. New model: AAA from DHCP Relay Agent 173 3.1 Description 175 If DHCP is to replace PPP in some environments, a similar model is 176 needed so the client details are checked on the first node of 177 attachment (CMTS, DSLAM, etc.). This would produce the layout of 178 Figure 4. This is consistent with the approach followed in 179 [DHC-AGENT] in that the access point is the first trusted point in 180 the provider network. 182 Local Domain Internet 183 +-------------+ +----------------+ 184 | +------+ | | +------+ | 185 | | AAAL | | AAA Protocol | | AAAP | | 186 | | +----------------------+ | | 187 | +---+--+ | | +------+ | 188 | | | | | 189 | | | +----------------+ 190 | | | 191 | | +----------------+ 192 +--------+ | +---+---+ +--------+ | 193 | DHCP | DHCP | | DHCP | | DHCP | | 194 | Client |-------|--| Relay |-------| Server | | 195 +--------+ | +-------+ +--------+ | 196 | | 197 +------------------------------+ 199 Figure 4: DHCP Relay Agent Model 201 3.2 Advantages 203 The major benefit from this new model is the ability to enforce 204 policy. In Figure 2, the DHCP server can only Authenticate the client 205 details but not much else. In the PPP model, because the AAA check 206 takes place at the NAS, it is possible to get detailed, customized 207 configuration for the client and dynamically configure an access list 208 on the NAS's interface to restrict/allow certain functions and 209 resources. 211 It could be argued that this customization is also possible in the 212 currently proposed model (AAA from DHCP server). Once a user identity 213 has been established using AAA, looking up access control lists and 214 storing usage information could be done using LDAP or other existing 215 means to communicate with databases/directories. However there is 216 value for a provider in reusing as much as possible the same existing 217 AAA mechanisms as currently deployed. 219 4. Impact on DHCP 221 4.1 Authenticating a user 223 Discussion: 224 In order to authenticate a user, a AAA server needs to be passed some 225 information of the form username/password. How does the AAA client 226 get this information? Does it get it through DHCP (either through 227 existing options or through a new one) or does it get it through a 228 separate challenge sent by the access point? Note that once an access 229 point gets the username/password information, it can use it for the 230 Agent Remote ID sub-option proposed in [DHC-AGENT]. 232 4.2 Relay Agent behaviour 234 Discussion: 235 Clearly, the relay agent behaviour needs to be specified when 236 triggering AAA from DHCP messages. 237 The relay agent needs to know: 238 - Which DHCP message triggers a AAA check. 239 - Which DHCP message triggers the download of policies (such as an 240 access list) on the access point? Note that in order to install 241 access lists, some information is required such as the IP address 242 given to the client. 243 - What action to take if no response is received from the AAA server 244 (timer, notification sent back to client). 246 The Relay agent must be able to terminate service to a client if not 247 authorized by a AAA server. 249 5. Security considerations 251 Authentication is presently being added to the DHCP protocol 252 [DHC-AUTH]. This allows DHCP clients and servers to authenticate 253 each other. Our purpose differs in that we want to authenticate and 254 authorize a user before he accesses a provider network, to apply 255 policy to customize this access connection and to account for the 256 service. However it may be possible to re-use some elements of this 257 authentication framework when coupling AAA to DHCP. 259 6. Acknowledgements 261 The authors would like to thank their colleague Alan O'Neill, who 262 initiated this work. 264 7. References 266 [DHC-AAA] S. Das, A. McAuley, Telcordia, S. Baba, Y. Shobatake, 267 Toshiba, "Authentication, Authorization, and Accounting Requirements 268 for Roaming Nodes using DHCP", 269 , March 2000 271 [MOBILEIP-AAA], S. Glass, Sun, T. Hiller, Lucent, S. Jacobs, GTE, 272 C. Perkins, Nokia, "Mobile IP Authentication, Authorization, and 273 Accounting Requirements", , 274 March 2000. 276 [DHC-AGENT] M. Patrick, Motorola, "DHCP Relay Agent Information 277 Option", , May 2000 279 [DHC-ENHANCE], A. McAuley, S. Das, Telcordia, S. Baba, Y. Shobatake 280 Toshiba, "Requirements for Extending DHCP into New Environments", 281 , March 2000 283 [DHC-AUTH] R. Droms, Bucknell University, "Authentication for DHCP 284 Messages", , October 1999 286 8. Authors 288 George Tsirtsis 289 Internet Futures Group 290 Advanced Communications Research 291 BT 292 Phone: +44 20 88260073 293 Email: george.tsirtsis@bt.com 295 Jerome Privat 296 BT Advanced Communications Technology Centre 297 Adastral Park, Martlesham Heath, IP5 3RE 298 UK 299 Phone: +44 1473 606304 300 Email: jerome.privat@bt.com 302 Full Copyright Statement 304 Copyright (C) The Internet Society (1999). All Rights Reserved. 306 This document and translations of it may be copied and furnished to 307 others, and derivative works that comment on or otherwise explain it 308 or assist in its implementation may be prepared, copied, published and 309 distributed, in whole or in part, without restriction of any kind, 310 provided that the above copyright notice and this paragraph are 311 included on all such copies and derivative works. However, this 312 document itself may not be modified in any way, such as by removing 313 the copyright notice or references to the Internet Society or other 314 Internet organizations, except as needed for the purpose of developing 315 Internet standards in which case the procedures for copyrights defined 316 in the Internet Standards process must be followed, or as required to 317 translate it into languages other than English. 319 The limited permissions granted above are perpetual and will not be 320 revoked by the Internet Society or its successors or assigns. 322 This document and the information contained herein is provided on an 323 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 324 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 325 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 326 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 327 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.