IETF PANA Working Group
Internet Draft H. Tschofenig
Siemens
Corporate Technology
A. Yegin
DoCoMo USA Labs
D. Forsberg
Nokia
Document:
draft-tschofenig-pana-bootstrap-rfc3118-01.txt
Expires: April 2004 October 2003
Bootstrapping RFC3118 Delayed authentication using PANA
<draft-tschofenig-pana-bootstrap-rfc3118-01.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
DHCP authentication extension (RFC3118) cannot be widely deployed
due to lack of an out-of-band key agreement protocol for DHCP
clients and servers. This draft outlines how EAP methods carried
over PANA can be used to establish a local trust relation and
generate keys that can be used in conjunction with RFC3118.
Tschofenig et al. Expires - April 2004 [Page 1]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
Table of Contents
1. Introduction...............................................2
2. Terminology................................................3
3. Overview and Building Blocks...............................4
3.1 PaC to PAA Communication................................5
3.2 PAA to DHCP Communication...............................5
3.3 Key Derivation..........................................6
4. Requirements...............................................6
5. Security parameters for RFC 3118...........................7
5.1 Authentication Option of RFC 3118.......................7
5.1.1 Code Field............................................8
5.1.2 Length Field..........................................8
5.1.3 Protocol Field........................................8
5.1.4 Algorithm Field.......................................8
5.1.5 Replay Detection Method (RDM) Field...................8
5.1.6 Replay Detection Field................................8
5.1.7 Authentication Information Field......................9
5.2 Lifetime of the DHCP security association...............9
6. Processing Details and Payloads............................9
6.1 Capability Indication and Trigger Message...............9
6.2 Key Derivation.........................................11
6.3 DHCP SA Sub-option.....................................12
7. Example message flow......................................13
8. Security Considerations...................................14
9. IANA Considerations.......................................17
10. Open Issues...............................................18
11. References................................................18
12. Acknowledgments...........................................19
13. Author's Addresses........................................19
1. Introduction
PANA [PANA] provides network access authentication by carrying
Extensible Authentication Protocol (EAP) between the hosts and the
access networks. The combination of EAP with an AAA architecture
allows authentication and authorization of a roaming user to an
access network. A successful authentication between a client and the
network produces a dynamically created trust relation between the
two. Various EAP authentication methods are capable of generating
cryptographic keys (e.g., shared secrets) between the client and the
authentication agent after successful authentication.
DHCP [RFC2131] is a protocol which provides an end host with
configuration parameters. The base DHCP does not include any
security mechanism, hence it is vulnerable to a number of security
threats. Security considerations section of RFC 2131 identifies this
protocol as "quite insecure" and lists various security threats.
RFC 3118 is the DHCP authentication protocol which defines how to
authenticate various DHCP messages. It does not support roaming
Tschofenig et al. Expires - April 2004 [Page 2]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
clients and assumes out-of band or manual key establishment. These
limitations have been inhibiting widespread deployment of this
security mechanism.
It is possible to use the authentication and key exchange procedure
executed during the network access authentication to bootstrap a
security association for DHCP. The trust relation created during the
access authentication process can be used with RFC 3118 to provide
security for DHCP. This document defines how to use PANA to
bootstrap RFC 3118 for securing DHCP.
PANA protocol allows clients to use this protocol even before they
are assigned an IP address. A PANA client (PaC) can use the
unspecified IP address as its source address during this phase.
This approach provides a two-step solution:
- Authentication and key exchange (provided by EAP methods carried
over PANA)
- DHCP message protection by generating the required shared secrets
for RFC 3118.
Instead of adding EAP support to DHCP itself (which requires
modifications to the DHCP protocol due to the nature of EAP
messaging) we keep the two protocols separate.
This document is organized as follows. Section 2 describes new
terms. Section 3 gives an overview of the basic communication and
describes the building blocks. Requirements are presented in Section
4. The details of the established parameters for the DHCP SA are
listed in Section 5. Processing details and payload formats are
illustrated in Section 6. A short message flow describes the
protocol interaction in Section 6.3. Finally in Section 8 additional
security considerations are discussed.
2. Terminology
This document uses the following terms:
- DHCP security association
To secure DHCP messages a number of parameters including the key
that is shared between the PaC (DHCP client) and the DHCP server
have to be established. These parameters are collectively referred
to as DHCP security association (or in short DHCP SA). Once a DHCP
server is selected the DHCP SA is use between the DHCP client and
the DHCP server.
- DHCP Key
Tschofenig et al. Expires - April 2004 [Page 3]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
This term refers to the fresh and unique session key dynamically
established between the DHCP client (PaC) and the DHCP server. This
key is used to protect DHCP messages as described in [RFC3118].
Further PANA related terms can be found in [PY+02].
In this document, the key words "MAY", "MUST, "MUST NOT",
OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [RFC2119].
3. Overview and Building Blocks
Based on the PANA protocol interaction this bootstrapping mechanism
requires protocol interaction between the PaC (which acts as DHCP
client), the PANA Authentication Agent (PAA) and the DHCP server. A
security association will be established between the DHCP server and
the DHCP client to protect DHCP messages.
DHCP SA is generated based on the PANA SA after a successful PANA
authentication. DHCP SA information needs to be transferred from the
PAA (where it is generated) to the DHCP server (where it will be
needed).
PAA is located one IP hop away from the PaC. If the DHCP server is
on the same link, it can be co-located with the PAA. When PAA and
DHCP server are co-located, an internal mechanism, such as an API,
is sufficient for transferring the SA information. If the DHCP
server is multiple hops away from the DHCP client, then there must
be a DHCP relay on the same link as the client. In that case, PAA
should be co-located with the DHCP relay. The SA information can be
communicated to the DHCP server using the DHCP relay agent
information options [DS02]. For the purpose of confidentiality
protection IPsec protection MUST be applied as described in [RD03].
Two different scenarios are illustrated in Figure 1.
+---------+ +--------------+
| PaC/ | | PAA / |
| DHCP |<================>| DHCP server |
| client | PANA and DHCP | |
+---------+ +--------------+
+---------+ +--------------+ +---------+
| PaC/ | | PAA / | | DHCP |
| DHCP |<================>| DHCP relay |<======>| server |
| client | PANA and DHCP | | DHCP | |
+---------+ +--------------+ +---------+
Legend:
Tschofenig et al. Expires - April 2004 [Page 4]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
PaC - PANA Client
PAA - PANA Authentication Agent
Figure 1: DHCP Protocol Bootstrapping
When the DHCP SA information is received by the DHCP server and
client, it can be used along with RFC3118 to protect DHCP messages
against various security threats.
The following building blocks have been identified:
3.1 PaC to PAA Communication
Additional payloads are required within PANA in order to bootstrap
RFC3118. These payloads therefore provide the following
functionality:
a) Capability indication
A capability describes a certain functionality which is either
supported or not. In order to trigger an action or to obtain a
certain kind of data item it is necessary to execute some message
exchanges. This message exchange allows both entities to learn
commonly supported functionality.
b) Trigger message
A trigger message allows one entity (either PaC or PAA) to request a
certain action to be executed. For this protocol a trigger message
sent by the PaC causes the PAA to create the DHCP security
association for support with [RFC3118].
Section 6 describes the message payloads for the additional objects
required in PANA usage with this bootstrapping protocol.
3.2 PAA to DHCP Communication
If the PAA and the DHCP server are co-located then only an API call
is required for transferring the necessary information from the PAA
to the DHCP server. If the PAA and the DHCP server are not co-
located then an additional protocol is needed. [WH+02] points to the
importance of this communication as: "Key distribution is not merely
a data transport operation; it is also a mechanism for building
transitive trust;". Indeed the trust relationship between the PaC
and the PAA, which was dynamically established during network access
authentication, is used to extend the trust relationship to the DHCP
server. The PAA, which is co-located with the DHCP Relay, and the
DHCP server trust each other and both entities belong to the same
administrative domain as the PAA.
Tschofenig et al. Expires - April 2004 [Page 5]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
Security sensitive information has to be exchanged (such as session
keys) between the DHCP relay (PAA) and the DHCP server. This
protocol is not part of PANA but the security implications must be
considered.
[DS02] enables transmission of AAA-related RADIUS attributes from
DHCP relay to DHCP server in the form of relay agent information
options. DHCP SA is generated at the end of the AAA process, and
therefore it can be provided to the DHCP server in a sub-option
carried along with other AAA-related information. Protection of this
exchange MUST be provided. [RD03] proposes IPsec protection of the
DHCP messages exchanged between the DHCP relay and the DHCP server.
DHCP objects (protected with IPsec) can therefore be used to
communicate the necessary parameters.
3.3 Key Derivation
As a result of the EAP authentication and key exchange method a
Master Session Key (MSK) is established which is used to establish a
PANA security association. The key derivation procedure for
establishing PANA SA is defined in [PANA]. Another security
association for usage with DHCP according to [RFC3118] needs to be
established. A discussion of the required parameters for the
security association is given in Section 5 and the key derivation
function is provided in Section 6.2
Since different bootstrapping applications need different keys it is
necessary to derive these keys from the session key provided by the
EAP method. It would be possible to reuse work done by members of
the EAP working group on key derviation for multiple applications
[SE03]. The key derivation mechanism used in this document is
similar.
4. Requirements
The following requirements regarding protocol design and deployment
have to be met:
- The DHCP protocol as defined in [RFC2131] MUST NOT be modified.
- The security mechanism defined in [RFC3118] MUST NOT be modified.
- The key derivation procedure MUST establish a unique and fresh
session key for the usage with [RFC3118]. The session key MUST never
be used again in later protocol run.
- It MUST be ensured that only the intended parties have access to
the session key. Hence the key transport between the PAA and the
DHCP server MUST be authenticated, integrity, replay and
confidentiality protected. The security mechanism used to protect
Tschofenig et al. Expires - April 2004 [Page 6]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
the transport of the session key between the PAA and the DHCP server
MUST have an adequate key strength. Section 5.4 of [AS+03] offers a
description of issues concerning key wrapping.
- The DHCP server MUST ensure that only authorized nodes are allowed
to install keying material for subsequent DHCP message protection.
- The established DHCP security association MUST provide data origin
authentication, integrity protection and replay protection. A non-
goal of this draft is to provide confidentiality protection for DHCP
messages.
- The lifetime of the DHCP session key is limited to the PANA
session lifetime. The session key MUST NOT be used beyond that
lifetime. The first DHCP message provides key confirmation of the
established session key between the PaC and the DHCP server. The
DHCP is active after a successful completion of the bootstrapping
procedure (indicated by the PAA).
- Key Naming
Both the DHCP client and the DHCP server MUST have means to uniquely
identify the DHCP SA.
The derived session key (DHCP key) MUST be bound to a particular
session between the particular PaC and an entity in the access
network. It MUST be possible for the two peers (PaC and DHCP server)
to verify that each other is indeed the intended recipients of the
distributed session key. Once the established DHCP SA is selected
for protection of DHCP messages (implicit) key confirmation is
provided.
5. Security parameters for RFC 3118
5.1 Authentication Option of RFC 3118
[RFC3118] defines two security protocols with a newly defined
authentication option:
- Configuration token
- Delayed authentication
The generic format of the authentication option is defined in
Section 2 of [RFC3118] and contains the following fields:
- Code (8 bits)
- Length (8 bits)
- Protocol (8 bits)
- Algorithm (8 bits)
- Replay Detection Method - RDM (8 bits)
- Replay Detection (64 bits)
Tschofenig et al. Expires - April 2004 [Page 7]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
- Authentication Information (variable length)
5.1.1 Code Field
The value for the Code field of this authentication option is 90.
5.1.2 Length Field
The Length field indicates the length of the authentication option
payload.
5.1.3 Protocol Field
[RFC3118] defines two values for the Protocol field - zero and one.
A value of zero indicates the usage of the configuration token
authentication option.
As described in Section 4 of [RFC3118] the configuration token only
provides weak entity authentication. Hence its usage is not
recommended. This authentication option will not be considered for
the purpose of bootstrapping.
A value of one in the Protocol field in the authentication option
indicates the Delayed authentication. The usage of this option is
subsequently assumed in this document.
Since the value for this field is known in advance it does not need
to be negotiated between the DHCP client and DHCP server.
5.1.4 Algorithm Field
[RFC3118] only defines the usage of HMAC-MD5 (value 1 in the
Algorithm field). This document assumes that HMAC-MD5 is used to
protect DHCP messages.
Since the value for this field is known in advance it does not need
to be negotiated.
5.1.5 Replay Detection Method (RDM) Field
The value of zero for the RDM name space is assigned to use a
monotonically increasing value.
Since the value for this field is known in advance it does not need
to be negotiated.
5.1.6 Replay Detection Field
This field contains the value that is used for replay protection.
This value MUST be monotonically increasing according to the
provided replay detection method.
Tschofenig et al. Expires - April 2004 [Page 8]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
An initial value must, however, be set. In case of bootstrapping
with PANA an initial value of zero is used. The length of 64 bits
(and a start-value of zero) ensure that a sequence number roll-over
is very unlikely to occur.
Since the value for this field is known in advance it does not need
to be negotiated.
5.1.7 Authentication Information Field
The content of this field depends on the type of message where the
authentication option is used. Section 5.2 of [RFC3118] does not
provide content for the DHCPDISCOVER and the DHCPINFORM message.
Hence for these messages no additional considerations need to be
specified in this document.
For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the
Authentication Information field is given as:
- Secret ID (32 bits)
- HMAC-MD5 (128 bits)
The Secret ID is chosen by the PAA to prevent collisions.
HMAC-MD5 is the output of the key message digest computation. Note
that not all fields of the DHCP message are protected as described
in [RFC3118].
5.2 Lifetime of the DHCP security association
The lifetime of the DHCP security association has to be limited to
prevent the DHCP from storing state information over a long time.
The lifetime of the DHCP SA should be set to the lifetime of PANA SA
which is determined by the PANA session lifetime. The PaC (i.e. DHCP
client), PAA, and DHCP server should be aware (directly or
indirectly) about the lifetime.
The PaC can at any time trigger a new bootstrapping protocol run to
establish a new security association with the DHCP server. The IP
address lease time SHOULD be limited by the DHCP SA lifetime.
6. Processing Details and Payloads
This section defines the necessary extensions for PANA and a key
derivation procedure.
6.1 Capability Indication and Trigger Message
Tschofenig et al. Expires - April 2004 [Page 9]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP-
AVP is included in the PANA-Bind-Request message if PAA is offering
DHCP SA bootstrapping service. If the PaC wants to proceed with
creating DHCP SA at the end of the PANA authentication, it MUST
include DHCP-AVP in its PANA-Bind-Answer message.
Absence of this AVP in the PANA-Bind-Request message sent by PAA
indicates unavailability of this additional service. In that case,
PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore
received DHCP-AVP. When this AVP is received by PaC, it may or may
not include the AVP in its response depending on its desire to
create DHCP SA. DHCP SA can be created as soon as each entity has
received and sent one DHCP-AVP.
The detailed DHCP-AVP format is presented below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Flags | AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secret ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
TBD
AVP Flags
The AVP Flags field is eight bits. The following bits are
assigned:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V M r r r r r r|
+-+-+-+-+-+-+-+-+
M(andatory)
- The 'M' Bit, known as the Mandatory bit,
indicates whether support of the AVP is
required. This bit is not set in DHCP-AVP.
V(endor)
Tschofenig et al. Expires - April 2004 [Page 10]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
- The 'V' bit, known as the Vendor-Specific bit,
indicates whether the optional Vendor-Id field
is present in the AVP header. This bit is not set in
DHCP-AVP.
r(eserved)
- These flag bits are reserved for future use,
and MUST be set to zero, and ignored by the
receiver.
AVP Length
The AVP Length field is three octets, and indicates the number
of octets in this AVP including the AVP Code, AVP Length, AVP
Flags, and AVP data.
Secret ID
32 bit value that identifies the DHCP Key produced as a result of
the bootstrapping process. This value is determined by PAA and
sent to PaC. PAA determines this value by randomly picking a
number from the available session ID pool. If PaC's response does
not contain DHCP-AVP then this value is returned to the available
identifiers pool. Otherwise, it is allocated to the PaC until
DHCP SA expires. PaC MUST set this field to all 0s in its
response.
Nonce Data (variable length)
Contains the random data generated by the transmitting entity.
This field contains Nonce_PaC when the AVP is sent by PaC, and
Nonce_PAA when the AVP is sent by PAA. Nonce value MUST be
randomly chosen and MUST be at least 128 bits in size. Nonce
values MUST NOT be reused.
6.2 Key Derivation
This section describes the key derivation procedure which allows to
establish a DHCP security association. The key derivation procedure
is reused from IKE [RFC2409]. The character '|' denotes
concatenation.
DHCP Key = HMAC-MD5(MSK, const | Session ID | Nonce_PaC | Nonce_PAA)
The values of have the following meaning:
- MSK
Tschofenig et al. Expires - April 2004 [Page 11]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
The Master Session Key (MSK) is provided by the EAP method as part
of the PANA/EAP protocol execution.
- const
This is a string constant. The value of the const parameter is set
to "PANA RFC3118 Bootstrapping".
- Session ID
This is the PANA session ID as defined in [PANA]. It is used to
identify a unique session between the PaC and PAA.
- Nonce_PaC
This random number is provided by the PaC and exchanged within the
PANA protocol.
- Nonce_PAA
This random number is provided by the PAA/DHCP server and exchanged
with the PANA protocol.
- DHCP Key
This session key is 128-bit in length and used as the session key
for securing DHCP messages. Figure 1 of [EAP-Key] refers to this
derived key as Transient Session Keys (TSKs).
6.3 DHCP SA Sub-option
When PAA and DHCP server are not co-located, the DHCP SA information
is carried from the PAA (DHCP relay) to the DHCP server in a DHCP
relay agent info option. This sub-option can be included along with
the RADIUS attributes sub-option that is carried after the network
access authentication.
The format of the DHCP SA sub-option is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubOpt Code | Length | Secret ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secret ID (continued) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ DHCP Key +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tschofenig et al. Expires - April 2004 [Page 12]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
| | Lifetime ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Lifetime (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SubOpt Code
TBD
Length
This value is set to 24.
Secret ID
This is the 32-bit value assigned by the PAA which is used to
identify the DHCP key.
DHCP Key
128-bit DHCP key computed by PAA is carried in this field.
Lifetime
The lifetime of DHCP SA. This Unsigned32 value contains
the number of seconds remaining before the DHCP SA is
considered expired.
7. Example message flow
Figure 2 depicts a message flow that enables DHCP bootstrapping. The
PANA message flow starts with a discovery of the PAA, followed by
network access authentication. Finally, when the authentication
succeeds a PANA security association is established. The DHCP-AVP
payload contains parameters described in Section 6.
PaC PAA Message(tseq,rseq)[AVPs]
------------------------------------------------------
-----> PANA-PAA-Discover(0,0)
<----- PANA-Start-Request(x,0)[Cookie]
-----> PANA-Start-Answer(y,x)[Cookie]
<----- PANA-Auth-Request(x+1,y)
[Session-Id, EAP{Request}]
-----> PANA-Auth-Answer(y+1,x+1)
[Session-Id, EAP{Response}]
.
.
<----- PANA-Auth-Request(x+n,y+n-1)
[Session-Id, EAP{Request}]
-----> PANA-Auth-Answer(y+n,x+n)
Tschofenig et al. Expires - April 2004 [Page 13]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
[Session-Id, EAP{Response}]
<----- PANA-Bind-Request(x+n+1,y+n)
[EAP{Success}, Session-Id, Device-Id,
DHCP-AVP, Lifetime, MAC]
-----> PANA-Bind-Answer(y+n+1,x+n+1)
[Session-Id, Device-Id, DHCP-AVP,
MAC]
Figure 2: Message flow for PANA DHCP bootstrapping
PANA SA will be created based on the PANA authentication. Since PaC
and PAA have exchanged DHCP-AVPs, additionally a DHCP SA will be
generated as outlined earlier. DHCP SA parameters can be immediately
provided to the DHCP server when PAA and DHCP server are co-located.
When they are on separate nodes, the next DHCP request sent by the
DHCP client (PaC) can piggyback the DHCP SA parameters to the DHCP
server as it is relayed by the DHCP relay (PAA).
8. Security Considerations
This document describes a mechanism for dynamically establishing a
security association to protect DHCP signaling messages.
PANA uses EAP to support a number of authentication methods. With
the functionality of EAP this document therefore supports DHCP
security for roaming users.
This document separates the different security mechanisms in a
modular way:
a) The appropriate EAP method for a certain scenario, environment or
architecture can be chosen. The security properties heavily depend
on the chosen EAP method.
b) PANA carries EAP messages and provides additional security. The
security features of PANA are described in [PANA].
c) The security mechanism in [RFC3118] is reused for providing
authentication, integrity and replay protection for DHCP messages.
If the PAA and the DHCP server are co-located then the session keys
and the security parameters are transferred locally (via an API
call). Some security protocols already exercise similar methodology
to separate functionality.
If the PAA and the DHCP server are not co-located then there is some
similarity to the requirements and issues discussed with the EAP
Keying Framework (see [AS+03]). Figure 3 is taken from Section 4.1
of [AS+03] and adjusted accordingly. A major difference from [AS+03]
is that the communication between the PAA and DHCP server takes
place within the same administrative domain. Hence the security
Tschofenig et al. Expires - April 2004 [Page 14]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
considerations are different to those described in [WH+03].
Secondly, even after DHCP client and DHCP server acquire the DHCP
key, the PAA host continues to be on the DHCP path when acting as a
DHCP relay.
PaC (DHCP client)
/\
Protocol: EAP over PANA / \
Auth: Mutual / \
Unique keys: / \
- MSK / \
- PANA key / \
- DHCP key / \
PAA +--------------+ DHCP server
Protocol: DHCP or API
Auth: Mutual
Unique key: DHCP key
Figure 3: Keying Architecture
Figure 3 describes the participating entities and the protocol
executed between them. It must be ensured that the derived session
key between the PaC and the DHCP server is fresh and unique.
The key transport mechanism, which is used to carry the session key
between the PAA and DHCP server, must provide the following
functionality:
- Confidentiality protection
- Replay protection
- Integrity protection
Furthermore it is necessary that the two parties (DHCP server and
the PAA) authorize the establishment of the DHCP security
association.
Russ Housley recently (at the 56th IETF) presented a list of
recommendations for key management protocols which describe
requirements for an acceptable solution. Although the presentation
focused on NASREQ some issues might also applicable in our context.
We will address the presented issues briefly:
- Algorithm independence
Our proposal bootstraps a DHCP security association based on RFC
3118 where only a single integrity algorithm (namely HMAC-MD5) is
proposed which is mandatory to implement.
Tschofenig et al. Expires - April 2004 [Page 15]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
- Establish strong, fresh session keys (maintain algorithm
independence)
PANA relies on EAP to provide strong and fresh session keys for each
initial authentication and key exchange protocol run. Furthermore
the key derivation function provided in Section 6.2 contains random
numbers provided by the PaC and the PAA which additionally add
randomness to the generated key.
- Replay protection
Replay protection is provided at different places:
The EAP method executed between the EAP peer and the EAP server
which is carried over PANA (between the PaC and the PAA) MUST
provide a replay protection mechanism.
Additionally random numbers and the session id is included in the
key derivation procedure which aims to provide a fresh and unique
session key between the PaC (DHCP client) and the DHCP server.
Furthermore, the key transport mechanism between the PAA and the
DHCP server must also provide replay protection (in addition to
confidentiality protection).
Finally, the security mechanisms provided in RFC 3118, for which
this draft bootstraps the security association, also provides replay
protection.
- Authenticate all parties
Authentication between the PaC and the PAA is provided by the PANA
protocol which utilizes EAP. Key confirmation of PANA SA is
accomplished at the final stage of the PANA exchange.
Key confirmation between the PaC and the DHCP server is provided
with the first protected DHCP message exchange.
- Perform authorization
Authorization for network access is provided during the PANA
exchange. The authorization procedure for DHCP bootstrapping is
executed by the PAA before this service is offered to the PaC. The
PAA might choose not to include DHCP-AVP in a PANA-Bind-Request
based on its local policies.
- Maintain confidentiality of session keys
The DHCP session keys are only known to the intended parties (i.e.,
to the PaC, PAA and the DHCP server).
Tschofenig et al. Expires - April 2004 [Page 16]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
The PANA protocol does not transport keys. The exchanged random
numbers which are incorporated into the key derivation function do
not need to be kept confidential.
DHCP relay agent information MUST be protected using [RD03] with
non-null IPsec encryption.
- Confirm selection of "best" ciphersuite
This proposal does not provide confidentiality protection of DHCP
signaling messages. Only a single algorithm is offered for integrity
protection. Hence no algorithm negotiation and therefore no
confirmation of the selection occur.
- Uniquely name session keys
The DHCP SA is uniquely identified using a Secret ID (described in
[RFC3118] and reused in this document).
- Compromised PAA and DHCP server
A compromised PAA may leak the DHCP session key, the EAP derived
session key (e.g., MSK) and the PANA SA. It will furthermore allow
corruption of the DHCP protocol executed between the hosts and the
DHCP server since PAA node either acts as a DHCP relay or DHCP
server.
A compromised PAA may also allow creation of further DHCP SAs or
other known attacks on the DHCP protocol (e.g., address depletion).
A compromised PAA will not be able to modify, replay, inject DHCP
messages which use security associations established without the
PANA bootstrapping protocol (e.g., manually configured DHCP SAs).
On the other hand, a compromised DHCP server may only leak the DHCP
key information. MSK and PANA SA will not be compromised in this
case.
- Bind key to appropriate context
The key derivation function described in Section 6.2 includes
parameters (such as the PANA session ID and a constant) which
prevents reuse of the established session key for other purposes.
The key derivation includes the session identifier to associate the
key to the context of a certain PANA protocol session and therefore
to a particular client.
9. IANA Considerations
TBD
Tschofenig et al. Expires - April 2004 [Page 17]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
10. Open Issues
This document describes a bootstrapping procedure for [RFC3118]. The
same procedure could be applied for [DHCPv6].
Some text is required to describe the details of the DHCP multi-
server model. When multiple DHCP servers send DHCPOFFER in response
to the DHCPDISCOVER where each server has a distinct server id and
the client chooses a single server among multiple DHCPOFFER
messages. For the client there is no difference between any of the
DHCP server.
11. References
[DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M.
Carney: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
Internet-Draft, (work in progress), November, 2002.
[PANA] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin:
"Protocol for Carrying Authentication for Network Access (PANA)",
Internet-Draft, (work in progress), March, 2003.
[RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J.
Turner, "Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.:
"Protocol for Carrying Authentication for Network Access (PANA)
Requirements and Terminology", Internet-Draft, (work in progress),
April, 2003.
[DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option
for the DHCP Relay Agent Information", Internet-Draft, (work in
progress), October, 2002.
[SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication
Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in
progress), April, 2003.
[AS+03] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz: "EAP
Keying Framework", Internet-Draft, (work in progress), October 2003.
Tschofenig et al. Expires - April 2004 [Page 18]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
[RFC2132] Alexander, S. and Droms, R.: "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[WH+03] J. Walker, R. Housley, and N. Cam-Winget, "AAA key
distribution", Internet Draft, (work in progress), April 2002.
[RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes",
RFC 2548, March 1999.
[CFB02] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS
Security Application", Internet-Draft, (work in progress), March
2002.
[RD03] R. Droms: "Authentication of DHCP Relay Agent Options Using
IPsec", Internet-Draft (work in progress), August 2003.
[SE03] J. Salowey and P. Eronen: "EAP Key Derivation for Multiple
Applications", Internet-Draft (work in progress), June 2003.
12. Acknowledgments
We would like to thank Yoshihiro Ohba for his comments to this
draft.
13. Author's Addresses
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Alper E. Yegin
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA, 95110
USA
Phone: +1 408 451 4743
Email: alper@docomolabs-usa.com
Dan Forsberg
Nokia Research Center
P.O. Box 407
FIN-00045 NOKIA GROUP, Finland
Phone: +358 50 4839470
EMail: dan.forsberg@nokia.com
Tschofenig et al. Expires - April 2004 [Page 19]
Internet Draft Bootstrapping RFC3118 using PANA October 2003
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Tschofenig et al. Expires - April 2004 [Page 20]