idnits 2.17.1 draft-yegin-eap-boot-rfc3118-03.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, updated by RFC 4748 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 883. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 14, 2008) is 5763 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 424, but not defined -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 1 error (**), 0 flaws (~~), 3 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 Nokia Siemens Networks 4 Intended status: Standards Track A. Yegin 5 Expires: January 15, 2009 Samsung 6 D. Forsberg 7 Nokia 8 July 14, 2008 10 Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based 11 Network Access Authentication 12 draft-yegin-eap-boot-rfc3118-03.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 January 15, 2009. 39 Abstract 41 The DHCP authentication extension (RFC 3118) cannot be widely 42 deployed due to lack of a key agreement protocol. This document 43 outlines how EAP-based network access authentication mechanisms can 44 be used to establish bootstrap keying material that can be used to 45 subsequently use RFC 3118 security. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 3. Overview and Building Blocks . . . . . . . . . . . . . . . . . 6 52 4. Buliding DHCP SA . . . . . . . . . . . . . . . . . . . . . . . 8 53 4.1. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 4.2. PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 4.4. Computing DHCP SA . . . . . . . . . . . . . . . . . . . . 11 57 5. Delivering DHCP SA . . . . . . . . . . . . . . . . . . . . . . 13 58 6. Using DHCP SA . . . . . . . . . . . . . . . . . . . . . . . . 15 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 61 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 62 10. Acknowledegments . . . . . . . . . . . . . . . . . . . . . . . 24 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 65 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 67 Intellectual Property and Copyright Statements . . . . . . . . . . 28 69 1. Introduction 71 The Extensible Authentication Protocol (EAP) [RFC3748] provides a 72 network access authentication framework by carrying authentication 73 process between the hosts and the access networks. The combination 74 of EAP with a AAA architecture allows authentication and 75 authorization of a roaming user to an access network. A successful 76 authentication between a client and the network produces a 77 dynamically created trust relation between the two. Almost all EAP 78 methods (e.g., EAP-TLS, EAP-SIM) are capable of generating 79 cryptographic keys between the EAP peer and the EAP server. Using 80 key transport via the AAA infrastructure the EAP server makes the 81 EAP-provided keying material available to the Authenticator (e.g., 82 Network Access Server; NAS) after a successful authentication 83 attempt. These keys are commonly used in conjunction with per-packet 84 security mechanisms (e.g., link-layer ciphering). This procedure is 85 described in [I-D.ietf-eap-keying]. 87 DHCP [RFC2131] is a protocol which provides a host with configuration 88 parameters. The base DHCP does not include any security mechanism, 89 hence it is vulnerable to a number of security threats. The security 90 considerations section of RFC 2131 [RFC2131] identifies it as "quite 91 insecure" and lists various security threats. 93 RFC 3118 [RFC3118] is the DHCP authentication protocol that defines 94 how to authenticate various DHCP messages. It does not support 95 roaming clients and assumes out-of-band or manual key establishment. 96 These limitations have been inhibiting widespread deployment of this 97 security mechanism as noted in a DHCPv4 threat analysis 98 [I-D.ietf-dhc-v4-threat-analysis]. 100 It is possible to use the authentication and key exchange procedure 101 executed during the network access authentication to bootstrap a 102 security association for DHCP. The access authentication procedure 103 can be utilized to dynamically provide the keying material to RFC 104 3118 based security protection for DHCP. This document defines how 105 to use the EAP-based access authentication procedure to bootstrap RFC 106 3118 security. 108 The general framework of the mechanism described in this I-D can be 109 outlined as follows: 111 1. The client gains network access by utilizing an EAP method that 112 generates session keys. As part of the network access process, 113 the client and the authentication agent (NAS) communicate their 114 intention to create a DHCP security association and exchange the 115 required parameters (e.g., nonce, key ID, etc.) The required 116 information exchange is handled by the EAP lower-layer which also 117 carries EAP. 119 2. Although the newly generated DHCP SA is already available to the 120 DHCP client, in case the NAS (acting as a DHCP relay) and the 121 DHCP server are not co-located, the SA parameters need to be 122 communicated to the DHCP server. This requires a protocol 123 exchange, which can be piggybacked with the DHCP signaling. 125 3. The DHCP signaling that immediately follows the network access 126 authentication process utilizes RFC 3118 to secure the protocol 127 exchange. Both the client and the server rely on the DHCP SA to 128 compute and verify the authentication codes. 130 This framework requires extensions to the EAP lower-layers (PPP 131 [RFC1661], IEEE 802.1X , PANA [RFC5191]) to carry the supplemental 132 parameters required for the generation of the DHCP SA. Another 133 extension is required to carry the DHCP SA parameters from a DHCP 134 relay to a DHCP server. RFC 3118 can be used without any 135 modifications or extensions. 137 2. Terminology 139 In this document, the key words "MAY", "MUST, "MUST NOT", 140 OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be 141 interpreted as described in [RFC2119]. 143 This document uses the following terms: 145 DHCP Security Association: 147 To secure DHCP messages a number of parameters including the key 148 that is shared between the client (DHCP client) and the DHCP 149 server have to be established. These parameters are collectively 150 referred to as DHCP security association (or in short DHCP SA). 152 DHCP SA can be considered as a group security association. The 153 DHCP SA parameters are provided to the DHCP server as soon as the 154 client chooses the server to carry out DHCP. The same DHCP SA can 155 be used by any one of the DHCP servers that are available to the 156 client. 158 DHCP Key: 160 This term refers to the fresh and unique session key dynamically 161 established between the DHCP client and the DHCP server. This key 162 is used to protect DHCP messages as described in [RFC3118]. 164 3. Overview and Building Blocks 166 The bootstrapping mechanism requires protocol interaction between the 167 client host (which acts as a DHCP client), the NAS and the DHCP 168 server. A security association will be established between the DHCP 169 server and the DHCP client to protect the DHCP messages. 171 A DHCP SA is generated based on the EAP method derived key after a 172 successful EAP method protocol run. Both the client and the NAS 173 should agree on the generation of a DHCP SA after the EAP SA is 174 created. This involves a handshake between the two and exchange of 175 additional parameters (such as nonce, key ID, etc.). These 176 additional information needs to be carried over the EAP lower-layer 177 that also carries the EAP payloads. 179 The DHCP SA is ultimately needed by the DHCP client and the DHCP 180 server. On the network side, the DHCP SA information needs to be 181 transferred from the NAS (where it is generated) to the DHCP server 182 (where it will be used). On the client host side, it is transferred 183 from the network access authentication client to the DHCP client. 185 NAS is always located one IP hop away from the client. If the DHCP 186 server is on the same link, it can be co-located with the NAS. When 187 the NAS and the DHCP server are co-located, an internal mechanism, 188 such as an API, is sufficient for transferring the SA information. 189 If the DHCP server is multiple hops away from the DHCP client, then 190 there must be a DHCP relay on the same link as the client. In that 191 case, the NAS should be co-located with the DHCP relay 193 [RFC4014] enables transmission of AAA-related RADIUS attributes from 194 a DHCP relay to a DHCP server in the form of relay agent information 195 options. DHCP SA is generated at the end of the AAA process, and 196 therefore it can be provided to the DHCP server in a sub-option 197 carried along with other AAA-related information. Confidentiality, 198 replay, and integrity protection of this exchange MUST be provided. 199 [I-D.ietf-dhc-relay-agent-ipsec] proposes IPsec protection of the 200 DHCP messages exchanged between the DHCP relay and the DHCP server. 201 DHCP objects (protected with IPsec) can therefore be used to 202 communicate the necessary parameters. 204 Two different deployment scenarios are illustrated in Figure 1. 206 +---------+ +------------------+ 207 |EAP Peer/| |EAP Authenticator/| 208 | DHCP |<============>| DHCP server | 209 | client | EAP and DHCP | | 210 +---------+ +------------------+ 211 Client Host NAS 213 +---------+ +------------------+ +-----------+ 214 |EAP Peer/| |EAP Authenticator/| | | 215 | DHCP |<============>| DHCP relay |<========>|DHCP server| 216 | client | EAP and DHCP | | DHCP | | 217 +---------+ +------------------+ +-----------+ 218 Client Host NAS 220 Figure 1: Protocols and end points. 222 When the DHCP SA information is received by the DHCP server and 223 client, it can be used along with RFC 3118 to protect DHCP messages 224 against various security threats. This draft provides the guidelines 225 regarding how the RFC 3118 protocol fields should be filled in based 226 on the DHCP SA. 228 4. Buliding DHCP SA 230 DHCP SA is created at the end of the EAP-based access authentication 231 process. This section describes extensions to the EAP lower-layers 232 for exchanging the additional information, and the process of 233 generating the DHCP SA. 235 4.1. 802.1X 237 This work needs to be done in the IEEE and hence this section is 238 intentionally left blank. 240 4.2. PPP 242 A new IPCP configuration option is defined in order to bootstrap DHCP 243 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 The detailed DHCP-SA Configuration Option is presented below. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Length | Reserved | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Secret ID | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 ~ Nonce Data ~ 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 2: DHCP SA Configuration Option 263 Type 265 o TBD 267 Length 269 o >=24 271 Reserved 273 o A 16-bit value reserved for future use. It MUST be initialized to 274 zero by the sender, and ignored by the receiver. 276 Secret ID 278 o 32 bit value that identifies the DHCP Key produced as a result of 279 the bootstrapping process. This value is determined by the NAS 280 and sent to the client. The NAS determines this value by randomly 281 picking a number from the available secret ID pool. If the client 282 does not request DHCP-SA configuration option, this value is 283 returned to the available identifiers pool. Otherwise, it is 284 allocated to the client until the DHCP SA expires. The client 285 MUST set this field to all 0s in its own request. 287 Nonce Data (variable length) 289 o Contains the random data generated by the transmitting entity. 290 This field contains the Nonce_client value when the option is sent 291 by client, and the Nonce_NAS value when the option is sent by NAS. 292 Nonce value MUST be randomly chosen and MUST be at least 128 bits 293 in size. Nonce values MUST NOT be reused. 295 4.3. PANA 297 A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP- 298 AVP is included in the PANA-Bind-Request message if PAA (NAS) is 299 offering DHCP SA bootstrapping service. If the PaC wants to proceed 300 with creating DHCP SA at the end of the PANA authentication, it MUST 301 include DHCP-AVP in its PANA-Bind-Answer message. 303 Absence of this AVP in the PANA-Bind-Request message sent by the PAA 304 indicates unavailability of this additional service. In that case, 305 PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore 306 received DHCP-AVP. When this AVP is received by the PaC, it may or 307 may not include the AVP in its response depending on its desire to 308 create a DHCP SA. A DHCP SA can be created as soon as each entity 309 has received and sent one DHCP-AVP. 311 The detailed DHCP-AVP format is presented below: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | AVP Code | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | AVP Flags | AVP Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Secret ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 ~ Nonce Data ~ 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 3: DHCP AVP Format 329 AVP Code 331 o TBD 333 AVP Flags 335 o The AVP Flags field is eight bits. The following bits are 336 assigned: 338 0 1 2 3 4 5 6 7 339 +-+-+-+-+-+-+-+-+ 340 |V M r r r r r r| 341 +-+-+-+-+-+-+-+-+ 343 Figure 4: DHCP AVP Flags 345 M(andatory) 347 o The 'M' Bit, known as the Mandatory bit, indicates whether support 348 of the AVP is required. This bit is not set in DHCP-AVP. 350 V(endor) 352 o The 'V' bit, known as the Vendor-Specific bit, indicates whether 353 the optional Vendor-Id field is present in the AVP header. This 354 bit is not set in DHCP-AVP. 356 r(eserved) 358 o These flag bits are reserved for future use, and MUST be set to 359 zero, and ignored by the receiver. 361 AVP Length 363 o The AVP Length field is three octets, and indicates the number of 364 octets in this AVP including the AVP Code, AVP Length, AVP Flags, 365 and AVP data. 367 Secret ID 369 o A 32-bit value that identifies the DHCP Key produced as a result 370 of the bootstrapping process. This value is determined by the PAA 371 and sent to the PaC. The PAA determines this value by randomly 372 picking a number from the available secret ID pool. If PaC's 373 response does not contain DHCP-AVP then this value is returned to 374 the available identifiers pool. Otherwise, it is allocated to the 375 PaC until the DHCP SA expires. The PaC MUST set this field to all 376 0s in its response. 378 Nonce Data (variable length) 380 o Contains the random data generated by the transmitting entity. 381 This field contains the Nonce_client value when the AVP is sent by 382 PaC, and the Nonce_NAS value when the AVP is sent by PAA. Nonce 383 value MUST be randomly chosen and MUST be at least 128 bits in 384 size. Nonce values MUST NOT be reused. 386 4.4. Computing DHCP SA 388 The key derivation procedure is reused from IKE [RFC2409]. The 389 character '|' denotes concatenation. 391 DHCP Key = HMAC-SHA1(MSK, const | Secret ID | Nonce_client | 392 Nonce_NAS) 394 The values have the following meaning: 396 MSK: 398 A key derived by the EAP peer and EAP (authentication) server at 399 the end of the successful network access AAA. 401 const: 403 This is a string constant. The value of the const parameter is 404 set to "EAP RFC 3118 Bootstrapping". 406 Secret ID: 408 The unique identifier of the DHCP key as carried by the EAP lower- 409 layer protocol extension. 411 Nonce Client: 413 This random number is provided by the client and carried by the 414 EAP lower-layer protocol extension. 416 Nonce NAS: 418 This random number is provided by the NAS and carried by the EAP 419 lower-layer protocol. 421 DHCP Key: 423 This session key is 128-bit in length and used as the session key 424 for securing DHCP messages. Figure 1 of [EAP-Key] refers to this 425 derived key as a Transient Session Key (TSK). 427 The lifetime of the DHCP security association has to be limited to 428 prevent the DHCP server from storing state information indefinitely. 429 The lifetime of the DHCP SA SHOULD be set equal to the lifetime of 430 the network access service. The client host, NAS, and the DHCP 431 server SHOULD be (directly or indirectly) aware of this lifetime at 432 the end of a network access AAA. 434 The PaC can at any time trigger a new bootstrapping protocol run to 435 establish a new security association with the DHCP server. The IP 436 address lease time SHOULD be limited by the DHCP SA lifetime 438 5. Delivering DHCP SA 440 When the NAS and the DHCP server are not co-located, the DHCP SA 441 information is carried from the NAS (DHCP relay) to the DHCP server 442 in a DHCP relay agent info option. This sub-option can be included 443 along with the RADIUS attributes sub-option that is carried after the 444 network access authentication. 446 The format of the DHCP SA sub-option is: 448 0 1 2 3 449 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | SubOpt Code | Length | Reserved | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Secret ID | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 + + 458 | | 459 + DHCP Key + 460 | | 461 + + 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Lifetime | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 5: DHCP SA Suboption 469 subopt code: 471 TBD 473 Length: 475 This value is set to 26. 477 Reserved: 479 A 16-bit value reserved for future use. It MUST be initialized to 480 zero by the sender, and ignored by the receiver. 482 Secret ID: 484 This is the 32-bit value assigned by the NAS and used to identify 485 the DHCP key. 487 DHCP Key: 489 128-bit DHCP key computed by the NAS is carried in this field. 491 Lifetime: 493 The lifetime of the DHCP SA. This Unsigned32 value contains the 494 number of seconds remaining before the DHCP SA is considered 495 expired. 497 6. Using DHCP SA 499 Once the DHCP SA is in place, it is used along with RFC 3118 to 500 secure the DHCP protocol exchange. 502 RFC 3118 [RFC3118] defines two security protocols with a newly 503 defined authentication option: 505 o Configuration token 507 o Delayed authentication 509 The generic format of the authentication option is defined in Section 510 2 of RFC 3118 [RFC3118] and contains the following fields: 512 o Code 514 o Delayed authentication 516 The value for the Code field of this authentication option is 90. 518 o Length 520 The Length field indicates the length of the authentication option 521 payload. 523 o Protocol 525 RFC 3118 [RFC3118] defines two values for the Protocol field - zero 526 and one. A value of zero indicates the usage of the configuration 527 token authentication option. 529 As described in Section 4 of RFC 3118 [RFC3118] the configuration 530 token only provides weak entity authentication. Hence its usage is 531 not recommended. This authentication option will not be considered 532 for the purpose of bootstrapping. 534 A value of one in the Protocol field in the authentication option 535 indicates the delayed authentication. The usage of this option is 536 subsequently assumed in this document. 538 Since the value for this field is known in advance it does not need 539 to be negotiated between the DHCP client and DHCP server. 541 o Algorithm 543 RFC 3118 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the 544 Algorithm field). This document assumes that HMAC-MD5 is used to 545 protect DHCP messages. 547 Since the value for this field is known in advance it does not need 548 to be negotiated. [Editor's Note: Based on crypto agility 549 requirements it seems reasonable to consider future algorithm support 550 as well.] 552 o Replay Detection Method (RDM) 554 The value of zero for the RDM name space is assigned to use a 555 monotonically increasing value. 557 Since the value for this field is known in advance it does not need 558 to be negotiated. 560 o Replay Detection 562 This field contains the value that is used for replay protection. 563 This value MUST be monotonically increasing according to the provided 564 replay detection method. An initial value must, however, be set. In 565 case of bootstrapping with EAP an initial value of zero is used. The 566 length of 64 bits (and a start-value of zero) ensures that a sequence 567 number rollover is very unlikely to occur. 569 Since the value for this field is known in advance it does not need 570 to be negotiated. 572 o Authentication Information 574 The content of this field depends on the type of message where the 575 authentication option is used. Section 5.2 of RFC 3118 [RFC3118] 576 does not provide content for the DHCPDISCOVER and the DHCPINFORM 577 message. Hence for these messages no additional considerations need 578 to be specified in this document. 580 Since the value for this field is known in advance it does not need 581 to be negotiated. 583 For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the 584 Authentication Information field is given as: 586 o Secret ID (32 bits) 588 o HMAC-MD5 (128 bits) 590 The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If 591 there are multiple NASes per DHCP server, this identifier space might 592 need to be pre-partitioned among the NASes.] 593 HMAC-MD5 is the output of the key message digest computation. Note 594 that not all fields of the DHCP message are protected as described in 595 RFC 3118 [RFC3118]. 597 7. Security Considerations 599 This document describes a mechanism for dynamically establishing a 600 security association to protect DHCP signaling messages. 602 If the NAS and the DHCP server are co-located then the session keys 603 and the security parameters are transferred locally (via an API 604 call). Some security protocols already exercise similar methodology 605 to separate functionality. 607 If the NAS and the DHCP server are not co-located then there is some 608 similarity to the requirements and issues discussed with the EAP 609 Keying Framework (see [I-D.ietf-eap-keying]). The DHCP key is a 610 Transient Session Key (TEK) from [I-D.ietf-eap-keying]. The key is 611 generated by both the DHCP client and the DHCP relay, and transported 612 from the DHCP relay to the DHCP server. The DHCP protocol exchange 613 between the DHCP client and DHCP server is protected using this key. 615 EAP peer (DHCP client) +-----------------------+ DHCP server 616 /\ / 617 / \ Protocol: EAP / 618 / \ lower-layer; / 619 / \ Auth: Mutual; / 620 / \ Unique key: / 621 Protocol: EAP; / \ DHCP key / 622 Auth: Mutual; / \ / Protocol: DHCP, or API; 623 Unique keys:MSK, / \ / Auth: Mutual; 624 EMSK / \ / Unique key: DHCP key 625 / \ / 626 / \ / 627 Auth. server +----------------------+ Authenticator 628 Protocol: AAA; (NAS, DHCP relay) 629 Auth: Mutual; 630 Unique key: 631 AAA session key 633 Figure 6: Keying Architecture 635 Figure 6 describes the participating entities and the protocols 636 executed among them. It must be ensured that the derived session key 637 between the DHCP client and the DHCP server is fresh and unique. 639 The key transport mechanism, which is used to carry the session key 640 between the NAS and DHCP server, must provide the following 641 functionality: 643 o Confidentiality protection 645 o Replay protection 647 o Integrity protection 649 Furthermore, it is necessary that the two parties (DHCP server and 650 the NAS) authorize the establishment of the DHCP security 651 association. 653 Below we provide a list of security properties of the suggested 654 mechanism: 656 Algorithm independence: 658 This proposal bootstraps a DHCP security association for RFC 3118 659 where only a single integrity algorithm (namely HMAC-MD5) is 660 proposed which is mandatory to implement. 662 Establish strong, fresh session keys (maintain algorithm 663 independence): 665 This scheme relies on EAP methods to provide strong and fresh 666 session keys for each initial authentication and key exchange 667 protocol run. Furthermore the key derivation function provided in 668 Section 4.4 contains random numbers provided by the client and the 669 NAS which additionally add randomness to the generated key. 671 Replay protection: 673 Replay protection is provided at different places. The EAP method 674 executed between the EAP peer and the EAP server MUST provide a 675 replay protection mechanism. Additionally random numbers and the 676 secret ID are included in the key derivation procedure which aim 677 to provide a fresh and unique session key between the DHCP client 678 and the DHCP server. Furthermore, the key transport mechanism 679 between the NAS and the DHCP server must also provide replay 680 protection (in addition to confidentiality protection). Finally, 681 the security mechanisms provided in RFC 3118, for which this draft 682 bootstraps the security association, also provides replay 683 protection. 685 Authenticate all parties: 687 Authentication between the EAP peer and the EAP server is based on 688 the used EAP method. After a successful authentication and 689 protocol run, the host and the NAS in the network provide MSK 690 confirmation either based on the 4-way handshake in IEEE 802.11i 691 or based on the protected PANA exchange. DHCP key confirmation 692 between the DHCP client and server is provided with the first 693 protected DHCP message exchange. 695 Perform authorization: 697 Authorization for network access is provided during the EAP 698 exchange. The authorization procedure for DHCP bootstrapping is 699 executed by the NAS before this service is offered to the client. 700 The NAS might choose not to include DHCP-AVP or DHCP SA 701 Configuration Option during network access authorization based on 702 the authorization policies. 704 Maintain confidentiality of session keys: 706 The DHCP session keys are only known to the intended parties 707 (i.e., to the DHCP client, relay, and server). The EAP protocol 708 itself does not transport keys. The exchanged random numbers 709 which are incorporated into the key derivation function do not 710 need to be kept confidential. DHCP relay agent information MUST 711 be protected using [RFC4014] with non-null IPsec encryption. 713 Confirm selection of 'best' cipher-suite: 715 This proposal does not provide confidentiality protection of DHCP 716 signaling messages. Only a single algorithm is offered for 717 integrity protection. Hence no algorithm negotiation and 718 therefore no confirmation of the selection occur. 720 Uniquely name session keys: 722 The DHCP SA is uniquely identified using a Secret ID (described in 723 [RFC3118] and reused in this document). 725 Compromised NAS and DHCP server: 727 A compromised NAS may leak the DHCP session key and the EAP 728 derived session key (e.g., MSK). It will furthermore allow 729 corruption of the DHCP protocol executed between the hosts and the 730 DHCP server since NAS either acts as a DHCP relay or a DHCP 731 server. A compromised NAS may also allow creation of further DHCP 732 SAs or other known attacks on the DHCP protocol (e.g., address 733 depletion). A compromised NAS will not be able to modify, replay, 734 inject DHCP messages which use security associations established 735 without the EAP-based bootstrapping mechanism (e.g., manually 736 configured DHCP SAs). On the other hand, a compromised DHCP 737 server may only leak the DHCP key information. MSK will not be 738 compromised in this case. 740 Bind key to appropriate context: 742 The key derivation function described in Section 4.4 includes 743 parameters (such as the secret ID and a constant) which prevents 744 reuse of the established session key for other purposes. 746 8. IANA Considerations 748 [Editor's Note: A future version of this draft will provide IANA 749 considerations.] 751 9. Open Issues 753 This document describes a bootstrapping procedure for DHCPv4. The 754 same procedure could be applied for DHCPv6 but is not described in 755 this document. 757 10. Acknowledegments 759 We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for 760 their feedback to this document. Additionally, we would to thank 761 Ralph Droms, Allison Mankin and Barr Hibbs for their support to 762 continue this work. 764 11. References 766 11.1. Normative References 768 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 769 RFC 1661, July 1994. 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, March 1997. 774 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 775 RFC 2131, March 1997. 777 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 778 Messages", RFC 3118, June 2001. 780 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 781 Levkowetz, "Extensible Authentication Protocol (EAP)", 782 RFC 3748, June 2004. 784 [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication 785 Dial-In User Service (RADIUS) Attributes Suboption for the 786 Dynamic Host Configuration Protocol (DHCP) Relay Agent 787 Information Option", RFC 4014, February 2005. 789 11.2. Informative References 791 [I-D.ietf-dhc-relay-agent-ipsec] 792 Droms, R., "Authentication of DHCP Relay Agent Options 793 Using IPsec", draft-ietf-dhc-relay-agent-ipsec-02 (work in 794 progress), May 2005. 796 [I-D.ietf-dhc-v4-threat-analysis] 797 Hibbs, R., "Dynamic Host Configuration Protocol for IPv4 798 (DHCPv4) Threat Analysis", 799 draft-ietf-dhc-v4-threat-analysis-03 (work in progress), 800 June 2006. 802 [I-D.ietf-eap-keying] 803 Aboba, B., Simon, D., and P. Eronen, "Extensible 804 Authentication Protocol (EAP) Key Management Framework", 805 draft-ietf-eap-keying-22 (work in progress), 806 November 2007. 808 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 809 (IKE)", RFC 2409, November 1998. 811 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 813 Yegin, "Protocol for Carrying Authentication for Network 814 Access (PANA)", RFC 5191, May 2008. 816 Authors' Addresses 818 Hannes Tschofenig 819 Nokia Siemens Networks 820 Linnoitustie 6 821 Espoo 02600 822 Finland 824 Phone: +358 (50) 4871445 825 Email: Hannes.Tschofenig@gmx.net 826 URI: http://www.tschofenig.priv.at 828 Alper E. Yegin 829 Samsung 830 Istanbul, 831 Turkey 833 Phone: 834 Email: a.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 Full Copyright Statement 847 Copyright (C) The IETF Trust (2008). 849 This document is subject to the rights, licenses and restrictions 850 contained in BCP 78, and except as set forth therein, the authors 851 retain all their rights. 853 This document and the information contained herein are provided on an 854 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 855 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 856 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 857 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 858 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 859 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 861 Intellectual Property 863 The IETF takes no position regarding the validity or scope of any 864 Intellectual Property Rights or other rights that might be claimed to 865 pertain to the implementation or use of the technology described in 866 this document or the extent to which any license under such rights 867 might or might not be available; nor does it represent that it has 868 made any independent effort to identify any such rights. Information 869 on the procedures with respect to rights in RFC documents can be 870 found in BCP 78 and BCP 79. 872 Copies of IPR disclosures made to the IETF Secretariat and any 873 assurances of licenses to be made available, or the result of an 874 attempt made to obtain a general license or permission for the use of 875 such proprietary rights by implementers or users of this 876 specification can be obtained from the IETF on-line IPR repository at 877 http://www.ietf.org/ipr. 879 The IETF invites any interested party to bring to its attention any 880 copyrights, patents or patent applications, or other proprietary 881 rights that may cover technology that may be required to implement 882 this standard. Please address the information to the IETF at 883 ietf-ipr@ietf.org.