[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
IETF PANA Working Group
Internet Draft                                            H. Tschofenig
                                                                 Siemens
                                                    Corporate Technology
                                                                A. Yegin
                                                         DoCoMo USA Labs
                                                             D. Forsberg
                                                                   Nokia
Document:
draft-tschofenig-pana-bootstrap-rfc3118-01.txt
Expires: April 2004                                        October 2003


          Bootstrapping RFC3118 Delayed authentication using PANA
             <draft-tschofenig-pana-bootstrap-rfc3118-01.txt>


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

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 methods carried
   over PANA can be used to establish a local trust relation and
   generate keys that can be used in conjunction with RFC3118.






Tschofenig et al.        Expires - April 2004                 [Page 1]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   Table of Contents

   1.   Introduction...............................................2
   2.   Terminology................................................3
   3.   Overview and Building Blocks...............................4
      3.1  PaC to PAA Communication................................5
      3.2  PAA to DHCP Communication...............................5
      3.3  Key Derivation..........................................6
   4.   Requirements...............................................6
   5.   Security parameters for RFC 3118...........................7
      5.1  Authentication Option of RFC 3118.......................7
      5.1.1  Code Field............................................8
      5.1.2  Length Field..........................................8
      5.1.3  Protocol Field........................................8
      5.1.4  Algorithm Field.......................................8
      5.1.5  Replay Detection Method (RDM) Field...................8
      5.1.6  Replay Detection Field................................8
      5.1.7  Authentication Information Field......................9
      5.2  Lifetime of the DHCP security association...............9
   6.   Processing Details and Payloads............................9
      6.1  Capability Indication and Trigger Message...............9
      6.2  Key Derivation.........................................11
      6.3  DHCP SA Sub-option.....................................12
   7.   Example message flow......................................13
   8.   Security Considerations...................................14
   9.   IANA Considerations.......................................17
   10.  Open Issues...............................................18
   11.  References................................................18
   12.  Acknowledgments...........................................19
   13.  Author's Addresses........................................19

1. Introduction

   PANA [PANA] provides network access authentication by carrying
   Extensible Authentication Protocol (EAP) between the hosts and the
   access networks. The combination of EAP with an 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 are capable of generating
   cryptographic keys (e.g., shared secrets) between the client and the
   authentication agent after successful authentication.

   DHCP [RFC2131] is a protocol which provides an end host with
   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
Tschofenig et al.        Expires - April 2004                 [Page 2]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   clients and assumes out-of band or manual key establishment. These
   limitations have been inhibiting widespread deployment of this
   security mechanism.

   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
   security for DHCP. This document defines how to use PANA to
   bootstrap RFC 3118 for securing DHCP.

   PANA protocol allows clients to use this protocol even before they
   are assigned an IP address. A PANA client (PaC) can use the
   unspecified IP address as its source address during this phase.

   This approach provides a two-step solution:

   - Authentication and key exchange (provided by EAP methods carried
     over PANA)
   - DHCP message protection by generating the required shared secrets
     for RFC 3118.

   Instead of adding EAP support to DHCP itself (which requires
   modifications to the DHCP protocol due to the nature of EAP
   messaging) we keep the two protocols separate.

   This document is organized as follows. Section 2 describes new
   terms. Section 3 gives an overview of the basic communication and
   describes the building blocks. Requirements are presented in Section
   4. The details of the established parameters for the DHCP SA are
   listed in Section 5. Processing details and payload formats are
   illustrated in Section 6. A short message flow describes the
   protocol interaction in Section 6.3. Finally in Section 8 additional
   security considerations are discussed.

2. 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 PaC (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). Once a DHCP
   server is selected the DHCP SA is use between the DHCP client and
   the DHCP server.

   - DHCP Key


Tschofenig et al.        Expires - April 2004                 [Page 3]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   This term refers to the fresh and unique session key dynamically
   established between the DHCP client (PaC) and the DHCP server. This
   key is used to protect DHCP messages as described in [RFC3118].

   Further PANA related terms can be found in [PY+02].

   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. Overview and Building Blocks

   Based on the PANA protocol interaction this bootstrapping mechanism
   requires protocol interaction between the PaC (which acts as DHCP
   client), the PANA Authentication Agent (PAA) and the DHCP server. A
   security association will be established between the DHCP server and
   the DHCP client to protect DHCP messages.

   DHCP SA is generated based on the PANA SA after a successful PANA
   authentication. DHCP SA information needs to be transferred from the
   PAA (where it is generated) to the DHCP server (where it will be
   needed).

   PAA is located one IP hop away from the PaC. If the DHCP server is
   on the same link, it can be co-located with the PAA. When PAA and
   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, PAA
   should be co-located with the DHCP relay. The SA information can be
   communicated to the DHCP server using the DHCP relay agent
   information options [DS02]. For the purpose of confidentiality
   protection IPsec protection MUST be applied as described in [RD03].

   Two different scenarios are illustrated in Figure 1.

    +---------+                  +--------------+
    |   PaC/  |                  |   PAA /      |
    |   DHCP  |<================>|  DHCP server |
    |  client |  PANA and DHCP   |              |
    +---------+                  +--------------+


    +---------+                  +--------------+        +---------+
    |   PaC/  |                  |   PAA /      |        |  DHCP   |
    |   DHCP  |<================>|  DHCP relay  |<======>|  server |
    |  client |  PANA and DHCP   |              |  DHCP  |         |
    +---------+                  +--------------+        +---------+


   Legend:
Tschofenig et al.        Expires - April 2004                 [Page 4]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003



      PaC - PANA Client
      PAA - PANA Authentication Agent

                   Figure 1: DHCP Protocol Bootstrapping

   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.


   The following building blocks have been identified:

3.1 PaC to PAA Communication

   Additional payloads are required within PANA in order to bootstrap
   RFC3118. These payloads therefore provide the following
   functionality:

   a) Capability indication

   A capability describes a certain functionality which is either
   supported or not. In order to trigger an action or to obtain a
   certain kind of data item it is necessary to execute some message
   exchanges. This message exchange allows both entities to learn
   commonly supported functionality.

   b) Trigger message

   A trigger message allows one entity (either PaC or PAA) to request a
   certain action to be executed. For this protocol a trigger message
   sent by the PaC causes the PAA to create the DHCP security
   association for support with [RFC3118].

   Section 6 describes the message payloads for the additional objects
   required in PANA usage with this bootstrapping protocol.

