idnits 2.17.00 (12 Aug 2021) /tmp/idnits56622/draft-yegin-eap-boot-rfc3118-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 867. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 2006) is 5938 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-Key' is mentioned on line 427, but not defined == Unused Reference: 'I-D.ietf-dhc-v4-threat-analysis' is defined on line 798, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-dhc-v4-threat-analysis-02 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration H. Tschofenig 3 Internet-Draft Siemens 4 Expires: August 5, 2006 A. Yegin 5 Samsung 6 D. Forsberg 7 Nokia 8 February 2006 10 Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based 11 Network Access Authentication 12 draft-yegin-eap-boot-rfc3118-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 5, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The DHCP authentication extension (RFC 3118) cannot be widely 46 deployed due to lack of a key agreement protocol. This document 47 outlines how EAP-based network access authentication mechanisms can 48 be used to establish bootstrap keying material that can be used to 49 subsequently use RFC 3118 security. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Overview and Building Blocks . . . . . . . . . . . . . . . . . 6 56 4. Buliding DHCP SA . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.2. PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.4. Computing DHCP SA . . . . . . . . . . . . . . . . . . . . 11 61 5. Delivering DHCP SA . . . . . . . . . . . . . . . . . . . . . . 13 62 6. Using DHCP SA . . . . . . . . . . . . . . . . . . . . . . . . 15 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 65 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 66 10. Acknowledegments . . . . . . . . . . . . . . . . . . . . . . . 24 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 71 Intellectual Property and Copyright Statements . . . . . . . . . . 28 73 1. Introduction 75 The Extensible Authentication Protocol (EAP) [RFC3748] provides a 76 network access authentication framework by carrying authentication 77 process between the hosts and the access networks. The combination 78 of EAP with a AAA architecture allows authentication and 79 authorization of a roaming user to an access network. A successful 80 authentication between a client and the network produces a 81 dynamically created trust relation between the two. Almost all EAP 82 methods (e.g., EAP-TLS, EAP-SIM) are capable of generating 83 cryptographic keys between the EAP peer and the EAP server. Using 84 key transport via the AAA infrastructure the EAP server makes the 85 EAP-provided keying material available to the Authenticator (e.g., 86 Network Access Server; NAS) after a successful authentication 87 attempt. These keys are commonly used in conjunction with per-packet 88 security mechanisms (e.g., link-layer ciphering). This procedure is 89 described in [I-D.ietf-eap-keying]. 91 DHCP [RFC2131] is a protocol which provides a host with configuration 92 parameters. The base DHCP does not include any security mechanism, 93 hence it is vulnerable to a number of security threats. The security 94 considerations section of RFC 2131 [RFC2131] identifies it as "quite 95 insecure" and lists various security threats. 97 RFC 3118 [RFC3118] is the DHCP authentication protocol that defines 98 how to authenticate various DHCP messages. It does not support 99 roaming clients and assumes out-of-band or manual key establishment. 100 These limitations have been inhibiting widespread deployment of this 101 security mechanism as noted in a DHCPv4 threat analysis [I-D.ietf- 102 dhc-v4-threat-analysis]. 104 It is possible to use the authentication and key exchange procedure 105 executed during the network access authentication to bootstrap a 106 security association for DHCP. The access authentication procedure 107 can be utilized to dynamically provide the keying material to RFC 108 3118 based security protection for DHCP. This document defines how 109 to use the EAP-based access authentication procedure to bootstrap RFC 110 3118 security. 112 The general framework of the mechanism described in this I-D can be 113 outlined as follows: 115 1. The client gains network access by utilizing an EAP method that 116 generates session keys. As part of the network access process, 117 the client and the authentication agent (NAS) communicate their 118 intention to create a DHCP security association and exchange the 119 required parameters (e.g., nonce, key ID, etc.) The required 120 information exchange is handled by the EAP lower-layer which also 121 carries EAP. 123 2. Although the newly generated DHCP SA is already available to the 124 DHCP client, in case the NAS (acting as a DHCP relay) and the 125 DHCP server are not co-located, the SA parameters need to be 126 communicated to the DHCP server. This requires a protocol 127 exchange, which can be piggybacked with the DHCP signaling. 129 3. The DHCP signaling that immediately follows the network access 130 authentication process utilizes RFC 3118 to secure the protocol 131 exchange. Both the client and the server rely on the DHCP SA to 132 compute and verify the authentication codes. 134 This framework requires extensions to the EAP lower-layers (PPP 135 [RFC1661], IEEE 802.1X , PANA [I-D.ietf-pana-pana]) to carry the 136 supplemental parameters required for the generation of the DHCP SA. 137 Another extension is required to carry the DHCP SA parameters from a 138 DHCP relay to a DHCP server. RFC 3118 can be used without any 139 modifications or extensions. 141 2. Terminology 143 In this document, the key words "MAY", "MUST, "MUST NOT", 144 OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be 145 interpreted as described in [RFC2119]. 147 This document uses the following terms: 149 DHCP Security Association: 151 To secure DHCP messages a number of parameters including the key 152 that is shared between the client (DHCP client) and the DHCP 153 server have to be established. These parameters are collectively 154 referred to as DHCP security association (or in short DHCP SA). 156 DHCP SA can be considered as a group security association. The 157 DHCP SA parameters are provided to the DHCP server as soon as the 158 client chooses the server to carry out DHCP. The same DHCP SA can 159 be used by any one of the DHCP servers that are available to the 160 client. 162 DHCP Key: 164 This term refers to the fresh and unique session key dynamically 165 established between the DHCP client and the DHCP server. This key 166 is used to protect DHCP messages as described in [RFC3118]. 168 3. Overview and Building Blocks 170 The bootstrapping mechanism requires protocol interaction between the 171 client host (which acts as a DHCP client), the NAS and the DHCP 172 server. A security association will be established between the DHCP 173 server and the DHCP client to protect the DHCP messages. 175 A DHCP SA is generated based on the EAP method derived key after a 176 successful EAP method protocol run. Both the client and the NAS 177 should agree on the generation of a DHCP SA after the EAP SA is 178 created. This involves a handshake between the two and exchange of 179 additional parameters (such as nonce, key ID, etc.). These 180 additional information needs to be carried over the EAP lower-layer 181 that also carries the EAP payloads. 183 The DHCP SA is ultimately needed by the DHCP client and the DHCP 184 server. On the network side, the DHCP SA information needs to be 185 transferred from the NAS (where it is generated) to the DHCP server 186 (where it will be used). On the client host side, it is transferred 187 from the network access authentication client to the DHCP client. 189 NAS is always located one IP hop away from the client. If the DHCP 190 server is on the same link, it can be co-located with the NAS. When 191 the NAS and the DHCP server are co-located, an internal mechanism, 192 such as an API, is sufficient for transferring the SA information. 193 If the DHCP server is multiple hops away from the DHCP client, then 194 there must be a DHCP relay on the same link as the client. In that 195 case, the NAS should be co-located with the DHCP relay 197 [RFC4014] enables transmission of AAA-related RADIUS attributes from 198 a DHCP relay to a DHCP server in the form of relay agent information 199 options. DHCP SA is generated at the end of the AAA process, and 200 therefore it can be provided to the DHCP server in a sub-option 201 carried along with other AAA-related information. Confidentiality, 202 replay, and integrity protection of this exchange MUST be provided. 203 [I-D.ietf-dhc-relay-agent-ipsec] proposes IPsec protection of the 204 DHCP messages exchanged between the DHCP relay and the DHCP server. 205 DHCP objects (protected with IPsec) can therefore be used to 206 communicate the necessary parameters. 208 Two different deployment scenarios are illustrated in Figure 1. 210 +---------+ +------------------+ 211 |EAP Peer/| |EAP Authenticator/| 212 | DHCP |<============>| DHCP server | 213 | client | EAP and DHCP | | 214 +---------+ +------------------+ 215 Client Host NAS 217 +---------+ +------------------+ +-----------+ 218 |EAP Peer/| |EAP Authenticator/| | | 219 | DHCP |<============>| DHCP relay |<========>|DHCP server| 220 | client | EAP and DHCP | | DHCP | | 221 +---------+ +------------------+ +-----------+ 222 Client Host NAS 224 Figure 1: Protocols and end points. 226 When the DHCP SA information is received by the DHCP server and 227 client, it can be used along with RFC 3118 to protect DHCP messages 228 against various security threats. This draft provides the guidelines 229 regarding how the RFC 3118 protocol fields should be filled in based 230 on the DHCP SA. 232 4. Buliding DHCP SA 234 DHCP SA is created at the end of the EAP-based access authentication 235 process. This section describes extensions to the EAP lower-layers 236 for exchanging the additional information, and the process of 237 generating the DHCP SA. 239 4.1. 802.1X 241 [Editor's Note: This work needs to be done outside the IETF.] 243 4.2. PPP 245 A new IPCP configuration option is defined in order to bootstrap DHCP 246 SA between the PPP peers. Each end of the link must separately 247 request this option for mutual establishment of DHCP SA. Only one 248 side sending the option will not produce any state. 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 Figure 2: DHCP SA Configuration Option 266 Type 268 o TBD 270 Length 272 o >=24 274 Reserved 276 o A 16-bit value reserved for future use. It MUST be initialized to 277 zero by the sender, and ignored by the receiver. 279 Secret ID 280 o 32 bit value that identifies the DHCP Key produced as a result of 281 the bootstrapping process. This value is determined by the NAS 282 and sent to the client. The NAS determines this value by randomly 283 picking a number from the available secret ID pool. If the client 284 does not request DHCP-SA configuration option, this value is 285 returned to the available identifiers pool. Otherwise, it is 286 allocated to the client until the DHCP SA expires. The client 287 MUST set this field to all 0s in its own request. 289 Nonce Data (variable length) 291 o Contains the random data generated by the transmitting entity. 292 This field contains the Nonce_client value when the option is sent 293 by client, and the Nonce_NAS value when the option is sent by NAS. 294 Nonce value MUST be randomly chosen and MUST be at least 128 bits 295 in size. Nonce values MUST NOT be reused. 297 4.3. PANA 299 A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP- 300 AVP is included in the PANA-Bind-Request message if PAA (NAS) is 301 offering DHCP SA bootstrapping service. If the PaC wants to proceed 302 with creating DHCP SA at the end of the PANA authentication, it MUST 303 include DHCP-AVP in its PANA-Bind-Answer message. 305 Absence of this AVP in the PANA-Bind-Request message sent by the PAA 306 indicates unavailability of this additional service. In that case, 307 PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore 308 received DHCP-AVP. When this AVP is received by the PaC, it may or 309 may not include the AVP in its response depending on its desire to 310 create a DHCP SA. A DHCP SA can be created as soon as each entity 311 has received and sent one DHCP-AVP. 313 The detailed DHCP-AVP format is presented below: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | AVP Code | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | AVP Flags | AVP Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Secret ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 ~ Nonce Data ~ 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 3: DHCP AVP Format 331 AVP Code 333 o TBD 335 AVP Flags 337 o 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 Figure 4: DHCP AVP Flags 347 M(andatory) 349 o The 'M' Bit, known as the Mandatory bit, indicates whether support 350 of the AVP is required. This bit is not set in DHCP-AVP. 352 V(endor) 354 o The 'V' bit, known as the Vendor-Specific bit, indicates whether 355 the optional Vendor-Id field is present in the AVP header. This 356 bit is not set in DHCP-AVP. 358 r(eserved) 360 o These flag bits are reserved for future use, and MUST be set to 361 zero, and ignored by the receiver. 363 AVP Length 365 o The AVP Length field is three octets, and indicates the number of 366 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 367 and AVP data. 369 Secret ID 371 o A 32-bit value that identifies the DHCP Key produced as a result 372 of the bootstrapping process. This value is determined by the PAA 373 and sent to the PaC. The PAA determines this value by randomly 374 picking a number from the available secret ID pool. If PaC's 375 response does not contain DHCP-AVP then this value is returned to 376 the available identifiers pool. Otherwise, it is allocated to the 377 PaC until the DHCP SA expires. The PaC MUST set this field to all 378 0s in its response. 380 Nonce Data (variable length) 382 o Contains the random data generated by the transmitting entity. 383 This field contains the Nonce_client value when the AVP is sent by 384 PaC, and the Nonce_NAS value when the AVP is sent by PAA. Nonce 385 value MUST be randomly chosen and MUST be at least 128 bits in 386 size. Nonce values MUST NOT be reused. 388 4.4. Computing DHCP SA 390 The key derivation procedure is reused from IKE [RFC2409]. The 391 character '|' denotes concatenation. 393 DHCP Key = HMAC-SHA1(AAA-key, const | Secret ID | Nonce_client | 394 Nonce_NAS) 396 The values have the following meaning: 398 AAA-key: 400 A key derived by the EAP peer and EAP (authentication) server and 401 transported to the authenticator (NAS) at the end of the 402 successful network access AAA. 404 const: 406 This is a string constant. The value of the const parameter is 407 set to "EAP RFC 3118 Bootstrapping". 409 Secret ID: 411 The unique identifier of the DHCP key as carried by the EAP lower- 412 layer protocol extension. 414 Nonce Client: 416 This random number is provided by the client and carried by the 417 EAP lower-layer protocol extension. 419 Nonce NAS: 421 This random number is provided by the NAS and carried by the EAP 422 lower-layer protocol. 424 DHCP Key: 426 This session key is 128-bit in length and used as the session key 427 for securing DHCP messages. Figure 1 of [EAP-Key] refers to this 428 derived key as a Transient Session Key (TSK). 430 The lifetime of the DHCP security association has to be limited to 431 prevent the DHCP server from storing state information indefinitely. 432 The lifetime of the DHCP SA SHOULD be set equal to the lifetime of 433 the network access service. The client host, NAS, and the DHCP 434 server SHOULD be (directly or indirectly) aware of this lifetime at 435 the end of a network access AAA. 437 The PaC can at any time trigger a new bootstrapping protocol run to 438 establish a new security association with the DHCP server. The IP 439 address lease time SHOULD be limited by the DHCP SA lifetime 441 5. Delivering DHCP SA 443 When the NAS and the DHCP server are not co-located, the DHCP SA 444 information is carried from the NAS (DHCP relay) to the DHCP server 445 in a DHCP relay agent info option. This sub-option can be included 446 along with the RADIUS attributes sub-option that is carried after the 447 network access authentication. 449 The format of the DHCP SA sub-option is: 451 0 1 2 3 452 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | SubOpt Code | Length | Reserved | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Secret ID | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 + + 461 | | 462 + DHCP Key + 463 | | 464 + + 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Lifetime | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 5: DHCP SA Suboption 472 subopt code: 474 TBD 476 Length: 478 This value is set to 26. 480 Reserved: 482 A 16-bit value reserved for future use. It MUST be initialized to 483 zero by the sender, and ignored by the receiver. 485 Secret ID: 487 This is the 32-bit value assigned by the NAS and used to identify 488 the DHCP key. 490 DHCP Key: 492 128-bit DHCP key computed by the NAS is carried in this field. 494 Lifetime: 496 The lifetime of the DHCP SA. This Unsigned32 value contains the 497 number of seconds remaining before the DHCP SA is considered 498 expired. 500 6. Using DHCP SA 502 Once the DHCP SA is in place, it is used along with RFC 3118 to 503 secure the DHCP protocol exchange. 505 RFC 3118 [RFC3118] defines two security protocols with a newly 506 defined authentication option: 508 o Configuration token 510 o Delayed authentication 512 The generic format of the authentication option is defined in Section 513 2 of RFC 3118 [RFC3118] and contains the following fields: 515 o Code 517 o Delayed authentication 519 The value for the Code field of this authentication option is 90. 521 o Length 523 The Length field indicates the length of the authentication option 524 payload. 526 o Protocol 528 RFC 3118 [RFC3118] defines two values for the Protocol field - zero 529 and one. A value of zero indicates the usage of the configuration 530 token authentication option. 532 As described in Section 4 of RFC 3118 [RFC3118] the configuration 533 token only provides weak entity authentication. Hence its usage is 534 not recommended. This authentication option will not be considered 535 for the purpose of bootstrapping. 537 A value of one in the Protocol field in the authentication option 538 indicates the delayed authentication. The usage of this option is 539 subsequently assumed in this document. 541 Since the value for this field is known in advance it does not need 542 to be negotiated between the DHCP client and DHCP server. 544 o Algorithm 546 RFC 3118 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the 547 Algorithm field). This document assumes that HMAC-MD5 is used to 548 protect DHCP messages. 550 Since the value for this field is known in advance it does not need 551 to be negotiated. [Editor's Note: Consider future algorithm support] 553 o Replay Detection Method (RDM) 555 The value of zero for the RDM name space is assigned to use a 556 monotonically increasing value. 558 Since the value for this field is known in advance it does not need 559 to be negotiated. 561 o Replay Detection 563 This field contains the value that is used for replay protection. 564 This value MUST be monotonically increasing according to the provided 565 replay detection method. An initial value must, however, be set. In 566 case of bootstrapping with EAP an initial value of zero is used. The 567 length of 64 bits (and a start-value of zero) ensures that a sequence 568 number rollover is very unlikely to occur. 570 Since the value for this field is known in advance it does not need 571 to be negotiated. 573 o Authentication Information 575 The content of this field depends on the type of message where the 576 authentication option is used. Section 5.2 of RFC 3118 [RFC3118] 577 does not provide content for the DHCPDISCOVER and the DHCPINFORM 578 message. Hence for these messages no additional considerations need 579 to be specified in this document. 581 Since the value for this field is known in advance it does not need 582 to be negotiated. 584 For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the 585 Authentication Information field is given as: 587 o Secret ID (32 bits) 589 o HMAC-MD5 (128 bits) 591 The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If 592 there are multiple NASes per DHCP server, this identifier space might 593 need to be pre-partitioned among the NASes.] 595 HMAC-MD5 is the output of the key message digest computation. Note 596 that not all fields of the DHCP message are protected as described in 597 RFC 3118 [RFC3118]. 599 7. Security Considerations 601 This document describes a mechanism for dynamically establishing a 602 security association to protect DHCP signaling messages. 604 If the NAS and the DHCP server are co-located then the session keys 605 and the security parameters are transferred locally (via an API 606 call). Some security protocols already exercise similar methodology 607 to separate functionality. 609 If the NAS and the DHCP server are not co-located then there is some 610 similarity to the requirements and issues discussed with the EAP 611 Keying Framework (see [I-D.ietf-eap-keying]). The DHCP key is a TSK 612 (Transient Session Key from [I-D.ietf-eap-keying]). The key is 613 generated by both the DHCP client and the DHCP relay, and transported 614 from the DHCP relay to the DHCP server. The DHCP protocol exchange 615 between the DHCP client and DHCP server is protected using this key. 617 EAP peer (DHCP client) +-----------------------+ DHCP server 618 /\ / 619 / \ Protocol: EAP / 620 / \ lower-layer; / 621 / \ Auth: Mutual; / 622 / \ Unique key: / 623 Protocol: EAP; / \ DHCP key / 624 Auth: Mutual; / \ / Protocol: DHCP, or API; 625 Unique keys: MK, / \ / Auth: Mutual; 626 TEKs, EMSK / \ / Unique key: DHCP key 627 / \ / 628 / \ / 629 Auth. server +----------------------+ Authenticator 630 Protocol: AAA; (NAS, DHCP relay) 631 Auth: Mutual; 632 Unique key: 633 AAA session key 635 Figure 6: Keying Architecture 637 Figure 6 describes the participating entities and the protocols 638 executed among them. It must be ensured that the derived session key 639 between the DHCP client and the DHCP server is fresh and unique. 641 The key transport mechanism, which is used to carry the session key 642 between the NAS and DHCP server, must provide the following 643 functionality: 645 o Confidentiality protection 647 o Replay protection 649 o Integrity protection 651 Furthermore, it is necessary that the two parties (DHCP server and 652 the NAS) authorize the establishment of the DHCP security 653 association. 655 Below we provide a list of security properties of the suggested 656 mechanism: 658 Algorithm independence: 660 This proposal bootstraps a DHCP security association for RFC 3118 661 where only a single integrity algorithm (namely HMAC-MD5) is 662 proposed which is mandatory to implement. 664 Establish strong, fresh session keys (maintain algorithm 665 independence): 667 This scheme relies on EAP methods to provide strong and fresh 668 session keys for each initial authentication and key exchange 669 protocol run. Furthermore the key derivation function provided in 670 Section 4.4 contains random numbers provided by the client and the 671 NAS which additionally add randomness to the generated key. 673 Replay protection: 675 Replay protection is provided at different places. The EAP method 676 executed between the EAP peer and the EAP server MUST provide a 677 replay protection mechanism. Additionally random numbers and the 678 secret ID are included in the key derivation procedure which aim 679 to provide a fresh and unique session key between the DHCP client 680 and the DHCP server. Furthermore, the key transport mechanism 681 between the NAS and the DHCP server must also provide replay 682 protection (in addition to confidentiality protection). Finally, 683 the security mechanisms provided in RFC 3118, for which this draft 684 bootstraps the security association, also provides replay 685 protection. 687 Authenticate all parties: 689 Authentication between the EAP peer and the EAP server is based on 690 the used EAP method. After a successful authentication and 691 protocol run, the host and the NAS in the network provide AAA-key 692 confirmation either based on the 4-way handshake in IEEE 802.11i 693 or based on the protected PANA exchange. DHCP key confirmation 694 between the DHCP client and server is provided with the first 695 protected DHCP message exchange. 697 Perform authorization: 699 Authorization for network access is provided during the EAP 700 exchange. The authorization procedure for DHCP bootstrapping is 701 executed by the NAS before this service is offered to the client. 702 The NAS might choose not to include DHCP-AVP or DHCP SA 703 Configuration Option during network access authorization based on 704 the authorization policies. 706 Maintain confidentiality of session keys: 708 The DHCP session keys are only known to the intended parties 709 (i.e., to the DHCP client, relay, and server). The EAP protocol 710 itself does not transport keys. The exchanged random numbers 711 which are incorporated into the key derivation function do not 712 need to be kept confidential. DHCP relay agent information MUST 713 be protected using [RFC4014] with non-null IPsec encryption. 715 Confirm selection of 'best' cipher-suite: 717 This proposal does not provide confidentiality protection of DHCP 718 signaling messages. Only a single algorithm is offered for 719 integrity protection. Hence no algorithm negotiation and 720 therefore no confirmation of the selection occur. 722 Uniquely name session keys: 724 The DHCP SA is uniquely identified using a Secret ID (described in 725 [RFC3118] and reused in this document). 727 Compromised NAS and DHCP server: 729 A compromised NAS may leak the DHCP session key and the EAP 730 derived session key (e.g., AAA-key). It will furthermore allow 731 corruption of the DHCP protocol executed between the hosts and the 732 DHCP server since NAS either acts as a DHCP relay or a DHCP 733 server. A compromised NAS may also allow creation of further DHCP 734 SAs or other known attacks on the DHCP protocol (e.g., address 735 depletion). A compromised NAS will not be able to modify, replay, 736 inject DHCP messages which use security associations established 737 without the EAP-based bootstrapping mechanism (e.g., manually 738 configured DHCP SAs). On the other hand, a compromised DHCP 739 server may only leak the DHCP key information. AAA-key will not 740 be compromised in this case. 742 Bind key to appropriate context: 744 The key derivation function described in Section 4.4 includes 745 parameters (such as the secret ID and a constant) which prevents 746 reuse of the established session key for other purposes. 748 8. IANA Considerations 750 [Editor's Note: A future version of this draft will provide IANA 751 considerations.] 753 9. Open Issues 755 This document describes a bootstrapping procedure for DHCPv4. The 756 same procedure could be applied for DHCPv6 but is not described in 757 this document. 759 10. Acknowledegments 761 We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for 762 their feedback to this document. Additionally, we would to thank 763 Ralph Droms, Allison Mankin and Barr Hibbs for their support to 764 continue this work. 766 11. References 768 11.1. Normative References 770 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 771 RFC 1661, July 1994. 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, March 1997. 776 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 777 RFC 2131, March 1997. 779 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 780 Messages", RFC 3118, June 2001. 782 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 783 Levkowetz, "Extensible Authentication Protocol (EAP)", 784 RFC 3748, June 2004. 786 [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication 787 Dial-In User Service (RADIUS) Attributes Suboption for the 788 Dynamic Host Configuration Protocol (DHCP) Relay Agent 789 Information Option", RFC 4014, February 2005. 791 11.2. Informative References 793 [I-D.ietf-dhc-relay-agent-ipsec] 794 Droms, R., "Authentication of DHCP Relay Agent Options 795 Using IPsec", draft-ietf-dhc-relay-agent-ipsec-02 (work in 796 progress), May 2005. 798 [I-D.ietf-dhc-v4-threat-analysis] 799 Hibbs, R., Smith, C., Volz, B., and M. Zohar, "Dynamic 800 Host Configuration Protocol for IPv4 (DHCPv4) Threat 801 Analysis", draft-ietf-dhc-v4-threat-analysis-02 (work in 802 progress), April 2004. 804 [I-D.ietf-eap-keying] 805 Aboba, B., "Extensible Authentication Protocol (EAP) Key 806 Management Framework", draft-ietf-eap-keying-09 (work in 807 progress), January 2006. 809 [I-D.ietf-pana-pana] 810 Forsberg, D., "Protocol for Carrying Authentication for 811 Network Access (PANA)", draft-ietf-pana-pana-10 (work in 812 progress), July 2005. 814 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 815 (IKE)", RFC 2409, November 1998. 817 Authors' Addresses 819 Hannes Tschofenig 820 Siemens 821 Otto-Hahn-Ring 6 822 Munich, Bayern 81739 823 Germany 825 Email: Hannes.Tschofenig@siemens.com 826 URI: http://www.tschofenig.com 828 Alper E. Yegin 829 Samsung 830 Istanbul, 831 Turkey 833 Phone: 834 Email: alper01.yegin@partner.samsung.com 836 Dan Forsberg 837 Nokia Research Center 838 P.O. Box 407 839 FIN-00045 840 Finland 842 Phone: +358 50 4839470 843 Email: dan.forsberg@nokia.com 845 Intellectual Property Statement 847 The IETF takes no position regarding the validity or scope of any 848 Intellectual Property Rights or other rights that might be claimed to 849 pertain to the implementation or use of the technology described in 850 this document or the extent to which any license under such rights 851 might or might not be available; nor does it represent that it has 852 made any independent effort to identify any such rights. Information 853 on the procedures with respect to rights in RFC documents can be 854 found in BCP 78 and BCP 79. 856 Copies of IPR disclosures made to the IETF Secretariat and any 857 assurances of licenses to be made available, or the result of an 858 attempt made to obtain a general license or permission for the use of 859 such proprietary rights by implementers or users of this 860 specification can be obtained from the IETF on-line IPR repository at 861 http://www.ietf.org/ipr. 863 The IETF invites any interested party to bring to its attention any 864 copyrights, patents or patent applications, or other proprietary 865 rights that may cover technology that may be required to implement 866 this standard. Please address the information to the IETF at 867 ietf-ipr@ietf.org. 869 Disclaimer of Validity 871 This document and the information contained herein are provided on an 872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 879 Copyright Statement 881 Copyright (C) The Internet Society (2006). This document is subject 882 to the rights, licenses and restrictions contained in BCP 78, and 883 except as set forth therein, the authors retain all their rights. 885 Acknowledgment 887 Funding for the RFC Editor function is currently provided by the 888 Internet Society.