idnits 2.17.00 (12 Aug 2021) /tmp/idnits31774/draft-yegin-eap-boot-rfc3118-01.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 924. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 940), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 1070 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 (January 2005) is 6334 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 77, but not defined == Missing Reference: 'EAP-Key' is mentioned on line 441, but not defined == Unused Reference: 'RFC2408' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'RFC2548' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'CFB02' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'SE03' is defined on line 857, 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: 10 errors (**), 0 flaws (~~), 11 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yegin 3 Internet Draft Samsung 4 H. Tschofenig 5 Siemens Corporate Technology 6 D. Forsberg 7 Nokia 9 Expires: July 2005 January 2005 11 Bootstrapping RFC3118 Delayed DHCP Authentication 12 Using EAP-based Network Access Authentication 13 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 DHCP authentication extension (RFC3118) cannot be widely deployed 47 due to lack of an out-of-band key agreement protocol for DHCP 48 clients and servers. This draft outlines how EAP-based network 49 access authentication mechanisms can be used to establish a local 50 trust relation and generate keys that can be used in conjunction 51 with RFC3118. 53 Yegin, et al. Expires July 2005 54 [Page 2] EAP-boot-RFC3118 January 2005 56 Table of Contents 58 1.0 Introduction.................................................2 59 2.0 Terminology..................................................3 60 3.0 Overview and Building Blocks.................................4 61 4.0 Building DHCP SA.............................................5 62 4.1. 802.1X....................................................5 63 4.2. PPP.......................................................5 64 4.3. PANA......................................................7 65 4.4. Computing DHCP SA.........................................8 66 5.0 Delivering DHCP SA..........................................10 67 6.0 Using DHCP SA...............................................11 68 7.0 Security Considerations.....................................13 69 8.0 IANA Considerations.........................................16 70 9.0 Open Issues.................................................16 71 10.0 References.................................................16 72 11.0 Acknowledgments............................................17 73 12.0 Author's Addresses.........................................18 75 1.0 Introduction 77 EAP [EAP] provides a network access authentication framework by 78 carrying authentication process between the hosts and the access 79 networks. The combination of EAP with a AAA architecture allows 80 authentication and authorization of a roaming user to an access 81 network. A successful authentication between a client and the 82 network produces a dynamically created trust relation between the 83 two. Various EAP authentication methods (e.g., EAP-TLS, EAP-SIM) 84 are capable of generating cryptographic keys between the client and 85 the local authentication agent (network access server - NAS) after 86 the successful authentication. These keys are commonly used in 87 conjunction with per-packet security mechanisms (e.g., link-layer 88 ciphering). 90 DHCP [RFC2131] is a protocol which provides an end host with the 91 configuration parameters. The base DHCP does not include any 92 security mechanism, hence it is vulnerable to a number of security 93 threats. Security considerations section of RFC 2131 identifies this 94 protocol as "quite insecure" and lists various security threats. 96 RFC 3118 is the DHCP authentication protocol which defines how to 97 authenticate various DHCP messages. It does not support roaming 98 clients and assumes out-of band or manual key establishment. These 99 limitations have been inhibiting widespread deployment of this 100 security mechanism [DHC-THREAT]. 102 It is possible to use the authentication and key exchange procedure 103 executed during the network access authentication to bootstrap a 104 security association for DHCP. The trust relation created during the 105 access authentication process can be used with RFC 3118 to provide 107 Yegin, et al. Expires July 2005 108 [Page 3] EAP-boot-RFC3118 January 2005 110 security for DHCP. This document defines how to use EAP-based access 111 authentication process to bootstrap RFC 3118 for securing DHCP. 113 The general framework of the mechanism described in this I-D can be 114 outlined as follows: 116 (1) The client gains network access by utilizing an EAP 117 authentication method that generates session keys. As part of 118 the network access process, the client and the authentication 119 agent (NAS) communicate their intention to create a DHCP 120 security association and exchange the required parameters 121 (e.g., nonce, key ID, etc.) The required information exchange 122 is handled by the EAP lower-layer which also carries EAP. 124 (2) Although the newly generated DHCP SA is already available to 125 the DHCP client, in case the NAS (acting as a DHCP relay) and 126 the DHCP server are not co-located, the SA parameters need to 127 be communicated to the DHCP server. This requires a protocol 128 exchange, which can be piggybacked with the DHCP signaling. 130 (3) The DHCP signaling that immediately follows the network access 131 authentication process utilizes RFC3118 to secure the protocol 132 exchange. Both the client and the server rely on the DHCP SA 133 to compute and verify the authentication codes. 135 This framework requires extensions to the EAP lower-layers (PPP 136 [PPP], IEEE 802.1X [8021X], PANA [PANA]) to carry the supplemental 137 parameters required for the generation of the DHCP SA. Another 138 extension is required to carry the DHCP SA parameters from a DHCP 139 relay to a DHCP server. RFC3118 can be used without any 140 modifications or extensions. 142 2.0 Terminology 144 This document uses the following terms: 146 - DHCP Security Association 148 To secure DHCP messages a number of parameters including the key 149 that is shared between the client (DHCP client) and the DHCP server 150 have to be established. These parameters are collectively referred 151 to as DHCP security association (or in short DHCP SA). 153 DHCP SA can be considered as a group security association. The DHCP 154 SA parameters are provided to the DHCP server as soon as the client 155 chooses the server to carry out DHCP. The same DHCP SA can be used 156 by any one of the DHCP servers that are available to the client. 158 Yegin, et al. Expires July 2005 159 [Page 4] EAP-boot-RFC3118 January 2005 161 - DHCP Key 163 This term refers to the fresh and unique session key dynamically 164 established between the DHCP client and the DHCP server. This key is 165 used to protect DHCP messages as described in [RFC3118]. 167 In this document, the key words "MAY", "MUST, "MUST NOT", 168 OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be 169 interpreted as described in [RFC2119]. 171 3.0 Overview and Building Blocks 173 The bootstrapping mechanism requires protocol interaction between 174 the client host (which acts as a DHCP client), the NAS and the DHCP 175 server. A security association will be established between the DHCP 176 server and the DHCP client to protect the DHCP messages. 178 A DHCP SA is generated based on the EAP SA after a successful EAP 179 authentication. Both the client and the NAS should agree on the 180 generation of a DHCP SA after the EAP SA is created. This involves a 181 handshake between the two and exchange of additional parameters 182 (such as nonce, key ID, etc.). These additional information needs to 183 be carried over the EAP lower-layer that also carries the EAP 184 payloads. 186 The DHCP SA is ultimately needed by the DHCP client and the DHCP 187 server. On the network side, the DHCP SA information needs to be 188 transferred from the NAS (where it is generated) to the DHCP server 189 (where it will be used). On the client host side, it is transferred 190 from the network access authentication client to the DHCP client. 192 NAS is always located one IP hop away from the client. If the DHCP 193 server is on the same link, it can be co-located with the NAS. When 194 the NAS and the DHCP server are co-located, an internal mechanism, 195 such as an API, is sufficient for transferring the SA information. 196 If the DHCP server is multiple hops away from the DHCP client, then 197 there must be a DHCP relay on the same link as the client. In that 198 case, the NAS should be co-located with the DHCP relay. 200 [DS02] enables transmission of AAA-related RADIUS attributes from a 201 DHCP relay to a DHCP server in the form of relay agent information 202 options. DHCP SA is generated at the end of the AAA process, and 203 therefore it can be provided to the DHCP server in a sub-option 204 carried along with other AAA-related information. Confidentiality, 205 replay, and integrity protection of this exchange MUST be provided. 206 [RD03] proposes IPsec protection of the DHCP messages exchanged 207 between the DHCP relay and the DHCP server. DHCP objects (protected 208 with IPsec) can therefore be used to communicate the necessary 209 parameters. 211 Yegin, et al. Expires July 2005 212 [Page 5] EAP-boot-RFC3118 January 2005 214 Two different deployment scenarios are illustrated in Figure 1. 216 +---------+ +------------------+ 217 |EAP Peer/| |EAP Authenticator/| 218 | DHCP |<============>| DHCP server | 219 | client | EAP and DHCP | | 220 +---------+ +------------------+ 221 Client Host NAS 223 +---------+ +------------------+ +-----------+ 224 |EAP Peer/| |EAP Authenticator/| | | 225 | DHCP |<============>| DHCP relay |<========>|DHCP server| 226 | client | EAP and DHCP | | DHCP | | 227 +---------+ +------------------+ +-----------+ 228 Client Host NAS 230 Figure 1: Protocols and end points. 232 When the DHCP SA information is received by the DHCP server and 233 client, it can be used along with RFC3118 to protect DHCP messages 234 against various security threats. This draft provides the guidelines 235 regarding how the RFC3118 protocol fields should be filled in based 236 on the DHCP SA. 238 4.0 Building DHCP SA 240 DHCP SA is created at the end of the EAP-based access authentication 241 process. This section describes extensions to the EAP lower-layers 242 for exchanging the additional information, and the process of 243 generating the DHCP SA. 245 4.1. 802.1X 247 TBD. 249 4.2. PPP 251 A new IPCP configuration option is defined in order to bootstrap 252 DHCP SA between the PPP peers. Each end of the link must separately 253 request this option for mutual establishment of DHCP SA. Only one 254 side sending the option will not produce any state. 256 Yegin, et al. Expires July 2005 257 [Page 6] EAP-boot-RFC3118 January 2005 259 The detailed DHCP-SA Configuration Option is presented below. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Secret ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 ~ Nonce Data ~ 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Type 275 TBD 277 Length 279 >=24 281 Reserved 283 A 16-bit value reserved for future use. It MUST be initialized 284 to zero by the sender, and ignored by the receiver. 286 Secret ID 288 32 bit value that identifies the DHCP Key produced as a result 289 of the bootstrapping process. This value is determined by the 290 NAS and sent to the client. The NAS determines this value by 291 randomly picking a number from the available secret ID pool. If 292 the client does not request DHCP-SA configuration option, this 293 value is returned to the available identifiers pool. Otherwise, 294 it is allocated to the client until the DHCP SA expires. The 295 client MUST set this field to all 0s in its own request. 297 Nonce Data (variable length) 299 Contains the random data generated by the transmitting entity. 300 This field contains the Nonce_client value when the option is 301 sent by client, and the Nonce_NAS value when the option is sent 302 by NAS. Nonce value MUST be randomly chosen and MUST be at least 303 128 bits in size. Nonce values MUST NOT be reused. 305 Yegin, et al. Expires July 2005 306 [Page 7] EAP-boot-RFC3118 January 2005 308 4.3. PANA 310 A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP- 311 AVP is included in the PANA-Bind-Request message if PAA (NAS) is 312 offering DHCP SA bootstrapping service. If the PaC wants to proceed 313 with creating DHCP SA at the end of the PANA authentication, it MUST 314 include DHCP-AVP in its PANA-Bind-Answer message. 316 Absence of this AVP in the PANA-Bind-Request message sent by the PAA 317 indicates unavailability of this additional service. In that case, 318 PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore 319 received DHCP-AVP. When this AVP is received by the PaC, it may or 320 may not include the AVP in its response depending on its desire to 321 create a DHCP SA. A DHCP SA can be created as soon as each entity 322 has received and sent one DHCP-AVP. 324 The detailed DHCP-AVP format is presented below. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | AVP Code | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | AVP Flags | AVP Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Secret ID | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 ~ Nonce Data ~ 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 AVP Code 342 TBD 344 AVP Flags 346 The AVP Flags field is eight bits. The following bits are 347 assigned: 349 0 1 2 3 4 5 6 7 350 +-+-+-+-+-+-+-+-+ 351 |V M r r r r r r| 352 +-+-+-+-+-+-+-+-+ 354 M(andatory) 356 - The 'M' Bit, known as the Mandatory bit, indicates 357 whether support of the AVP is required. This bit is not 358 set in DHCP-AVP. 360 Yegin, et al. Expires July 2005 361 [Page 8] EAP-boot-RFC3118 January 2005 363 V(endor) 365 - The 'V' bit, known as the Vendor-Specific bit, indicates 366 whether the optional Vendor-Id field is present in the AVP 367 header. This bit is not set in DHCP-AVP. 369 r(eserved) 371 - These flag bits are reserved for future use, and MUST be 372 set to zero, and ignored by the receiver. 374 AVP Length 376 The AVP Length field is three octets, and indicates the number 377 of octets in this AVP including the AVP Code, AVP Length, AVP 378 Flags, and AVP data. 380 Secret ID 382 A 32-bit value that identifies the DHCP Key produced as a 383 result of the bootstrapping process. This value is determined 384 by the PAA and sent to the PaC. The PAA determines this value 385 by randomly picking a number from the available secret ID pool. 386 If PaC's response does not contain DHCP-AVP then this value is 387 returned to the available identifiers pool. Otherwise, it is 388 allocated to the PaC until the DHCP SA expires. The PaC MUST 389 set this field to all 0s in its response. 391 Nonce Data (variable length) 393 Contains the random data generated by the transmitting entity. 394 This field contains the Nonce_client value when the AVP is sent 395 by PaC, and the Nonce_NAS value when the AVP is sent by PAA. 396 Nonce value MUST be randomly chosen and MUST be at least 128 397 bits in size. Nonce values MUST NOT be reused. 399 4.4. Computing DHCP SA 401 The key derivation procedure is reused from IKE [RFC2409]. The 402 character '|' denotes concatenation. 404 DHCP Key = HMAC-MD5(AAA-key, const | Secret ID | Nonce_client | 405 Nonce_NAS) 407 Yegin, et al. Expires July 2005 408 [Page 9] EAP-boot-RFC3118 January 2005 410 The values have the following meaning: 412 - AAA-key: 414 A key derived by the EAP peer and EAP (authentication) server 415 and transported to the authenticator (NAS) at the end of the 416 successful network access AAA. 418 - const: 420 This is a string constant. The value of the const parameter is 421 set to "EAP RFC3118 Bootstrapping". 423 - Secret ID: 425 The unique identifier of the DHCP key as carried by the EAP 426 lower-layer protocol extension. 428 - Nonce_client: 430 This random number is provided by the client and carried by the 431 EAP lower-layer protocol extension. 433 - Nonce_NAS: 435 This random number is provided by the NAS and carried by the 436 EAP lower-layer protocol. 438 - DHCP Key: 440 This session key is 128-bit in length and used as the session 441 key for securing DHCP messages. Figure 1 of [EAP-Key] refers to 442 this derived key as a Transient Session Key (TSK). 444 The lifetime of the DHCP security association has to be limited to 445 prevent the DHCP server from storing state information indefinitely. 446 The lifetime of the DHCP SA should be set to the lifetime of the 447 network access service. The client host, NAS, and the DHCP server 448 should be (directly or indirectly) aware of this lifetime at the end 449 of a network access AAA. 451 The PaC can at any time trigger a new bootstrapping protocol run to 452 establish a new security association with the DHCP server. The IP 453 address lease time SHOULD be limited by the DHCP SA lifetime. 455 Yegin, et al. Expires July 2005 456 [Page 10] EAP-boot-RFC3118 January 2005 458 5.0 Delivering DHCP SA 460 When the NAS and the DHCP server are not co-located, the DHCP SA 461 information is carried from the NAS (DHCP relay) to the DHCP server 462 in a DHCP relay agent info option. This sub-option can be included 463 along with the RADIUS attributes sub-option that is carried after 464 the network access authentication. 466 The format of the DHCP SA sub-option is: 468 0 1 2 3 469 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | SubOpt Code | Length | Reserved | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Secret ID | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 + + 478 | | 479 + DHCP Key + 480 | | 481 + + 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Lifetime | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 SubOpt Code 489 TBD 491 Length 493 This value is set to 26. 495 Reserved 497 A 16-bit value reserved for future use. It MUST be initialized 498 to zero by the sender, and ignored by the receiver. 500 Secret ID 502 This is the 32-bit value assigned by the NAS and used to 503 identify the DHCP key. 505 DHCP Key 507 128-bit DHCP key computed by the NAS is carried in this field. 509 Yegin, et al. Expires July 2005 510 [Page 11] EAP-boot-RFC3118 January 2005 512 Lifetime 514 The lifetime of the DHCP SA. This Unsigned32 value contains the 515 number of seconds remaining before the DHCP SA is considered 516 expired. 518 6.0 Using DHCP SA 520 Once the DHCP SA is in place, it is used along with RFC3118 to 521 secure the DHCP protocol exchange. 523 [RFC3118] defines two security protocols with a newly defined 524 authentication option: 526 - Configuration token 527 - Delayed authentication 529 The generic format of the authentication option is defined in 530 Section 2 of [RFC3118] and contains the following fields: 532 - Code 534 The value for the Code field of this authentication option is 535 90. 537 - Length 539 The Length field indicates the length of the authentication 540 option payload. 542 - Protocol 544 [RFC3118] defines two values for the Protocol field - zero and 545 one. A value of zero indicates the usage of the configuration 546 token authentication option. 548 As described in Section 4 of [RFC3118] the configuration token 549 only provides weak entity authentication. Hence its usage is 550 not recommended. This authentication option will not be 551 considered for the purpose of bootstrapping. 553 A value of one in the Protocol field in the authentication 554 option indicates the delayed authentication. The usage of this 555 option is subsequently assumed in this document. 557 Since the value for this field is known in advance it does not 558 need to be negotiated between the DHCP client and DHCP server. 560 Yegin, et al. Expires July 2005 561 [Page 12] EAP-boot-RFC3118 January 2005 563 - Algorithm 565 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the 566 Algorithm field). This document assumes that HMAC-MD5 is used 567 to protect DHCP messages. 569 Since the value for this field is known in advance it does not 570 need to be negotiated. [TBD: Consider future algorithm support] 572 - Replay Detection Method (RDM) 574 The value of zero for the RDM name space is assigned to use a 575 monotonically increasing value. 577 Since the value for this field is known in advance it does not 578 need to be negotiated. 580 - Replay Detection 582 This field contains the value that is used for replay 583 protection. This value MUST be monotonically increasing 584 according to the provided replay detection method. An initial 585 value must, however, be set. In case of bootstrapping with EAP 586 an initial value of zero is used. The length of 64 bits (and a 587 start-value of zero) ensures that a sequence number rollover is 588 very unlikely to occur. 590 Since the value for this field is known in advance it does not 591 need to be negotiated. 593 - Authentication Information 595 The content of this field depends on the type of message where 596 the authentication option is used. Section 5.2 of [RFC3118] 597 does not provide content for the DHCPDISCOVER and the 598 DHCPINFORM message. Hence for these messages no additional 599 considerations need to be specified in this document. 601 For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of 602 the Authentication Information field is given as: 604 - Secret ID (32 bits) 605 - HMAC-MD5 (128 bits) 607 The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If 608 there are multiple NASes per DHCP server, this identifier space 609 might need to be pre-partitioned among the NASes.] 611 HMAC-MD5 is the output of the key message digest computation. Note 612 that not all fields of the DHCP message are protected as described 613 in [RFC3118]. 615 Yegin, et al. Expires July 2005 616 [Page 13] EAP-boot-RFC3118 January 2005 618 7.0 Security Considerations 620 This document describes a mechanism for dynamically establishing a 621 security association to protect DHCP signaling messages. 623 If the NAS and the DHCP server are co-located then the session keys 624 and the security parameters are transferred locally (via an API 625 call). Some security protocols already exercise similar methodology 626 to separate functionality. 628 If the NAS and the DHCP server are not co-located then there is some 629 similarity to the requirements and issues discussed with the EAP 630 Keying Framework (see [AS+03]). Figure 2 is originally taken from 631 Section 4.1 of [AS+03] and extended accordingly. DHCP key is a TSK 632 (Transient Session Key [AS+03]). The key is generated by both the 633 DHCP client and the DHCP relay, and transported from the DHCP relay 634 to the DHCP server. DHCP protocol traffic between the DHCP client 635 and DHCP server is protected using this key. 637 EAP peer (DHCP client) +-----------------------+ DHCP server 638 /\ / 639 / \ Protocol: EAP / 640 / \ lower-layer; / 641 / \ Auth: Mutual; / 642 / \ Unique key: / 643 Protocol: EAP; / \ DHCP key / 644 Auth: Mutual; / \ / Protocol: DHCP, or API; 645 Unique keys: MK, / \ / Auth: Mutual; 646 TEKs, EMSK / \ / Unique key: DHCP key 647 / \ / 648 / \ / 649 Auth. server +----------------------+ Authenticator 650 Protocol: AAA; (NAS, DHCP relay) 651 Auth: Mutual; 652 Unique key: 653 AAA session key 655 Figure 2: Keying Architecture 657 Figure 2 describes the participating entities and the protocols 658 executed among them. It must be ensured that the derived session key 659 between the DHCP client and the server is fresh and unique. 661 Yegin, et al. Expires July 2005 662 [Page 14] EAP-boot-RFC3118 January 2005 664 The key transport mechanism, which is used to carry the session key 665 between the NAS and DHCP server, must provide the following 666 functionality: 668 - Confidentiality protection 669 - Replay protection 670 - Integrity protection 672 Furthermore it is necessary that the two parties (DHCP server and 673 the NAS) authorize the establishment of the DHCP security 674 association. 676 At IETF 56 Russ Housley presented a list of recommendations for key 677 management protocols which describe requirements for an acceptable 678 solution. Although the presentation focused on NASREQ some issues 679 might be also applicable in this context. 681 - Algorithm independence: 683 This proposal bootstraps a DHCP security association for RFC 3118 684 where only a single integrity algorithm (namely HMAC-MD5) is 685 proposed which is mandatory to implement. 687 - Establish strong, fresh session keys (maintain algorithm 688 independence): 690 This scheme relies on EAP methods to provide strong and fresh 691 session keys for each initial authentication and key exchange 692 protocol run. Furthermore the key derivation function provided in 693 Section 4.4 contains random numbers provided by the client and the 694 NAS which additionally add randomness to the generated key. 696 - Replay protection: 698 Replay protection is provided at different places. 700 The EAP method executed between the EAP peer and the EAP server MUST 701 provide a replay protection mechanism. 703 Additionally random numbers and the secret ID are included in the 704 key derivation procedure which aim to provide a fresh and unique 705 session key between the DHCP client and the DHCP server. 707 Furthermore, the key transport mechanism between the NAS and the 708 DHCP server must also provide replay protection (in addition to 709 confidentiality protection). 711 Finally, the security mechanisms provided in RFC 3118, for which 712 this draft bootstraps the security association, also provides replay 713 protection. 715 Yegin, et al. Expires July 2005 716 [Page 15] EAP-boot-RFC3118 January 2005 718 - Authenticate all parties: 720 Authentication between the EAP peer and the EAP server is based on 721 the used EAP method. After a successful authentication and protocol 722 run, the host and the NAS in the network provide AAA-key 723 confirmation either based on the 4-way handshake in IEEE 802.11i or 724 based on the protected PANA exchange. DHCP key confirmation between 725 the DHCP client and server is provided with the first protected DHCP 726 message exchange. 728 - Perform authorization: 730 Authorization for network access is provided during the EAP 731 exchange. The authorization procedure for DHCP bootstrapping is 732 executed by the NAS before this service is offered to the client. 733 The NAS might choose not to include DHCP-AVP or DHCP SA 734 Configuration Option during network access authorization based on 735 the authorization policies. 737 - Maintain confidentiality of session keys: 739 The DHCP session keys are only known to the intended parties (i.e., 740 to the DHCP client, relay [TBD: is that OK?], and server). The EAP 741 protocol itself does not transport keys. The exchanged random 742 numbers which are incorporated into the key derivation function do 743 not need to be kept confidential. 745 DHCP relay agent information MUST be protected using [RD03] with 746 non-null IPsec encryption. 748 - Confirm selection of "best" cipher-suite: 750 This proposal does not provide confidentiality protection of DHCP 751 signaling messages. Only a single algorithm is offered for integrity 752 protection. Hence no algorithm negotiation and therefore no 753 confirmation of the selection occur. 755 - Uniquely name session keys: 757 The DHCP SA is uniquely identified using a Secret ID (described in 758 [RFC3118] and reused in this document). 760 - Compromised NAS and DHCP server: 762 A compromised NAS may leak the DHCP session key and the EAP derived 763 session key (e.g., AAA-key). It will furthermore allow corruption of 764 the DHCP protocol executed between the hosts and the DHCP server 765 since NAS either acts as a DHCP relay or a DHCP server. 767 A compromised NAS may also allow creation of further DHCP SAs or 768 other known attacks on the DHCP protocol (e.g., address depletion). 770 Yegin, et al. Expires July 2005 771 [Page 16] EAP-boot-RFC3118 January 2005 773 A compromised NAS will not be able to modify, replay, inject DHCP 774 messages which use security associations established without the 775 EAP-based bootstrapping mechanism (e.g., manually configured DHCP 776 SAs). 778 On the other hand, a compromised DHCP server may only leak the DHCP 779 key information. AAA-key will not be compromised in this case. 781 - Bind key to appropriate context: 783 The key derivation function described in Section 4.4 includes 784 parameters (such as the secret ID and a constant) which prevents 785 reuse of the established session key for other purposes. 787 8.0 IANA Considerations 789 TBD 791 9.0 Open Issues 793 This document describes a bootstrapping procedure for [RFC3118]. The 794 same procedure could be applied for [DHCPv6]. 796 10.0 References 798 [DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. 799 Carney: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 800 Internet-Draft, (work in progress), November, 2002. 802 [PANA] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin: 803 "Protocol for Carrying Authentication for Network Access (PANA)", 804 Internet-Draft, (work in progress), March, 2003. 806 [RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP 807 Messages", RFC 3118, June 2001. 809 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 810 (IKE)", RFC 2409, November 1998. 812 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 813 "Internet Security Association and Key Management Protocol 814 (ISAKMP)", RFC 2408, November 1998. 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, March 1997. 819 [PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.: 820 "Protocol for Carrying Authentication for Network Access (PANA) 822 Yegin, et al. Expires July 2005 823 [Page 17] EAP-boot-RFC3118 January 2005 825 Requirements and Terminology", Internet-Draft, (work in progress), 826 April, 2003. 828 [DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option 829 for the DHCP Relay Agent Information", Internet-Draft, (work in 830 progress), October, 2002. 832 [SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication 833 Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in 834 progress), April, 2003. 836 [AS+03] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz: "EAP 837 Keying Framework", Internet-Draft, (work in progress), October 2003. 839 [RFC2132] Alexander, S. and Droms, R.: "DHCP Options and BOOTP 840 Vendor Extensions", RFC 2132, March 1997. 842 [RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC 2131, 843 March 1997. 845 [WH+03] J. Walker, R. Housley, and N. Cam-Winget, "AAA key 846 distribution", Internet Draft, (work in progress), April 2002. 848 [RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", 849 RFC 2548, March 1999. 851 [CFB02] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS Security 852 Application", Internet-Draft, (work in progress), March 2002. 854 [RD03] R. Droms: "Authentication of DHCP Relay Agent Options Using 855 IPsec", Internet-Draft (work in progress), August 2003. 857 [SE03] J. Salowey and P. Eronen: "EAP Key Derivation for Multiple 858 Applications", Internet-Draft (work in progress), June 2003. 860 [DHC-THREAT] Hibbs, R., Smith, C., Volz, B., Zohar, M., "Dynamic 861 Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", 862 Internet-draft (expired), June 2003. 864 [8021X] IEEE Standard for Local and Metropolitan Area Networks, 865 "Port-Based Network Access Control", IEEE Std 802.1X-2001. 867 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD 868 51), July 1994. 870 11.0 Acknowledgments 872 We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for 873 their useful feedback to this work. 875 Yegin, et al. Expires July 2005 876 [Page 18] EAP-boot-RFC3118 January 2005 878 12.0 Author's Addresses 880 Alper E. Yegin 881 Samsung Advanced Institute of Technology 882 75 West Plumeria Drive 883 San Jose, CA 95134 884 USA 885 Phone: +1 408 544 5656 886 EMail: alper.yegin@samsung.com 888 Hannes Tschofenig 889 Siemens AG 890 Otto-Hahn-Ring 6 891 81739 Munich 892 Germany 893 EMail: Hannes.Tschofenig@siemens.com 895 Dan Forsberg 896 Nokia Research Center 897 P.O. Box 407 898 FIN-00045 NOKIA GROUP, Finland 899 Phone: +358 50 4839470 900 EMail: dan.forsberg@nokia.com 902 Intellectual Property Statement 904 The IETF takes no position regarding the validity or scope of any 905 Intellectual Property Rights or other rights that might be claimed to 906 pertain to the implementation or use of the technology described in 907 this document or the extent to which any license under such rights 908 might or might not be available; nor does it represent that it has 909 made any independent effort to identify any such rights. Information 910 on the procedures with respect to rights in RFC documents can be 911 found in BCP 78 and BCP 79. 913 Copies of IPR disclosures made to the IETF Secretariat and any 914 assurances of licenses to be made available, or the result of an 915 attempt made to obtain a general license or permission for the use of 916 such proprietary rights by implementers or users of this 917 specification can be obtained from the IETF on-line IPR repository at 918 http://www.ietf.org/ipr. 920 The IETF invites any interested party to bring to its attention any 921 copyrights, patents or patent applications, or other proprietary 922 rights that may cover technology that may be required to implement 923 this standard. Please address the information to the IETF at 924 ietf-ipr@ietf.org. 926 Disclaimer of Validity 928 This document and the information contained herein are provided on an 929 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 930 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 931 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 932 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 933 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 934 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 936 Copyright Statement 938 Copyright (C) The Internet Society (2005). This document is subject 939 to the rights, licenses and restrictions contained in BCP 78, and 940 except as set forth therein, the authors retain all their rights. 942 Acknowledgment 944 Funding for the RFC Editor function is currently provided by the 945 Internet Society. 947 Yegin, et al. Expires July 2005