idnits 2.17.1 draft-ietf-dhc-dhcproam-00.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): ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- ** 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 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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. 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 (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) -- Missing reference section? '1' on line 15 looks like a reference -- Missing reference section? '2' on line 47 looks like a reference -- Missing reference section? '3' on line 156 looks like a reference -- Missing reference section? '4' on line 180 looks like a reference -- Missing reference section? '5' on line 80 looks like a reference -- Missing reference section? '6' on line 154 looks like a reference -- Missing reference section? '7' on line 331 looks like a reference -- Missing reference section? '8' on line 216 looks like a reference -- Missing reference section? '9' on line 244 looks like a reference -- Missing reference section? '10' on line 301 looks like a reference -- Missing reference section? '11' on line 307 looks like a reference -- Missing reference section? '12' on line 316 looks like a reference -- Missing reference section? '13' on line 381 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-ietf-dhc-dhcproam-00.txt B. Mukherjee 2 Internet Draft B. Gage 3 Y. Liu 4 Nortel Networks 6 February 2001 8 Extensions to DHCP for Roaming Users 9 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 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 documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to 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/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Abstract 33 This draft defines enhancements to DHCP so that it can be used by 34 access networks as an initial configuration protocol for nomadic 35 users. The authentication mechanism described here interacts with 36 existing public Authentication, Authorization, and Accounting (AAA) 37 mechanisms, thus enabling per customer authentication and 38 authorization across multiple domains. In addition, we describe a 39 mechanism that enables the client to authenticate the network to 40 prevent attacks on an end host from a bogus network access point. 42 2. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC-2119 [2]. 48 3. Introduction 49 Providing authenticated IP access to subscribers across 50 administrative domains is expected to be a vital functionality of 51 next generation access networks. Such access networks are expected 52 to perform authentication, authorization, accounting (AAA) [3] in 53 addition to IP parameter configuration for its subscribers. The 54 mechanisms described here address the requirements for accessing 55 these networks in a flexible and extensible manner using the 56 existing AAA infrastructure to perform the actual authentication. 57 Similar motivations were expressed in proposing requirements for 58 extending DHCP to new environments [4]. We expect that the proposed 59 mechanisms will allow DHCP to be used as a secure yet easy to 60 administer initial configuration protocol in commercial access 61 networks as opposed to its present usage as means of configuring a 62 pool of trusted hosts in a LAN. 64 3.2. Overview 66 This document defines mechanisms for authentication in access 67 networks by means of DHCP. In order to be authorized for using the 68 access network, the user must submit credentials via DHCP 69 authentication messages. In response, the access network may 70 indicate that a user has been authorized by providing configuration 71 parameters to the user's mobile host. The user may also verify the 72 access network's credentials as a part of the process. The 73 authentication messages also provide a framework for negotiating 74 other parameters, some of which may aid in enhancing the security of 75 the system. 77 Any proposed security mechanism should allow flexible authentication 78 between the network and its subscribers with scope for negotiation 79 about the mechanisms to be used and the type of ciphers (e.g., ssl 80 handshakes [5]). This is because the networks and their users may 81 support only a few of the possible wide range of security mechanisms 82 available. This may be due to internal constraints of the hosts 83 (e.g., CPU cycles may be a bottleneck in case of a mobile user) or 84 the security level the hosts desire (e.g., the network may only 85 allow users that perform per message authentication). Furthermore no 86 assumptions can be made about the local security requirements of 87 visited domains. Thus a flexible mechanism that allows the security 88 parameters to be negotiated and established is desirable. The 89 security mechanisms defined here can be used to create trust 90 relationships between the network and the client that may be used 91 then for accountable usage of the network resources. 93 4. Network Model 95 Throughout this document we use the example of an access network in 96 order to demonstrate how the authentication additions in DHCP may be 97 of use in new environments. The model of the network used by this 98 draft is depicted in the Figure 1 below. This is similar to the 99 model described in the draft on AAA requirements for DHCP [3]. The 100 model assumes that the users may roam and thus their initial 101 interaction with the accessed network is overseen by a public AAA 102 mechanism. The public AAA infrastructure consists of local AAA 103 authorities in each of the access networks. These local AAA servers 104 communicate among each other through a hierarchy of public AAA 105 servers, and security associations exist between the local AAA 106 server and the DHCP servers. The public AAA servers have inter 107 domain security associations through the public AAA servers that 108 allow them to authenticate users from visited domains. Thus upon 109 presenting the right information a user can authenticate himself to 110 a visited network, obtain the right levels of authorization and at 111 the same time be accountable for the use of the network. This model 112 allows the network access provider to leverage the existing AAA 113 mechanisms to perform user authentication and accounting in a 114 scalable manner across domains instead of using localized 115 mechanisms. 117 Subscriber Visited Domain Home Domain 118 +-------------+ +-------------+ 119 | +------+ | | +------+ | 120 | | AAAL | | | | AAAL | | 121 | | +---+--------+--+ | | 122 | +---+--+ | | +------+ | 123 | | | | | 124 | | | +-------------+ 125 | | | 126 | | | 127 +-------+ +------+ +--+---+ | 128 |DHCP | |DHCP | |DHCP | | 129 |Client |---+Relay +-+Server| | 130 +-------+ +------+ +------+ | 131 | | AAAL = local authority 132 +-------------+ 134 Figure 1: DHCP's interaction with AAA 136 5. Related Work 138 The DHCP working group of IETF has in the past expressed the need 139 for DHCP to support AAA functions [3] and be extensible to different 140 environments than ethernet LANs [4]. These are the principal 141 motivations behind our work. 143 5.1 Requirements for using DHCP in new environments 144 The draft [3] had proposed that DHCP use the public AAA server 145 infrastructure to perform AAA for roaming nodes and had set out the 146 requirements for the same. Leveraging the AAA infrastructure 147 provides a network service provider with a scalable way of ensuring 148 access security because it does not require every DHCP server to 149 have a pre-established security association with every DHCP client 150 it may ever talk to. Using the public AAA infrastructure, the DHCP 151 servers will be able to provide access to nodes from visited domains 152 and bill them through their local service providers. Most major ISPs 153 presently use AAA servers which support RADIUS or TACACS+ for 154 customer accounting [6]. In this draft we describe mechanisms that 155 allow DHCP to extensibly interface with this AAA infrastructure thus 156 meeting the requirements set out by the requirements draft [3]. 158 5.2 Mobile IP and PPP 160 There are other commonly used protocols like PPP and mobile IP, 161 which are used for related functions. We contend that none of the 162 above protocols are as suited for initial registration and 163 configuration as DHCP. For instance, PPP's registration model 164 assumes a point-to-point connection and is requires explicit link 165 configuration before entering into IP authentication and 166 configuration. This leads to considerable delay and overhead in 167 providing access to the mobile host. Moreover when the host roams 168 the physical layer parameters may change and may cause PPP to 169 restart configuration to reinitialize its link layer. Mobile IP 170 based registration depends on the availability of the 'home-agent' 171 and is tied in to that particular mobility solution. New generations 172 of wireless networks may use and deploy several other types of 173 mobility solutions. Thus there exists the need for a general-purpose 174 protocol for registration and configuration that is not tied in to 175 other functions or environments. DHCP is a natural choice because it 176 exclusively deals with registration and configuration of nodes, 177 independent of other functions being handled in a particular 178 scenario. The draft [4] argues in favor of using DHCP as a general- 179 purpose registration and configuration mechanism. In our proposal we 180 address several of the requirements listed in this draft[4]. 182 5.2. DHCP message authentication option. 184 The DHC WG has produced a draft that describes an authentication 185 method for DHCP messages [7]. This involves a replay detection 186 method as well as a keyed hash that allows the receiver of the 187 message to authenticate the source. The mechanism relies on a shared 188 secret between the two negotiating authorities. For the case of 189 servers providing service to local clients, the above mechanism may 190 be sufficient. But in the more general case of the clients roaming 191 across domains it is not possible to create all the possible key 192 associations before hand. Possible solutions to this problem were 193 discussed in the DHC WG meeting on June 1998. It may be possible to 194 use the public key infrastructure to authenticate the client and the 195 server and then use Diffie-Hellman to generate a shared secret that 196 can then be used to authenticate messages. But a potential problem 197 is that an uninitialized client may not be able to contact a trusted 198 PKI node, resulting in an asymmetrical security relationship against 199 the client. For instance, the server's certificate may have been 200 revoked by the PKI authority and the client has no means of finding 201 that out. In this document, the authentication mechanism leverages 202 the AAA infrastructure to not only authenticate the client and the 203 server in a symmetric fashion, but also to allow the network to 204 initiate the AAA functions at the same time. In addition, the extra 205 set of messages and the state allow the use of additional security 206 mechanisms, like re-keying, that cannot be completed by piggybacking 207 on the present set of DHCP messages. Another proposal was to create 208 a IPSEC security association between the client and the server. 209 Setting up a valid security association with an uninitialized client 210 may not be possible without a valid IP address and a configured 211 stack. 213 5.3. Dynamic Registration and Configuration Protocol 215 Another protocol, called Dynamic Registration and Configuration 216 Protocol (DRCP)[8], was proposed in order to address the need for 217 new features in a registration and configuration framework like 218 DHCP. However DRCP requires every client to be a router. The DRCP 219 protocol allows the servers to send advertisement messages that 220 allow the clients to send discover messages to the servers using 221 unicast. The protocol however does not specify any mechanisms for 222 performing AAA functions or security mechanisms. 224 6. DHCP with Extensible Authentication 226 Adding authentication to DHCP allows the client and the server to 227 establish mutual trust before configuration is effected. From the 228 perspective of an access network, authentication mechanisms in DHCP 229 allow easy configuration of subscriber devices as well as protection 230 against certain theft of service attacks. A simple approach to 231 prevent unauthorized access is that the configuration of the mobile 232 host be completed only after the user is authenticated. The 233 underlying assumption being that the configuration step is the one 234 that allows a client to act as a fully functional host and access 235 the network and its resources, and if this step fails to complete 236 the mobile will be incapable of using the network. The threat 237 scenario that this addresses is when a user attempts to access the 238 IP services of the network without presenting valid credentials 239 (e.g., user-id or password). 241 However the authentication mechanism used by the access networks 242 must be scalable as each of the access networks are expected to be 243 extensive. Thus pre-establishing security association between every 244 client and the DHCP servers[9] in the access network may not be a 245 viable option. In addition, the home and visited systems are 246 expected to interact with each other in order to provide access to 247 roaming users of other access networks. This would mean that for 248 visiting users the access network would need a mechanism to create a 249 security association between the users home domain and itself. 251 From the perspective of the subscriber, DHCP should allow access 252 across different service provider domains. From the perspective of 253 the service provider there is a need for an authentication mechanism 254 in order to provide service to subscribers roaming from other 255 networks. 257 This document describes an optional extension to the DHCP protocol 258 to include an authentication phase and to add authentication 259 messages to DHCP. To support this option, the DHCP client must be 260 modified to include a new state and to send new messages and options 261 for authentication. The DHCP relay agent may remain the same, and 262 does not need to be altered for the authentication phase. The DHCP 263 server must also be modified to process the DHCP authentication 264 messages and to forward the required messages to the AAA components. 266 6.1. Authentication Messages and Options 268 This option adds two new authentication messages to the set of 269 existing DHCP messages: 271 DHCPAUTHREQ Request for authentication information (e.g. request 272 for challenge response). 273 DHCPAUTHRESP Response to a DHCPAUTHREQ 275 The value of message type for new messages is left as TBD until 276 assigned by IANA. 278 The messages are generic in nature and thus allow the DHCP server 279 and client to establish the required credentials using any 280 authentication protocol they predetermine or negotiate. The 281 authentication phase may be completely skipped to remain backward 282 compatible but the DHCP server may enforce a policy that makes 283 authentication mandatory for certain (groups of) mobiles. The new 284 messages function as means of transporting authentication 285 information to and from the network's AAA mechanisms. In doing so we 286 are able to leverage the existing AAA infrastructure to perform 287 inter-domain authentication and authorization. 289 This document defines new message types for authentication, as 290 opposed to piggybacking security information upon existing messages, 291 in order to make the process flexible and extensible. For example, 292 there are instances like the challenge-response protocols where the 293 present sequences of DHCP messages are unable to fulfill the 294 functionality. In addition challenges for re-keying in mid-session 295 cannot be fitted in the existing messages without causing the client 296 to restart the configuration procedure. The separate messages also 297 allow the authentication protocol to be symmetrical, allowing the 298 server to authenticate the client and the client, if necessary, to 299 authenticate the server. The need to be extensible was also 300 propounded in other initial access protocols like PPP, which itself 301 has an extensible authentication protocol [10]. 303 Several new options are defined to carry authentication information 304 within the DHCPAUTHREQ and DHCPAUTHRESP messages as well as in other 305 DHCP messages like DHCPREQUEST and DHCPACK. The client uses the 306 DHCPREQUEST message to present its Network Access Identifier 307 (NAI)[11] and to request the use of an (or possibly a set of) 308 authentication mechanism by setting the appropriate option fields. 309 The server can then query its local AAA mechanism about the security 310 parameters supported for the given NAI. The DHCP server then can use 311 the authentication request message (DHCPATHREQ) to ask the client to 312 present it with authentication information that will be relayed on 313 to the AAA mechanism. The option fields are thus used to indicate 314 the choice when negotiating and then to carry actual data during the 315 security exchange. The authentication mechanisms may be a challenge 316 response handshake protocol (CHAP) [12], digital signature, plain 317 password etc. The current set of option types that may be used are 318 listed below: 320 Option # Option Type 321 ---------------------------------------- 322 TBD NAI 323 TBD PAP 324 TBD CHAP 325 TBD Signature 327 Table 1: Authentication Options 329 6.2 The DHCP Server 331 The DHCP server model is relatively simple as compared to [7], as it 332 need not manage and process keys or any client specific 333 authentication information by itself. The DHCP server receives the 334 user identification (e.g. NAI) from the client in a DHCPREQUEST; if 335 the client is supporting a password protocol (e.g. PAP), the 336 DHCPREQUEST may also include the password. The DHCP server then 337 contacts the local AAA server (e.g. using RADIUS) with the DHCP 338 client information and asks the AAA server if it can configure the 339 client. For a network that uses a challenge response protocol for 340 authentication, the server issues the challenge with a DHCPAUTHREQ 341 message, receives the challenge response from the client through a 342 DHCPAUTHRESP message and forwards the response to the AAA server for 343 client authentication. 345 If the client chooses to authenticate the network, the DHCP server 346 also needs to respond to DHCPAUTHREQ messages with a DHCPAUTHRESP 347 message for the client. If a challenge-response protocol is used by 348 the client for network authentication, the DHCP server must ask the 349 AAA server to create a response for the challenge. Extensions to 350 existing AAA protocols to support this function are beyond the scope 351 of this document. 353 6.3. The DHCP Client 355 The DHCP client needs to be modified to incorporate the optional 356 authentication mechanisms. First, it requires a new state in the 357 client's state machine called AUTHENTICATING. This state is entered 358 upon the receipt of a DHCPAUTHREQ message or when the client sends 359 out a DHCPAUTHREQ message. The client MUST respond to a DHCPAUTHREQ 360 message received when it is in the states REBOOTING, REQUESTING, 361 RENEWING, REBINDING and AUTHENTICATING. The client MAY send 362 DHCPAUTHREQ when it is in the BOUND or AUTHENTICATING state. 364 The client MUST respond to the DHCPAUTHREQ message with the message 365 DHCPAUTHRESP. Both of these messages carry authentication options as 366 described above. If the server had issued the challenge, the client 367 MUST depart from the AUTHENTICATING state upon the receipt of a 368 DHCPACK or a DHCPNACK message. The client MUST return to the bound 369 state if the server responds with a DHCPACK but if the message 370 received is DHCPNAK it MUST go back to the INIT state. 372 If the client had sent the DHCPAUTHREQ, the client MUST leave the 373 AUTHENTICATING state and enter the BOUND state when a valid 374 DHCPAUTHRES is received. If a valid DHCPAUTHRESP is not received, 375 the client MUST enter the REBIND state and obtain new configuration 376 parameters. The lease timers MUST be set as per the security 377 requirements such that the server and the client cannot delay the 378 response to the AUTHREQ messages indefinitely. Upon the expiry of 379 the T1 and T2 timers the authenticating client MUST enter the 380 REBINDING and RENEWING state respectively. The remaining state 381 transitions are the same as described in RFC 2131[13]. 383 The DHCP client also needs to be augmented with an authentication 384 module that can manage keys, respond to challenges or encrypt 385 messages. The specific functions of the authentication module is 386 implementation dependent. The following is the state diagram for the 387 client with the new state AUTHENTICATING as well as the new messages 388 DHCPAUTHREQ and DHCPAUTHRES. 390 ------ ------- 391 | | +-------------------------->| |<------------------+ 392 |INIT- | | +------------------>| INIT | | 393 |REBOOT|DHCPNAK/ | +---------->| |<---+ | 394 | |Restart | | ------- | | 395 ------ | DHCPNAK/ | | | 396 | |Discard offer | -/Send DHCPDISCOVER | 397 -/Send DHCPREQUEST | | | 398 | | | DHCPACK v | | 399 ----------- | (not accept.)/ ----------- | | 400 | | |Send DHCPDECLINE | | | 401 | REBOOTING | | | | SELECTING |<----+ | 402 | | | / | | |DHCPOFFER/ | 403 ----------- | / ----------- | |Collect | 404 | | / | | | replies | 405 DHCPACK/ | / +----------------+ +-------+ | 406 Record lease, set| | v Select offer/ | 407 timers T1, T2 ------------ send DHCPREQUEST | | 408 | +----->| | DHCPNAK, Lease expired/ | 409 | | | REQUESTING | Halt network | 410 DHCPOFFER/ | | | | 411 Discard /------------ | | 412 | | / | | ----------- | 413 | +----/---+ DHCPACK/ | | | 414 | / Record lease, set -----| REBINDING | | 415 | DHCPAUTHREQ timers T1, T2 / | | | 416 | / | DHCPACK/ ----------- | 417 | / v Record lease, set ^ | | 418 +---/------------> ------- /timers T1,T2 | DHCPAUTHREQ | 419 | +----->| |<---+ | | | 420 | | BOUND |<---+ | | 421 DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/ 422 DHCPNAK/Discard -> ------- | Broadcast Halt network 423 | / | | | DHCPREQUEST | 424 | +-------+ | DHCPACK/ | | | 425 | T1 expires/ Record lease, set | | | 426 DHCP | Send DHCPREQUEST timers T1, T2 | | | 427 AUTHREQ| to leasing server | | | | 428 -/Send | | ---------- | | | 429 DHCP | / | | |-----------+ | | 430 AUTHRES| DHCPACK +->| RENEWING | | 431 +---+ | / | |-------------------------+ 432 | | v / /---------- | 433 | ------- DHCPAUTHREQ / | | 434 +->| |<-------------+----------------------------+ | 435 |AUTHENTICATING | 436 | |----------------DHCPNACK-----------------------------+ 437 ------- 438 Figure 2: State-transition diagram for DHCP clients 440 6.4. Interworking with AAA Servers 442 The AAA mechanisms described here are similar to the ones already 443 deployed and used by ISPs to serve PPP users. A AAA protocol like 444 RADIUS can be employed with no modification to support client 445 authentication by the network. The RADIUS protocol however needs to 446 be modified in order to support network authentication by the 447 client. These modifications are beyond the scope of this document. 449 6.5. Illustrations 451 To see the use of the authentication mechanisms described here, 452 consider the case of a subscriber connecting to an access network 453 and requesting configuration using DHCP. Figures below show the 454 message flow between DHCP components of a network and their 455 interaction with the AAA components. In the first case the network 456 authenticates the client and in the second case the client 457 authenticates the network. The last illustration shows how the 458 initial configuration of a typical host would work when both the 459 client and the network are being authenticated. 461 DHCP Client DHCP Server AAA 462 v v v 463 | | | 464 .. .. .. 465 |\_____________ | | 466 | DHCPREQUEST \| | 467 | (nai+chap) | | 468 | _____________/| | 469 |/DHCPAUTHREQ | | 470 | (c1) | | 471 |\_____________ | | 472 | DHCPAUTHRES \| | 473 | (r1) | | 474 | |\______________ | 475 | | AccessRequest \| 476 | | (c1 + r1) | 477 | | ______________/| 478 | |/ AccessResponse| 479 | | (accept) | 480 | _____________/| | 481 |/ DHCPACK | | 482 | | | 483 | | | 484 | Initialization complete | 485 v v v 487 Figure 3: Authentication of the client 489 In Figure 3, the Client starts by sending the NAI in the appropriate 490 option field. It also indicates its preference to perform CHAP 491 authentication by including the CHAP option field. The server can 492 check that it does indeed support the requested authentication 493 method and thus sends an authentication request message with the 494 challenge in the CHAP option. The client can now use a key shared 495 with its home AAA authority to respond to the challenge. Upon 496 receiving the response, the DHCP server can then contact the local 497 AAA server using, for example, a RADIUS Access Request message 498 containing the challenge that was sent to the client and the 499 response received from it. The AAA server may in turn contact the 500 client's local AAA server. The AAA authority can then verify if the 501 client's response to the challenge was correct using the shared key. 502 The DHCP server, upon receiving the access response, will send a 503 DHCPACK if the client authentication succeeded or DHCPNAK otherwise. 504 Finally the DHCP client can verify and accept the parameters sent to 505 it in the DHCPACK message. 507 DHCP Client DHCP Server AAA 508 v v v 509 | | | 510 .. .. .. 511 | | | 512 |\_____________ | | 513 | DHCPAUTHREQ \| | 514 | (nai+c2) | | 515 | |\______________ | 516 | | AuthRequest \| 517 | | (c2) | 518 | | ______________/| 519 | |/ AuthResponse | 520 | | (r2) | 521 | _____________/| | 522 |/ DHCPAUTHRES | | 523 | (r2) | | 524 | | | 525 | Network authentication complete| 526 v v v 528 Figure 4: Authentication of the network 530 As shown in Figure 4, the client may also require authentication of 531 the network and sends its own challenge to the network in a 532 DHCPAUTHREQ message. The DHCP server may forward that request to the 533 AAA server who will then use the key it shares with the client to 534 respond. The Client upon confirming that the response was correct 535 will reenter bound state and resume normal operation. Otherwise, if 536 the response to the challenge was incorrect, it may reject the 537 parameters it was given and restart configuration. 539 DHCP Client DHCP Server AAA 540 v v v 541 | | | 542 .. .. .. 543 | | | 544 |\_____________ | | 545 | DHCPREQUEST \| | 546 | (nai+chap) | | 547 | _____________/| | 548 |/DHCPAUTHREQ | | 549 | (c1) | | 550 |\_____________ | | 551 | DHCPAUTHRES \| | 552 | (r1+c2) | | 553 | |\______________ | 554 | | AccessRequest \| 555 | | (c1+r1+c2) | 556 | | ______________/| 557 | |/ AccessResponse| 558 | | (accept+r2) | 559 | _____________/| | 560 |/ DHCPACK | | 561 | (r2) | | 562 | | | 563 | Initialization complete | 564 v v v 566 Figure 5: Authentication of the client and the network 568 During initial configuration when both sides may want to establish 569 trust the two steps above may be combined as shown in Figure 5. In 570 this case, the network's challenge is contained in its DHCPAUTHREQ 571 message and the client's response is contained in its DHCPAUTRES 572 message. The client's challenge is also contained in its DHCPAUTHRES 573 message and the network's response to the challenge is contained in 574 its DHCPACK message. 576 For re-authenticating, challenges can be sent using the DHCPAUTHREQ 577 and DHCPAUTHRESP messages at any time without the need for 578 reconfiguration or rebinding. 580 7. Security Considerations 582 The purpose of this document is to describe a mechanism for 583 authenticating DHCP clients and servers. It does not cover other 584 possible security attacks such as IP spoofing. 586 8. References 587 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 588 9, RFC 2026, October 1996. 589 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 590 Levels", BCP 14, RFC 2119, March 1997 591 3 S. Das, A. McAuley, A. Baba, Y. Shobatake, _Authentication, 592 Authorization, and Accounting Requirements for Roaming Nodes 593 using DHCP_, Internet Draft , March 2000. 595 4 S. Das, A. McAuley, A. Baba, Y. Shobatake, _Requirements for 596 Extending DHCP into New Environments_, Internet Draft , March 2000. 598 5 K. Hickman, "The SSL protocol", Netscape Communication Corp., 599 February 1995 600 6 C. Munroe, 601 "http://www.uu.net/press_center/hot_tech_topics/vpn/vpn- 602 whitepaper.pdf", White Paper, May 2000. 603 7 R. Dorms, W. Arbaugh, "Authentication for DHCP Message", Internet 604 Draft , July 2000. 605 8 S. Das, A. McAuley, A. Baba, Y. Shobatake, "Dynamic Registration 606 and Configuration Protocol (DRCP)", Internet Draft , July 2000. 608 9 B. Volz, S. Gonczi, T. Lemon, R. Stevens, "DHC Load Balancing 609 Algorithm", Internet Draft, . 610 11 L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 611 Protocol(EAP)", RFC 2284, March 1998. 612 11 Aboda, Beadles, "The Network Access Identifier" RFC 2486, January 613 1999 614 12 W. Simpson, "PPP Challenge Handshake Authentication Protocol 615 (CHAP)", RFC 1994, August 1996. 616 13 R. Dorms, "The Dynamic Host Control Protocol", RFC 2131, March 617 1997 618 10. Acknowledgments 620 We Acknowledge the help of Kris Ng and all the members of the 621 Advanced Wireless research group at Nortel Networks. 623 11. Author's Addresses 625 Biswaroop Mukherjee 626 Nortel Networks, 627 Ottawa, ON, 628 Canada. 629 Email: biswaroo@nortelnetworks.com 631 Bill Gage 632 Nortel Networks, 633 Ottawa, ON, 634 Canada. 635 Email: gageb@ nortelnetworks.com 637 Yajun Liu 638 Nortel Networks, 639 Ottawa, ON, 640 Canada. 641 Email: yajun@nortelnetworks.com 643 Full Copyright Statement 645 "Copyright (C) The Internet Society (date). All Rights Reserved. 646 This document and translations of it may be copied and furnished to 647 others, and derivative works that comment on or otherwise explain it 648 or assist in its implementation may be prepared, copied, published 649 and distributed, in whole or in part, without restriction of any 650 kind, provided that the above copyright notice and this paragraph 651 are included on all such copies and derivative works. However, this 652 document itself may not be modified in any way, such as by removing 653 the copyright notice or references to the Internet Society or other 654 Internet organizations, except as needed for the purpose of 655 developing Internet standards in which case the procedures for 656 copyrights defined in the Internet Standards process must be 657 followed, or as required to translate it into.