Internet DRAFT - draft-ram-dhc-dhcpv6-diam-app
draft-ram-dhc-dhcpv6-diam-app
DHCP Diameter Application August 31, 2006
DHC working group Vishnu Ram
Internet Draft Vihang Kamble
Document: draft-ram-dhc-dhcpv6-diam-app-01.txt Saumya Upadhyaya
Nitin Jain
Expires: March 4, 2007 August 31, 2006
DHCP Diameter Application
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2007.
Abstract
Dynamic Host Configuration Protocol version 6 (DHCPv6)
authentication, as described in RFC3315, makes use of a model
described in RFC3118. The DHCP threat model is described in RFC3118.
But RFC3315 does not discuss the dynamic establishment of the
security association between client and the DHCPv6 server. Also it
assumes that the establishment of the security association is done
out of band.
This draft proposes to make use of the security association between
DHCPv6 client and the home authentication, authorization and
accounting (AAAH) to establish the security association dynamically
and in band. This draft defines an AAA interface between DHCPv6
Vishnu et al., Expires March 4, 2007 [Page 1]
DHCP Diameter Application August 31, 2006
server and AAAH which enables the authentication of the DHCPv6 client
with AAAH.
Table of Contents
1. Introduction...................................................3
2. Scope of this Document.........................................3
3. Terminology....................................................3
4. AAA architecture for DHCPv6 authentication.....................4
5. Scenarios and message flows....................................5
5.1. DHCPv6 client initial authentication......................5
5.2. DHCPv6 renewal of SA......................................6
5.3. AAAH initiated termination of the DHCPv6 service..........6
5.4. DHCPv6 server initiated termination of the DHCPv6 service.7
5.5. AAAH Initiated configuration..............................8
6. Diameter message description...................................8
6.1. ADR/ADA...................................................8
6.2. PCR/PCA..................................................11
6.3. DTR/DTA..................................................11
7. Diameter AVPs for DHCP Diameter application...................12
7.1. User-Name AVP............................................13
7.2. DHCP-Identifier AVP......................................13
7.3. DHCP-Message AVP.........................................13
7.4. Client-AAA-Authentication AVP............................14
7.5. Option-Request-Option AVP................................14
7.6. User-Config-Params AVP...................................14
7.7. Config-Option AVP........................................14
7.8. Client-Server-SA AVP.....................................15
7.9. DHCPv6-Algorithm Type....................................15
7.10. DHCPv6-Authentication key AVP...........................15
7.11. DHCPv6-Nonce AVP........................................15
7.12. DHCPv6-Lifetime AVP.....................................15
7.13. DHCPv6-AAA-SPI AVP......................................15
7.14. Authentication-Information AVP..........................16
8. IANA Considerations...........................................16
8.1. Application Identifier...................................16
8.2. Application messages.....................................16
8.3. AVP Codes................................................16
9. Security Considerations.......................................16
10. References...................................................16
10.1. Normative References....................................16
10.2. Informative References..................................17
11. Full Copyright Statement.....................................18
12. Intellectual Property........................................18
Vishnu et al., Expires March 4, 2007 [Page 2]
DHCP Diameter Application August 31, 2006
1. Introduction
The threat model for DHCPv6 is being discussed in [2].
Static SA between client and server may not be feasible in a
deployment scenario where client is roaming. [1] discusses out of
band security association set up between client and server. The
mechanism to transfer the dynamically established SA between server
and client is out of scope of this document and is discussed in [6].
The Authentication, Authorization and Accounting server (AAA) in the
client's home domain can be used to authenticate the client.
When the server detects that the client does not have an SA with
itself, it uses the AAA interface with AAAH to authenticate the
client. AAAH uses its preexisting SA with the client to authenticate
the client and sends the reply to server. AAAH also generates and
transfers the DHCPv6 SA to server which in turn transfers it to
client.
2. Scope of this Document
This document defines the interface between server and the AAAH to
authenticate a client. The interface is based on Diameter [5]
protocol.
This document does not discuss the DHCPv6 messaging necessary to
provide the authentication. It shall be discussed in [6]. Also this
document does not discuss the optimization necessary to support the
mobility. In this document we assume that the authentication process
is started afresh when DHCPv6 moves from one server to another
server. This document does not discuss the accounting for DHCPv6
service and a separate document is needed to discuss that.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
AAA Authentication, Authorization, and Accounting.
Key A number, kept secret. Only nodes in possession of
the key have any hope of using the security
transform to obtain correct results.
Key Generation Nonce
Nonce data used for the purpose of creating a key.
Vishnu et al., Expires March 4, 2007 [Page 3]
DHCP Diameter Application August 31, 2006
DHCPv6 Security Association (DSA)
A DHCPv6 Security Association is a simplex
Connection that applies security services to DHCPv6
Messages between a DHCPv6 Client and server
using the options defined in this document. A
DHCPv6 Security Association is uniquely identified
by the peer source and destination IP addresses and
an SPI. Two nodes may have one or more DHCPv6
Security Associations; however, typically there is
no reason to have more than one DHCPv6 Security
Association between two nodes, except as a transient
condition during re-keying events.
Security Algorithm
A set of rules for using input data and a secret key
for producing data for use in security protocols.
SPI Security Parameters Index. The SPI is an arbitrary
32-bit value that assists in the identification of
an AAA, IP, or DHCPv6 Security Association.
Client In this document client refers to DHCPv6 client
Server In this document server refers to DHCPv6 server
4. AAA architecture for DHCPv6 authentication
A typical roaming scenario where a client uses DHCPv6 service in the
foreign domain is shown is fig 1. E.g. when the client request DHCPv6
service by issuing the DHCPv6 SOLICIT message, the server creates a
AAA-DHCP-Request (ADR) message, which includes the AVP's defined in
[5]. Upon receiving the ADR, the AAAH authenticates the client for
the DHCPv6 services and generates a security association (SA) for the
client. This SA is sent to the server in the AAA-DHCP-Answer (ADA)
message. The server uses this SA for the message authentication
between itself and the client.
Vishnu et al., Expires March 4, 2007 [Page 4]
DHCP Diameter Application August 31, 2006
Foreign Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAF | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | |
| DC |- -|- -| DS | | DC = DHCPV6 client
| | | | | | DS = DHCPV6 server
| | | | | | AAAF = Foreign authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Fig 1
5. Scenarios and message flows
5.1. DHCPv6 client initial authentication
Fig 2 shows the message flows during the initial DHCPv6
authentication.
client server AAAH
| | |
| | |
| | |
| | |
|-DHCPSOLICIT+ | |
| opt req opt with ---->| |
| Key Req indication+ | |
| client-aaa auth extn |--- AAA-DHCP-Request + --->|
| | SA request + |
| | DHCP message + |
| | client-aaa auth |
| | |
| | |
| |<---AAA-DHCP-Reply + ---|
| | SA + config options |
| | |
|<-- DHCPADVERTISE+-----| |
| Key Reply+auth extn | |
Fig 2
Vishnu et al., Expires March 4, 2007 [Page 5]
DHCP Diameter Application August 31, 2006
When the client sends a DHCPSOLICIT with a key generation option in
the option request option the server MUST send an ADR message to
authenticate the client as well as to acquire the SA. The server MUST
also add the DHCPv6 message received from client with modification
explained in sec 7.1 to AAAH. The AAAH authenticates the client by
verifying the client- AAA authentication and sends the response in
the ADA message. It also contains DHCPv6 authentication key which is
used locally by the server and a nonce which the client utilizes to
derive the DHCPv6 authentication key. The server encapsulates the
nonce, lifetime and Client-AAA-SPI received in a Key Generation Data
portion. The further details of client-server interaction are
available in [6].
5.2. DHCPv6 renewal of SA
The SA has a lifetime and before the lifetime expires the client MUST
renew the SA i.e. it should get a new SA. During the renewal process,
client send DHCPv6 message with client-server authentication option
with key generation option in the option request option. The HMAC in
the client-server authentication option [6] is calculated using the
current SA between the client and server. The server authenticates
the message using client-server authentication option and sends the
ADR message to the AAAH. The difference between the initial
authentication and the renewal is that during renewal clients MUST
NOT include client-AAA authentication option. During renewal the
server SHOULD NOT send the DHCPv6 message in the ADR message. When
AAAH receives an ADR without the DHCPv6 message it means that the
message authentication has been already performed by the server. AAAH
generates a new nonce and a new key from the nonce and sends it in
the ADA message as it was during the initial authentication.
5.3. AAAH initiated termination of the DHCPv6 service
When the DHCPv6 services are terminated at the AAAH, say, due to
administrative reasons then the AAAH MUST send a DHCP Terminate
Request (DTR) to the server. AAAH MUST send this message only to the
server who is currently providing DHCPv6 services to the client.
After receiving DTR the server sends DHCP Terminate Answer (DTA)
indicating that DHCPv6 can terminate the DHCPv6 session. The server
notifies the client by the mechanism discussed in [6]. Fig 3 shows
the mechanism discussed above.
Vishnu et al., Expires March 4, 2007 [Page 6]
DHCP Diameter Application August 31, 2006
client server AAAH
| | |
| | decision to
| | terminate
| | DHCP service
| | |
| | |
| |<--DHCP-Terminate-Request--|
| | |
| | |
| |---DHCP-Terminate-Answer-->|
| | |
| terminate DHCP |
| service |
| | |
|<-- DHCP messaging to->| |
| terminate the lease | |
| | |
Fig 3
5.4. DHCPv6 server initiated termination of the DHCPv6 service
The foreign domain may also want to terminate the DHCPv6 services
given to client. In this case, as explained in fig 4, the server MUST
send the DHCP Terminate Request (DTR). This is necessary to clean up
the SA in the AAAH to avoid the loss of synchronization between the
server and the AAAH. AAAH replies with DTA which confirm the clean up
of the SA.
client server AAAH
| | |
| decision to |
| terminate DHCP |
| service |
| | |
| | |
| | |
| |--DHCP-Terminate-Request-->|
| | |
| | |
| |<--DHCP-Terminate-Answer--_|
| | |
| terminate DHCP |
| service |
| | |
|<-- DHCP messaging to->| |
| terminate the lease | |
Fig 4
Vishnu et al., Expires March 4, 2007 [Page 7]
DHCP Diameter Application August 31, 2006
5.5. AAAH Initiated configuration
In certain scenarios the configuration parameters of the client can
change at AAAH after client has acquired the configuration
parameters. E.g. When the Home Address (HA) allotted to the client
changes. The AAAH MUST be able to inform the client that the
configuration has changed. AAAH sends Push Configuration request
(PCR) to server with the new configuration parameters. The server
acknowledges with PCA if the client is currently with the server. The
server then invokes the mechanism to transfer the parameters to
client. This mechanism could include sending a DHCPRECONFIGURE
message to client. Refer [2] for details. Fig 5 explains the message
flows.
client server AAAH
| | |
| | Decision to
| | change config
| | |
| |<--Push-config-Request-----|
| | |
| | |
| |---Push-Config-Answer----->|
| | SA request |
| | |
| change the config |
| locally |
| | |
| | |
|<-- DHCP messaging to->| |
| transfer new config | |
Fig 5
6. Diameter message description
This section describes the details of the Diameter message namely
ADR/ADA, PCR/PCA.
6.1. ADR/ADA
6.1.1. AAA-DHCPv6-Request
This message is used by the server to authenticate the client for
DHCPv6 service as well to get the configuration parameters (e.g.
MIPv6 bootstrapping information) for the client from AAAH. This
message also updates the AAAH about the DHCP server to which the
client is currently attached to.
Vishnu et al., Expires March 4, 2007 [Page 8]
DHCP Diameter Application August 31, 2006
The server MUST include the DHCPv6 message received from client e.g.
DHCP SOLICIT or DHCP INFOREQ in the ADR only if there is no SA
between client and server. AAAH authenticates the DHCP message only
if client-AAA authentication option AVP is present. In order to make
the AAAH agnostic of the DHCPv6 message formats, the DHCPv6
authentication information and the SPI from the client-AAA
authentication option MUST be copied from the corresponding DHCPv6
message and added separately in client-AAA authentication AVP in ADR.
The DHCPv6 message is added in the ADR message (after setting the MAC
field to be 0 in the client-AAA authentication option) as DHCP
message AVP. The DHCPv6 message in DHCP message AVP is used by AAAH
to calculate the MAC and to verify the same.
AAA-DHCP-Request ::= <Diameter Header: REQ,PXY >
<Session-ID >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ User-Name }
{ DHCP-Identifier }
[ Destination-Host ]
[ Origin-State-Id ]
[ DHCP message ]
[ client-AAA authentication ]
[ option request option ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
6.1.2. AAA-DHCP-Answer
This message is used by the AAAH in response to ADR. This message
sends the result of the authentication of the client. Also this
message MAY contain configuration parameters (e.g. MIPv6
bootstrapping information) for the client from AAAH.
AAA-DHCP-Answer ::= <Diameter Header: PXY >
<Session-ID >
{ Origin-Host }
{ Origin-Realm }
{ Request-Type }
{ Result-Code }
[ User-Name ]
[ DHCP-Identifier ]
[ User-Config-Params ]
[ Origin-State-Id ]
[ Auth-Session-State ]
Vishnu et al., Expires March 4, 2007 [Page 9]
DHCP Diameter Application August 31, 2006
[ Client-Server-SA ]
*[ Proxy-Info ]
*[ AVP ]
6.1.3. Behavior of AAAH on receiving ADR
AAAH SHALL authenticate the client for DHCPv6 service if client-AAA
authentication option is present. AAAH SHALL identify the client by
the user-name AVP. AAAH generates the nonce for the client. The
DHCPv6 authentication keys are sent to the server along with the
nonce. If the server requests for configuration parameters (e.g.
MIPv6 bootstrapping information) and AAAH has the information then
AAAH SHOULD send this information in the ADA.
6.1.4. Key generation at AAAH
The AAAH generates DHCPv6 authentication key and transmits it to the
server. The AAAH generates nonce that corresponds to the key and
transmits it to the client. When it is necessary to protect the
DHCPv6 authentication key and SPIs from un-trusted Diameter agents,
end-to-end security mechanisms such as TLS or IPSec are required to
eliminate all Diameter Agents between the server and the AAAH.
In [6], the security associations are established via nonce
transmitted to the client via DHCPv6. To provide the nonce, the AAAH
must generate a random value of at least 128 bits [6]. The client
then uses the nonce to derive the DHCPv6 authentication key. More
details of the DHCPv6 authentication key creation procedures can be
seen in [6].
6.1.5. Role of server
Server plays an important role in DHCPv6 authentication since it is
the entity which translates the DHCPv6 messages from client and forms
the Diameter message towards the AAAH. Server SHOULD use the NAI [3]
of the client to find the realm of the AAAH and realm based routing
is assumed so that the ADR reaches AAAH. When the client does not
have SA with the server it inserts the client-AAA authentication
option and indicates that it needs SA establishment in DHCPv6
message. The server should take this message and construct the ADR
message by populating the AVPs in the ADR with information received
in DHCPv6 message. The DHCPv6 message is added with the modification
explained above in the DHCP message AVP in ADR message. When the
server receives the ADA from AAAH then it extracts the SA which
includes the DHCPv6 authentication key and sends the keying material
(nonce) to client in DHCPv6 message.
6.1.6. Role of AAAF
Vishnu et al., Expires March 4, 2007 [Page 10]
DHCP Diameter Application August 31, 2006
The AAAF MAY not play any active role in DHCPv6 authentication. It
SHOULD be a Diameter relay to route the Diameter messages from server
to AAAH.
6.2. PCR/PCA
6.2.1. Push configuration request (PCR)
This message is used by the AAAH to asynchronously send the
configuration parameters to client. AAAH sends this message to server
which is currently serving the client. The configuration parameter
AVP may be in the xml format [6] which is recognized at both the AAAH
and server.
Push-Config-Request ::= <Diameter Header: REQ, PXY >
<Session-ID >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Name }
{ DHCP-Identifier }
{ User-Config-Params }
{ Auth-Application-Id }
[ Origin-State-Id ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
6.2.2. Push Configuration Answer (PCA)
This message is sent by the server in response to PCR. The result
code of this message indicates if the corresponding client is present
with the server.
Push-Config-Answer ::= <Diameter Header: PXY >
<Session-ID >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ User-Name ]
[ DHCP-Identifier ]
[ Origin-State-Id ]
*[ Proxy-Info ]
*[ AVP ]
6.3. DTR/DTA
The DTR/DTA messages are used to terminate the DHCP session.
Vishnu et al., Expires March 4, 2007 [Page 11]
DHCP Diameter Application August 31, 2006
6.3.1. DHCP Terminate Request (DTR)
This message is triggered by either the AAAH or DHCP Server to
terminate the DHCP session.
DHCP-Terminate-Request ::= <Diameter Header: REQ, PXY >
<Session-ID >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ User-Name }
{ DHCP-Identifier }
{ Termination-Cause }
{ Auth-Application-Id }
[ Origin-State-Id ]
[ Destination-Host ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
6.3.2. DHCP Terminate Answer(DTA)
This message is sent in response to a DTR message by either the DHCP
Server or AAAH
DHCP-Terminate-Answer ::= <Diameter Header: PXY >
<Session-ID >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ User-Name ]
[ DHCP-Identifier ]
[ Origin-State-Id ]
*[ Proxy-Info ]
*[ AVP ]
7. Diameter AVPs for DHCP Diameter application
This section gives the details of AVPs introduced in this draft and
existing AVPs which need clarification.
The following table describes the Diameter AVPs defined in the DHCP
Diameter application, their AVP Code values, types, possible flag
values, and whether the AVP MAY be encrypted.
Vishnu et al., Expires March 4, 2007 [Page 12]
DHCP Diameter Application August 31, 2006
+--------------------+
| AVP Flag rules |
|----+-----+----+----|----+
AVP Section | | |SHLD|MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr|
-----------------------------------------|----+-----+----+----|----|
DHCP-Identifier TBD 7.2 OctetString M P V Y
DHCP-Message TBD 7.3 OctetString M P V Y
Client-AAA-
Authentication TBD 7.4 Grouped M P V Y
Option-Request-
Option TBD 7.5 Grouped M P V Y
User-Config-
Params TBD 7.6 OctetString M P V Y
Config-Option TBD 7.7 unsigned32 M P V Y
Client-Server-SA TBD 7.8 Grouped M P V Y
DHCPv6-Algorithm-
Type TBD 7.9 Enumerated M P V Y
DHCPv6-
Authentication-
Key TBD 7.10 OctetString M P V Y
DHCPv6-Nonce TBD 7.11 OctetString M P V Y
DHCPv6-Lifetime TBD 7.12 unsigned32 M P V Y
DHCPv6-AAA-SPI TBD 7.13 unsigned32 M P V Y
Authentication-
Information TBD 7.14 OctetString M P V Y
7.1. User-Name AVP
This AVP is defined in [5] and it contains the NAI of the DHCP
client.
7.2. DHCP-Identifier AVP
This AVP (AVP code TBD) is of type OctetString and contains the
identifier used by the DHCP server to identify the DHCP client.
7.3. DHCP-Message AVP
This AVP (AVP code TBD) is of type OctetString and contains the
DHCPv6 message received from client. The DHCPv6 modifies the DHCPv6
message received and then populates this AVP. The AAAH need not
understand the contents of the DHCP message. AAAH authenticates the
DHCPv6 message by calculating the HMAC on it and then verifying with
the client-AAA authentication AVP. DHCP message AVP and client-AAA
authentication AVP MUST be present together.
Vishnu et al., Expires March 4, 2007 [Page 13]
DHCP Diameter Application August 31, 2006
7.4. Client-AAA-Authentication AVP
This AVP (AVP code TBD) is of type grouped and contains the
authentication information sent by the client as well as the AAA SPI
used in generating this authentication information. Client calculates
the authentication information using the shared secret, indexed by
the AAA SPI, between client and AAAH [6]. AAAH authenticates the
DHCPv6 message by calculating the HMAC on DHCPv6 message received in
DHCP message AVP.
Client-AAA-Authentication::=<AVP Header:TBD >
{DHCPv6-AAA-SPI}
{Authentication-Information AVP}
7.5. Option-Request-Option AVP
This AVP (AVP code TBD) is of type grouped and it indicates the
configuration options requested by the client. It has one or more
Config-Option AVP. The data field of this AVP has the following ABNF
grammar:
Option-Request-Option::=<AVP Header:TBD >
*{Config-Option AVP}
7.6. User-Config-Params AVP
This AVP (AVP code TBD) is of type OctetString and contains the
configuration parameters for client. The AVP contains the
configuration parameters in xml format which understood by the AAAH
and server. The details of the xml format are below
<?xml version="1.0" encoding="UTF-8"?>
<DHCPConfigParams>
<HaIpAddress> 1:2:3:4:5:6:7:8 </HaIpAddress>
<HomeIpAddress>1:2:3:4:5:6:7:9</HomeIpAddress>
<Mip6Nonce> mipv6nonce </Mip6Nonce>
<AaaKey> 1 </AaaKey>
<Mip6SaLifetime> 100 </Mip6SaLifetime>
</DHCPConfigParams>
Note: The values used above are sample values.
7.7. Config-Option AVP
This AVP (AVP code TBD) is of type unsigned32 and requests the
configuration option which is requested by the client. AAAH maps the
Vishnu et al., Expires March 4, 2007 [Page 14]
DHCP Diameter Application August 31, 2006
integer received in this AVP to the corresponding configuration
parameter.
7.8. Client-Server-SA AVP
This AVP (AVP code TBD) is of type Grouped and it contains the client
server SA. Server extracts the key and lifetime received in this AVP,
copies it locally and sends the nonce received in SA to client.
client use the nonce to generate the client-server SA locally. The
data field of this AVP has the following ABNF grammar:
DHCPv6-client-server-SA::=< AVP Header:TBD >
{ DHCPv6-Algorithm-Type }
{ DHCPv6-Authentication-key }
{ DHCPv6-Nonce }
{ DHCPv6-Lifetime }
{ DHCPv6-AAA-SPI }
* [ AVP ]
7.9. DHCPv6-Algorithm Type
This AVP (AVP code TBD) is of type Enumerated and contains the
algorithm identifier for the associated client-server authentication
option. The following values are currently defined:
2 HMAC-SHA-1
3 HMAC-MD5
7.10. DHCPv6-Authentication key AVP
This AVP (AVP code TBD) is of type OctetString and contains the
DHCPv6 authentication key.
7.11. DHCPv6-Nonce AVP
This AVP (AVP code TBD) is of type OctetString and contains the nonce
sent to the DHCPv6 client for the client -
-server authentication.
7.12. DHCPv6-Lifetime AVP
This AVP (AVP code TBD) is of type unsigned32 and contains the
lifetime of the security association being set up.
7.13. DHCPv6-AAA-SPI AVP
This AVP (AVP code TBD) is of type unsigned32 and contains the SPI
shared between the client and AAA which is used to generate the keys.
Vishnu et al., Expires March 4, 2007 [Page 15]
DHCP Diameter Application August 31, 2006
7.14. Authentication-Information AVP
This AVP (AVP code TBD) is of type OctetString and contains the
authentication information (say, the HMAC) calculated by the client.
8. IANA Considerations
8.1. Application Identifier
This document defines a new application called DHCP Diameter
Application and the application identifier of this application is
TBD.
8.2. Application messages
ADR/ADA have a value of TBD
PCR/PCA have a value of TBD
DTR/DTA have a value of TBD
8.3. AVP Codes
DHCP-Identifier AVP is set to TBD
DHCP-Message AVP is set to TBD
Client-AAA-Authentication AVP is set to TBD
Option-Request-Option AVP is set to TBD
User-Config-Params AVP is set to TBD
Config-Option AVP is set to TBD
Client-Server-SA AVP is set to TBD
DHCPv6-Algorithm-Type is set to TBD
DHCPv6-Authentication-Key AVP is set to TBD
DHCPv6-Nonce AVP is set to TBD
DHCPv6-Lifetime AVP is set to TBD
DHCPv6-AAA-SPI AVP is set to TBD
Authentication-Information AVP is set to TBD
9. Security Considerations
In this document we assume that the message transfer between the
server and AAAH is secure. This could be achieved by IPsec or
equivalent protocol.
10. References
10.1. Normative References
[1] R. Droms (ed.), J. Bound, B. Volz, T. Lemon, C. Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for
Vishnu et al., Expires March 4, 2007 [Page 16]
DHCP Diameter Application August 31, 2006
IPv6 (DHCPv6)", RFC 3315, July 2003
[2] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
DHCP Messages", RFC 3118, June 2001.
[3] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[4] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
10.2. Informative References
[6] Vishnu, R., Vihang, G., Saumya, U., Nitin, J., "Dynamic
security association establishment for DHCPv6" Work in
progress
Authors' Addresses
Vishnu Ram
Motorola
66/1, Bagmane Tech Park,
C V Raman Nagar, Bangalore, 560093
vishnu@motorola.com
Vihang Kamble
Motorola
66/1, Bagmane Tech Park,
C V Raman Nagar, Bangalore, 560093
vihang@motorola.com
Saumya Upadhyaya
Motorola
66/1, Bagmane Tech Park,
C V Raman Nagar, Bangalore, 560093
saumya@motorola.com
Nitin Jain
Motorola
66/1, Bagmane Tech Park,
C V Raman Nagar, Bangalore, 560093
nitin@motorola.com
Contributors
Significant contributions to this draft were made by Nikhil Suares,
Satendra G and Liyaqatali G Nadaf in the Diameter arena.
Vishnu et al., Expires March 4, 2007 [Page 17]
DHCP Diameter Application August 31, 2006
11. Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
12. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Vishnu et al., Expires March 4, 2007 [Page 18]