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]