One document matched: draft-yegin-eap-boot-rfc3118-03.xml
<?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> >=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>
| PAFTECH AB 2003-2026 | 2026-04-22 12:43:16 |