3.2 PAA to DHCP Communication

   If the PAA and the DHCP server are co-located then only an API call
   is required for transferring the necessary information from the PAA
   to the DHCP server. If the PAA and the DHCP server are not co-
   located then an additional protocol is needed. [WH+02] points to the
   importance of this communication as: "Key distribution is not merely
   a data transport operation; it is also a mechanism for building
   transitive trust;". Indeed the trust relationship between the PaC
   and the PAA, which was dynamically established during network access
   authentication, is used to extend the trust relationship to the DHCP
   server. The PAA, which is co-located with the DHCP Relay, and the
   DHCP server trust each other and both entities belong to the same
   administrative domain as the PAA.
Tschofenig et al.        Expires - April 2004                 [Page 5]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003



   Security sensitive information has to be exchanged (such as session
   keys) between the DHCP relay (PAA) and the DHCP server. This
   protocol is not part of PANA but the security implications must be
   considered.

   [DS02] enables transmission of AAA-related RADIUS attributes from
   DHCP relay to 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. 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.

3.3 Key Derivation

   As a result of the EAP authentication and key exchange method a
   Master Session Key (MSK) is established which is used to establish a
   PANA security association. The key derivation procedure for
   establishing PANA SA is defined in [PANA]. Another security
   association for usage with DHCP according to [RFC3118] needs to be
   established. A discussion of the required parameters for the
   security association is given in Section 5 and the key derivation
   function is provided in Section 6.2

   Since different bootstrapping applications need different keys it is
   necessary to derive these keys from the session key provided by the
   EAP method. It would be possible to reuse work done by members of
   the EAP working group on key derviation for multiple applications
   [SE03]. The key derivation mechanism used in this document is
   similar.

4. Requirements

   The following requirements regarding protocol design and deployment
   have to be met:

   - The DHCP protocol as defined in [RFC2131] MUST NOT be modified.

   - The security mechanism defined in [RFC3118] MUST NOT be modified.

   - The key derivation procedure MUST establish a unique and fresh
   session key for the usage with [RFC3118]. The session key MUST never
   be used again in later protocol run.

   - It MUST be ensured that only the intended parties have access to
   the session key. Hence the key transport between the PAA and the
   DHCP server MUST be authenticated, integrity, replay and
   confidentiality protected. The security mechanism used to protect
