DHC Working Group J. Salowey Internet-Draft R. Pruss Intended status: Standards Track Cisco Systems, Inc. Expires: January 7, 2009 July 6, 2008 Using EAP keying material to derive keys for DHCP Authentication draft-salowey-dhc-eapkey-3118-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo describes a mechanism to use keying material derived from the extensible authentication protocol (EAP) to derive cryptographic keys for authentication of the Dynamic Host Configuration Protocol (DHCP). Keys are derived from the EAP extended master session key (EMSK) and are used in a new DHCP authentication option based on the DHCP delayed authentication option defined in RFC 3118. Salowey & Pruss Expires January 7, 2009 [Page 1] Internet-Draft EAP keying of DHCP Authentication July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 3. EAP-keyed Delayed Authentication Protocol . . . . . . . . . . . 3 4. Distributing derived keys . . . . . . . . . . . . . . . . . . . 4 4.1. DHCP Server Co-located with EAP Authenticator . . . . . . . 4 4.2. DHCP Relay Co-located with EAP Authenticator . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Salowey & Pruss Expires January 7, 2009 [Page 2] Internet-Draft EAP keying of DHCP Authentication July 2008 1. Introduction The Extensible Authentication Protocol (EAP) [RFC3748] is commonly used to authenticate a network access client before granting network access. During the authentication process it is common for EAP methods to derive a master session key (MSK) for protecting traffic communicated between the network access client and the EAP authenticator (see [I-D.ietf-eap-keying]). In addition EAP methods that derive keys are required to derive an Extended Master Session Key (EMSK) that can be used to derive keys for other purposes. This document describes a mechanism for deriving keys to be used in the Dynamic Host Configuration Protocol (DHCP) EAP-keyed delayed authentication option which is based on the "delayed authentication" option defined in [RFC3118]. The key derivation follows the EMSK key derivation framework defined in [I-D.ietf-hokey-emsk-hierarchy]. In order for keys to be available for this mechanism a key deriving EAP authentication must have been successfully executed using a mechanism such as 802.1X [8021X], PPP [RFC3748], PANA [RFC5191] or EAP-DHCP [I-D.pruss-dhcp-auth-dsl]. Non-key deriving EAP mechanisms cannot be used for the purposes described in this document. Previous work, [I-D.yegin-eap-boot-rfc3118], described a similar mechanism. The current proposal derives keys from the EMSK instead of the MSK to avoid any conflicts that might arise from existing or future uses of the MSK. In addition this memo defines DHCP options to indicate the identity and availability of the necessary EAP key material to the DHCP client and server. [I-D.yegin-eap-boot-rfc3118] defines a mechanism to carry indication within EAP lower layer protocols to signal when keys for this purpose should be derived. This is a useful feature and may be added to a future version of this draft. 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 3. EAP-keyed Delayed Authentication Protocol RFC 3118 provides cryptographic authentication in the "delayed authentication" option. The memo defines a new protocol option, "EAP-keyed delayed authentication option". This option is identical to the "delayed authentication" protocol option with the exception that the secret ID and the secret key used for message authentication Salowey & Pruss Expires January 7, 2009 [Page 3] Internet-Draft EAP keying of DHCP Authentication July 2008 are derived from a previous successful EAP exchange using the EMSK key derivation framework defined in [I-D.ietf-hokey-emsk-hierarchy]. The client indicates this option if it has successfully completed and EAP key-deriving method and has access to the keys necessary for DHCP protection. This document defines an EMSK usage for the EAP-keyed delayed authentication option. The secret key used is derived from a usage specific root key (USRK). The key label for an RFC 3118 root key, RFC3118-RK, is "dhcp-rfc3118@ietf.org". No optional data is used in the key derivation and the length of the RFC3118-RK is 32 bytes. The lifetime of the RFC3118-RK is the same as the EAP session. The key MUST be replaced by a new key a new EAP transaction completes successfully. The secret key used for calculating the MAC is derived from the RFC3118-RK. For the HMAC-MD5 algorithm the key is derived by taking the first 16 bytes of the RFC3118-RK. The secret ID used in RFC 3118 authentication is the first 32-bits of the key name for the RFC3118-RK. 4. Distributing derived keys The RFC3118-RK is mutually derived by the EAP peer and EAP server. In order for it to be useful the key must be delivered to where it will be used on the DHCP Server. This document considers two cases. In the first case the DHCP server is co-located with the EAP authenticator. This is for network devices that act as a DHCP server. In the second case the DHCP relay is co-located with the EAP authenticator. 4.1. DHCP Server Co-located with EAP Authenticator When the DHCP server is co-located with the EAP Authenticator the RFC3118-RK must be delivered to the EAP Authenticator from the EAP Server. If the EAP Server and EAP Authenticator are co-located this is simply done through a local API. If these two entities are not co-located then a AAA protocol is often used to carry key material. In this case the key is delivered in a keying-material attribute such as the one defined in [I-D.zorn-radius-keywrap]. A new AP ID is defined as RFC3118-RK (TBD). The KM-ID field contains the key ID for the RFC3118-RK. 4.2. DHCP Relay Co-located with EAP Authenticator When the DHCP Relay is co-located with the EAP Authenticator the RFC3118-RK must be delivered to DHCP Sever by way of the authenticator. To do this EAP Authenticator receives a wrapped key from the EAP Server. If these two entities are not co-located then Salowey & Pruss Expires January 7, 2009 [Page 4] Internet-Draft EAP keying of DHCP Authentication July 2008 the a AAA protocol is often used to carry key material as noted above. The key then must be delivered to the DHCP server. A new sub-option of the DHCP Relay Option (Option 82) can be created for this purpose, such as the one defined in [I-D.yegin-eap-boot-rfc3118]. 5. IANA Considerations This section will need to allocate the key labels for the key derivation. It will also need to allocate a new APP ID for RFC3118-RK. A option number for the EAP-keyed delayed authentication option also needs to be allocated. 6. Security Considerations This section needs to be expanded. Some topics include protection of the key from the DHCP relay to the DHCP server. Suitable policies for the case where key material is not available on client and server. Signaling capabilities in lower layers. 7. Acknowledgements [I-D.yegin-eap-boot-rfc3118] describes a similar mechanism. Mark Stapp has also presented on EAP and DHCP interaction in the ICOS BOF at IETF 62. 8. References 8.1. Normative References [I-D.ietf-eap-keying] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-22 (work in progress), November 2007. [I-D.ietf-hokey-emsk-hierarchy] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-07 (work in progress), June 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Salowey & Pruss Expires January 7, 2009 [Page 5] Internet-Draft EAP keying of DHCP Authentication July 2008 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 8.2. Informative References [8021X] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control", December 2004. [I-D.pruss-dhcp-auth-dsl] Pruss, R., Zorn, G., Maglione, R., and L. Yizhou, "Authentication Extensions for the Dynamic Host Configuration Protocol", draft-pruss-dhcp-auth-dsl-03 (work in progress), May 2008. [I-D.yegin-eap-boot-rfc3118] Yegin, A., "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication", draft-yegin-eap-boot-rfc3118-02 (work in progress), March 2006. [I-D.zorn-radius-keywrap] Zorn, G., "RADIUS Attributes for the Delivery of Keying Material", draft-zorn-radius-keywrap-13 (work in progress), April 2007. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. Authors' Addresses Joseph Salowey Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA Email: jsalowey@cisco.com Salowey & Pruss Expires January 7, 2009 [Page 6] Internet-Draft EAP keying of DHCP Authentication July 2008 Richard Pruss Cisco Systems, Inc. 80 Albert Street Brisbane, Queensland 4000 Australia Email: ric@cisco.com Salowey & Pruss Expires January 7, 2009 [Page 7] Internet-Draft EAP keying of DHCP Authentication July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Salowey & Pruss Expires January 7, 2009 [Page 8]