[Search] [txt|pdfized|bibtex] [Tracker] [Email] [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-00.txt
   Expires: December 2003                                     June 2003


          Bootstrapping RFC3118 Delayed authentication using PANA
             <draft-tschofenig-pana-bootstrap-rfc3118-00.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

   PANA provides network access authentication and uses the Extensible
   Authentication Protocol (EAP) to carry different authentication
   methods. The combination of EAP with an AAA architecture allows
   authentication and authorization of a roaming user to an access
   network.





Tschofenig et al.         Expires - December 2003             [Page 1]


   DHCP is a protocol which provides an end host with configuration
   parameters. Without proper security for DHCP an adversary can mount
   a number of attacks.

   It seems to be reasonable to use the authentication and key exchange
   procedure executed during the network access authentication to
   bootstrap a security association for DHCP.


   Table of Contents

   1.   Introduction...............................................2
   2.   Terminology................................................4
   3.   Overview and Building Blocks...............................4
      3.1  PaC <-> PAA Communication...............................5
      3.2  PAA <-> 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...................9
      5.1.6  Replay Detection Field................................9
      5.1.7  Authentication Information Field......................9
      5.2  Lifetime of the DHCP security association..............10
   6.   Processing Details and Payloads...........................10
      6.1  Capability Indication and Trigger Message..............10
      6.2  Key Derivation.........................................12
   7.   Example message flow......................................13
   8.   Security Considerations...................................13
   9.   IANA Considerations.......................................17
   10.  Open Issues...............................................17
   11.  References................................................17
   12.  Acknowledgments...........................................18
   13.  Author's Addresses........................................18

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



Tschofenig et al.         Expires - December 2003             [Page 2]


                   Bootstrapping RFC3118 using PANA          June 2003


   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 mechanisms, 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. This protocol extension does not
   support roaming clients and assumes the availability of an out-of
   band shared secret between the client and the DHCP server. These
   limitations have been inhibiting widespread deployment of this
   security mechanism.

   It seems to be reasonable 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.

   PANA thereby offers a split between the two protocols:

   - Authentication and key exchange
     (provided by PANA and EAP in particular)
   - 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 separate the two protocols. We call this procedure
   bootstrapping RFC 3118.

   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 7. Finally in Section 8 additional
   security considerations are discussed.




Tschofenig et al.         Expires - December 2003             [Page 3]


                   Bootstrapping RFC3118 using PANA          June 2003


2. Terminology

   This document uses the following term:

   - 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
   as DHCP security association (or in short DHCP SA).

   - DHCP Key

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

   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 inter-process communication. 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 will be co-
   located with the DHCP relay. The required parameters can be
   communicated to the DHCP server using the DHCP relay agent
   information options [DS02]. For the purpose of confidentiality
   protection IPsec protection can be applied as described in [SL+03].

   The protocol interaction is illustrated in Figure 1.

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


Tschofenig et al.         Expires - December 2003             [Page 4]


                   Bootstrapping RFC3118 using PANA          June 2003




     Legend:

      PaC - PANA Client
      PAA - PANA Authentication Agent

                   Figure 1: DHCP Protocol Bootstrapping

   The following building blocks have been identified:

3.1 PaC <-> PAA Communication

   Additional payloads are required within PANA as indicated with (A)
   in Figure 1. 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 the usage with this bootstrapping protocol.

3.2 PAA <-> 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 software modules of the DHCP server. If the PAA and the DHCP
   server are not co-located then an additional protocol is needed to
   transport the security parameters from the PAA to the DHCP server.
   [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


Tschofenig et al.         Expires - December 2003             [Page 5]


                   Bootstrapping RFC3118 using PANA          June 2003


   and both entities belong to the same administrative domain as the
   PAA.

   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.

   Two different protocols have been suggest in the past to support key
   transport: Radius and Diameter

   In order to secure the key transport key wrap mechanisms for
   Diameter and for Radius have been specified (see [CFB02] and
   [RFC2548]). The protection mechanism for key transport for Diameter
   applies application level security mechanisms based on CMS whereas
   Radius uses lower-layer security mechanisms such as IPsec.

   In this context another approach might be possible: [DS02] allows a
   DHCP relay to add information which is then sent to the DHCP server.
   [SL+03] proposes IPsec protection of the DHCP messages exchanged
   between the DHCP relay and the DHCP server. DHCP objects itself
   (protected with IPsec) can therefore be used to communicate the
   necessary parameters.

   Further work is required to
   (a) select one protocol which provides adequate security for the key
   transport
   (b) specify object payloads to carry the parameters between the PAA
   and the DHCP server.

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

4. Requirements





Tschofenig et al.         Expires - December 2003             [Page 6]


                   Bootstrapping RFC3118 using PANA          June 2003


   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.
   Instead it will be used as a basis for bootstrapping the security
   with the help of PANA.

   - 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 another protocol run or with another DHCP server.

   - 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
   the transport of the session key between the PAA and the DHCP server
   MUST have an adequate key strength. Section 5.4 of [AS03] 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 session key between the PaC and the DHCP server becomes active
   immediately when the PAA returns a PANA message indicating the
   successful completion of the bootstrapping procedure. The lifetime
   of the session key at the DHCP is limited to the indicated lifetime.
   The session key MUST NOT be used beyond that lifetime. Key
   confirmation of the established session key between the PaC and the
   DHCP server is provided by exchanging the first DHCP messages.

   - Key Naming

   The derived session key (DHCP key) MUST be bound to a particular
   session between the particular PaC and a DHCP server. 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.

5. Security parameters for RFC 3118

5.1 Authentication Option of RFC 3118



Tschofenig et al.         Expires - December 2003             [Page 7]


                   Bootstrapping RFC3118 using PANA          June 2003


   [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)
   - Authentication Information (variable length)

5.1.1 Code Field

   The value for the Code field of this authentication option is fixed.
   Since the value for this field is known in advance it does not need
   to be communicated.

5.1.2 Length Field

   The Length field indicates the length of the authentication option
   payload. Since the value for this field can be computed it does not
   need to be communicated.

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 the usage is
   inappropriate. 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 communicated.

5.1.4 Algorithm Field



Tschofenig et al.         Expires - December 2003             [Page 8]


                   Bootstrapping RFC3118 using PANA          June 2003


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

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

5.1.6 Replay Detection Field

   This field contains the value which is used for replay protection
   and it MUST be monotonically increasing according to the provided
   replay detection method.

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

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



Tschofenig et al.         Expires - December 2003             [Page 9]


                   Bootstrapping RFC3118 using PANA          June 2003


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 SHOULD be set to exceed the DHCP lease time. Since
   access control implemented with the help of packet filters or
   cryptographic data protection has to be associated somehow with the
   accounting system it is a policy decision for the network to specify
   a particular lifetime.

   The DHCP server, the PAA, the Enforcement Point (EP) and the AAA
   server should be aware (directly or indirectly) of the lifetime.

   The PaC can at any time trigger a new bootstrapping protocol run to
   establish a new security association with the DHCP server.

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


   A new PANA AVP is defined in order to bootstrap DHCP SA between the
   PaC and PAA. DHCP-AVP is included in the PANA_success 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_success_ack message.

   Absence of this AVP in the PANA_success 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
   if it receives this 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                          |


Tschofenig et al.         Expires - December 2003            [Page 10]


                   Bootstrapping RFC3118 using PANA          June 2003


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

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


Tschofenig et al.         Expires - December 2003            [Page 11]


                   Bootstrapping RFC3118 using PANA          June 2003


      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_DHCP 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_DHCP
   | DHCP-Server-Identity)

   The values of have the following meaning:

   - MSK

   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 DHCP Bootstrapping".

   - Session ID

   This value is a 128-bit value as defined in the PANA protocol
   [PANA]. This value identifiers a particular session of a client.

   - Nonce_PaC

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

   - Nonce_DHCP



Tschofenig et al.         Expires - December 2003            [Page 12]


                   Bootstrapping RFC3118 using PANA          June 2003


   This random number is provided by the PAA/DHCP server and exchanged
   with the PANA protocol.

   - DHCP-Server-Identity

   The DHCP-Server-Identity field contains the IP address of the DHCP
   to which the session keys will be sent.

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

7. Example message flow

   This section describes some basic PANA message flows which use DHCP
   bootstrapping.

   Figure 2 depicts a message flow which enables DHCP bootstrapping.
   The PANA message flow starts with a discovery of the PAA, followed
   by network access authentication. Finally, after the authentication
   is successful a PANA security association is established which
   protects subsequent messages such as the DHCP-AVP. The DHCP-AVP
   payload contains parameters described in Section 6. As a summary, it
   indicates that the network supports bootstrapping and provides the
   necessary parameter if requested by the PaC.

      PaC      PAA         Message(tseq,rseq)[AVPs]
      ------------------------------------------------------
         ----->            PANA_discover(0,0)
         <-----            PANA_start(x,0)[Cookie]
         ----->            PANA_start(y,x)[Cookie]
         <-----            PANA_auth(x+1,y)[EAP{Request}]
         ----->            PANA_auth(y+1,x+1)[EAP{Response}]
           .
           .
         <-----            PANA_auth(x+n,y+n-1)[EAP{Request}]
         ----->            PANA_auth(y+n,x+n)[EAP{Response}]
         <-----            PANA_success(x+n+1,y+n)  // F-flag set
                           [EAP{Success}, DHCP-AVP, MAC]
         ----->            PANA_success_ack(y+n+1,x+n+1)
                           [Device-Id, DHCP-AVP, MAC]  // F-flag set

             Figure 2: Message flow for PANA DHCP bootstrapping

8. Security Considerations




Tschofenig et al.         Expires - December 2003            [Page 13]


                   Bootstrapping RFC3118 using PANA          June 2003


   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 and key exchange
   protocols. With the functionality of EAP this document therefore
   supports DHCP security for roaming users.

   This document separates the different security mechanisms in a clean
   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.

   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 [AS03]). Figure 3 is taken from Section 4.5 of
   [AS03] and adjusted accordingly. A major different to [AS03] is that
   the communication between the PAA and DHCP server takes place
   between the same administrative domain. Hence the security issues
   described in [WH+03] are much less problematic.

                          PaC (DHCP client)
                             /\
       Protocol: PANA(EAP)  /  \
       Auth: Mutual        /    \  Protocol: Key derivation for DHCP SA
       Unique keys:       /      \  Auth: Mutual
       - EAP derived Keys/        \ Unique key: DHCP Key
       - PANA SA        /          \
                       /            \
                 PAA  +--------------+ DHCP server

                      Protocol: DHCP, AAA or API
                      Auth: Mutual
                   Unique key: protocol dependent

                       Figure 3: Keying Architecture



