[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Dynamic Host Configuration                                 H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                                A. Yegin
Expires: January 15, 2009                                        Samsung
                                                             D. Forsberg
                                                                   Nokia
                                                           July 14, 2008


   Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based
                     Network Access Authentication
                  draft-yegin-eap-boot-rfc3118-03.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 15, 2009.














Tschofenig, et al.      Expires January 15, 2009                [Page 1]


Internet-Draft           Bootstrapping RFC 3118                July 2008


Abstract

   The DHCP authentication extension (RFC 3118) cannot be widely
   deployed due to lack of a key agreement protocol.  This document
   outlines how EAP-based network access authentication mechanisms can
   be used to establish bootstrap keying material that can be used to
   subsequently use RFC 3118 security.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview and Building Blocks . . . . . . . . . . . . . . . . .  6
   4.  Buliding DHCP SA . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  802.1X . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  PPP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  PANA . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Computing DHCP SA  . . . . . . . . . . . . . . . . . . . . 11
   5.  Delivering DHCP SA . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Using DHCP SA  . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10. Acknowledegments . . . . . . . . . . . . . . . . . . . . . . . 24
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     11.2. Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 28





















Tschofenig, et al.      Expires January 15, 2009                [Page 2]


Internet-Draft           Bootstrapping RFC 3118                July 2008


1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC3748] 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.  Almost all EAP
   methods (e.g., EAP-TLS, EAP-SIM) are capable of generating
   cryptographic keys between the EAP peer and the EAP server.  Using
   key transport via the AAA infrastructure the EAP server makes the
   EAP-provided keying material available to the Authenticator (e.g.,
   Network Access Server; NAS) after a successful authentication
   attempt.  These keys are commonly used in conjunction with per-packet
   security mechanisms (e.g., link-layer ciphering).  This procedure is
   described in [I-D.ietf-eap-keying].

   DHCP [RFC2131] is a protocol which provides a host with configuration
   parameters.  The base DHCP does not include any security mechanism,
   hence it is vulnerable to a number of security threats.  The security
   considerations section of RFC 2131 [RFC2131] identifies it as "quite
   insecure" and lists various security threats.

   RFC 3118 [RFC3118] is the DHCP authentication protocol that 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 as noted in a DHCPv4 threat analysis
   [I-D.ietf-dhc-v4-threat-analysis].

   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 access authentication procedure
   can be utilized to dynamically provide the keying material to RFC
   3118 based security protection for DHCP.  This document defines how
   to use the EAP-based access authentication procedure to bootstrap RFC
   3118 security.

   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 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



Tschofenig, et al.      Expires January 15, 2009                [Page 3]


Internet-Draft           Bootstrapping RFC 3118                July 2008


       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 RFC 3118 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
   [RFC1661], IEEE 802.1X , PANA [RFC5191]) 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.  RFC 3118 can be used without any
   modifications or extensions.
































Tschofenig, et al.      Expires January 15, 2009                [Page 4]


Internet-Draft           Bootstrapping RFC 3118                July 2008


2.  Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT",
   OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be
   interpreted as described in [RFC2119].

   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.

   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].

























Tschofenig, et al.      Expires January 15, 2009                [Page 5]


Internet-Draft           Bootstrapping RFC 3118                July 2008


3.  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 method derived key after a
   successful EAP method protocol run.  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

   [RFC4014] 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.
   [I-D.ietf-dhc-relay-agent-ipsec] 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.

   Two different deployment scenarios are illustrated in Figure 1.










Tschofenig, et al.      Expires January 15, 2009                [Page 6]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   +---------+              +------------------+
   |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 RFC 3118 to protect DHCP messages
   against various security threats.  This draft provides the guidelines
   regarding how the RFC 3118 protocol fields should be filled in based
   on the DHCP SA.





























Tschofenig, et al.      Expires January 15, 2009                [Page 7]


Internet-Draft           Bootstrapping RFC 3118                July 2008


