DHCP Diameter Application July 2006 DHC working group Vishnu Ram Internet Draft Vihang Kamble Document: draft-ram-dhc-dhcpv6-diam-app-00.txt Saumya Upadhyaya Nitin Jain Expires: January 2007 July 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 January, 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 January 2007 [Page 1] DHCP Diameter Application July 2006 server and AAAH which enables the authentication of the DHCPv6 client with AAAH. Table of Contents 1. Introduction...................................................2 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-Authenticator AVP.............................13 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 8. IANA Considerations...........................................15 8.1. Application Identifier...................................15 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.....................................17 12. Intellectual Property........................................18 1. Introduction Vishnu et al., Expires January 2007 [Page 2] DHCP Diameter Application July 2006 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. DHCPv6 Security Association (DSA) A DHCPv6 Security Association is a simplex Vishnu et al., Expires January 2007 [Page 3] DHCP Diameter Application July 2006 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 January 2007 [Page 4] DHCP Diameter Application July 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 When the client sends a DHCPSOLICIT with a key generation option in the option request option the server MUST send an ADR message to Vishnu et al., Expires January 2007 [Page 5] DHCP Diameter Application July 2006 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 authenticator 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 January 2007 [Page 6] DHCP Diameter Application July 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 January 2007 [Page 7] DHCP Diameter Application July 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 January 2007 [Page 8] DHCP Diameter Application July 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 ::= { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Application-Id } { User-Name } { DHCP-Identifier } [ Destination-Host ] [ Origin-State-Id ] [ DHCP message ] [ client-AAA authenticator ] [ 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 ::= { Origin-Host } { Origin-Realm } { Request-Type } { User-Name } { DHCP-Identifier } { User-Config-Params } { Result-Code } [ Origin-State-Id ] Vishnu et al., Expires January 2007 [Page 9] DHCP Diameter Application July 2006 [ Auth-Session-State ] [ 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 authenticator 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 authenticator 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. Vishnu et al., Expires January 2007 [Page 10] DHCP Diameter Application July 2006 6.1.6. Role of AAAF 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 ::= { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } { DHCP-Identifier } { User-Config-Params } [ 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 ::= { Origin-Host } { Origin-Realm } { User-Name } { DHCP-Identifier } { Result-Code } [ Origin-State-Id ] *[ Proxy-Info ] *[ AVP ] 6.3. DTR/DTA Vishnu et al., Expires January 2007 [Page 11] DHCP Diameter Application July 2006 The DTR/DTA messages are used to terminate the DHCP session. 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 ::= { Origin-Host } { Origin-Realm } { Destination-Realm } { User-Name } { DHCP-Identifier } { Termination-Cause } [ 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 ::= { Origin-Host } { Origin-Realm } { User-Name } { DHCP-Identifier } { Result-Code } [ 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 credit-control application, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. Vishnu et al., Expires January 2007 [Page 12] DHCP Diameter Application July 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- Authenticator TBD 7.4 OctetString 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 unsigned16 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 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 authenticator AVP. DHCP message AVP and client-AAA authenticator AVP MUST be present together. 7.4. Client-AAA-Authenticator AVP Vishnu et al., Expires January 2007 [Page 13] DHCP Diameter Application July 2006 This AVP (AVP code TBD) is of type OctetString and contains the authenticator sent by the client. Client calculates the authenticator using the shared secret between client and AAAH [6]. AAAH authenticates the DHCPv6 message by calculating the HMAC on DHCPv6 message received in DHCP message 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::= *{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 xml tags are the DHCP option codes. The details of the xml format are below <445> 1:2:3:4:5:6:7:8 <446>1:2:3:4:5:6:7:9 <447> mipv6nonce <448> 1 <449> 100 Note: The values used above are sample values. 7.7. Config-Option AVP This AVP (AVP code TBD) is of type unsigned16 and requests the configuration option which is requested by the client. AAAH maps the integer received in this AVP to the corresponding configuration parameter. Vishnu et al., Expires January 2007 [Page 14] DHCP Diameter Application July 2006 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. 8. IANA Considerations 8.1. Application Identifier Vishnu et al., Expires January 2007 [Page 15] DHCP Diameter Application July 2006 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-Authenticator 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 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 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. Vishnu et al., Expires January 2007 [Page 16] DHCP Diameter Application July 2006 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. 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. Vishnu et al., Expires January 2007 [Page 17] DHCP Diameter Application July 2006 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. Vishnu et al., Expires January 2007 [Page 18]