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]