4.  Buliding 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

   This work needs to be done in the IEEE and hence this section is
   intentionally left blank.

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.

   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                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: DHCP SA Configuration Option

   Type

   o  TBD

   Length

   o  >=24

   Reserved

   o  A 16-bit value reserved for future use.  It MUST be initialized to
      zero by the sender, and ignored by the receiver.




Tschofenig, et al.      Expires January 15, 2009                [Page 8]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   Secret ID

   o  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)

   o  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.

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:















Tschofenig, et al.      Expires January 15, 2009                [Page 9]


Internet-Draft           Bootstrapping RFC 3118                July 2008


          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                         ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 3: DHCP AVP Format

   AVP Code

   o  TBD

   AVP Flags

   o  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|
        +-+-+-+-+-+-+-+-+

                           Figure 4: DHCP AVP Flags

   M(andatory)

   o  The 'M' Bit, known as the Mandatory bit, indicates whether support
      of the AVP is required.  This bit is not set in DHCP-AVP.

   V(endor)

   o  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)

   o  These flag bits are reserved for future use, and MUST be set to
      zero, and ignored by the receiver.




Tschofenig, et al.      Expires January 15, 2009               [Page 10]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   AVP Length

   o  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

   o  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)

   o  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-SHA1(MSK, const | Secret ID | Nonce_client |
   Nonce_NAS)

   The values have the following meaning:

   MSK:

      A key derived by the EAP peer and EAP (authentication) server 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 RFC 3118 Bootstrapping".






Tschofenig, et al.      Expires January 15, 2009               [Page 11]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   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 equal 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

















Tschofenig, et al.      Expires January 15, 2009               [Page 12]


Internet-Draft           Bootstrapping RFC 3118                July 2008


5.  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                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5: DHCP SA Suboption

   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.






Tschofenig, et al.      Expires January 15, 2009               [Page 13]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   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.


   Lifetime:

      The lifetime of the DHCP SA.  This Unsigned32 value contains the
      number of seconds remaining before the DHCP SA is considered
      expired.



































Tschofenig, et al.      Expires January 15, 2009               [Page 14]


Internet-Draft           Bootstrapping RFC 3118                July 2008


6.  Using DHCP SA

   Once the DHCP SA is in place, it is used along with RFC 3118 to
   secure the DHCP protocol exchange.

   RFC 3118 [RFC3118] defines two security protocols with a newly
   defined authentication option:

   o  Configuration token

   o  Delayed authentication

   The generic format of the authentication option is defined in Section
   2 of RFC 3118 [RFC3118] and contains the following fields:

   o  Code

   o  Delayed authentication

   The value for the Code field of this authentication option is 90.

   o  Length

   The Length field indicates the length of the authentication option
   payload.

   o  Protocol

   RFC 3118 [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 RFC 3118 [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.

   o  Algorithm

   RFC 3118 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the
   Algorithm field).  This document assumes that HMAC-MD5 is used to



Tschofenig, et al.      Expires January 15, 2009               [Page 15]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   protect DHCP messages.

   Since the value for this field is known in advance it does not need
   to be negotiated.  [Editor's Note: Based on crypto agility
   requirements it seems reasonable to consider future algorithm support
   as well.]

   o  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.

   o  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.

   o  Authentication Information

   The content of this field depends on the type of message where the
   authentication option is used.  Section 5.2 of RFC 3118 [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.

   Since the value for this field is known in advance it does not need
   to be negotiated.

   For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the
   Authentication Information field is given as:

   o  Secret ID (32 bits)

   o  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.]



Tschofenig, et al.      Expires January 15, 2009               [Page 16]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   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
   RFC 3118 [RFC3118].
















































Tschofenig, et al.      Expires January 15, 2009               [Page 17]


Internet-Draft           Bootstrapping RFC 3118                July 2008


7.  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 [I-D.ietf-eap-keying]).  The DHCP key is a
   Transient Session Key (TEK) from [I-D.ietf-eap-keying].  The key is
   generated by both the DHCP client and the DHCP relay, and transported
   from the DHCP relay to the DHCP server.  The DHCP protocol exchange
   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:MSK, /              \       / Auth: Mutual;
    EMSK           /                \     / Unique key: DHCP key
                  /                  \   /
                 /                    \ /
   Auth. server +----------------------+  Authenticator
                      Protocol: AAA;     (NAS, DHCP relay)
                      Auth: Mutual;
                      Unique key:
                       AAA session key


                       Figure 6: Keying Architecture

   Figure 6 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 DHCP server is fresh and unique.

   The key transport mechanism, which is used to carry the session key
   between the NAS and DHCP server, must provide the following
   functionality:





