<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3748 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml' >
<!ENTITY RFC2131 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml' >
<!ENTITY RFC1661 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1661.xml' >
<!ENTITY RFC4014 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4014.xml' >
<!ENTITY RFC2119 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' >
<!ENTITY RFC2409 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml' >
<!ENTITY RFC3118 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml' >
<!ENTITY RFC2131 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml' >
<!ENTITY I-D.ietf-dhc-v4-threat-analysis PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-v4-threat-analysis.xml' >
<!ENTITY RFC5191
 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml' >
<!ENTITY I-D.ietf-eap-keying
 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-eap-keying.xml' >
<!ENTITY I-D.ietf-dhc-relay-agent-ipsec
 PUBLIC ''  'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-relay-agent-ipsec.xml' >
]> 

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc category="std" docName="draft-yegin-eap-boot-rfc3118-03.txt" ipr="full3978">
    <front>
        <title abbrev="Bootstrapping RFC 3118">Bootstrapping RFC3118 Delayed DHCP Authentication
            Using EAP-based Network Access Authentication</title>

        <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
            <organization>Nokia Siemens Networks</organization>
            <address>
                <postal>
                    <street>Linnoitustie 6</street>
                    <city>Espoo</city>
                    <code>02600</code>
                    <country>Finland</country>
                </postal>
                <phone>+358 (50) 4871445</phone>
                <email>Hannes.Tschofenig@gmx.net</email>
                <uri>http://www.tschofenig.priv.at</uri>
            </address>
        </author>
        
        <author initials="A." surname="Yegin" fullname="Alper E. Yegin">
            <organization abbrev="Samsung">Samsung</organization>
            <address>
                <postal>
                    <street/>
                    <city>Istanbul</city>
                    <region/>
                    <code/>
                    <country>Turkey</country>
                </postal>
                <phone/>
                <email>a.yegin@partner.samsung.com</email>
            </address>
        </author>
        <author fullname="Dan Forsberg" initials="D." surname="Forsberg">
            <organization abbrev="Nokia">Nokia Research Center</organization>
            <address>
                <postal>
                    <street>P.O. Box 407</street>
                    <code>FIN-00045</code>
                    <country>Finland</country>
                </postal>
                <phone>+358 50 4839470</phone>
                <email>dan.forsberg@nokia.com</email>
            </address>
        </author>
        <date  year="2008"/>
        <area>Internet Area</area>
        <workgroup>Dynamic Host Configuration</workgroup>
        <keyword>bootstrapping rfc3118 security</keyword>
        <keyword>DHCP Authentication using EAP</keyword>
        <abstract>
            <t>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. </t>
        </abstract>
    </front>
    <middle>
        <section anchor="introduction" title="Introduction">
            <t>The Extensible Authentication Protocol (EAP) <xref target="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 <xref target="I-D.ietf-eap-keying"/>.</t>
            <t>DHCP <xref target="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 <xref target="RFC2131"/> identifies it as "quite insecure" and lists
                various security threats.</t>
            <t>RFC 3118 <xref target="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 <xref target="I-D.ietf-dhc-v4-threat-analysis"/>. </t>
            <t>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. </t>
            <t>The general framework of the mechanism described in this I-D can be outlined as
                follows: <list style="numbers">
                    <t> 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 carries EAP.</t>
                    <t>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.</t>
                    <t>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.</t>
                </list>
            </t>
            <t>This framework requires extensions to the EAP lower-layers (PPP <xref
                target="RFC1661"/>, IEEE 802.1X , PANA <xref target="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. </t>
        </section>
        <!-- introduction -->
        <section anchor="terminology" title="Terminology">
            <t>In this document, the key words "MAY", "MUST, "MUST NOT", OPTIONAL","RECOMMENDED
                "SHOULD", and "SHOULD NOT", are to be interpreted as described in <xref target="RFC2119"/>.</t>
            <t>This document uses the following terms:</t>
            <t>
                <list style="hanging">
                    <t hangText="DHCP Security Association:">
                        <vspace blankLines="1"/>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).<vspace
                        blankLines="1"/> 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. </t>
                    <t hangText="DHCP Key:">
                        <vspace blankLines="1"/> 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 <xref
                        target="RFC3118"/>. </t>
                </list>
            </t>
        </section>
        <!-- terminology -->
        <section anchor="Overview" title="Overview and Building Blocks ">
            <t> 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. </t>
            <t>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. </t>
            <t>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. </t>
            <t>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</t>
            <t>
                <xref target="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.
                    <xref target="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. </t>
            <t> Two different deployment scenarios are illustrated in <xref target="protocols"/>. </t>
            <figure anchor="protocols" title="Protocols and end points. ">
                <artwork><![CDATA[
+---------+              +------------------+ 
|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                        
                                                       ]]></artwork>
            </figure>
            <t>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. </t>
        </section>
        <!-- sysdesc -->
        <section anchor="building" title="Buliding DHCP SA">
            <t>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.</t>
            <section anchor="e802" title="802.1X">
                <t>This work needs to be done in the IEEE and hence this section is intentionally left blank.</t>
            </section>
            <section anchor="ppp" title="PPP">
                <t> 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.</t>
                <t> The detailed DHCP-SA Configuration Option is presented below.</t>
                <figure anchor="dhcp" title="DHCP SA Configuration Option">
                    <artwork><![CDATA[
    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                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                </figure>
                <t> Type <list style="symbols">
                        <t> TBD </t>
                    </list>
                </t>
                <t>Length <list style="symbols">
                        <t> &gt;=24 </t>
                    </list>
                </t>
                <t>Reserved <list style="symbols">
                        <t> A 16-bit value reserved for future use. It MUST be initialized to zero
                            by the sender, and ignored by the receiver. </t>
                    </list>
                </t>
                <t>Secret ID <list style="symbols">
                        <t> 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. </t>
                    </list>
                </t>
                <t> Nonce Data (variable length) <list style="symbols">
                        <t> 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. </t>
                    </list>
                </t>
            </section>
            <section anchor="pana" title="PANA">
                <t>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. </t>
                <t> 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. </t>
                <t> The detailed DHCP-AVP format is presented below:</t>
                <figure anchor="dhcp-avp" title="DHCP AVP Format">
                    <artwork><![CDATA[
       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                         ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                                       ]]></artwork>
                </figure>
                <t> AVP Code <list style="symbols">
                        <t> TBD </t>
                    </list>
                </t>
                <t>AVP Flags <list style="symbols">
                        <t> The AVP Flags field is eight bits. The following bits are assigned:
                                <figure anchor="dhcp-avp-flag" title="DHCP AVP Flags">
                                <artwork><![CDATA[
     0 1 2 3 4 5 6 7 
     +-+-+-+-+-+-+-+-+ 
     |V M r r r r r r| 
     +-+-+-+-+-+-+-+-+ 
                                                       ]]></artwork>
                            </figure>
                        </t>
                    </list>
                </t>
                <t>M(andatory) <list style="symbols">
                        <t> The 'M' Bit, known as the Mandatory bit, indicates whether support of
                            the AVP is required. This bit is not set in DHCP-AVP. </t>
                    </list>
                </t>
                <t>V(endor) <list style="symbols">
                        <t> 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. </t>
                    </list>
                </t>
                <t>r(eserved) <list style="symbols">
                        <t> These flag bits are reserved for future use, and MUST be set to zero,
                            and ignored by the receiver. </t>
                    </list>
                </t>
                <t>AVP Length <list style="symbols">
                        <t>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. </t>
                    </list>
                </t>
                <t>Secret ID <list style="symbols">
                        <t>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. </t>
                    </list>
                </t>
                <t>Nonce Data (variable length) <list style="symbols">
                        <t>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. </t>
                    </list>
                </t>
            </section>
            <section anchor="computing" title="Computing DHCP SA">
                <t>The key derivation procedure is reused from IKE <xref target="RFC2409"/>. The
                    character '|' denotes concatenation.</t>
                <t> DHCP Key = HMAC-SHA1(MSK, const | Secret ID | Nonce_client | Nonce_NAS)</t>
                <t>The values have the following meaning:<list style="hanging">
                        <t hangText="MSK:">
                            <vspace blankLines="1"/> A key derived by the EAP peer and EAP
                            (authentication) server at
                            the end of the successful network access AAA. <vspace blankLines="1"/>
                        </t>
                        <t hangText="const:">
                            <vspace blankLines="1"/> This is a string constant. The value of the
                            const parameter is set to "EAP RFC 3118 Bootstrapping". <vspace blankLines="1"/>
                        </t>
                        <t hangText="Secret ID:">
                            <vspace blankLines="1"/>The unique identifier of the DHCP key as carried
                            by the EAP lower-layer protocol extension. <vspace blankLines="1"/>
                        </t>
                        <t hangText="Nonce Client:">
                            <vspace blankLines="1"/> This random number is provided by the client
                            and carried by the EAP lower-layer protocol extension. <vspace blankLines="1"/>
                        </t>
                        <t hangText="Nonce NAS:">
                            <vspace blankLines="1"/> This random number is provided by the NAS and
                            carried by the EAP lower-layer protocol. <vspace blankLines="1"/>
                        </t>
                        <t hangText="DHCP Key:">
                            <vspace blankLines="1"/>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). </t>
                    </list>
                </t>
                <t>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.</t>
                <t>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</t>
            </section>
        </section>
        <section anchor="delivering" title="Delivering DHCP SA">
            <t> 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.</t>
            <t>The format of the DHCP SA sub-option is: <figure anchor="dhcp-suboption" title="DHCP SA Suboption">
                    <artwork><![CDATA[
    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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
]]></artwork>
                </figure>
            </t>
            <t>
                <list style="hanging">
                    <t hangText="subopt code:">
                        <vspace blankLines="1"/> TBD <vspace blankLines="1"/>
                    </t>
                    <t hangText="Length:">
                        <vspace blankLines="1"/> This value is set to 26.<vspace blankLines="1"/>
                    </t>
                    <t hangText="Reserved:">
                        <vspace blankLines="1"/> A 16-bit value reserved for future use. It MUST be
                        initialized to zero by the sender, and ignored by the receiver. <vspace blankLines="1"/>
                    </t>
                    <t hangText="Secret ID:">
                        <vspace blankLines="1"/> This is the 32-bit value assigned by the NAS and
                        used to identify the DHCP key. <vspace blankLines="1"/>
                    </t>
                    <t hangText="DHCP Key:">
                        <vspace blankLines="1"/> 128-bit DHCP key computed by the NAS is carried in
                        this field.<vspace blankLines="1"/>
                    </t>
                    <t hangText="Lifetime:">
                        <vspace blankLines="1"/>The lifetime of the DHCP SA. This Unsigned32 value
                        contains the number of seconds remaining before the DHCP SA is considered
                            expired.<vspace blankLines="1"/>
                    </t>
                </list>
            </t>
        </section>
        <section anchor="using" title="Using DHCP SA">
            <t>Once the DHCP SA is in place, it is used along with RFC 3118 to secure the DHCP
                protocol exchange.</t>
            <t>RFC 3118 <xref target="RFC3118"/> defines two security protocols with a newly defined
                authentication option: <list style="symbols">
                    <t>Configuration token </t>
                    <t>Delayed authentication </t>
                </list>
            </t>
            <t>The generic format of the authentication option is defined in Section 2 of RFC 3118
                    <xref target="RFC3118"/> and contains the following fields: <list style="symbols">
                    <t>Code </t>
                    <t>Delayed authentication </t>
                </list>
            </t>
            <t>The value for the Code field of this authentication option is 90. </t>
            <t>
                <list style="symbols">
                    <t>Length </t>
                </list>
            </t>
            <t>The Length field indicates the length of the authentication option payload. </t>
            <t>
                <list style="symbols">
                    <t>Protocol </t>
                </list>
            </t>
            <t>RFC 3118 <xref target="RFC3118"/> defines two values for the Protocol field - zero
                and one. A value of zero indicates the usage of the configuration token
                authentication option. </t>
            <t>As described in Section 4 of RFC 3118 <xref target="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. </t>
            <t>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. </t>
            <t>Since the value for this field is known in advance it does not need to be negotiated
                between the DHCP client and DHCP server. </t>
            <t>
                <list style="symbols">
                    <t> Algorithm </t>
                </list>
            </t>
            <t>RFC 3118 <xref target="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. </t>
            <t>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.] </t>
            <t>
                <list style="symbols">
                    <t> Replay Detection Method (RDM) </t>
                </list>
            </t>
            <t>The value of zero for the RDM name space is assigned to use a monotonically
                increasing value. </t>
            <t>Since the value for this field is known in advance it does not need to be negotiated. </t>
            <t>
                <list style="symbols">
                    <t> Replay Detection</t>
                </list>
            </t>
            <t>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.</t>
            <t>Since the value for this field is known in advance it does not need to be negotiated. </t>
            <t>
                <list style="symbols">
                    <t> Authentication Information</t>
                </list>
            </t>
            <t>The content of this field depends on the type of message where the authentication
                option is used. Section 5.2 of RFC 3118 <xref target="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. </t>
            <t>Since the value for this field is known in advance it does not need to be negotiated. </t>
            <t> For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the Authentication
                Information field is given as: <list style="symbols">
                    <t>Secret ID (32 bits) </t>
                    <t>HMAC-MD5 (128 bits)</t>
                </list>
            </t>
            <t>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.]</t>
            <t>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 <xref
                target="RFC3118"/>. </t>
        </section>
        <!-- reqts -->
        <section anchor="security-considerations" title="Security Considerations">
            <t>This document describes a mechanism for dynamically establishing a security
                association to protect DHCP signaling messages. </t>
            <t>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.</t>
            <t>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 <xref
                target="I-D.ietf-eap-keying"/>). The DHCP key is a Transient Session Key (TEK) from
                    <xref target="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.</t>
            <figure anchor="keying" title="Keying Architecture">
                <artwork><![CDATA[
 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

                                                       ]]></artwork>
            </figure>
            <t>
                <xref target="keying"/> 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.</t>
            <t> The key transport mechanism, which is used to carry the session key between the NAS
                and DHCP server, must provide the following functionality: <list style="symbols">
                    <t> Confidentiality protection </t>
                    <t> Replay protection</t>
                    <t> Integrity protection </t>
                </list>
            </t>
            <t>Furthermore, it is necessary that the two parties (DHCP server and the NAS) authorize
                the establishment of the DHCP security association. </t>
            <t>Below we provide a list of security properties of the suggested mechanism: <list style="hanging">
                    <t hangText="Algorithm independence:">
                        <vspace blankLines="1"/> 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.</t>
                    <t hangText="Establish strong, fresh session keys (maintain algorithm independence):">
                        <vspace blankLines="1"/>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 <xref
                        target="computing"/> contains random numbers provided by the client and the
                        NAS which additionally add randomness to the generated key.</t>
                    <t hangText="Replay protection:">
                        <vspace blankLines="1"/>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. </t>
                    <t hangText="Authenticate all parties:">
                        <vspace blankLines="1"/>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 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. </t>
                    <t hangText="Perform authorization:">
                        <vspace blankLines="1"/>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. </t>
                    <t hangText="Maintain confidentiality of session keys:">
                        <vspace blankLines="1"/>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 <xref
                        target="RFC4014"/> with non-null IPsec encryption. </t>
                    <t hangText="Confirm selection of 'best' cipher-suite:">
                        <vspace blankLines="1"/>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. </t>
                    <t hangText="Uniquely name session keys:">
                        <vspace blankLines="1"/>The DHCP SA is uniquely identified using a Secret ID
                        (described in <xref target="RFC3118"/> and reused in this document). </t>
                    <t hangText="Compromised NAS and DHCP server:">
                        <vspace blankLines="1"/>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. </t>
                    <t hangText="Bind key to appropriate context:">
                        <vspace blankLines="1"/>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. </t>
                </list>
            </t>
        </section>
        <section anchor="iana-considerations" title="IANA Considerations">
            <t>[Editor's Note: A future version of this draft will provide IANA considerations.]</t>
        </section>
        <section anchor="open" title="Open Issues">
            <t>This document describes a bootstrapping procedure for DHCPv4. The same procedure
                could be applied for DHCPv6 but is not described in this document.</t>
        </section>
        <section anchor="acks" title="Acknowledegments">
            <t> 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.</t>
        </section>
    </middle>
    <back>
        <references title="Normative References"> &RFC2119; &RFC3748; &RFC2131;
            &RFC1661; &RFC4014; &RFC3118; </references>
        <references title="Informative References"> &I-D.ietf-dhc-v4-threat-analysis;
            &RFC5191; &I-D.ietf-eap-keying; &RFC2409;
            &I-D.ietf-dhc-relay-agent-ipsec;
            <!--
            <reference anchor="8021X">
                <front>
                    <title>IEEE Standard for Local and Metropolitan Area Networks, IEEE Std 802.1X-2001.</title>
                    <author fullname=" " initials=" " surname=" ">
                        <organization/>
                    </author>
                    <date year=" " month=" "/>
                </front>
                <format type=" " target=" "/>
            </reference>
-->
        </references>
    </back>
</rfc>