Tschofenig et al.        Expires - April 2004                 [Page 6]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   the transport of the session key between the PAA and the DHCP server
   MUST have an adequate key strength. Section 5.4 of [AS+03] offers a
   description of issues concerning key wrapping.

   - The DHCP server MUST ensure that only authorized nodes are allowed
   to install keying material for subsequent DHCP message protection.

   - The established DHCP security association MUST provide data origin
   authentication, integrity protection and replay protection. A non-
   goal of this draft is to provide confidentiality protection for DHCP
   messages.

   - The lifetime of the DHCP session key is limited to the PANA
   session lifetime. The session key MUST NOT be used beyond that
   lifetime. The first DHCP message provides key confirmation of the
   established session key between the PaC and the DHCP server. The
   DHCP is active after a successful completion of the bootstrapping
   procedure (indicated by the PAA).

   - Key Naming

   Both the DHCP client and the DHCP server MUST have means to uniquely
   identify the DHCP SA.

   The derived session key (DHCP key) MUST be bound to a particular
   session between the particular PaC and an entity in the access
   network. It MUST be possible for the two peers (PaC and DHCP server)
   to verify that each other is indeed the intended recipients of the
   distributed session key. Once the established DHCP SA is selected
   for protection of DHCP messages (implicit) key confirmation is
   provided.

5. Security parameters for RFC 3118

