idnits 2.17.00 (12 Aug 2021) /tmp/idnits1665/draft-tschofenig-pana-bootstrap-rfc3118-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 2003) is 6914 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 586, but not defined == Missing Reference: 'AVPs' is mentioned on line 603, but not defined == Missing Reference: 'Cookie' is mentioned on line 607, but not defined == Missing Reference: 'Device-Id' is mentioned on line 617, but not defined == Missing Reference: 'DHCP-AVP' is mentioned on line 617, but not defined == Missing Reference: 'MAC' is mentioned on line 617, but not defined == Unused Reference: 'RFC2408' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 843, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'AS03' ** Downref: Normative reference to an Informational RFC: RFC 2548 -- Possible downref: Non-RFC (?) normative reference: ref. 'CFB02' Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 7 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-00.txt 12 Expires: December 2003 June 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 PANA provides network access authentication and uses the Extensible 41 Authentication Protocol (EAP) to carry different authentication 42 methods. The combination of EAP with an AAA architecture allows 43 authentication and authorization of a roaming user to an access 44 network. 46 DHCP is a protocol which provides an end host with configuration 47 parameters. Without proper security for DHCP an adversary can mount 48 a number of attacks. 50 It seems to be reasonable to use the authentication and key exchange 51 procedure executed during the network access authentication to 52 bootstrap a security association for DHCP. 54 Table of Contents 56 1. Introduction...............................................2 57 2. Terminology................................................4 58 3. Overview and Building Blocks...............................4 59 3.1 PaC <-> PAA Communication...............................5 60 3.2 PAA <-> DHCP Communication..............................5 61 3.3 Key Derivation..........................................6 62 4. Requirements...............................................6 63 5. Security parameters for RFC 3118...........................7 64 5.1 Authentication Option of RFC 3118.......................7 65 5.1.1 Code Field............................................8 66 5.1.2 Length Field..........................................8 67 5.1.3 Protocol Field........................................8 68 5.1.4 Algorithm Field.......................................8 69 5.1.5 Replay Detection Method (RDM) Field...................9 70 5.1.6 Replay Detection Field................................9 71 5.1.7 Authentication Information Field......................9 72 5.2 Lifetime of the DHCP security association..............10 73 6. Processing Details and Payloads...........................10 74 6.1 Capability Indication and Trigger Message..............10 75 6.2 Key Derivation.........................................12 76 7. Example message flow......................................13 77 8. Security Considerations...................................13 78 9. IANA Considerations.......................................17 79 10. Open Issues...............................................17 80 11. References................................................17 81 12. Acknowledgments...........................................18 82 13. Author's Addresses........................................18 84 1. Introduction 86 PANA [PANA] provides network access authentication by carrying 87 Extensible Authentication Protocol (EAP) between the hosts and the 88 access networks. The combination of EAP with an AAA architecture 89 allows authentication and authorization of a roaming user to an 90 access network. A successful authentication between a client and the 91 network produces a dynamically created trust relation between the 92 two. Various EAP authentication methods are capable of generating 93 cryptographic keys (e.g., shared secrets) between the client and the 94 authentication agent after successful authentication. 96 DHCP [RFC2131] is a protocol which provides an end host with 97 configuration parameters. The base DHCP does not include any 98 security mechanisms, hence it is vulnerable to a number of security 99 threats. Security considerations section of RFC 2131 identifies this 100 protocol as "quite insecure" and lists various security threats. 102 RFC 3118 is the DHCP authentication protocol which defines how to 103 authenticate various DHCP messages. This protocol extension does not 104 support roaming clients and assumes the availability of an out-of 105 band shared secret between the client and the DHCP server. These 106 limitations have been inhibiting widespread deployment of this 107 security mechanism. 109 It seems to be reasonable to use the authentication and key exchange 110 procedure executed during the network access authentication to 111 bootstrap a security association for DHCP. The trust relation 112 created during the access authentication process can be used with 113 RFC 3118 to provide security for DHCP. This document defines how to 114 use PANA to bootstrap RFC 3118 for securing DHCP. 116 PANA protocol allows clients to use this protocol even before they 117 are assigned an IP address. A PANA client (PaC) can use the 118 unspecified IP address as its source address during this phase. 120 PANA thereby offers a split between the two protocols: 122 - Authentication and key exchange 123 (provided by PANA and EAP in particular) 124 - DHCP message protection by generating the required shared secrets 125 for RFC 3118. 127 Instead of adding EAP support to DHCP itself (which requires 128 modifications to the DHCP protocol due to the nature of EAP 129 messaging) we separate the two protocols. We call this procedure 130 bootstrapping RFC 3118. 132 This document is organized as follows. Section 2 describes new 133 terms. Section 3 gives an overview of the basic communication and 134 describes the building blocks. Requirements are presented in Section 135 4. The details of the established parameters for the DHCP SA are 136 listed in Section 5. Processing details and payload formats are 137 illustrated in Section 6. A short message flow describes the 138 protocol interaction in Section 7. Finally in Section 8 additional 139 security considerations are discussed. 141 2. Terminology 143 This document uses the following term: 145 - DHCP security association 147 To secure DHCP messages a number of parameters including the key 148 that is shared between the PaC (DHCP client) and the DHCP server 149 have to be established. These parameters are collectively referred 150 as DHCP security association (or in short DHCP SA). 152 - DHCP Key 154 This term refers to the fresh and unique session key dynamically 155 established between the DHCP client (PaC) and the DHCP server. This 156 key is used to protect DHCP messages as described in [RFC3118]. 158 Further PANA related terms can be found in [PY+02]. 160 In this document, the key words "MAY", "MUST, "MUST NOT", 161 OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be 162 interpreted as described in [RFC2119]. 164 3. Overview and Building Blocks 166 Based on the PANA protocol interaction this bootstrapping protocol 167 requires protocol interaction between the PaC (which acts as DHCP 168 client), the PANA Authentication Agent (PAA) and the DHCP server. A 169 security association will be established between the DHCP server and 170 the DHCP client to protect DHCP messages. 172 PAA is located one IP hop away from the PaC. If the DHCP server is 173 on the same link, it can be co-located with the PAA. When PAA and 174 DHCP server are co-located, an internal mechanism, such as an API, 175 is sufficient for inter-process communication. If the DHCP server is 176 multiple hops away from the DHCP client, then there must be a DHCP 177 relay on the same link as the client. In that case, PAA will be co- 178 located with the DHCP relay. The required parameters can be 179 communicated to the DHCP server using the DHCP relay agent 180 information options [DS02]. For the purpose of confidentiality 181 protection IPsec protection can be applied as described in [SL+03]. 183 The protocol interaction is illustrated in Figure 1. 185 +---------+ +--------------+ 186 | | | PAA / | 187 | PaC |<===========================>| DHCP relay | 188 | | PANA and DHCP | or server | 189 +---------+ +--------------+ 190 Legend: 192 PaC - PANA Client 193 PAA - PANA Authentication Agent 195 Figure 1: DHCP Protocol Bootstrapping 197 The following building blocks have been identified: 199 3.1 PaC <-> PAA Communication 201 Additional payloads are required within PANA as indicated with (A) 202 in Figure 1. These payloads therefore provide the following 203 functionality: 205 a) Capability indication 207 A capability describes a certain functionality which is either 208 supported or not. In order to trigger an action or to obtain a 209 certain kind of data item it is necessary to execute some message 210 exchanges. This message exchange allows both entities to learn 211 commonly supported functionality. 213 b) Trigger message 215 A trigger message allows one entity (either PaC or PAA) to request a 216 certain action to be executed. For this protocol a trigger message 217 sent by the PaC causes the PAA to create the DHCP security 218 association for support with [RFC3118]. 220 Section 6 describes the message payloads for the additional objects 221 required in PANA the usage with this bootstrapping protocol. 223 3.2 PAA <-> DHCP Communication 225 If the PAA and the DHCP server are co-located then only an API call 226 is required for transferring the necessary information from the PAA 227 to the software modules of the DHCP server. If the PAA and the DHCP 228 server are not co-located then an additional protocol is needed to 229 transport the security parameters from the PAA to the DHCP server. 230 [WH+02] points to the importance of this communication as: "Key 231 distribution is not merely a data transport operation; it is also a 232 mechanism for building transitive trust;". Indeed the trust 233 relationship between the PaC and the PAA, which was dynamically 234 established during network access authentication, is used to extend 235 the trust relationship to the DHCP server. The PAA, which is co- 236 located with the DHCP Relay, and the DHCP server trust each other 237 and both entities belong to the same administrative domain as the 238 PAA. 240 Security sensitive information has to be exchanged (such as session 241 keys) between the DHCP relay (PAA) and the DHCP server. This 242 protocol is not part of PANA but the security implications must be 243 considered. 245 Two different protocols have been suggest in the past to support key 246 transport: Radius and Diameter 248 In order to secure the key transport key wrap mechanisms for 249 Diameter and for Radius have been specified (see [CFB02] and 250 [RFC2548]). The protection mechanism for key transport for Diameter 251 applies application level security mechanisms based on CMS whereas 252 Radius uses lower-layer security mechanisms such as IPsec. 254 In this context another approach might be possible: [DS02] allows a 255 DHCP relay to add information which is then sent to the DHCP server. 256 [SL+03] proposes IPsec protection of the DHCP messages exchanged 257 between the DHCP relay and the DHCP server. DHCP objects itself 258 (protected with IPsec) can therefore be used to communicate the 259 necessary parameters. 261 Further work is required to 262 (a) select one protocol which provides adequate security for the key 263 transport 264 (b) specify object payloads to carry the parameters between the PAA 265 and the DHCP server. 267 3.3 Key Derivation 269 As a result of the EAP authentication and key exchange method a 270 Master Session Key (MSK) is established which is used to establish a 271 PANA security association. The key derivation procedure for 272 establishing this PANA SA is defined in [PANA]. Another security 273 association for usage with DHCP according to [RFC3118] needs to be 274 established. A discussion of the required parameters for the 275 security association is given in Section 5 and the key derivation 276 function is provided in Section 6.2 278 Since different bootstrapping applications need different keys it is 279 necessary to derive these keys from the session key provided by the 280 EAP method. 282 4. Requirements 283 The following requirements regarding protocol design and deployment 284 have to be met: 286 - The DHCP protocol as defined in [RFC2131] MUST NOT be modified. 288 - The security mechanism defined in [RFC3118] MUST NOT be modified. 289 Instead it will be used as a basis for bootstrapping the security 290 with the help of PANA. 292 - The key derivation procedure MUST establish a unique and fresh 293 session key for the usage with [RFC3118]. The session key MUST never 294 be used again in another protocol run or with another DHCP server. 296 - It MUST be ensured that only the intended parties have access to 297 the session key. Hence the key transport between the PAA and the 298 DHCP server MUST be authenticated, integrity, replay and 299 confidentiality protected. The security mechanism used to protect 300 the transport of the session key between the PAA and the DHCP server 301 MUST have an adequate key strength. Section 5.4 of [AS03] offers a 302 description of issues concerning key wrapping. 304 - The DHCP server MUST ensure that only authorized nodes are allowed 305 to install keying material for subsequent DHCP message protection. 307 - The established DHCP security association MUST provide data origin 308 authentication, integrity protection and replay protection. A non- 309 goal of this draft is to provide confidentiality protection for DHCP 310 messages. 312 - The session key between the PaC and the DHCP server becomes active 313 immediately when the PAA returns a PANA message indicating the 314 successful completion of the bootstrapping procedure. The lifetime 315 of the session key at the DHCP is limited to the indicated lifetime. 316 The session key MUST NOT be used beyond that lifetime. Key 317 confirmation of the established session key between the PaC and the 318 DHCP server is provided by exchanging the first DHCP messages. 320 - Key Naming 322 The derived session key (DHCP key) MUST be bound to a particular 323 session between the particular PaC and a DHCP server. It MUST be 324 possible for the two peers (PaC and DHCP server) to verify that each 325 other is indeed the intended recipients of the distributed session 326 key. 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 fixed. 352 Since the value for this field is known in advance it does not need 353 to be communicated. 355 5.1.2 Length Field 357 The Length field indicates the length of the authentication option 358 payload. Since the value for this field can be computed it does not 359 need to be communicated. 361 5.1.3 Protocol Field 363 [RFC3118] defines two values for the Protocol field - zero and one. 364 A value of zero indicates the usage of the configuration token 365 authentication option. 367 As described in Section 4 of [RFC3118] the configuration token only 368 provides weak entity authentication. Hence the usage is 369 inappropriate. This authentication option will not be considered for 370 the purpose of bootstrapping. 372 A value of one in the Protocol field in the authentication option 373 indicates the Delayed authentication. The usage of this option is 374 subsequently assumed in this document. 376 Since the value for this field is known in advance it does not need 377 to be communicated. 379 5.1.4 Algorithm Field 381 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the 382 Algorithm field). This document assumes that HMAC-MD5 is used to 383 protect DHCP messages. 385 Since the value for this field is known in advance it does not need 386 to be communicated. 388 5.1.5 Replay Detection Method (RDM) Field 390 The value of zero for the RDM name space is assigned to use a 391 monotonically increasing value. 393 Since the value for this field is known in advance it does not need 394 to be communicated. 396 5.1.6 Replay Detection Field 398 This field contains the value which is used for replay protection 399 and it MUST be monotonically increasing according to the provided 400 replay detection method. 402 An initial value must, however, be set. In case of bootstrapping 403 with PANA an initial value of zero is used. The length of 64 bits 404 (and a start-value of zero) ensure that a sequence number roll-over 405 is very unlikely to occur. 407 Since the value for this field is known in advance it does not need 408 to be communicated. 410 5.1.7 Authentication Information Field 412 The content of this field depends on the type of message where the 413 authentication option is used. Section 5.2 of [RFC3118] does not 414 provide content for the DHCPDISCOVER and the DHCPINFORM message. 415 Hence for these messages no additional considerations need to be 416 specified in this document. 418 For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the 419 Authentication Information field is given as: 421 - Secret ID (32 bits) 422 - HMAC-MD5 (128 bits) 424 The Secret ID is chosen by the PAA to prevent collisions. 426 HMAC-MD5 is the output of the key message digest computation. Note 427 that not all fields of the DHCP message are protected as described 428 in [RFC3118]. 430 5.2 Lifetime of the DHCP security association 432 The lifetime of the DHCP security association has to be limited to 433 prevent the DHCP from storing state information over a long time. 435 The lifetime SHOULD be set to exceed the DHCP lease time. Since 436 access control implemented with the help of packet filters or 437 cryptographic data protection has to be associated somehow with the 438 accounting system it is a policy decision for the network to specify 439 a particular lifetime. 441 The DHCP server, the PAA, the Enforcement Point (EP) and the AAA 442 server should be aware (directly or indirectly) of the lifetime. 444 The PaC can at any time trigger a new bootstrapping protocol run to 445 establish a new security association with the DHCP server. 447 6. Processing Details and Payloads 449 This section defines the necessary extensions for PANA and a key 450 derivation procedure. 452 6.1 Capability Indication and Trigger Message 454 A new PANA AVP is defined in order to bootstrap DHCP SA between the 455 PaC and PAA. DHCP-AVP is included in the PANA_success message if PAA 456 is offering DHCP SA bootstrapping service. If the PaC wants to 457 proceed with creating DHCP SA at the end of the PANA authentication, 458 it MUST include DHCP-AVP in its PANA_success_ack message. 460 Absence of this AVP in the PANA_success message sent by PAA 461 indicates unavailability of this additional service. In that case, 462 PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore 463 if it receives this AVP. When this AVP is received by PaC, it may or 464 may not include the AVP in its response depending on its desire to 465 create DHCP SA. DHCP SA can be created as soon as each entity has 466 received and sent one DHCP-AVP. 468 The detailed DHCP-AVP format is presented below. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | AVP Code | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | AVP Flags | AVP Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Secret ID | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | | 480 ~ Nonce Data ~ 481 | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 AVP Code 486 TBD 488 AVP Flags 490 The AVP Flags field is eight bits. The following bits are 491 assigned: 493 0 1 2 3 4 5 6 7 494 +-+-+-+-+-+-+-+-+ 495 |V M r r r r r r| 496 +-+-+-+-+-+-+-+-+ 498 M(andatory) 500 - The 'M' Bit, known as the Mandatory bit, 501 indicates whether support of the AVP is 502 required. This bit is not set in DHCP-AVP. 504 V(endor) 506 - The 'V' bit, known as the Vendor-Specific bit, 507 indicates whether the optional Vendor-Id field 508 is present in the AVP header. This bit is not set in 509 DHCP-AVP. 511 r(eserved) 513 - These flag bits are reserved for future use, 514 and MUST be set to zero, and ignored by the 515 receiver. 517 AVP Length 519 The AVP Length field is three octets, and indicates the number 520 of octets in this AVP including the AVP Code, AVP Length, AVP 521 Flags, and the AVP data. 523 Secret ID 525 32 bit value that identifies the DHCP Key produced as a result of 526 the bootstrapping process. This value is determined by PAA and 527 sent to PaC. PAA determines this value by randomly picking a 528 number from the available session ID pool. If PaC's response does 529 not contain DHCP-AVP then this value is returned to the available 530 identifiers pool. 531 Otherwise, it is allocated to the PaC until DHCP SA expires. PaC 532 MUST set this field to all 0s in its response. 534 Nonce Data (variable length) 536 Contains the random data generated by the transmitting entity. 537 This field contains Nonce_PaC when the AVP is sent by PaC, and 538 Nonce_DHCP when the AVP is sent by PAA. Nonce value MUST be 539 randomly chosen and MUST be at least 128 bits in size. Nonce 540 values MUST NOT be reused. 542 6.2 Key Derivation 544 This section describes the key derivation procedure which allows to 545 establish a DHCP security association. The key derivation procedure 546 is reused from IKE [RFC2409]. The character '|' denotes 547 concatenation. 549 DHCP Key = HMAC-MD5(MSK, const | Session ID | Nonce_PaC | Nonce_DHCP 550 | DHCP-Server-Identity) 552 The values of have the following meaning: 554 - MSK 556 The Master Session Key (MSK) is provided by the EAP method as part 557 of the PANA/EAP protocol execution. 559 - const 561 This is a string constant. The value of the const parameter is set 562 to "PANA DHCP Bootstrapping". 564 - Session ID 566 This value is a 128-bit value as defined in the PANA protocol 567 [PANA]. This value identifiers a particular session of a client. 569 - Nonce_PaC 571 This random number is provided by the PaC and exchanged within the 572 PANA protocol. 574 - Nonce_DHCP 575 This random number is provided by the PAA/DHCP server and exchanged 576 with the PANA protocol. 578 - DHCP-Server-Identity 580 The DHCP-Server-Identity field contains the IP address of the DHCP 581 to which the session keys will be sent. 583 - DHCP Key 585 This session key is 128-bit in length and used as the session key 586 for securing DHCP messages. Figure 1 of [EAP-Key] refers to this 587 derived key as Transient Session Keys (TSKs). 589 7. Example message flow 591 This section describes some basic PANA message flows which use DHCP 592 bootstrapping. 594 Figure 2 depicts a message flow which enables DHCP bootstrapping. 595 The PANA message flow starts with a discovery of the PAA, followed 596 by network access authentication. Finally, after the authentication 597 is successful a PANA security association is established which 598 protects subsequent messages such as the DHCP-AVP. The DHCP-AVP 599 payload contains parameters described in Section 6. As a summary, it 600 indicates that the network supports bootstrapping and provides the 601 necessary parameter if requested by the PaC. 603 PaC PAA Message(tseq,rseq)[AVPs] 604 ------------------------------------------------------ 605 -----> PANA_discover(0,0) 606 <----- PANA_start(x,0)[Cookie] 607 -----> PANA_start(y,x)[Cookie] 608 <----- PANA_auth(x+1,y)[EAP{Request}] 609 -----> PANA_auth(y+1,x+1)[EAP{Response}] 610 . 611 . 612 <----- PANA_auth(x+n,y+n-1)[EAP{Request}] 613 -----> PANA_auth(y+n,x+n)[EAP{Response}] 614 <----- PANA_success(x+n+1,y+n) // F-flag set 615 [EAP{Success}, DHCP-AVP, MAC] 616 -----> PANA_success_ack(y+n+1,x+n+1) 617 [Device-Id, DHCP-AVP, MAC] // F-flag set 619 Figure 2: Message flow for PANA DHCP bootstrapping 621 8. Security Considerations 622 This document describes a mechanism for dynamically establishing a 623 security association to protect DHCP signaling messages. 625 PANA uses EAP to support a number of authentication and key exchange 626 protocols. With the functionality of EAP this document therefore 627 supports DHCP security for roaming users. 629 This document separates the different security mechanisms in a clean 630 way: 632 a) The appropriate EAP method for a certain scenario, environment or 633 architecture can be chosen. The security properties heavily depend 634 on the chosen EAP method. 636 b) PANA carries EAP messages and provides additional security. The 637 security features of PANA are described in [PANA]. 639 c) The security mechanism in [RFC3118] is reused for providing 640 authentication, integrity and replay protection. 642 If the PAA and the DHCP server are co-located then the session keys 643 and the security parameters are transferred locally (via an API 644 call). Some security protocols already exercise similar methodology 645 to separate functionality. 647 If the PAA and the DHCP server are not co-located then there is some 648 similarity to the requirements and issues discussed with the EAP 649 Keying Framework (see [AS03]). Figure 3 is taken from Section 4.5 of 650 [AS03] and adjusted accordingly. A major different to [AS03] is that 651 the communication between the PAA and DHCP server takes place 652 between the same administrative domain. Hence the security issues 653 described in [WH+03] are much less problematic. 655 PaC (DHCP client) 656 /\ 657 Protocol: PANA(EAP) / \ 658 Auth: Mutual / \ Protocol: Key derivation for DHCP SA 659 Unique keys: / \ Auth: Mutual 660 - EAP derived Keys/ \ Unique key: DHCP Key 661 - PANA SA / \ 662 / \ 663 PAA +--------------+ DHCP server 665 Protocol: DHCP, AAA or API 666 Auth: Mutual 667 Unique key: protocol dependent 669 Figure 3: Keying Architecture 670 Figure 3 describes the participating entities and the protocol 671 executed between them. It must be ensured that the derived session 672 key between the PaC and the DHCP server is fresh and unique. 674 The key transport mechanism, which is used to carry the session key 675 between the PAA and DHCP server, must provide the following 676 functionality: 678 - Confidentiality protection 679 - Replay protection 680 - Integrity protection 682 Furthermore it is necessary that the two parties (DHCP server and 683 the PAA) authorize the establishment of the DHCP security 684 association. 686 Russ Housley recently (at the 56th IETF) presented a list of 687 recommendations for key management protocols which describe 688 requirements for an acceptable solution. Although the presentation 689 focused on NASREQ some issues might also applicable in our context. 690 We will address the presented issues briefly: 692 - Algorithm independence 694 Our proposal bootstraps a DHCP security association based on RFC 695 3118 where only a single integrity algorithm (namely HMAC-MD5) is 696 proposed which is mandatory to implement. 698 - Establish strong, fresh session keys (Maintain algorithm 699 independence) 701 PANA relies on EAP to provide strong and fresh session keys for each 702 initial authentication and key exchange protocol run. Furthermore 703 the key derivation function provided in Section 6.2 contains random 704 numbers provided by the PaC and the PAA which additionally add 705 randomness to the generated key. 707 - Include replay detection mechanism 709 Replay protection is provided by the PANA protocol itself and by 710 including random numbers for the key derivation procedure which aims 711 to provide a fresh and unique session key between the PaC (DHCP 712 client) and the DHCP server. 714 Furthermore, the key transport mechanism between the PAA and the 715 DHCP server must also provide replay protection (in addition to 716 confidentiality protection). 718 - Authenticate all parties 719 Authentication between the PaC and the PAA is provided by the PANA 720 protocol which utilizes EAP. After establishing a PANA security 721 association key confirmation of this PANA SA is provided. 723 Key confirmation between the PaC and the DHCP server is provided 724 with the first protected DHCP messages exchanged. 726 - Perform authorization 728 Authorization for network access is provided during the PANA 729 exchange. The authorization procedure for DHCP bootstrapping is 730 executed by the PAA after the PaC requests bootstrapping. 732 The PAA might reject a request for bootstrapping based on local 733 policies. 735 - Maintain confidentiality of session keys 737 The DHCP session keys are known to the indented parties only i.e. to 738 the PaC, PAA and the DHCP server. 740 The PANA protocol does not transport keys at all. The exchanged 741 random numbers which are incorporated into the key derivation 742 function do not need to be kept confidential. 744 The key transport between the PAA and the DHCP server (in case that 745 these two entities are not co-located) must ensure confidentiality 746 of the session keys. 748 - Confirm selection of "best" ciphersuite 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 occurs. 755 - Uniquely name session keys 757 The session key is uniquely named by including identifiers of the 758 intended parties (DHCP server and PaC) into the key derivation 759 function. Furthermore a constant "PANA DHCP Bootstrapping" is 760 included which prevents usage of this session key for a different 761 bootstrapping application. 763 - Compromised PAA 765 A compromised PAA will be able to learn the DHCP session key and the 766 EAP derived session key (e.g. MSK) and the PANA SA. It will 767 furthermore be able to corrupt the DHCP protocol executed between 768 mobile end hosts and the DHCP server since 769 - the PAA either itself acts as a DHCP server or 770 - the PAA acts as a DHCP relay. 772 A compromised PAA will also be able to create further DHCP SAs or to 773 perform other known attacks on the DHCP protocol (e.g. address 774 depletion). 776 A compromised PAA will not be able to modify, reply, inject DHCP 777 messages which use security associations established without the 778 PANA bootstrapping protocol (e.g. manually configured DHCP SAs) or 779 DHCP SAs established with PANA before the PAA was compromised. 781 - Bind key to appropriate context 783 The key derivation function described in Section 6.2 includes 784 parameters (such as the DHCP server identity and a constant) which 785 prevents reuse of the established session key for other purposes. 786 The key derivation includes the session identifier to associate the 787 key to the context of a certain PANA protocol session and therefore 788 to a particular client. 790 9. IANA Considerations 792 TBD 794 10. Open Issues 796 This document describes a bootstrapping procedure for [RFC3118]. The 797 same procedure could be applied for [DHCPv6]. 799 It is necessary to describe the details of the capability 800 negotiation within PANA and to define the DHCP object structure 801 which allows communication of the necessary parameters between the 802 PAA and the DHCP server. 804 11. References 806 [DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. 807 Carney: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 808 Internet-Draft, (work in progress), November, 2002. 810 [PANA] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin: 811 "Protocol for Carrying Authentication for Network Access (PANA)", 812 Internet-Draft, (work in progress), March, 2003. 814 [RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP 815 Messages", RFC 3118, June 2001. 817 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 818 (IKE)", RFC 2409, November 1998. 820 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. 821 Turner, "Internet Security Association and Key Management Protocol 822 (ISAKMP)", RFC 2408, November 1998. 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.: 828 "Protocol for Carrying Authentication for Network Access (PANA) 829 Requirements and Terminology", Internet-Draft, (work in progress), 830 April, 2003. 832 [DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option 833 for the DHCP Relay Agent Information", Internet-Draft, (work in 834 progress), October, 2002. 836 [SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication 837 Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in 838 progress), April, 2003. 840 [AS03] Aboba, B. and Simon, D.: "EAP Keying Framework", Internet- 841 Draft, (work in progress), March 2003. 843 [RFC2132] Alexander, S. and Droms, R.: "DHCP Options and BOOTP 844 Vendor Extensions", RFC 2132, March 1997. 846 [RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC 847 2131, March 1997. 849 [WH+03] J. Walker, R. Housley, and N. Cam-Winget, "AAA key 850 distribution", Internet Draft, (work in progress), April 2002. 852 [RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", 853 RFC 2548, March 1999. 855 [CFB02] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS 856 Security Application", Internet-Draft, (work in progress), March 857 2002. 859 12. Acknowledgments 861 Place your name here. 863 13. Author's Addresses 864 Hannes Tschofenig 865 Siemens AG 866 Otto-Hahn-Ring 6 867 81739 Munich 868 Germany 869 EMail: Hannes.Tschofenig@siemens.com 871 Alper E. Yegin 872 DoCoMo USA Labs 873 181 Metro Drive, Suite 300 874 San Jose, CA, 95110 875 USA 876 Phone: +1 408 451 4743 877 Email: alper@docomolabs-usa.com 879 Dan Forsberg 880 Nokia Research Center 881 P.O. Box 407 882 FIN-00045 NOKIA GROUP, Finland 883 Phone: +358 50 4839470 884 EMail: dan.forsberg@nokia.com 886 Full Copyright Statement 888 Copyright (C) The Internet Society (2001). All Rights Reserved. 889 This document and translations of it may be copied and furnished to 890 others, and derivative works that comment on or otherwise explain it 891 or assist in its implementation may be prepared, copied, published 892 and distributed, in whole or in part, without restriction of any 893 kind, provided that the above copyright notice and this paragraph 894 are included on all such copies and derivative works. However, this 895 document itself may not be modified in any way, such as by removing 896 the copyright notice or references to the Internet Society or other 897 Internet organizations, except as needed for the purpose of 898 developing Internet standards in which case the procedures for 899 copyrights defined in the Internet Standards process must be 900 followed, or as required to translate it into languages other than 901 English. 903 The limited permissions granted above are perpetual and will not be 904 revoked by the Internet Society or its successors or assigns. 906 This document and the information contained herein is provided on an 907 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 908 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 909 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 910 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 911 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.