[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/