Network Working Group A. Yegin Internet Draft Samsung H. Tschofenig Siemens Corporate Technology D. Forsberg Nokia Expires: July 2005 January 2005 Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract DHCP authentication extension (RFC3118) cannot be widely deployed due to lack of an out-of-band key agreement protocol for DHCP clients and servers. This draft outlines how EAP-based network access authentication mechanisms can be used to establish a local trust relation and generate keys that can be used in conjunction with RFC3118. Yegin, et al. Expires July 2005 [Page 2] EAP-boot-RFC3118 January 2005 Table of Contents 1.0 Introduction.................................................2 2.0 Terminology..................................................3 3.0 Overview and Building Blocks.................................4 4.0 Building DHCP SA.............................................5 4.1. 802.1X....................................................5 4.2. PPP.......................................................5 4.3. PANA......................................................7 4.4. Computing DHCP SA.........................................8 5.0 Delivering DHCP SA..........................................10 6.0 Using DHCP SA...............................................11 7.0 Security Considerations.....................................13 8.0 IANA Considerations.........................................16 9.0 Open Issues.................................................16 10.0 References.................................................16 11.0 Acknowledgments............................................17 12.0 Author's Addresses.........................................18 1.0 Introduction EAP [EAP] provides a network access authentication framework by carrying authentication process between the hosts and the access networks. The combination of EAP with a AAA architecture allows authentication and authorization of a roaming user to an access network. A successful authentication between a client and the network produces a dynamically created trust relation between the two. Various EAP authentication methods (e.g., EAP-TLS, EAP-SIM) are capable of generating cryptographic keys between the client and the local authentication agent (network access server - NAS) after the successful authentication. These keys are commonly used in conjunction with per-packet security mechanisms (e.g., link-layer ciphering). DHCP [RFC2131] is a protocol which provides an end host with the configuration parameters. The base DHCP does not include any security mechanism, hence it is vulnerable to a number of security threats. Security considerations section of RFC 2131 identifies this protocol as "quite insecure" and lists various security threats. RFC 3118 is the DHCP authentication protocol which defines how to authenticate various DHCP messages. It does not support roaming clients and assumes out-of band or manual key establishment. These limitations have been inhibiting widespread deployment of this security mechanism [DHC-THREAT]. It is possible to use the authentication and key exchange procedure executed during the network access authentication to bootstrap a security association for DHCP. The trust relation created during the access authentication process can be used with RFC 3118 to provide Yegin, et al. Expires July 2005 [Page 3] EAP-boot-RFC3118 January 2005 security for DHCP. This document defines how to use EAP-based access authentication process to bootstrap RFC 3118 for securing DHCP. The general framework of the mechanism described in this I-D can be outlined as follows: (1) The client gains network access by utilizing an EAP authentication method that generates session keys. As part of the network access process, the client and the authentication agent (NAS) communicate their intention to create a DHCP security association and exchange the required parameters (e.g., nonce, key ID, etc.) The required information exchange is handled by the EAP lower-layer which also carries EAP. (2) Although the newly generated DHCP SA is already available to the DHCP client, in case the NAS (acting as a DHCP relay) and the DHCP server are not co-located, the SA parameters need to be communicated to the DHCP server. This requires a protocol exchange, which can be piggybacked with the DHCP signaling. (3) The DHCP signaling that immediately follows the network access authentication process utilizes RFC3118 to secure the protocol exchange. Both the client and the server rely on the DHCP SA to compute and verify the authentication codes. This framework requires extensions to the EAP lower-layers (PPP [PPP], IEEE 802.1X [8021X], PANA [PANA]) to carry the supplemental parameters required for the generation of the DHCP SA. Another extension is required to carry the DHCP SA parameters from a DHCP relay to a DHCP server. RFC3118 can be used without any modifications or extensions. 2.0 Terminology This document uses the following terms: - DHCP Security Association To secure DHCP messages a number of parameters including the key that is shared between the client (DHCP client) and the DHCP server have to be established. These parameters are collectively referred to as DHCP security association (or in short DHCP SA). DHCP SA can be considered as a group security association. The DHCP SA parameters are provided to the DHCP server as soon as the client chooses the server to carry out DHCP. The same DHCP SA can be used by any one of the DHCP servers that are available to the client. Yegin, et al. Expires July 2005 [Page 4] EAP-boot-RFC3118 January 2005 - DHCP Key This term refers to the fresh and unique session key dynamically established between the DHCP client and the DHCP server. This key is used to protect DHCP messages as described in [RFC3118]. In this document, the key words "MAY", "MUST, "MUST NOT", OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 3.0 Overview and Building Blocks The bootstrapping mechanism requires protocol interaction between the client host (which acts as a DHCP client), the NAS and the DHCP server. A security association will be established between the DHCP server and the DHCP client to protect the DHCP messages. A DHCP SA is generated based on the EAP SA after a successful EAP authentication. Both the client and the NAS should agree on the generation of a DHCP SA after the EAP SA is created. This involves a handshake between the two and exchange of additional parameters (such as nonce, key ID, etc.). These additional information needs to be carried over the EAP lower-layer that also carries the EAP payloads. The DHCP SA is ultimately needed by the DHCP client and the DHCP server. On the network side, the DHCP SA information needs to be transferred from the NAS (where it is generated) to the DHCP server (where it will be used). On the client host side, it is transferred from the network access authentication client to the DHCP client. NAS is always located one IP hop away from the client. If the DHCP server is on the same link, it can be co-located with the NAS. When the NAS and the DHCP server are co-located, an internal mechanism, such as an API, is sufficient for transferring the SA information. If the DHCP server is multiple hops away from the DHCP client, then there must be a DHCP relay on the same link as the client. In that case, the NAS should be co-located with the DHCP relay. [DS02] enables transmission of AAA-related RADIUS attributes from a DHCP relay to a DHCP server in the form of relay agent information options. DHCP SA is generated at the end of the AAA process, and therefore it can be provided to the DHCP server in a sub-option carried along with other AAA-related information. Confidentiality, replay, and integrity protection of this exchange MUST be provided. [RD03] proposes IPsec protection of the DHCP messages exchanged between the DHCP relay and the DHCP server. DHCP objects (protected with IPsec) can therefore be used to communicate the necessary parameters. Yegin, et al. Expires July 2005 [Page 5] EAP-boot-RFC3118 January 2005 Two different deployment scenarios are illustrated in Figure 1. +---------+ +------------------+ |EAP Peer/| |EAP Authenticator/| | DHCP |<============>| DHCP server | | client | EAP and DHCP | | +---------+ +------------------+ Client Host NAS +---------+ +------------------+ +-----------+ |EAP Peer/| |EAP Authenticator/| | | | DHCP |<============>| DHCP relay |<========>|DHCP server| | client | EAP and DHCP | | DHCP | | +---------+ +------------------+ +-----------+ Client Host NAS Figure 1: Protocols and end points. When the DHCP SA information is received by the DHCP server and client, it can be used along with RFC3118 to protect DHCP messages against various security threats. This draft provides the guidelines regarding how the RFC3118 protocol fields should be filled in based on the DHCP SA. 4.0 Building DHCP SA DHCP SA is created at the end of the EAP-based access authentication process. This section describes extensions to the EAP lower-layers for exchanging the additional information, and the process of generating the DHCP SA. 4.1. 802.1X TBD. 4.2. PPP A new IPCP configuration option is defined in order to bootstrap DHCP SA between the PPP peers. Each end of the link must separately request this option for mutual establishment of DHCP SA. Only one side sending the option will not produce any state. Yegin, et al. Expires July 2005 [Page 6] EAP-boot-RFC3118 January 2005 The detailed DHCP-SA Configuration Option is presented below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secret ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length >=24 Reserved A 16-bit value reserved for future use. It MUST be initialized to zero by the sender, and ignored by the receiver. Secret ID 32 bit value that identifies the DHCP Key produced as a result of the bootstrapping process. This value is determined by the NAS and sent to the client. The NAS determines this value by randomly picking a number from the available secret ID pool. If the client does not request DHCP-SA configuration option, this value is returned to the available identifiers pool. Otherwise, it is allocated to the client until the DHCP SA expires. The client MUST set this field to all 0s in its own request. Nonce Data (variable length) Contains the random data generated by the transmitting entity. This field contains the Nonce_client value when the option is sent by client, and the Nonce_NAS value when the option is sent by NAS. Nonce value MUST be randomly chosen and MUST be at least 128 bits in size. Nonce values MUST NOT be reused. Yegin, et al. Expires July 2005 [Page 7] EAP-boot-RFC3118 January 2005 4.3. PANA A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP- AVP is included in the PANA-Bind-Request message if PAA (NAS) is offering DHCP SA bootstrapping service. If the PaC wants to proceed with creating DHCP SA at the end of the PANA authentication, it MUST include DHCP-AVP in its PANA-Bind-Answer message. Absence of this AVP in the PANA-Bind-Request message sent by the PAA indicates unavailability of this additional service. In that case, PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore received DHCP-AVP. When this AVP is received by the PaC, it may or may not include the AVP in its response depending on its desire to create a DHCP SA. A DHCP SA can be created as soon as each entity has received and sent one DHCP-AVP. The detailed DHCP-AVP format is presented below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Flags | AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secret ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code TBD AVP Flags The AVP Flags field is eight bits. The following bits are assigned: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V M r r r r r r| +-+-+-+-+-+-+-+-+ M(andatory) - The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. This bit is not set in DHCP-AVP. Yegin, et al. Expires July 2005 [Page 8] EAP-boot-RFC3118 January 2005 V(endor) - The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-Id field is present in the AVP header. This bit is not set in DHCP-AVP. r(eserved) - These flag bits are reserved for future use, and MUST be set to zero, and ignored by the receiver. AVP Length The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, and AVP data. Secret ID A 32-bit value that identifies the DHCP Key produced as a result of the bootstrapping process. This value is determined by the PAA and sent to the PaC. The PAA determines this value by randomly picking a number from the available secret ID pool. If PaC's response does not contain DHCP-AVP then this value is returned to the available identifiers pool. Otherwise, it is allocated to the PaC until the DHCP SA expires. The PaC MUST set this field to all 0s in its response. Nonce Data (variable length) Contains the random data generated by the transmitting entity. This field contains the Nonce_client value when the AVP is sent by PaC, and the Nonce_NAS value when the AVP is sent by PAA. Nonce value MUST be randomly chosen and MUST be at least 128 bits in size. Nonce values MUST NOT be reused. 4.4. Computing DHCP SA The key derivation procedure is reused from IKE [RFC2409]. The character '|' denotes concatenation. DHCP Key = HMAC-MD5(AAA-key, const | Secret ID | Nonce_client | Nonce_NAS) Yegin, et al. Expires July 2005 [Page 9] EAP-boot-RFC3118 January 2005 The values have the following meaning: - AAA-key: A key derived by the EAP peer and EAP (authentication) server and transported to the authenticator (NAS) at the end of the successful network access AAA. - const: This is a string constant. The value of the const parameter is set to "EAP RFC3118 Bootstrapping". - Secret ID: The unique identifier of the DHCP key as carried by the EAP lower-layer protocol extension. - Nonce_client: This random number is provided by the client and carried by the EAP lower-layer protocol extension. - Nonce_NAS: This random number is provided by the NAS and carried by the EAP lower-layer protocol. - DHCP Key: This session key is 128-bit in length and used as the session key for securing DHCP messages. Figure 1 of [EAP-Key] refers to this derived key as a Transient Session Key (TSK). The lifetime of the DHCP security association has to be limited to prevent the DHCP server from storing state information indefinitely. The lifetime of the DHCP SA should be set to the lifetime of the network access service. The client host, NAS, and the DHCP server should be (directly or indirectly) aware of this lifetime at the end of a network access AAA. The PaC can at any time trigger a new bootstrapping protocol run to establish a new security association with the DHCP server. The IP address lease time SHOULD be limited by the DHCP SA lifetime. Yegin, et al. Expires July 2005 [Page 10] EAP-boot-RFC3118 January 2005 5.0 Delivering DHCP SA When the NAS and the DHCP server are not co-located, the DHCP SA information is carried from the NAS (DHCP relay) to the DHCP server in a DHCP relay agent info option. This sub-option can be included along with the RADIUS attributes sub-option that is carried after the network access authentication. The format of the DHCP SA sub-option is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubOpt Code | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secret ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DHCP Key + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SubOpt Code TBD Length This value is set to 26. Reserved A 16-bit value reserved for future use. It MUST be initialized to zero by the sender, and ignored by the receiver. Secret ID This is the 32-bit value assigned by the NAS and used to identify the DHCP key. DHCP Key 128-bit DHCP key computed by the NAS is carried in this field. Yegin, et al. Expires July 2005 [Page 11] EAP-boot-RFC3118 January 2005 Lifetime The lifetime of the DHCP SA. This Unsigned32 value contains the number of seconds remaining before the DHCP SA is considered expired. 6.0 Using DHCP SA Once the DHCP SA is in place, it is used along with RFC3118 to secure the DHCP protocol exchange. [RFC3118] defines two security protocols with a newly defined authentication option: - Configuration token - Delayed authentication The generic format of the authentication option is defined in Section 2 of [RFC3118] and contains the following fields: - Code The value for the Code field of this authentication option is 90. - Length The Length field indicates the length of the authentication option payload. - Protocol [RFC3118] defines two values for the Protocol field - zero and one. A value of zero indicates the usage of the configuration token authentication option. As described in Section 4 of [RFC3118] the configuration token only provides weak entity authentication. Hence its usage is not recommended. This authentication option will not be considered for the purpose of bootstrapping. A value of one in the Protocol field in the authentication option indicates the delayed authentication. The usage of this option is subsequently assumed in this document. Since the value for this field is known in advance it does not need to be negotiated between the DHCP client and DHCP server. Yegin, et al. Expires July 2005 [Page 12] EAP-boot-RFC3118 January 2005 - Algorithm [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the Algorithm field). This document assumes that HMAC-MD5 is used to protect DHCP messages. Since the value for this field is known in advance it does not need to be negotiated. [TBD: Consider future algorithm support] - Replay Detection Method (RDM) The value of zero for the RDM name space is assigned to use a monotonically increasing value. Since the value for this field is known in advance it does not need to be negotiated. - Replay Detection This field contains the value that is used for replay protection. This value MUST be monotonically increasing according to the provided replay detection method. An initial value must, however, be set. In case of bootstrapping with EAP an initial value of zero is used. The length of 64 bits (and a start-value of zero) ensures that a sequence number rollover is very unlikely to occur. Since the value for this field is known in advance it does not need to be negotiated. - Authentication Information The content of this field depends on the type of message where the authentication option is used. Section 5.2 of [RFC3118] does not provide content for the DHCPDISCOVER and the DHCPINFORM message. Hence for these messages no additional considerations need to be specified in this document. For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the Authentication Information field is given as: - Secret ID (32 bits) - HMAC-MD5 (128 bits) The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If there are multiple NASes per DHCP server, this identifier space might need to be pre-partitioned among the NASes.] HMAC-MD5 is the output of the key message digest computation. Note that not all fields of the DHCP message are protected as described in [RFC3118]. Yegin, et al. Expires July 2005 [Page 13] EAP-boot-RFC3118 January 2005 7.0 Security Considerations This document describes a mechanism for dynamically establishing a security association to protect DHCP signaling messages. If the NAS and the DHCP server are co-located then the session keys and the security parameters are transferred locally (via an API call). Some security protocols already exercise similar methodology to separate functionality. If the NAS and the DHCP server are not co-located then there is some similarity to the requirements and issues discussed with the EAP Keying Framework (see [AS+03]). Figure 2 is originally taken from Section 4.1 of [AS+03] and extended accordingly. DHCP key is a TSK (Transient Session Key [AS+03]). The key is generated by both the DHCP client and the DHCP relay, and transported from the DHCP relay to the DHCP server. DHCP protocol traffic between the DHCP client and DHCP server is protected using this key. EAP peer (DHCP client) +-----------------------+ DHCP server /\ / / \ Protocol: EAP / / \ lower-layer; / / \ Auth: Mutual; / / \ Unique key: / Protocol: EAP; / \ DHCP key / Auth: Mutual; / \ / Protocol: DHCP, or API; Unique keys: MK, / \ / Auth: Mutual; TEKs, EMSK / \ / Unique key: DHCP key / \ / / \ / Auth. server +----------------------+ Authenticator Protocol: AAA; (NAS, DHCP relay) Auth: Mutual; Unique key: AAA session key Figure 2: Keying Architecture Figure 2 describes the participating entities and the protocols executed among them. It must be ensured that the derived session key between the DHCP client and the server is fresh and unique. Yegin, et al. Expires July 2005 [Page 14] EAP-boot-RFC3118 January 2005 The key transport mechanism, which is used to carry the session key between the NAS and DHCP server, must provide the following functionality: - Confidentiality protection - Replay protection - Integrity protection Furthermore it is necessary that the two parties (DHCP server and the NAS) authorize the establishment of the DHCP security association. At IETF 56 Russ Housley presented a list of recommendations for key management protocols which describe requirements for an acceptable solution. Although the presentation focused on NASREQ some issues might be also applicable in this context. - Algorithm independence: This proposal bootstraps a DHCP security association for RFC 3118 where only a single integrity algorithm (namely HMAC-MD5) is proposed which is mandatory to implement. - Establish strong, fresh session keys (maintain algorithm independence): This scheme relies on EAP methods to provide strong and fresh session keys for each initial authentication and key exchange protocol run. Furthermore the key derivation function provided in Section 4.4 contains random numbers provided by the client and the NAS which additionally add randomness to the generated key. - Replay protection: Replay protection is provided at different places. The EAP method executed between the EAP peer and the EAP server MUST provide a replay protection mechanism. Additionally random numbers and the secret ID are included in the key derivation procedure which aim to provide a fresh and unique session key between the DHCP client and the DHCP server. Furthermore, the key transport mechanism between the NAS and the DHCP server must also provide replay protection (in addition to confidentiality protection). Finally, the security mechanisms provided in RFC 3118, for which this draft bootstraps the security association, also provides replay protection. Yegin, et al. Expires July 2005 [Page 15] EAP-boot-RFC3118 January 2005 - Authenticate all parties: Authentication between the EAP peer and the EAP server is based on the used EAP method. After a successful authentication and protocol run, the host and the NAS in the network provide AAA-key confirmation either based on the 4-way handshake in IEEE 802.11i or based on the protected PANA exchange. DHCP key confirmation between the DHCP client and server is provided with the first protected DHCP message exchange. - Perform authorization: Authorization for network access is provided during the EAP exchange. The authorization procedure for DHCP bootstrapping is executed by the NAS before this service is offered to the client. The NAS might choose not to include DHCP-AVP or DHCP SA Configuration Option during network access authorization based on the authorization policies. - Maintain confidentiality of session keys: The DHCP session keys are only known to the intended parties (i.e., to the DHCP client, relay [TBD: is that OK?], and server). The EAP protocol itself does not transport keys. The exchanged random numbers which are incorporated into the key derivation function do not need to be kept confidential. DHCP relay agent information MUST be protected using [RD03] with non-null IPsec encryption. - Confirm selection of "best" cipher-suite: This proposal does not provide confidentiality protection of DHCP signaling messages. Only a single algorithm is offered for integrity protection. Hence no algorithm negotiation and therefore no confirmation of the selection occur. - Uniquely name session keys: The DHCP SA is uniquely identified using a Secret ID (described in [RFC3118] and reused in this document). - Compromised NAS and DHCP server: A compromised NAS may leak the DHCP session key and the EAP derived session key (e.g., AAA-key). It will furthermore allow corruption of the DHCP protocol executed between the hosts and the DHCP server since NAS either acts as a DHCP relay or a DHCP server. A compromised NAS may also allow creation of further DHCP SAs or other known attacks on the DHCP protocol (e.g., address depletion). Yegin, et al. Expires July 2005 [Page 16] EAP-boot-RFC3118 January 2005 A compromised NAS will not be able to modify, replay, inject DHCP messages which use security associations established without the EAP-based bootstrapping mechanism (e.g., manually configured DHCP SAs). On the other hand, a compromised DHCP server may only leak the DHCP key information. AAA-key will not be compromised in this case. - Bind key to appropriate context: The key derivation function described in Section 4.4 includes parameters (such as the secret ID and a constant) which prevents reuse of the established session key for other purposes. 8.0 IANA Considerations TBD 9.0 Open Issues This document describes a bootstrapping procedure for [RFC3118]. The same procedure could be applied for [DHCPv6]. 10.0 References [DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Internet-Draft, (work in progress), November, 2002. [PANA] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin: "Protocol for Carrying Authentication for Network Access (PANA)", Internet-Draft, (work in progress), March, 2003. [RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.: "Protocol for Carrying Authentication for Network Access (PANA) Yegin, et al. Expires July 2005 [Page 17] EAP-boot-RFC3118 January 2005 Requirements and Terminology", Internet-Draft, (work in progress), April, 2003. [DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option for the DHCP Relay Agent Information", Internet-Draft, (work in progress), October, 2002. [SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in progress), April, 2003. [AS+03] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz: "EAP Keying Framework", Internet-Draft, (work in progress), October 2003. [RFC2132] Alexander, S. and Droms, R.: "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [WH+03] J. Walker, R. Housley, and N. Cam-Winget, "AAA key distribution", Internet Draft, (work in progress), April 2002. [RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", RFC 2548, March 1999. [CFB02] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS Security Application", Internet-Draft, (work in progress), March 2002. [RD03] R. Droms: "Authentication of DHCP Relay Agent Options Using IPsec", Internet-Draft (work in progress), August 2003. [SE03] J. Salowey and P. Eronen: "EAP Key Derivation for Multiple Applications", Internet-Draft (work in progress), June 2003. [DHC-THREAT] Hibbs, R., Smith, C., Volz, B., Zohar, M., "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", Internet-draft (expired), June 2003. [8021X] IEEE Standard for Local and Metropolitan Area Networks, "Port-Based Network Access Control", IEEE Std 802.1X-2001. [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD 51), July 1994. 11.0 Acknowledgments We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for their useful feedback to this work. Yegin, et al. Expires July 2005 [Page 18] EAP-boot-RFC3118 January 2005 12.0 Author's Addresses Alper E. Yegin Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA Phone: +1 408 544 5656 EMail: alper.yegin@samsung.com Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Dan Forsberg Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP, Finland Phone: +358 50 4839470 EMail: dan.forsberg@nokia.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yegin, et al. Expires July 2005