Tschofenig et al.         Expires - December 2003            [Page 14]


                   Bootstrapping RFC3118 using PANA          June 2003


   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.

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

   - Include replay detection mechanism

   Replay protection is provided by the PANA protocol itself and by
   including random numbers for 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).

   - Authenticate all parties


Tschofenig et al.         Expires - December 2003            [Page 15]


                   Bootstrapping RFC3118 using PANA          June 2003



   Authentication between the PaC and the PAA is provided by the PANA
   protocol which utilizes EAP. After establishing a PANA security
   association key confirmation of this PANA SA is provided.

   Key confirmation between the PaC and the DHCP server is provided
   with the first protected DHCP messages exchanged.

   - Perform authorization

   Authorization for network access is provided during the PANA
   exchange. The authorization procedure for DHCP bootstrapping is
   executed by the PAA after the PaC requests bootstrapping.

   The PAA might reject a request for bootstrapping based on local
   policies.

   - Maintain confidentiality of session keys

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

   The PANA protocol does not transport keys at all. The exchanged
   random numbers which are incorporated into the key derivation
   function do not need to be kept confidential.

   The key transport between the PAA and the DHCP server (in case that
   these two entities are not co-located) must ensure confidentiality
   of the session keys.

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

   - Uniquely name session keys

   The session key is uniquely named by including identifiers of the
   intended parties (DHCP server and PaC) into the key derivation
   function. Furthermore a constant "PANA DHCP Bootstrapping" is
   included which prevents usage of this session key for a different
   bootstrapping application.

   - Compromised PAA

   A compromised PAA will be able to learn the DHCP session key and the
   EAP derived session key (e.g. MSK) and the PANA SA. It will


