idnits 2.17.00 (12 Aug 2021) /tmp/idnits56280/draft-yegin-eap-boot-rfc3118-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: ---------------------------------------------------------------------------- == 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 1043 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (February 2004) is 6669 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: 'EAP' is mentioned on line 68, but not defined == Missing Reference: 'EAP-Key' is mentioned on line 432, but not defined == Unused Reference: 'RFC2408' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'RFC2548' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'CFB02' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'SE03' is defined on line 848, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'PANA' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'DS02' ** Downref: Normative reference to an Informational RFC: RFC 2548 -- Possible downref: Non-RFC (?) normative reference: ref. 'CFB02' -- Possible downref: Non-RFC (?) normative reference: ref. 'RD03' -- Possible downref: Non-RFC (?) normative reference: ref. 'SE03' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC-THREAT' -- Possible downref: Non-RFC (?) normative reference: ref. '8021X' Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yegin 3 Internet Draft DoCoMo USA Labs 4 H. Tschofenig 5 Siemens Corporate Technology 6 D. Forsberg 7 Nokia 9 Expires: August 2004 February 2004 11 Bootstrapping RFC3118 Delayed DHCP Authentication 12 Using EAP-based Network Access Authentication 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance 18 with all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 DHCP authentication extension (RFC3118) cannot be widely deployed 38 due to lack of an out-of-band key agreement protocol for DHCP 39 clients and servers. This draft outlines how EAP-based network 40 access authentication mechanisms can be used to establish a local 41 trust relation and generate keys that can be used in conjunction 42 with RFC3118. 44 Yegin, et al. Expires August 2004 45 [Page 2] EAP-boot-RFC3118 February 2004 47 Table of Contents 49 1.0 Introduction.................................................2 50 2.0 Terminology..................................................3 51 3.0 Overview and Building Blocks.................................4 52 4.0 Building DHCP SA.............................................5 53 4.1. 802.1X....................................................5 54 4.2. PPP.......................................................5 55 4.3. PANA......................................................7 56 4.4. Computing DHCP SA.........................................8 57 5.0 Delivering DHCP SA..........................................10 58 6.0 Using DHCP SA...............................................11 59 7.0 Security Considerations.....................................13 60 8.0 IANA Considerations.........................................16 61 9.0 Open Issues.................................................16 62 10.0 References.................................................16 63 11.0 Acknowledgments............................................17 64 12.0 Author's Addresses.........................................18 66 1.0 Introduction 68 EAP [EAP] provides a network access authentication framework by 69 carrying authentication process between the hosts and the access 70 networks. The combination of EAP with a AAA architecture allows 71 authentication and authorization of a roaming user to an access 72 network. A successful authentication between a client and the 73 network produces a dynamically created trust relation between the 74 two. Various EAP authentication methods (e.g., EAP-TLS, EAP-SIM) 75 are capable of generating cryptographic keys between the client and 76 the local authentication agent (network access server - NAS) after 77 the successful authentication. These keys are commonly used in 78 conjunction with per-packet security mechanisms (e.g., link-layer 79 ciphering). 81 DHCP [RFC2131] is a protocol which provides an end host with the 82 configuration parameters. The base DHCP does not include any 83 security mechanism, hence it is vulnerable to a number of security 84 threats. Security considerations section of RFC 2131 identifies this 85 protocol as "quite insecure" and lists various security threats. 87 RFC 3118 is the DHCP authentication protocol which defines how to 88 authenticate various DHCP messages. It does not support roaming 89 clients and assumes out-of band or manual key establishment. These 90 limitations have been inhibiting widespread deployment of this 91 security mechanism [DHC-THREAT]. 93 It is possible to use the authentication and key exchange procedure 94 executed during the network access authentication to bootstrap a 95 security association for DHCP. The trust relation created during the 96 access authentication process can be used with RFC 3118 to provide 98 Yegin, et al. Expires August 2004 99 [Page 3] EAP-boot-RFC3118 February 2004 101 security for DHCP. This document defines how to use EAP-based access 102 authentication process to bootstrap RFC 3118 for securing DHCP. 104 The general framework of the mechanism described in this I-D can be 105 outlined as follows: 107 (1) The client gains network access by utilizing an EAP 108 authentication method that generates session keys. As part of 109 the network access process, the client and the authentication 110 agent (NAS) communicate their intention to create a DHCP 111 security association and exchange the required parameters 112 (e.g., nonce, key ID, etc.) The required information exchange 113 is handled by the EAP lower-layer which also carries EAP. 115 (2) Although the newly generated DHCP SA is already available to 116 the DHCP client, in case the NAS (acting as a DHCP relay) and 117 the DHCP server are not co-located, the SA parameters need to 118 be communicated to the DHCP server. This requires a protocol 119 exchange, which can be piggybacked with the DHCP signaling. 121 (3) The DHCP signaling that immediately follows the network access 122 authentication process utilizes RFC3118 to secure the protocol 123 exchange. Both the client and the server rely on the DHCP SA 124 to compute and verify the authentication codes. 126 This framework requires extensions to the EAP lower-layers (PPP 127 [PPP], IEEE 802.1X [8021X], PANA [PANA]) to carry the supplemental 128 parameters required for the generation of the DHCP SA. Another 129 extension is required to carry the DHCP SA parameters from a DHCP 130 relay to a DHCP server. RFC3118 can be used without any 131 modifications or extensions. 133 2.0 Terminology 135 This document uses the following terms: 137 - DHCP Security Association 139 To secure DHCP messages a number of parameters including the key 140 that is shared between the client (DHCP client) and the DHCP server 141 have to be established. These parameters are collectively referred 142 to as DHCP security association (or in short DHCP SA). 144 DHCP SA can be considered as a group security association. The DHCP 145 SA parameters are provided to the DHCP server as soon as the client 146 chooses the server to carry out DHCP. The same DHCP SA can be used 147 by any one of the DHCP servers that are available to the client. 149 Yegin, et al. Expires August 2004 150 [Page 4] EAP-boot-RFC3118 February 2004 152 - DHCP Key 154 This term refers to the fresh and unique session key dynamically 155 established between the DHCP client and the DHCP server. This key is 156 used to protect DHCP messages as described in [RFC3118]. 158 In this document, the key words "MAY", "MUST, "MUST NOT", 159 OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be 160 interpreted as described in [RFC2119]. 162 3.0 Overview and Building Blocks 164 The bootstrapping mechanism requires protocol interaction between 165 the client host (which acts as a DHCP client), the NAS and the DHCP 166 server. A security association will be established between the DHCP 167 server and the DHCP client to protect the DHCP messages. 169 A DHCP SA is generated based on the EAP SA after a successful EAP 170 authentication. Both the client and the NAS should agree on the 171 generation of a DHCP SA after the EAP SA is created. This involves a 172 handshake between the two and exchange of additional parameters 173 (such as nonce, key ID, etc.). These additional information needs to 174 be carried over the EAP lower-layer that also carries the EAP 175 payloads. 177 The DHCP SA is ultimately needed by the DHCP client and the DHCP 178 server. On the network side, the DHCP SA information needs to be 179 transferred from the NAS (where it is generated) to the DHCP server 180 (where it will be used). On the client host side, it is transferred 181 from the network access authentication client to the DHCP client. 183 NAS is always located one IP hop away from the client. If the DHCP 184 server is on the same link, it can be co-located with the NAS. When 185 the NAS and the DHCP server are co-located, an internal mechanism, 186 such as an API, is sufficient for transferring the SA information. 187 If the DHCP server is multiple hops away from the DHCP client, then 188 there must be a DHCP relay on the same link as the client. In that 189 case, the NAS should be co-located with the DHCP relay. 191 [DS02] enables transmission of AAA-related RADIUS attributes from a 192 DHCP relay to a DHCP server in the form of relay agent information 193 options. DHCP SA is generated at the end of the AAA process, and 194 therefore it can be provided to the DHCP server in a sub-option 195 carried along with other AAA-related information. Confidentiality, 196 replay, and integrity protection of this exchange MUST be provided. 197 [RD03] proposes IPsec protection of the DHCP messages exchanged 198 between the DHCP relay and the DHCP server. DHCP objects (protected 199 with IPsec) can therefore be used to communicate the necessary 200 parameters. 202 Yegin, et al. Expires August 2004 203 [Page 5] EAP-boot-RFC3118 February 2004 205 Two different deployment scenarios are illustrated in Figure 1. 207 +---------+ +------------------+ 208 |EAP Peer/| |EAP Authenticator/| 209 | DHCP |<============>| DHCP server | 210 | client | EAP and DHCP | | 211 +---------+ +------------------+ 212 Client Host NAS 214 +---------+ +------------------+ +-----------+ 215 |EAP Peer/| |EAP Authenticator/| | | 216 | DHCP |<============>| DHCP relay |<========>|DHCP server| 217 | client | EAP and DHCP | | DHCP | | 218 +---------+ +------------------+ +-----------+ 219 Client Host NAS 221 Figure 1: Protocols and end points. 223 When the DHCP SA information is received by the DHCP server and 224 client, it can be used along with RFC3118 to protect DHCP messages 225 against various security threats. This draft provides the guidelines 226 regarding how the RFC3118 protocol fields should be filled in based 227 on the DHCP SA. 229 4.0 Building DHCP SA 231 DHCP SA is created at the end of the EAP-based access authentication 232 process. This section describes extensions to the EAP lower-layers 233 for exchanging the additional information, and the process of 234 generating the DHCP SA. 236 4.1. 802.1X 238 TBD 240 4.2. PPP 242 A new IPCP configuration option is defined in order to bootstrap 243 DHCP SA between the PPP peers. Each end of the link must separately 244 request this option for mutual establishment of DHCP SA. Only one 245 side sending the option will not produce any state. 247 Yegin, et al. Expires August 2004 248 [Page 6] EAP-boot-RFC3118 February 2004 250 The detailed DHCP-SA Configuration Option is presented below. 252 0 1 2 3 253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type | Length | Reserved | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Secret ID | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 ~ Nonce Data ~ 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Type 266 TBD 268 Length 270 >=24 272 Reserved 274 A 16-bit value reserved for future use. It MUST be initialized 275 to zero by the sender, and ignored by the receiver. 277 Secret ID 279 32 bit value that identifies the DHCP Key produced as a result 280 of the bootstrapping process. This value is determined by the 281 NAS and sent to the client. The NAS determines this value by 282 randomly picking a number from the available secret ID pool. If 283 the client does not request DHCP-SA configuration option, this 284 value is returned to the available identifiers pool. Otherwise, 285 it is allocated to the client until the DHCP SA expires. The 286 client MUST set this field to all 0s in its own request. 288 Nonce Data (variable length) 290 Contains the random data generated by the transmitting entity. 291 This field contains the Nonce_client value when the AVP is sent 292 by client, and the Nonce_NAS value when the AVP is sent by NAS. 293 Nonce value MUST be randomly chosen and MUST be at least 128 294 bits in size. Nonce values MUST NOT be reused. 296 Yegin, et al. Expires August 2004 297 [Page 7] EAP-boot-RFC3118 February 2004 299 4.3. PANA 301 A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP- 302 AVP is included in the PANA-Bind-Request message if PAA (NAS) is 303 offering DHCP SA bootstrapping service. If the PaC wants to proceed 304 with creating DHCP SA at the end of the PANA authentication, it MUST 305 include DHCP-AVP in its PANA-Bind-Answer message. 307 Absence of this AVP in the PANA-Bind-Request message sent by the PAA 308 indicates unavailability of this additional service. In that case, 309 PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore 310 received DHCP-AVP. When this AVP is received by the PaC, it may or 311 may not include the AVP in its response depending on its desire to 312 create a DHCP SA. A DHCP SA can be created as soon as each entity 313 has received and sent one DHCP-AVP. 315 The detailed DHCP-AVP format is presented below. 317 0 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | AVP Code | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | AVP Flags | AVP Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Secret ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 ~ Nonce Data ~ 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 AVP Code 333 TBD 335 AVP Flags 337 The AVP Flags field is eight bits. The following bits are 338 assigned: 340 0 1 2 3 4 5 6 7 341 +-+-+-+-+-+-+-+-+ 342 |V M r r r r r r| 343 +-+-+-+-+-+-+-+-+ 345 M(andatory) 347 - The 'M' Bit, known as the Mandatory bit, indicates 348 whether support of the AVP is required. This bit is not 349 set in DHCP-AVP. 351 Yegin, et al. Expires August 2004 352 [Page 8] EAP-boot-RFC3118 February 2004 354 V(endor) 356 - The 'V' bit, known as the Vendor-Specific bit, indicates 357 whether the optional Vendor-Id field is present in the AVP 358 header. This bit is not set in DHCP-AVP. 360 r(eserved) 362 - These flag bits are reserved for future use, and MUST be 363 set to zero, and ignored by the receiver. 365 AVP Length 367 The AVP Length field is three octets, and indicates the number 368 of octets in this AVP including the AVP Code, AVP Length, AVP 369 Flags, and AVP data. 371 Secret ID 373 A 32-bit value that identifies the DHCP Key produced as a 374 result of the bootstrapping process. This value is determined 375 by the PAA and sent to the PaC. The PAA determines this value 376 by randomly picking a number from the available secret ID pool. 377 If PaC's response does not contain DHCP-AVP then this value is 378 returned to the available identifiers pool. Otherwise, it is 379 allocated to the PaC until the DHCP SA expires. The PaC MUST 380 set this field to all 0s in its response. 382 Nonce Data (variable length) 384 Contains the random data generated by the transmitting entity. 385 This field contains the Nonce_client value when the AVP is sent 386 by PaC, and the Nonce_NAS value when the AVP is sent by PAA. 387 Nonce value MUST be randomly chosen and MUST be at least 128 388 bits in size. Nonce values MUST NOT be reused. 390 4.4. Computing DHCP SA 392 The key derivation procedure is reused from IKE [RFC2409]. The 393 character '|' denotes concatenation. 395 DHCP Key = HMAC-MD5(AAA-key, const | Secret ID | Nonce_client | 396 Nonce_NAS) 398 Yegin, et al. Expires August 2004 399 [Page 9] EAP-boot-RFC3118 February 2004 401 The values have the following meaning: 403 - AAA-key: 405 A key derived by the EAP peer and EAP (authentication) server 406 and transported to the authenticator (NAS) at the end of the 407 successful network access AAA. 409 - const: 411 This is a string constant. The value of the const parameter is 412 set to "EAP RFC3118 Bootstrapping". 414 - Secret ID: 416 The unique identifier of the DHCP key as carried by the EAP 417 lower-layer protocol extension. 419 - Nonce_client: 421 This random number is provided by the client and carried by the 422 EAP lower-layer protocol extension. 424 - Nonce_NAS: 426 This random number is provided by the NAS and carried by the 427 EAP lower-layer protocol. 429 - DHCP Key: 431 This session key is 128-bit in length and used as the session 432 key for securing DHCP messages. Figure 1 of [EAP-Key] refers to 433 this derived key as a Transient Session Key (TSK). 435 The lifetime of the DHCP security association has to be limited to 436 prevent the DHCP server from storing state information indefinitely. 437 The lifetime of the DHCP SA should be set to the lifetime of the 438 network access service. The client host, NAS, and the DHCP server 439 should be (directly or indirectly) aware of this lifetime at the end 440 of a network access AAA. 442 The PaC can at any time trigger a new bootstrapping protocol run to 443 establish a new security association with the DHCP server. The IP 444 address lease time SHOULD be limited by the DHCP SA lifetime. 446 Yegin, et al. Expires August 2004 447 [Page 10] EAP-boot-RFC3118 February 2004 449 5.0 Delivering DHCP SA 451 When the NAS and the DHCP server are not co-located, the DHCP SA 452 information is carried from the NAS (DHCP relay) to the DHCP server 453 in a DHCP relay agent info option. This sub-option can be included 454 along with the RADIUS attributes sub-option that is carried after 455 the network access authentication. 457 The format of the DHCP SA sub-option is: 459 0 1 2 3 460 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | SubOpt Code | Length | Reserved | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Secret ID | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 + + 469 | | 470 + DHCP Key + 471 | | 472 + + 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Lifetime | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 SubOpt Code 480 TBD 482 Length 484 This value is set to 26. 486 Reserved 488 A 16-bit value reserved for future use. It MUST be initialized 489 to zero by the sender, and ignored by the receiver. 491 Secret ID 493 This is the 32-bit value assigned by the NAS and used to 494 identify the DHCP key. 496 DHCP Key 498 128-bit DHCP key computed by the NAS is carried in this field. 500 Yegin, et al. Expires August 2004 501 [Page 11] EAP-boot-RFC3118 February 2004 503 Lifetime 505 The lifetime of the DHCP SA. This Unsigned32 value contains the 506 number of seconds remaining before the DHCP SA is considered 507 expired. 509 6.0 Using DHCP SA 511 Once the DHCP SA is in place, it is used along with RFC3118 to 512 secure the DHCP protocol exchange. 514 [RFC3118] defines two security protocols with a newly defined 515 authentication option: 517 - Configuration token 518 - Delayed authentication 520 The generic format of the authentication option is defined in 521 Section 2 of [RFC3118] and contains the following fields: 523 - Code 525 The value for the Code field of this authentication option is 526 90. 528 - Length 530 The Length field indicates the length of the authentication 531 option payload. 533 - Protocol 535 [RFC3118] defines two values for the Protocol field - zero and 536 one. A value of zero indicates the usage of the configuration 537 token authentication option. 539 As described in Section 4 of [RFC3118] the configuration token 540 only provides weak entity authentication. Hence its usage is 541 not recommended. This authentication option will not be 542 considered for the purpose of bootstrapping. 544 A value of one in the Protocol field in the authentication 545 option indicates the delayed authentication. The usage of this 546 option is subsequently assumed in this document. 548 Since the value for this field is known in advance it does not 549 need to be negotiated between the DHCP client and DHCP server. 551 Yegin, et al. Expires August 2004 552 [Page 12] EAP-boot-RFC3118 February 2004 554 - Algorithm 556 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the 557 Algorithm field). This document assumes that HMAC-MD5 is used 558 to protect DHCP messages. 560 Since the value for this field is known in advance it does not 561 need to be negotiated. [TBD: Consider future algorithm support] 563 - Replay Detection Method (RDM) 565 The value of zero for the RDM name space is assigned to use a 566 monotonically increasing value. 568 Since the value for this field is known in advance it does not 569 need to be negotiated. 571 - Replay Detection 573 This field contains the value that is used for replay 574 protection. This value MUST be monotonically increasing 575 according to the provided replay detection method. An initial 576 value must, however, be set. In case of bootstrapping with EAP 577 an initial value of zero is used. The length of 64 bits (and a 578 start-value of zero) ensures that a sequence number rollover is 579 very unlikely to occur. 581 Since the value for this field is known in advance it does not 582 need to be negotiated. 584 - Authentication Information 586 The content of this field depends on the type of message where 587 the authentication option is used. Section 5.2 of [RFC3118] 588 does not provide content for the DHCPDISCOVER and the 589 DHCPINFORM message. Hence for these messages no additional 590 considerations need to be specified in this document. 592 For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of 593 the Authentication Information field is given as: 595 - Secret ID (32 bits) 596 - HMAC-MD5 (128 bits) 598 The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If 599 there are multiple NASes per DHCP server, this identifier space 600 might need to be pre-partitioned among the NASes.] 602 HMAC-MD5 is the output of the key message digest computation. Note 603 that not all fields of the DHCP message are protected as described 604 in [RFC3118]. 606 Yegin, et al. Expires August 2004 607 [Page 13] EAP-boot-RFC3118 February 2004 609 7.0 Security Considerations 611 This document describes a mechanism for dynamically establishing a 612 security association to protect DHCP signaling messages. 614 If the NAS and the DHCP server are co-located then the session keys 615 and the security parameters are transferred locally (via an API 616 call). Some security protocols already exercise similar methodology 617 to separate functionality. 619 If the NAS and the DHCP server are not co-located then there is some 620 similarity to the requirements and issues discussed with the EAP 621 Keying Framework (see [AS+03]). Figure 2 is originally taken from 622 Section 4.1 of [AS+03] and extended accordingly. DHCP key is a TSK 623 (Transient Session Key [AS+03]). The key is generated by both the 624 DHCP client and the DHCP relay, and transported from the DHCP relay 625 to the DHCP server. DHCP protocol traffic between the DHCP client 626 and DHCP server is protected using this key. 628 EAP peer (DHCP client) +-----------------------+ DHCP server 629 /\ / 630 / \ Protocol: EAP / 631 / \ lower-layer; / 632 / \ Auth: Mutual; / 633 / \ Unique key: / 634 Protocol: EAP; / \ DHCP key / 635 Auth: Mutual; / \ / Protocol: DHCP, or API; 636 Unique keys: MK, / \ / Auth: Mutual; 637 TEKs, EMSK / \ / Unique key: DHCP key 638 / \ / 639 / \ / 640 Auth. server +----------------------+ Authenticator 641 Protocol: AAA; (NAS, DHCP relay) 642 Auth: Mutual; 643 Unique key: 644 AAA session key 646 Figure 2: Keying Architecture 648 Figure 2 describes the participating entities and the protocols 649 executed among them. It must be ensured that the derived session key 650 between the DHCP client and the server is fresh and unique. 652 Yegin, et al. Expires August 2004 653 [Page 14] EAP-boot-RFC3118 February 2004 655 The key transport mechanism, which is used to carry the session key 656 between the NAS and DHCP server, must provide the following 657 functionality: 659 - Confidentiality protection 660 - Replay protection 661 - Integrity protection 663 Furthermore it is necessary that the two parties (DHCP server and 664 the NAS) authorize the establishment of the DHCP security 665 association. 667 At IETF 56 Russ Housley presented a list of recommendations for key 668 management protocols which describe requirements for an acceptable 669 solution. Although the presentation focused on NASREQ some issues 670 might be also applicable in this context. 672 - Algorithm independence: 674 This proposal bootstraps a DHCP security association for RFC 3118 675 where only a single integrity algorithm (namely HMAC-MD5) is 676 proposed which is mandatory to implement. 678 - Establish strong, fresh session keys (maintain algorithm 679 independence): 681 This scheme relies on EAP methods to provide strong and fresh 682 session keys for each initial authentication and key exchange 683 protocol run. Furthermore the key derivation function provided in 684 Section 4.4 contains random numbers provided by the client and the 685 NAS which additionally add randomness to the generated key. 687 - Replay protection: 689 Replay protection is provided at different places. 691 The EAP method executed between the EAP peer and the EAP server MUST 692 provide a replay protection mechanism. 694 Additionally random numbers and the secret ID are included in the 695 key derivation procedure which aim to provide a fresh and unique 696 session key between the DHCP client and the DHCP server. 698 Furthermore, the key transport mechanism between the NAS and the 699 DHCP server must also provide replay protection (in addition to 700 confidentiality protection). 702 Finally, the security mechanisms provided in RFC 3118, for which 703 this draft bootstraps the security association, also provides replay 704 protection. 706 Yegin, et al. Expires August 2004 707 [Page 15] EAP-boot-RFC3118 February 2004 709 - Authenticate all parties: 711 Authentication between the EAP peer and the EAP server is based on 712 the used EAP method. After a successful authentication and protocol 713 run, the host and the NAS in the network provide AAA-key 714 confirmation either based on the 4-way handshake in IEEE 802.11i or 715 based on the protected PANA exchange. DHCP key confirmation between 716 the DHCP client and server is provided with the first protected DHCP 717 message exchange. 719 - Perform authorization: 721 Authorization for network access is provided during the EAP 722 exchange. The authorization procedure for DHCP bootstrapping is 723 executed by the NAS before this service is offered to the client. 724 The NAS might choose not to include DHCP-AVP or DHCP SA 725 Configuration Option during network access authorization based on 726 the authorization policies. 728 - Maintain confidentiality of session keys: 730 The DHCP session keys are only known to the intended parties (i.e., 731 to the DHCP client, relay [TBD: is that OK?], and server). The EAP 732 protocol itself does not transport keys. The exchanged random 733 numbers which are incorporated into the key derivation function do 734 not need to be kept confidential. 736 DHCP relay agent information MUST be protected using [RD03] with 737 non-null IPsec encryption. 739 - Confirm selection of "best" cipher-suite: 741 This proposal does not provide confidentiality protection of DHCP 742 signaling messages. Only a single algorithm is offered for integrity 743 protection. Hence no algorithm negotiation and therefore no 744 confirmation of the selection occur. 746 - Uniquely name session keys: 748 The DHCP SA is uniquely identified using a Secret ID (described in 749 [RFC3118] and reused in this document). 751 - Compromised NAS and DHCP server: 753 A compromised NAS may leak the DHCP session key and the EAP derived 754 session key (e.g., AAA-key). It will furthermore allow corruption of 755 the DHCP protocol executed between the hosts and the DHCP server 756 since NAS either acts as a DHCP relay or a DHCP server. 758 A compromised NAS may also allow creation of further DHCP SAs or 759 other known attacks on the DHCP protocol (e.g., address depletion). 761 Yegin, et al. Expires August 2004 762 [Page 16] EAP-boot-RFC3118 February 2004 764 A compromised NAS will not be able to modify, replay, inject DHCP 765 messages which use security associations established without the 766 EAP-based bootstrapping mechanism (e.g., manually configured DHCP 767 SAs). 769 On the other hand, a compromised DHCP server may only leak the DHCP 770 key information. AAA-key will not be compromised in this case. 772 - Bind key to appropriate context: 774 The key derivation function described in Section 4.4 includes 775 parameters (such as the secret ID and a constant) which prevents 776 reuse of the established session key for other purposes. 778 8.0 IANA Considerations 780 TBD 782 9.0 Open Issues 784 This document describes a bootstrapping procedure for [RFC3118]. The 785 same procedure could be applied for [DHCPv6]. 787 10.0 References 789 [DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. 790 Carney: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 791 Internet-Draft, (work in progress), November, 2002. 793 [PANA] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin: 794 "Protocol for Carrying Authentication for Network Access (PANA)", 795 Internet-Draft, (work in progress), March, 2003. 797 [RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP 798 Messages", RFC 3118, June 2001. 800 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 801 (IKE)", RFC 2409, November 1998. 803 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 804 "Internet Security Association and Key Management Protocol 805 (ISAKMP)", RFC 2408, November 1998. 807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 808 Requirement Levels", BCP 14, RFC 2119, March 1997. 810 [PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.: 811 "Protocol for Carrying Authentication for Network Access (PANA) 813 Yegin, et al. Expires August 2004 814 [Page 17] EAP-boot-RFC3118 February 2004 816 Requirements and Terminology", Internet-Draft, (work in progress), 817 April, 2003. 819 [DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option 820 for the DHCP Relay Agent Information", Internet-Draft, (work in 821 progress), October, 2002. 823 [SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication 824 Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in 825 progress), April, 2003. 827 [AS+03] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz: "EAP 828 Keying Framework", Internet-Draft, (work in progress), October 2003. 830 [RFC2132] Alexander, S. and Droms, R.: "DHCP Options and BOOTP 831 Vendor Extensions", RFC 2132, March 1997. 833 [RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC 2131, 834 March 1997. 836 [WH+03] J. Walker, R. Housley, and N. Cam-Winget, "AAA key 837 distribution", Internet Draft, (work in progress), April 2002. 839 [RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", 840 RFC 2548, March 1999. 842 [CFB02] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS Security 843 Application", Internet-Draft, (work in progress), March 2002. 845 [RD03] R. Droms: "Authentication of DHCP Relay Agent Options Using 846 IPsec", Internet-Draft (work in progress), August 2003. 848 [SE03] J. Salowey and P. Eronen: "EAP Key Derivation for Multiple 849 Applications", Internet-Draft (work in progress), June 2003. 851 [DHC-THREAT] Hibbs, R., Smith, C., Volz, B., Zohar, M., "Dynamic 852 Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", 853 Internet-draft (expired), June 2003. 855 [8021X] IEEE Standard for Local and Metropolitan Area Networks, 856 "Port-Based Network Access Control", IEEE Std 802.1X-2001. 858 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD 859 51), July 1994. 861 11.0 Acknowledgments 863 We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for 864 their useful feedback to this work. 866 Yegin, et al. Expires August 2004 867 [Page 18] EAP-boot-RFC3118 February 2004 869 12.0 Author's Addresses 871 Alper E. Yegin 872 DoCoMo USA Labs 873 181 Metro Drive, Suite 300 874 San Jose, CA, 95110 875 USA 876 Phone: +1 408 451 4743 877 Email: alper@docomolabs-usa.com 879 Hannes Tschofenig 880 Siemens AG 881 Otto-Hahn-Ring 6 882 81739 Munich 883 Germany 884 EMail: Hannes.Tschofenig@siemens.com 886 Dan Forsberg 887 Nokia Research Center 888 P.O. Box 407 889 FIN-00045 NOKIA GROUP, Finland 890 Phone: +358 50 4839470 891 EMail: dan.forsberg@nokia.com 893 Full Copyright Statement 895 Copyright (C) The Internet Society (2004). All Rights Reserved. 896 This document and translations of it may be copied and furnished to 897 others, and derivative works that comment on or otherwise explain it 898 or assist in its implementation may be prepared, copied, published 899 and distributed, in whole or in part, without restriction of any 900 kind, provided that the above copyright notice and this paragraph 901 are included on all such copies and derivative works. However, this 902 document itself may not be modified in any way, such as by removing 903 the copyright notice or references to the Internet Society or other 904 Internet organizations, except as needed for the purpose of 905 developing Internet standards in which case the procedures for 906 copyrights defined in the Internet Standards process must be 907 followed, or as required to translate it into languages other than 908 English. 910 The limited permissions granted above are perpetual and will not be 911 revoked by the Internet Society or its successors or assigns. 913 This document and the information contained herein is provided on an 914 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 915 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 916 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 917 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 918 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 920 Yegin, et al. Expires August 2004