Tschofenig, et al.      Expires January 15, 2009               [Page 18]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   o  Confidentiality protection

   o  Replay protection

   o  Integrity protection

   Furthermore, it is necessary that the two parties (DHCP server and
   the NAS) authorize the establishment of the DHCP security
   association.

   Below we provide a list of security properties of the suggested
   mechanism:

   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.

   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 MSK
      confirmation either based on the 4-way handshake in IEEE 802.11i



Tschofenig, et al.      Expires January 15, 2009               [Page 19]


Internet-Draft           Bootstrapping RFC 3118                July 2008


      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, 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 [RFC4014] 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., MSK).  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).  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.  MSK will not be
      compromised in this case.



Tschofenig, et al.      Expires January 15, 2009               [Page 20]


Internet-Draft           Bootstrapping RFC 3118                July 2008


   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.














































Tschofenig, et al.      Expires January 15, 2009               [Page 21]


Internet-Draft           Bootstrapping RFC 3118                July 2008


8.  IANA Considerations

   [Editor's Note: A future version of this draft will provide IANA
   considerations.]















































Tschofenig, et al.      Expires January 15, 2009               [Page 22]


Internet-Draft           Bootstrapping RFC 3118                July 2008


9.  Open Issues

   This document describes a bootstrapping procedure for DHCPv4.  The
   same procedure could be applied for DHCPv6 but is not described in
   this document.














































Tschofenig, et al.      Expires January 15, 2009               [Page 23]


Internet-Draft           Bootstrapping RFC 3118                July 2008


10.  Acknowledegments

   We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for
   their feedback to this document.  Additionally, we would to thank
   Ralph Droms, Allison Mankin and Barr Hibbs for their support to
   continue this work.













































Tschofenig, et al.      Expires January 15, 2009               [Page 24]


Internet-Draft           Bootstrapping RFC 3118                July 2008


11.  References

11.1.  Normative References

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, 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.

   [RFC4014]  Droms, R. and J. Schnizlein, "Remote Authentication
              Dial-In User Service (RADIUS) Attributes Suboption for the
              Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Information Option", RFC 4014, February 2005.

11.2.  Informative References

   [I-D.ietf-dhc-relay-agent-ipsec]
              Droms, R., "Authentication of DHCP Relay Agent Options
              Using IPsec", draft-ietf-dhc-relay-agent-ipsec-02 (work in
              progress), May 2005.

   [I-D.ietf-dhc-v4-threat-analysis]
              Hibbs, R., "Dynamic Host Configuration Protocol for IPv4
              (DHCPv4) Threat Analysis",
              draft-ietf-dhc-v4-threat-analysis-03 (work in progress),
              June 2006.

   [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.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.



Tschofenig, et al.      Expires January 15, 2009               [Page 25]


Internet-Draft           Bootstrapping RFC 3118                July 2008


              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

















































Tschofenig, et al.      Expires January 15, 2009               [Page 26]


Internet-Draft           Bootstrapping RFC 3118                July 2008


Authors' Addresses

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at


   Alper E. Yegin
   Samsung
   Istanbul,
   Turkey

   Phone:
   Email: a.yegin@partner.samsung.com


   Dan Forsberg
   Nokia Research Center
   P.O. Box 407
   FIN-00045
   Finland

   Phone: +358 50 4839470
   Email: dan.forsberg@nokia.com





















Tschofenig, et al.      Expires January 15, 2009               [Page 27]


Internet-Draft           Bootstrapping RFC 3118                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.











Tschofenig, et al.      Expires January 15, 2009               [Page 28]


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