idnits 2.17.1 draft-tschofenig-pana-bootstrap-rfc3118-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (October 2003) is 7498 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 572, but not defined == Missing Reference: 'AVPs' is mentioned on line 632, but not defined == Missing Reference: 'Cookie' is mentioned on line 636, but not defined == Unused Reference: 'RFC2408' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'RFC2548' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'CFB02' is defined on line 912, 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' Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF PANA Working Group 3 Internet Draft H. Tschofenig 4 Siemens 5 Corporate Technology 6 A. Yegin 7 DoCoMo USA Labs 8 D. Forsberg 9 Nokia 10 Document: 11 draft-tschofenig-pana-bootstrap-rfc3118-01.txt 12 Expires: April 2004 October 2003 14 Bootstrapping RFC3118 Delayed authentication using PANA 15 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of Section 10 of RFC2026. 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 Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any 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/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 DHCP authentication extension (RFC3118) cannot be widely deployed 41 due to lack of an out-of-band key agreement protocol for DHCP 42 clients and servers. This draft outlines how EAP methods carried 43 over PANA can be used to establish a local trust relation and 44 generate keys that can be used in conjunction with RFC3118. 46 Table of Contents 48 1. Introduction...............................................2 49 2. Terminology................................................3 50 3. Overview and Building Blocks...............................4 51 3.1 PaC to PAA Communication................................5 52 3.2 PAA to DHCP Communication...............................5 53 3.3 Key Derivation..........................................6 54 4. Requirements...............................................6 55 5. Security parameters for RFC 3118...........................7 56 5.1 Authentication Option of RFC 3118.......................7 57 5.1.1 Code Field............................................8 58 5.1.2 Length Field..........................................8 59 5.1.3 Protocol Field........................................8 60 5.1.4 Algorithm Field.......................................8 61 5.1.5 Replay Detection Method (RDM) Field...................8 62 5.1.6 Replay Detection Field................................8 63 5.1.7 Authentication Information Field......................9 64 5.2 Lifetime of the DHCP security association...............9 65 6. Processing Details and Payloads............................9 66 6.1 Capability Indication and Trigger Message...............9 67 6.2 Key Derivation.........................................11 68 6.3 DHCP SA Sub-option.....................................12 69 7. Example message flow......................................13 70 8. Security Considerations...................................14 71 9. IANA Considerations.......................................17 72 10. Open Issues...............................................18 73 11. References................................................18 74 12. Acknowledgments...........................................19 75 13. Author's Addresses........................................19 77 1. Introduction 79 PANA [PANA] provides network access authentication by carrying 80 Extensible Authentication Protocol (EAP) between the hosts and the 81 access networks. The combination of EAP with an AAA architecture 82 allows authentication and authorization of a roaming user to an 83 access network. A successful authentication between a client and the 84 network produces a dynamically created trust relation between the 85 two. Various EAP authentication methods are capable of generating 86 cryptographic keys (e.g., shared secrets) between the client and the 87 authentication agent after successful authentication. 89 DHCP [RFC2131] is a protocol which provides an end host with 90 configuration parameters. The base DHCP does not include any 91 security mechanism, hence it is vulnerable to a number of security 92 threats. Security considerations section of RFC 2131 identifies this 93 protocol as "quite insecure" and lists various security threats. 95 RFC 3118 is the DHCP authentication protocol which defines how to 96 authenticate various DHCP messages. It does not support roaming 97 clients and assumes out-of band or manual key establishment. These 98 limitations have been inhibiting widespread deployment of this 99 security mechanism. 101 It is possible to use the authentication and key exchange procedure 102 executed during the network access authentication to bootstrap a 103 security association for DHCP. The trust relation created during the 104 access authentication process can be used with RFC 3118 to provide 105 security for DHCP. This document defines how to use PANA to 106 bootstrap RFC 3118 for securing DHCP. 108 PANA protocol allows clients to use this protocol even before they 109 are assigned an IP address. A PANA client (PaC) can use the 110 unspecified IP address as its source address during this phase. 112 This approach provides a two-step solution: 114 - Authentication and key exchange (provided by EAP methods carried 115 over PANA) 116 - DHCP message protection by generating the required shared secrets 117 for RFC 3118. 119 Instead of adding EAP support to DHCP itself (which requires 120 modifications to the DHCP protocol due to the nature of EAP 121 messaging) we keep the two protocols separate. 123 This document is organized as follows. Section 2 describes new 124 terms. Section 3 gives an overview of the basic communication and 125 describes the building blocks. Requirements are presented in Section 126 4. The details of the established parameters for the DHCP SA are 127 listed in Section 5. Processing details and payload formats are 128 illustrated in Section 6. A short message flow describes the 129 protocol interaction in Section 6.3. Finally in Section 8 additional 130 security considerations are discussed. 132 2. Terminology 134 This document uses the following terms: 136 - DHCP security association 138 To secure DHCP messages a number of parameters including the key 139 that is shared between the PaC (DHCP client) and the DHCP server 140 have to be established. These parameters are collectively referred 141 to as DHCP security association (or in short DHCP SA). Once a DHCP 142 server is selected the DHCP SA is use between the DHCP client and 143 the DHCP server. 145 - DHCP Key 146 This term refers to the fresh and unique session key dynamically 147 established between the DHCP client (PaC) and the DHCP server. This 148 key is used to protect DHCP messages as described in [RFC3118]. 150 Further PANA related terms can be found in [PY+02]. 152 In this document, the key words "MAY", "MUST, "MUST NOT", 153 OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be 154 interpreted as described in [RFC2119]. 156 3. Overview and Building Blocks 158 Based on the PANA protocol interaction this bootstrapping mechanism 159 requires protocol interaction between the PaC (which acts as DHCP 160 client), the PANA Authentication Agent (PAA) and the DHCP server. A 161 security association will be established between the DHCP server and 162 the DHCP client to protect DHCP messages. 164 DHCP SA is generated based on the PANA SA after a successful PANA 165 authentication. DHCP SA information needs to be transferred from the 166 PAA (where it is generated) to the DHCP server (where it will be 167 needed). 169 PAA is located one IP hop away from the PaC. If the DHCP server is 170 on the same link, it can be co-located with the PAA. When PAA and 171 DHCP server are co-located, an internal mechanism, such as an API, 172 is sufficient for transferring the SA information. If the DHCP 173 server is multiple hops away from the DHCP client, then there must 174 be a DHCP relay on the same link as the client. In that case, PAA 175 should be co-located with the DHCP relay. The SA information can be 176 communicated to the DHCP server using the DHCP relay agent 177 information options [DS02]. For the purpose of confidentiality 178 protection IPsec protection MUST be applied as described in [RD03]. 180 Two different scenarios are illustrated in Figure 1. 182 +---------+ +--------------+ 183 | PaC/ | | PAA / | 184 | DHCP |<================>| DHCP server | 185 | client | PANA and DHCP | | 186 +---------+ +--------------+ 188 +---------+ +--------------+ +---------+ 189 | PaC/ | | PAA / | | DHCP | 190 | DHCP |<================>| DHCP relay |<======>| server | 191 | client | PANA and DHCP | | DHCP | | 192 +---------+ +--------------+ +---------+ 194 Legend: 196 PaC - PANA Client 197 PAA - PANA Authentication Agent 199 Figure 1: DHCP Protocol Bootstrapping 201 When the DHCP SA information is received by the DHCP server and 202 client, it can be used along with RFC3118 to protect DHCP messages 203 against various security threats. 205 The following building blocks have been identified: 207 3.1 PaC to PAA Communication 209 Additional payloads are required within PANA in order to bootstrap 210 RFC3118. These payloads therefore provide the following 211 functionality: 213 a) Capability indication 215 A capability describes a certain functionality which is either 216 supported or not. In order to trigger an action or to obtain a 217 certain kind of data item it is necessary to execute some message 218 exchanges. This message exchange allows both entities to learn 219 commonly supported functionality. 221 b) Trigger message 223 A trigger message allows one entity (either PaC or PAA) to request a 224 certain action to be executed. For this protocol a trigger message 225 sent by the PaC causes the PAA to create the DHCP security 226 association for support with [RFC3118]. 228 Section 6 describes the message payloads for the additional objects 229 required in PANA usage with this bootstrapping protocol. 231 3.2 PAA to DHCP Communication 233 If the PAA and the DHCP server are co-located then only an API call 234 is required for transferring the necessary information from the PAA 235 to the DHCP server. If the PAA and the DHCP server are not co- 236 located then an additional protocol is needed. [WH+02] points to the 237 importance of this communication as: "Key distribution is not merely 238 a data transport operation; it is also a mechanism for building 239 transitive trust;". Indeed the trust relationship between the PaC 240 and the PAA, which was dynamically established during network access 241 authentication, is used to extend the trust relationship to the DHCP 242 server. The PAA, which is co-located with the DHCP Relay, and the 243 DHCP server trust each other and both entities belong to the same 244 administrative domain as the PAA. 246 Security sensitive information has to be exchanged (such as session 247 keys) between the DHCP relay (PAA) and the DHCP server. This 248 protocol is not part of PANA but the security implications must be 249 considered. 251 [DS02] enables transmission of AAA-related RADIUS attributes from 252 DHCP relay to DHCP server in the form of relay agent information 253 options. DHCP SA is generated at the end of the AAA process, and 254 therefore it can be provided to the DHCP server in a sub-option 255 carried along with other AAA-related information. Protection of this 256 exchange MUST be provided. [RD03] proposes IPsec protection of the 257 DHCP messages exchanged between the DHCP relay and the DHCP server. 258 DHCP objects (protected with IPsec) can therefore be used to 259 communicate the necessary parameters. 261 3.3 Key Derivation 263 As a result of the EAP authentication and key exchange method a 264 Master Session Key (MSK) is established which is used to establish a 265 PANA security association. The key derivation procedure for 266 establishing PANA SA is defined in [PANA]. Another security 267 association for usage with DHCP according to [RFC3118] needs to be 268 established. A discussion of the required parameters for the 269 security association is given in Section 5 and the key derivation 270 function is provided in Section 6.2 272 Since different bootstrapping applications need different keys it is 273 necessary to derive these keys from the session key provided by the 274 EAP method. It would be possible to reuse work done by members of 275 the EAP working group on key derviation for multiple applications 276 [SE03]. The key derivation mechanism used in this document is 277 similar. 279 4. Requirements 281 The following requirements regarding protocol design and deployment 282 have to be met: 284 - The DHCP protocol as defined in [RFC2131] MUST NOT be modified. 286 - The security mechanism defined in [RFC3118] MUST NOT be modified. 288 - The key derivation procedure MUST establish a unique and fresh 289 session key for the usage with [RFC3118]. The session key MUST never 290 be used again in later protocol run. 292 - It MUST be ensured that only the intended parties have access to 293 the session key. Hence the key transport between the PAA and the 294 DHCP server MUST be authenticated, integrity, replay and 295 confidentiality protected. The security mechanism used to protect 296 the transport of the session key between the PAA and the DHCP server 297 MUST have an adequate key strength. Section 5.4 of [AS+03] offers a 298 description of issues concerning key wrapping. 300 - The DHCP server MUST ensure that only authorized nodes are allowed 301 to install keying material for subsequent DHCP message protection. 303 - The established DHCP security association MUST provide data origin 304 authentication, integrity protection and replay protection. A non- 305 goal of this draft is to provide confidentiality protection for DHCP 306 messages. 308 - The lifetime of the DHCP session key is limited to the PANA 309 session lifetime. The session key MUST NOT be used beyond that 310 lifetime. The first DHCP message provides key confirmation of the 311 established session key between the PaC and the DHCP server. The 312 DHCP is active after a successful completion of the bootstrapping 313 procedure (indicated by the PAA). 315 - Key Naming 317 Both the DHCP client and the DHCP server MUST have means to uniquely 318 identify the DHCP SA. 320 The derived session key (DHCP key) MUST be bound to a particular 321 session between the particular PaC and an entity in the access 322 network. It MUST be possible for the two peers (PaC and DHCP server) 323 to verify that each other is indeed the intended recipients of the 324 distributed session key. Once the established DHCP SA is selected 325 for protection of DHCP messages (implicit) key confirmation is 326 provided. 328 5. Security parameters for RFC 3118 330 5.1 Authentication Option of RFC 3118 332 [RFC3118] defines two security protocols with a newly defined 333 authentication option: 335 - Configuration token 336 - Delayed authentication 338 The generic format of the authentication option is defined in 339 Section 2 of [RFC3118] and contains the following fields: 341 - Code (8 bits) 342 - Length (8 bits) 343 - Protocol (8 bits) 344 - Algorithm (8 bits) 345 - Replay Detection Method - RDM (8 bits) 346 - Replay Detection (64 bits) 347 - Authentication Information (variable length) 349 5.1.1 Code Field 351 The value for the Code field of this authentication option is 90. 353 5.1.2 Length Field 355 The Length field indicates the length of the authentication option 356 payload. 358 5.1.3 Protocol Field 360 [RFC3118] defines two values for the Protocol field - zero and one. 361 A value of zero indicates the usage of the configuration token 362 authentication option. 364 As described in Section 4 of [RFC3118] the configuration token only 365 provides weak entity authentication. Hence its usage is not 366 recommended. This authentication option will not be considered for 367 the purpose of bootstrapping. 369 A value of one in the Protocol field in the authentication option 370 indicates the Delayed authentication. The usage of this option is 371 subsequently assumed in this document. 373 Since the value for this field is known in advance it does not need 374 to be negotiated between the DHCP client and DHCP server. 376 5.1.4 Algorithm Field 378 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the 379 Algorithm field). This document assumes that HMAC-MD5 is used to 380 protect DHCP messages. 382 Since the value for this field is known in advance it does not need 383 to be negotiated. 385 5.1.5 Replay Detection Method (RDM) Field 387 The value of zero for the RDM name space is assigned to use a 388 monotonically increasing value. 390 Since the value for this field is known in advance it does not need 391 to be negotiated. 393 5.1.6 Replay Detection Field 395 This field contains the value that is used for replay protection. 396 This value MUST be monotonically increasing according to the 397 provided replay detection method. 399 An initial value must, however, be set. In case of bootstrapping 400 with PANA an initial value of zero is used. The length of 64 bits 401 (and a start-value of zero) ensure that a sequence number roll-over 402 is very unlikely to occur. 404 Since the value for this field is known in advance it does not need 405 to be negotiated. 407 5.1.7 Authentication Information Field 409 The content of this field depends on the type of message where the 410 authentication option is used. Section 5.2 of [RFC3118] does not 411 provide content for the DHCPDISCOVER and the DHCPINFORM message. 412 Hence for these messages no additional considerations need to be 413 specified in this document. 415 For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the 416 Authentication Information field is given as: 418 - Secret ID (32 bits) 419 - HMAC-MD5 (128 bits) 421 The Secret ID is chosen by the PAA to prevent collisions. 423 HMAC-MD5 is the output of the key message digest computation. Note 424 that not all fields of the DHCP message are protected as described 425 in [RFC3118]. 427 5.2 Lifetime of the DHCP security association 429 The lifetime of the DHCP security association has to be limited to 430 prevent the DHCP from storing state information over a long time. 432 The lifetime of the DHCP SA should be set to the lifetime of PANA SA 433 which is determined by the PANA session lifetime. The PaC (i.e. DHCP 434 client), PAA, and DHCP server should be aware (directly or 435 indirectly) about the lifetime. 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 6. Processing Details and Payloads 443 This section defines the necessary extensions for PANA and a key 444 derivation procedure. 446 6.1 Capability Indication and Trigger Message 447 A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP- 448 AVP is included in the PANA-Bind-Request message if PAA is offering 449 DHCP SA bootstrapping service. If the PaC wants to proceed with 450 creating DHCP SA at the end of the PANA authentication, it MUST 451 include DHCP-AVP in its PANA-Bind-Answer message. 453 Absence of this AVP in the PANA-Bind-Request message sent by PAA 454 indicates unavailability of this additional service. In that case, 455 PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore 456 received DHCP-AVP. When this AVP is received by PaC, it may or may 457 not include the AVP in its response depending on its desire to 458 create DHCP SA. DHCP SA can be created as soon as each entity has 459 received and sent one DHCP-AVP. 461 The detailed DHCP-AVP format is presented below. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | AVP Code | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | AVP Flags | AVP Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Secret ID | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | 473 ~ Nonce Data ~ 474 | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 AVP Code 479 TBD 481 AVP Flags 483 The AVP Flags field is eight bits. The following bits are 484 assigned: 486 0 1 2 3 4 5 6 7 487 +-+-+-+-+-+-+-+-+ 488 |V M r r r r r r| 489 +-+-+-+-+-+-+-+-+ 491 M(andatory) 493 - The 'M' Bit, known as the Mandatory bit, 494 indicates whether support of the AVP is 495 required. This bit is not set in DHCP-AVP. 497 V(endor) 498 - The 'V' bit, known as the Vendor-Specific bit, 499 indicates whether the optional Vendor-Id field 500 is present in the AVP header. This bit is not set in 501 DHCP-AVP. 503 r(eserved) 505 - These flag bits are reserved for future use, 506 and MUST be set to zero, and ignored by the 507 receiver. 509 AVP Length 511 The AVP Length field is three octets, and indicates the number 512 of octets in this AVP including the AVP Code, AVP Length, AVP 513 Flags, and AVP data. 515 Secret ID 517 32 bit value that identifies the DHCP Key produced as a result of 518 the bootstrapping process. This value is determined by PAA and 519 sent to PaC. PAA determines this value by randomly picking a 520 number from the available session ID pool. If PaC's response does 521 not contain DHCP-AVP then this value is returned to the available 522 identifiers pool. Otherwise, it is allocated to the PaC until 523 DHCP SA expires. PaC MUST set this field to all 0s in its 524 response. 526 Nonce Data (variable length) 528 Contains the random data generated by the transmitting entity. 529 This field contains Nonce_PaC when the AVP is sent by PaC, and 530 Nonce_PAA when the AVP is sent by PAA. Nonce value MUST be 531 randomly chosen and MUST be at least 128 bits in size. Nonce 532 values MUST NOT be reused. 534 6.2 Key Derivation 536 This section describes the key derivation procedure which allows to 537 establish a DHCP security association. The key derivation procedure 538 is reused from IKE [RFC2409]. The character '|' denotes 539 concatenation. 541 DHCP Key = HMAC-MD5(MSK, const | Session ID | Nonce_PaC | Nonce_PAA) 543 The values of have the following meaning: 545 - MSK 546 The Master Session Key (MSK) is provided by the EAP method as part 547 of the PANA/EAP protocol execution. 549 - const 551 This is a string constant. The value of the const parameter is set 552 to "PANA RFC3118 Bootstrapping". 554 - Session ID 556 This is the PANA session ID as defined in [PANA]. It is used to 557 identify a unique session between the PaC and PAA. 559 - Nonce_PaC 561 This random number is provided by the PaC and exchanged within the 562 PANA protocol. 564 - Nonce_PAA 566 This random number is provided by the PAA/DHCP server and exchanged 567 with the PANA protocol. 569 - DHCP Key 571 This session key is 128-bit in length and used as the session key 572 for securing DHCP messages. Figure 1 of [EAP-Key] refers to this 573 derived key as Transient Session Keys (TSKs). 575 6.3 DHCP SA Sub-option 577 When PAA and DHCP server are not co-located, the DHCP SA information 578 is carried from the PAA (DHCP relay) to the DHCP server in a DHCP 579 relay agent info option. This sub-option can be included along with 580 the RADIUS attributes sub-option that is carried after the network 581 access authentication. 583 The format of the DHCP SA sub-option is: 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | SubOpt Code | Length | Secret ID ~ 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 ~ Secret ID (continued) | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 590 | | 591 + + 592 | | 593 + DHCP Key + 594 | | 595 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | | Lifetime ~ 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 ~ Lifetime (continued) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 SubOpt Code 603 TBD 605 Length 607 This value is set to 24. 609 Secret ID 611 This is the 32-bit value assigned by the PAA which is used to 612 identify the DHCP key. 614 DHCP Key 616 128-bit DHCP key computed by PAA is carried in this field. 618 Lifetime 620 The lifetime of DHCP SA. This Unsigned32 value contains 621 the number of seconds remaining before the DHCP SA is 622 considered expired. 624 7. Example message flow 626 Figure 2 depicts a message flow that enables DHCP bootstrapping. The 627 PANA message flow starts with a discovery of the PAA, followed by 628 network access authentication. Finally, when the authentication 629 succeeds a PANA security association is established. The DHCP-AVP 630 payload contains parameters described in Section 6. 632 PaC PAA Message(tseq,rseq)[AVPs] 633 ------------------------------------------------------ 634 -----> PANA-PAA-Discover(0,0) 635 <----- PANA-Start-Request(x,0)[Cookie] 636 -----> PANA-Start-Answer(y,x)[Cookie] 637 <----- PANA-Auth-Request(x+1,y) 638 [Session-Id, EAP{Request}] 639 -----> PANA-Auth-Answer(y+1,x+1) 640 [Session-Id, EAP{Response}] 641 . 642 . 643 <----- PANA-Auth-Request(x+n,y+n-1) 644 [Session-Id, EAP{Request}] 645 -----> PANA-Auth-Answer(y+n,x+n) 647 [Session-Id, EAP{Response}] 648 <----- PANA-Bind-Request(x+n+1,y+n) 649 [EAP{Success}, Session-Id, Device-Id, 650 DHCP-AVP, Lifetime, MAC] 651 -----> PANA-Bind-Answer(y+n+1,x+n+1) 652 [Session-Id, Device-Id, DHCP-AVP, 653 MAC] 655 Figure 2: Message flow for PANA DHCP bootstrapping 657 PANA SA will be created based on the PANA authentication. Since PaC 658 and PAA have exchanged DHCP-AVPs, additionally a DHCP SA will be 659 generated as outlined earlier. DHCP SA parameters can be immediately 660 provided to the DHCP server when PAA and DHCP server are co-located. 661 When they are on separate nodes, the next DHCP request sent by the 662 DHCP client (PaC) can piggyback the DHCP SA parameters to the DHCP 663 server as it is relayed by the DHCP relay (PAA). 665 8. Security Considerations 667 This document describes a mechanism for dynamically establishing a 668 security association to protect DHCP signaling messages. 670 PANA uses EAP to support a number of authentication methods. With 671 the functionality of EAP this document therefore supports DHCP 672 security for roaming users. 674 This document separates the different security mechanisms in a 675 modular way: 677 a) The appropriate EAP method for a certain scenario, environment or 678 architecture can be chosen. The security properties heavily depend 679 on the chosen EAP method. 681 b) PANA carries EAP messages and provides additional security. The 682 security features of PANA are described in [PANA]. 684 c) The security mechanism in [RFC3118] is reused for providing 685 authentication, integrity and replay protection for DHCP messages. 687 If the PAA and the DHCP server are co-located then the session keys 688 and the security parameters are transferred locally (via an API 689 call). Some security protocols already exercise similar methodology 690 to separate functionality. 692 If the PAA and the DHCP server are not co-located then there is some 693 similarity to the requirements and issues discussed with the EAP 694 Keying Framework (see [AS+03]). Figure 3 is taken from Section 4.1 695 of [AS+03] and adjusted accordingly. A major difference from [AS+03] 696 is that the communication between the PAA and DHCP server takes 697 place within the same administrative domain. Hence the security 698 considerations are different to those described in [WH+03]. 699 Secondly, even after DHCP client and DHCP server acquire the DHCP 700 key, the PAA host continues to be on the DHCP path when acting as a 701 DHCP relay. 703 PaC (DHCP client) 704 /\ 705 Protocol: EAP over PANA / \ 706 Auth: Mutual / \ 707 Unique keys: / \ 708 - MSK / \ 709 - PANA key / \ 710 - DHCP key / \ 711 PAA +--------------+ DHCP server 713 Protocol: DHCP or API 714 Auth: Mutual 715 Unique key: DHCP key 717 Figure 3: Keying Architecture 719 Figure 3 describes the participating entities and the protocol 720 executed between them. It must be ensured that the derived session 721 key between the PaC and the DHCP server is fresh and unique. 723 The key transport mechanism, which is used to carry the session key 724 between the PAA and DHCP server, must provide the following 725 functionality: 727 - Confidentiality protection 728 - Replay protection 729 - Integrity protection 731 Furthermore it is necessary that the two parties (DHCP server and 732 the PAA) authorize the establishment of the DHCP security 733 association. 735 Russ Housley recently (at the 56th IETF) presented a list of 736 recommendations for key management protocols which describe 737 requirements for an acceptable solution. Although the presentation 738 focused on NASREQ some issues might also applicable in our context. 739 We will address the presented issues briefly: 741 - Algorithm independence 743 Our proposal bootstraps a DHCP security association based on RFC 744 3118 where only a single integrity algorithm (namely HMAC-MD5) is 745 proposed which is mandatory to implement. 747 - Establish strong, fresh session keys (maintain algorithm 748 independence) 750 PANA relies on EAP to provide strong and fresh session keys for each 751 initial authentication and key exchange protocol run. Furthermore 752 the key derivation function provided in Section 6.2 contains random 753 numbers provided by the PaC and the PAA which additionally add 754 randomness to the generated key. 756 - Replay protection 758 Replay protection is provided at different places: 760 The EAP method executed between the EAP peer and the EAP server 761 which is carried over PANA (between the PaC and the PAA) MUST 762 provide a replay protection mechanism. 764 Additionally random numbers and the session id is included in the 765 key derivation procedure which aims to provide a fresh and unique 766 session key between the PaC (DHCP client) and the DHCP server. 768 Furthermore, the key transport mechanism between the PAA and the 769 DHCP server must also provide replay protection (in addition to 770 confidentiality protection). 772 Finally, the security mechanisms provided in RFC 3118, for which 773 this draft bootstraps the security association, also provides replay 774 protection. 776 - Authenticate all parties 778 Authentication between the PaC and the PAA is provided by the PANA 779 protocol which utilizes EAP. Key confirmation of PANA SA is 780 accomplished at the final stage of the PANA exchange. 782 Key confirmation between the PaC and the DHCP server is provided 783 with the first protected DHCP message exchange. 785 - Perform authorization 787 Authorization for network access is provided during the PANA 788 exchange. The authorization procedure for DHCP bootstrapping is 789 executed by the PAA before this service is offered to the PaC. The 790 PAA might choose not to include DHCP-AVP in a PANA-Bind-Request 791 based on its local policies. 793 - Maintain confidentiality of session keys 795 The DHCP session keys are only known to the intended parties (i.e., 796 to the PaC, PAA and the DHCP server). 798 The PANA protocol does not transport keys. The exchanged random 799 numbers which are incorporated into the key derivation function do 800 not need to be kept confidential. 802 DHCP relay agent information MUST be protected using [RD03] with 803 non-null IPsec encryption. 805 - Confirm selection of "best" ciphersuite 807 This proposal does not provide confidentiality protection of DHCP 808 signaling messages. Only a single algorithm is offered for integrity 809 protection. Hence no algorithm negotiation and therefore no 810 confirmation of the selection occur. 812 - Uniquely name session keys 814 The DHCP SA is uniquely identified using a Secret ID (described in 815 [RFC3118] and reused in this document). 817 - Compromised PAA and DHCP server 819 A compromised PAA may leak the DHCP session key, the EAP derived 820 session key (e.g., MSK) and the PANA SA. It will furthermore allow 821 corruption of the DHCP protocol executed between the hosts and the 822 DHCP server since PAA node either acts as a DHCP relay or DHCP 823 server. 825 A compromised PAA may also allow creation of further DHCP SAs or 826 other known attacks on the DHCP protocol (e.g., address depletion). 828 A compromised PAA will not be able to modify, replay, inject DHCP 829 messages which use security associations established without the 830 PANA bootstrapping protocol (e.g., manually configured DHCP SAs). 832 On the other hand, a compromised DHCP server may only leak the DHCP 833 key information. MSK and PANA SA will not be compromised in this 834 case. 836 - Bind key to appropriate context 838 The key derivation function described in Section 6.2 includes 839 parameters (such as the PANA session ID and a constant) which 840 prevents reuse of the established session key for other purposes. 841 The key derivation includes the session identifier to associate the 842 key to the context of a certain PANA protocol session and therefore 843 to a particular client. 845 9. IANA Considerations 847 TBD 849 10. Open Issues 851 This document describes a bootstrapping procedure for [RFC3118]. The 852 same procedure could be applied for [DHCPv6]. 854 Some text is required to describe the details of the DHCP multi- 855 server model. When multiple DHCP servers send DHCPOFFER in response 856 to the DHCPDISCOVER where each server has a distinct server id and 857 the client chooses a single server among multiple DHCPOFFER 858 messages. For the client there is no difference between any of the 859 DHCP server. 861 11. References 863 [DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. 864 Carney: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 865 Internet-Draft, (work in progress), November, 2002. 867 [PANA] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin: 868 "Protocol for Carrying Authentication for Network Access (PANA)", 869 Internet-Draft, (work in progress), March, 2003. 871 [RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP 872 Messages", RFC 3118, June 2001. 874 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 875 (IKE)", RFC 2409, November 1998. 877 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. 878 Turner, "Internet Security Association and Key Management Protocol 879 (ISAKMP)", RFC 2408, November 1998. 881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 882 Requirement Levels", BCP 14, RFC 2119, March 1997. 884 [PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.: 885 "Protocol for Carrying Authentication for Network Access (PANA) 886 Requirements and Terminology", Internet-Draft, (work in progress), 887 April, 2003. 889 [DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option 890 for the DHCP Relay Agent Information", Internet-Draft, (work in 891 progress), October, 2002. 893 [SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication 894 Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in 895 progress), April, 2003. 897 [AS+03] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz: "EAP 898 Keying Framework", Internet-Draft, (work in progress), October 2003. 900 [RFC2132] Alexander, S. and Droms, R.: "DHCP Options and BOOTP 901 Vendor Extensions", RFC 2132, March 1997. 903 [RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC 904 2131, March 1997. 906 [WH+03] J. Walker, R. Housley, and N. Cam-Winget, "AAA key 907 distribution", Internet Draft, (work in progress), April 2002. 909 [RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", 910 RFC 2548, March 1999. 912 [CFB02] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS 913 Security Application", Internet-Draft, (work in progress), March 914 2002. 916 [RD03] R. Droms: "Authentication of DHCP Relay Agent Options Using 917 IPsec", Internet-Draft (work in progress), August 2003. 919 [SE03] J. Salowey and P. Eronen: "EAP Key Derivation for Multiple 920 Applications", Internet-Draft (work in progress), June 2003. 922 12. Acknowledgments 924 We would like to thank Yoshihiro Ohba for his comments to this 925 draft. 927 13. Author's Addresses 929 Hannes Tschofenig 930 Siemens AG 931 Otto-Hahn-Ring 6 932 81739 Munich 933 Germany 934 EMail: Hannes.Tschofenig@siemens.com 936 Alper E. Yegin 937 DoCoMo USA Labs 938 181 Metro Drive, Suite 300 939 San Jose, CA, 95110 940 USA 941 Phone: +1 408 451 4743 942 Email: alper@docomolabs-usa.com 944 Dan Forsberg 945 Nokia Research Center 946 P.O. Box 407 947 FIN-00045 NOKIA GROUP, Finland 948 Phone: +358 50 4839470 949 EMail: dan.forsberg@nokia.com 950 Full Copyright Statement 952 Copyright (C) The Internet Society (2001). All Rights Reserved. 953 This document and translations of it may be copied and furnished to 954 others, and derivative works that comment on or otherwise explain it 955 or assist in its implementation may be prepared, copied, published 956 and distributed, in whole or in part, without restriction of any 957 kind, provided that the above copyright notice and this paragraph 958 are included on all such copies and derivative works. However, this 959 document itself may not be modified in any way, such as by removing 960 the copyright notice or references to the Internet Society or other 961 Internet organizations, except as needed for the purpose of 962 developing Internet standards in which case the procedures for 963 copyrights defined in the Internet Standards process must be 964 followed, or as required to translate it into languages other than 965 English. 967 The limited permissions granted above are perpetual and will not be 968 revoked by the Internet Society or its successors or assigns. 970 This document and the information contained herein is provided on an 971 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 972 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 973 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 974 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 975 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.