5.1 Authentication Option of RFC 3118

   [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 (8 bits)
   - Length (8 bits)
   - Protocol (8 bits)
   - Algorithm (8 bits)
   - Replay Detection Method - RDM (8 bits)
   - Replay Detection (64 bits)
Tschofenig et al.        Expires - April 2004                 [Page 7]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   - Authentication Information (variable length)

5.1.1 Code Field

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

5.1.2 Length Field

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

5.1.3 Protocol Field

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

5.1.4 Algorithm Field

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

5.1.5 Replay Detection Method (RDM) Field

   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.

5.1.6 Replay Detection Field

   This field contains the value that is used for replay protection.
   This value MUST be monotonically increasing according to the
   provided replay detection method.
Tschofenig et al.        Expires - April 2004                 [Page 8]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003



   An initial value must, however, be set. In case of bootstrapping
   with PANA an initial value of zero is used. The length of 64 bits
   (and a start-value of zero) ensure that a sequence number roll-over
   is very unlikely to occur.

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

5.1.7 Authentication Information Field

   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 PAA to prevent collisions.

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

5.2 Lifetime of the DHCP security association

   The lifetime of the DHCP security association has to be limited to
   prevent the DHCP from storing state information over a long time.

   The lifetime of the DHCP SA should be set to the lifetime of PANA SA
   which is determined by the PANA session lifetime. The PaC (i.e. DHCP
   client), PAA, and DHCP server should be aware (directly or
   indirectly) about the lifetime.

   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.

6. Processing Details and Payloads

   This section defines the necessary extensions for PANA and a key
   derivation procedure.

6.1 Capability Indication and Trigger Message


Tschofenig et al.        Expires - April 2004                 [Page 9]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   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 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 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 PaC, it may or may
   not include the AVP in its response depending on its desire to
   create DHCP SA. 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.

      V(endor)
Tschofenig et al.        Expires - April 2004                [Page 10]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003



               - 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

      32 bit value that identifies the DHCP Key produced as a result of
      the bootstrapping process. This value is determined by PAA and
      sent to PaC. PAA determines this value by randomly picking a
      number from the available session 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
      DHCP SA expires. 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 Nonce_PaC when the AVP is sent by PaC, and
      Nonce_PAA 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.

6.2 Key Derivation

   This section describes the key derivation procedure which allows to
   establish a DHCP security association. The key derivation procedure
   is reused from IKE [RFC2409]. The character '|' denotes
   concatenation.

   DHCP Key = HMAC-MD5(MSK, const | Session ID | Nonce_PaC | Nonce_PAA)

   The values of have the following meaning:

   - MSK


Tschofenig et al.        Expires - April 2004                [Page 11]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   The Master Session Key (MSK) is provided by the EAP method as part
   of the PANA/EAP protocol execution.

   - const

   This is a string constant. The value of the const parameter is set
   to "PANA RFC3118 Bootstrapping".

   - Session ID

   This is the PANA session ID as defined in [PANA]. It is used to
   identify a unique session between the PaC and PAA.

   - Nonce_PaC

   This random number is provided by the PaC and exchanged within the
   PANA protocol.

   - Nonce_PAA

   This random number is provided by the PAA/DHCP server and exchanged
   with the PANA 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 Transient Session Keys (TSKs).

6.3 DHCP SA Sub-option

   When PAA and DHCP server are not co-located, the DHCP SA information
   is carried from the PAA (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:


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SubOpt Code  |    Length     |          Secret ID            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~     Secret ID (continued)     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                          DHCP Key                             +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tschofenig et al.        Expires - April 2004                [Page 12]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   |                               |         Lifetime              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~     Lifetime (continued)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   SubOpt Code

      TBD

   Length

      This value is set to 24.

   Secret ID

      This is the 32-bit value assigned by the PAA which is used to
      identify the DHCP key.

   DHCP Key

      128-bit DHCP key computed by PAA is carried in this field.

   Lifetime

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

7. Example message flow

   Figure 2 depicts a message flow that enables DHCP bootstrapping. The
   PANA message flow starts with a discovery of the PAA, followed by
   network access authentication. Finally, when the authentication
   succeeds a PANA security association is established. The DHCP-AVP
   payload contains parameters described in Section 6.

     PaC      PAA         Message(tseq,rseq)[AVPs]
      ------------------------------------------------------
         ----->            PANA-PAA-Discover(0,0)
         <-----            PANA-Start-Request(x,0)[Cookie]
         ----->            PANA-Start-Answer(y,x)[Cookie]
         <-----            PANA-Auth-Request(x+1,y)
                           [Session-Id, EAP{Request}]
         ----->            PANA-Auth-Answer(y+1,x+1)
                           [Session-Id, EAP{Response}]
           .
           .
         <-----            PANA-Auth-Request(x+n,y+n-1)
                           [Session-Id, EAP{Request}]
         ----->            PANA-Auth-Answer(y+n,x+n)
Tschofenig et al.        Expires - April 2004                [Page 13]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


                           [Session-Id, EAP{Response}]
         <-----            PANA-Bind-Request(x+n+1,y+n)
                           [EAP{Success}, Session-Id, Device-Id,
                            DHCP-AVP, Lifetime, MAC]
         ----->            PANA-Bind-Answer(y+n+1,x+n+1)
                           [Session-Id, Device-Id, DHCP-AVP,
                            MAC]

             Figure 2: Message flow for PANA DHCP bootstrapping

   PANA SA will be created based on the PANA authentication. Since PaC
   and PAA have exchanged DHCP-AVPs, additionally a DHCP SA will be
   generated as outlined earlier. DHCP SA parameters can be immediately
   provided to the DHCP server when PAA and DHCP server are co-located.
   When they are on separate nodes, the next DHCP request sent by the
   DHCP client (PaC) can piggyback the DHCP SA parameters to the DHCP
   server as it is relayed by the DHCP relay (PAA).

8. Security Considerations

   This document describes a mechanism for dynamically establishing a
   security association to protect DHCP signaling messages.

   PANA uses EAP to support a number of authentication methods. With
   the functionality of EAP this document therefore supports DHCP
   security for roaming users.

   This document separates the different security mechanisms in a
   modular way:

   a) The appropriate EAP method for a certain scenario, environment or
   architecture can be chosen. The security properties heavily depend
   on the chosen EAP method.

   b) PANA carries EAP messages and provides additional security. The
   security features of PANA are described in [PANA].

   c) The security mechanism in [RFC3118] is reused for providing
   authentication, integrity and replay protection for DHCP messages.

   If the PAA 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 PAA 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 3 is taken from Section 4.1
   of [AS+03] and adjusted accordingly. A major difference from [AS+03]
   is that the communication between the PAA and DHCP server takes
   place within the same administrative domain. Hence the security
Tschofenig et al.        Expires - April 2004                [Page 14]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   considerations are different to those described in [WH+03].
   Secondly, even after DHCP client and DHCP server acquire the DHCP
   key, the PAA host continues to be on the DHCP path when acting as a
   DHCP relay.


                          PaC (DHCP client)
                             /\
   Protocol: EAP over PANA  /  \
       Auth: Mutual        /    \
       Unique keys:       /      \
       - MSK             /        \
       - PANA key       /          \
       - DHCP key      /            \
                  PAA +--------------+ DHCP server

                      Protocol: DHCP or API
                      Auth: Mutual
                   Unique key: DHCP key


                       Figure 3: Keying Architecture

   Figure 3 describes the participating entities and the protocol
   executed between them. It must be ensured that the derived session
   key between the PaC and the DHCP server is fresh and unique.

   The key transport mechanism, which is used to carry the session key
   between the PAA 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 PAA) authorize the establishment of the DHCP security
   association.

   Russ Housley recently (at the 56th IETF) 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 also applicable in our context.
   We will address the presented issues briefly:

   - Algorithm independence

   Our proposal bootstraps a DHCP security association based on RFC
   3118 where only a single integrity algorithm (namely HMAC-MD5) is
   proposed which is mandatory to implement.