Tschofenig et al.         Expires - December 2003            [Page 16]


                   Bootstrapping RFC3118 using PANA          June 2003


   furthermore be able to corrupt the DHCP protocol executed between
   mobile end hosts and the DHCP server since
   - the PAA either itself acts as a DHCP server or
   - the PAA acts as a DHCP relay.

   A compromised PAA will also be able to create further DHCP SAs or to
   perform other known attacks on the DHCP protocol (e.g. address
   depletion).

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

   - Bind key to appropriate context

   The key derivation function described in Section 6.2 includes
   parameters (such as the DHCP server identity 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

10. Open Issues

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

   It is necessary to describe the details of the capability
   negotiation within PANA and to define the DHCP object structure
   which allows communication of the necessary parameters between the
   PAA and 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.


Tschofenig et al.         Expires - December 2003            [Page 17]


                   Bootstrapping RFC3118 using PANA          June 2003



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

   [AS03]   Aboba, B. and Simon, D.: "EAP Keying Framework", Internet-
   Draft, (work in progress), March 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.

12. Acknowledgments

   Place your name here.

13. Author's Addresses



Tschofenig et al.         Expires - December 2003            [Page 18]


                   Bootstrapping RFC3118 using PANA          June 2003


   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

   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 - December 2003            [Page 19]