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