Tschofenig et al.        Expires - April 2004                [Page 15]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   - Establish strong, fresh session keys (maintain algorithm
   independence)

   PANA relies on EAP to provide strong and fresh session keys for each
   initial authentication and key exchange protocol run. Furthermore
   the key derivation function provided in Section 6.2 contains random
   numbers provided by the PaC and the PAA 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
   which is carried over PANA (between the PaC and the PAA) MUST
   provide a replay protection mechanism.

   Additionally random numbers and the session id is included in the
   key derivation procedure which aims to provide a fresh and unique
   session key between the PaC (DHCP client) and the DHCP server.

   Furthermore, the key transport mechanism between the PAA 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 PaC and the PAA is provided by the PANA
   protocol which utilizes EAP. Key confirmation of PANA SA is
   accomplished at the final stage of the PANA exchange.

   Key confirmation between the PaC and the DHCP server is provided
   with the first protected DHCP message exchange.

   - Perform authorization

   Authorization for network access is provided during the PANA
   exchange. The authorization procedure for DHCP bootstrapping is
   executed by the PAA before this service is offered to the PaC. The
   PAA might choose not to include DHCP-AVP in a PANA-Bind-Request
   based on its local policies.

   - Maintain confidentiality of session keys

   The DHCP session keys are only known to the intended parties (i.e.,
   to the PaC, PAA and the DHCP server).

Tschofenig et al.        Expires - April 2004                [Page 16]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   The PANA protocol 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" ciphersuite

   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 PAA and DHCP server

   A compromised PAA may leak the DHCP session key, the EAP derived
   session key (e.g., MSK) and the PANA SA. It will furthermore allow
   corruption of the DHCP protocol executed between the hosts and the
   DHCP server since PAA node either acts as a DHCP relay or DHCP
   server.

   A compromised PAA may also allow creation of further DHCP SAs or
   other known attacks on the DHCP protocol (e.g., address depletion).

   A compromised PAA will not be able to modify, replay, inject DHCP
   messages which use security associations established without the
   PANA bootstrapping protocol (e.g., manually configured DHCP SAs).

   On the other hand, a compromised DHCP server may only leak the DHCP
   key information. MSK and PANA SA will not be compromised in this
   case.

   - Bind key to appropriate context

   The key derivation function described in Section 6.2 includes
   parameters (such as the PANA session ID and a constant) which
   prevents reuse of the established session key for other purposes.
   The key derivation includes the session identifier to associate the
   key to the context of a certain PANA protocol session and therefore
   to a particular client.

9. IANA Considerations

   TBD

Tschofenig et al.        Expires - April 2004                [Page 17]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


10. Open Issues

   This document describes a bootstrapping procedure for [RFC3118]. The
   same procedure could be applied for [DHCPv6].

   Some text is required to describe the details of the DHCP multi-
   server model. When multiple DHCP servers send DHCPOFFER in response
   to the DHCPDISCOVER where each server has a distinct server id and
   the client chooses a single server among multiple DHCPOFFER
   messages. For the client there is no difference between any of the
   DHCP server.

11. 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)
   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.

Tschofenig et al.        Expires - April 2004                [Page 18]


Internet Draft     Bootstrapping RFC3118 using PANA       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.

12. Acknowledgments

   We would like to thank Yoshihiro Ohba for his comments to this
   draft.

13. Author's Addresses

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   EMail: Hannes.Tschofenig@siemens.com

   Alper E. Yegin
   DoCoMo USA Labs
   181 Metro Drive, Suite 300
   San Jose, CA, 95110
   USA
   Phone: +1 408 451 4743
   Email: alper@docomolabs-usa.com

   Dan Forsberg
   Nokia Research Center
   P.O. Box 407
   FIN-00045 NOKIA GROUP, Finland
   Phone: +358 50 4839470
   EMail: dan.forsberg@nokia.com

Tschofenig et al.        Expires - April 2004                [Page 19]


Internet Draft     Bootstrapping RFC3118 using PANA       October 2003


   Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

























Tschofenig et al.        Expires - April 2004                [Page 20]