Network Working Group Vamsi Krishna.G, Internet Draft Nazim Agoulmine, Expires: August 2008 LRSM, UEVE, France February 18, 2008 Roaming Extensions for radius server draft-gondi-radext-radius-roaming-00.txt 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 August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The functionalities of radius server can be extended to provide new types of services for the users in Wireless and cellular network. Traditionally Radius servers are limited to authentication, access and accounting, there are few researchers proposing new extensions Vamsi & Nazim Expires August 18, 2008 [Page 1] Internet-Draft Roaming Extensions for radius server February 2008 to provide new functionalities for radius server in wireless and cellular networks. In this draft we are proposing to extend the functionalities of Radius to extend it to roaming and handover support for the mobile terminals. Using this mechanism the mobile terminal initially gets access to the network and then when there is a possibility of handover and roaming with the other access networks, mobile terminal communicates with the home radius server and creates the pre authentication information. In this process different mechanisms essential for roaming and handover are addressed such as Network Selection, Handover Initiation, Security Context Management, and Mobility Management. Using this mechanism the latency for handover and roaming can be reduced with higher level control mobility of the terminal during handover and roaming. Conventions used in this document 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 Error! Reference source not found.. Mobile Terminal (MT): The user terminal which has the capability of mobility traditionally a mobile phone or a laptop. Network Selection (NS): The process of identifying the best available network for accessing a network. Handover (HO): Mechanism involving the authentication and access control of the MT moving from one access network to another access network or technology. Security Configuration (SC): Authentication and re-authentication management of the mobile terminal in any access networks, in this draft context management is proposed where the security credentials can be transported to other mechanisms. Mobility Management (MM) In this mechanisms the mobility and session context management can be achieved. Extensible Authentication Protocol (EAP): Vamsi & Nazim Expires August 18, 2008 [Page 2] Internet-Draft Roaming Extensions for radius server February 2008 Extensible Authentication Protocol is a universal authentication framework frequently used in wireless networks and Point-to-Point connections defined by RFC 3748. Radius server: Remote Authentication Dial In User Service (RADIUS) is an AAA (authentication, authorization, and accounting) protocol for controlling access to network resources. Table of Contents 1. Introduction...................................................3 2. Mobility and Roaming Support for Radius servers................4 3. Radius server interactions.....................................5 3.1. Mobile terminal Interactions..............................5 3.2. Interactions with visiting networks Radius server.........5 4. Handover and roaming extensions................................6 4.1. Network Selection.........................................6 4.1.1. Packet format........................................6 4.2. Handover Initiation.......................................8 4.2.1. Packet format........................................8 4.3. Security Context Management...............................9 4.3.1. Packet format.......................................10 4.4. Mobility Management......................................11 4.4.1. Packet format.......................................11 5. Security Considerations.......................................13 6. IANA Considerations...........................................13 7. Conclusions...................................................13 8. References....................................................14 8.1. Normative References.....................................14 8.2. Informative References...................................14 Author's Addresses...............................................14 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................15 1. Introduction With the increase in the usage of different access technologies networks there is a need for access networks to support the mobile terminal to decide and transfer details during roaming and handover. By introducing this support the long lasting issues of Network Selection (NS), handover initiation (HO), Security context management (SC) for low delay during authentication, and mobility management (MM) can be addressed. In this draft we are proposing to Vamsi & Nazim Expires August 18, 2008 [Page 3] Internet-Draft Roaming Extensions for radius server February 2008 extend the functionalities by adding new modules in the Radius server for all the mentioned above processes. Ultimately the main aim of this is to provide network centric mobile terminal management to provide seamless roaming services during mobility. As mentioned above by introducing new modules of NS, etc.. Radius server can be extended to support roaming and handover before the mobile terminal does moves into new access network. A mobile terminal before moving into another network, using any transfer mechanism (in this case we proposed new EAP HO method) it can initiate the radius roaming support using the present connected network. Mobile terminal sends the NS request to the Radius server, radius server responds with the available access networks. The other processes like HO, SC, MM also can be transferred from the client to radius server and radius server to client and radius server negotiating with the other radius server for the allocation of resources or SC or MM to create the session even the mobile terminal moving to another access networks. In section 2 of this draft we explain detail process mechanisms with the new extensions to the radius server. Section 3 deals with the radius server interaction with the client and with another radius server. Section 4 provides information about the different modules used in the radius roaming extensions in detailed with the packet formats the attributes. 2. Mobility and Roaming Support for Radius servers In this draft we have proposed to add new functionalities with the existing ones where the Radius server can listen to requests from the mobile terminal and also to communicate with the other radius servers, network entities of the access networks for roaming and handover support. In this mechanism Network Selection is done on the access network as well as on the terminal. In this process the client terminal sends a request for NS with the list of available networks, the radius server with the NS extension listens to the request and reads the data sent by the mobile terminal, according to the user policy required QoS etc.. The radius server selects the access networks in the order of priority and sends back to the terminal. The terminal after receiving the reply selects the best access network and sends a request for handover initiation to the radius server. After receiving the request for handover initiation the radius server sends a request to the visiting access network for handover init, the visiting radius server checks the available resources on that AP or BS and SLA with the request server sends the reply as ok Vamsi & Nazim Expires August 18, 2008 [Page 4] Internet-Draft Roaming Extensions for radius server February 2008 or resources not available. After receiving the reply the home radius server sends the reply to client to initiate the handover mechanisms. With the init from the server the mobile terminal sends the request for the SC and MM request, the server creates the temporary keys and re-authentication ID and forwards to the visiting server and also as a reply to the mobile terminal with the details of SC. With the MM the radius server sends the details of mobile terminal for MM like the SPI, home address, and home agent address to the other visiting server. The visiting server after receiving the request forwards the user details to the MPA or FA of that access network to create the MM context for that SPI and after successful context creation the server acknowledges with success as reply to the home server. When these details are transferred to the mobile terminal, the terminal does start the re-authentication with the visiting network. With the SCM details from the home radius server during pre authentication it initiates the authentication and tries to access directly to the visiting network. By using this context transfer mechanism and pre authentication information exchange for NA, HO, SC and MM the total latency during the re-authentication can be reduced drastically in a controlled environment. 3. Radius server interactions 3.1. Mobile terminal Interactions The mobile terminal sends the request to the radius server in this case using new EAP-HO method which we are proposing in parallel with this draft. This EAP-HO sends the request for different mechanisms proposed in this draft as sub type. The information of NS, HO, SC and MM can be transferred using this EAP-HO. On the other side the Radius server has to be modified to accommodate this EAP method and constantly listens to the requests from the clients. After processing the different mechanisms (NS, HO, SC, MM), information these methods has to be transferred to the mobile terminal using EAP-HO as reply to the client. Not only EAP but also any mechanism which is compatible with Radius server in layer 2 and layer 3 can be used to transfer information. 3.2. Interactions with visiting networks Radius server New attributes and modules are developed so that when there is any information exchange for different processes using these extensions it can be achieved. The home and visiting radius server can interact with the new attributes proposed in this draft for different functionalities. Vamsi & Nazim Expires August 18, 2008 [Page 5] Internet-Draft Roaming Extensions for radius server February 2008 4. Handover and roaming extensions 4.1. Network Selection The server constantly scans on the ports mentioned in the configuration for any requests. It differentiates the requests from clients as well as from servers. In the NS procedure whenever there is any request from the client, the NS procedure checks the user policy and QoS to provide the access to users. If ever the user doesn't have any policy to roaming the server responds with no privileges to access network, if the user have provision then the server responds with the priority list according to the visiting networks and send back to the client. When the mobile terminal sends a request for NS with the home Radius server with the target network IDs, home AAA differentiates with the Local networks or visiting networks. After this home Radius server sends a request with NS extensions to the visiting networks radius server. Visiting network process the available information and sends the available target ID as a reply back to the home Radius server. If ever the request failed it sends NS failure as code value of the packet. 4.1.1. Packet format In this section we explain details of the extended functionalities of Radius with the NS with a new attribute valued pairs and codes. The Radius server builds NS Request message from the Access. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code (1 byte)| Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Vamsi & Nazim Expires August 18, 2008 [Page 6] Internet-Draft Roaming Extensions for radius server February 2008 Code = (1 byte) Network_Selection_Request = TBD (IANA consideration) Identifier: (1 byte) number to match the Request/Reply. Length: (2 bytes) length of the message, including Code, Identifier, Length, Authenticator, Attributes. Authenticator: The Authenticator field is 16 bytes. The most significant octet is transmitted first. This value is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm. Attributes: Network selection Attribute 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Length (2 bytes) | User's ID (B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User's ID (256 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Network ID (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Network ID (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = (1 byte) NS_Request_Attribute = TBD (IANA consideration) Length (2 bytes) = Length of the message User's ID: (256 bytes) extracted from the name of the user (ex: userID@realm). Target Network ID: contains details of target network BS or AP ID of around 4 bytes, the request can send around multiple target IDs to the authenticator in this case another Radius server, if ever there are no multiple entry the field will be empty. The visiting radius server replies to the home radius server with NS message. The Code field for this message is: NS_Accept = TBD (IANA consideration) Vamsi & Nazim Expires August 18, 2008 [Page 7] Internet-Draft Roaming Extensions for radius server February 2008 If there is failure in retrieving and processing the data the visiting radius server must reply the home radius server with a NS Reject message, with Code NS_Reject = TBD (IANA consideration) 4.2. Handover Initiation In this process when the client sends the HO initiation request for the target ID, the home radius server sends the request to the visiting radius server for HO initiation. Visiting Radius checks for the available resources for that target ID and sends the accept or reject as a reply to the home radius server. 4.2.1. Packet format Radius HO extension: In this section we explain details of the extended functionalities of Radius with the HO with a new attribute valued pairs and codes. The home Radius server builds HO Request message from the Access. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code (1 byte)| Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code = (1 byte) Handover_init_Request = TBD (IANA consideration) Identifier: (1 byte) number to match the Request/Reply. Length: (2 bytes) length of the message, including Code, Identifier, Length, Authenticator and attributes. Authenticator: The Authenticator field is 16 bytes. The most significant octet is transmitted first. This value is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm. Vamsi & Nazim Expires August 18, 2008 [Page 8] Internet-Draft Roaming Extensions for radius server February 2008 Attributes: Handover Intitiation Attribute 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Length (2 bytes) | User's ID (B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User's ID (256 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Network ID (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = (1 byte) NS_Request_Attribute = TBD (IANA consideration) Length (2 bytes) = Length of the message User's ID: (256 bytes) extracted from the name of the user (ex: userID@realm). Target Network ID: contains details of target network BS or AP ID of around 4 bytes. The visiting radius server reply to the home radius server with handover initiation Accept message. Code = HO_Accept = TBD (IANA consideration) If there is failure in retrieving and processing the data the visiting radius server must reply the home radius server with a HO initiation Reject message. Code = HO_Reject = TBD (IANA consideration) 4.3. Security Context Management In this process the home radius server derives the re-authentication ID and temporary keys for mobile terminal requests for security initiation. These details are transferred to the client as well as to the visiting network using security extensions. Upon receiving the details from the home network the visiting network configures the details in the server for that user id, if there is any problem during configuration or the data sent by the server, visiting sends a failure response, if ever the configuration is good the server responds with success. Vamsi & Nazim Expires August 18, 2008 [Page 9] Internet-Draft Roaming Extensions for radius server February 2008 4.3.1. Packet format Radius SC extension: The home Radius server builds SC Request message from the Access. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code (1 byte)| Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code = (1 byte) SC_Request = TBD (IANA consideration) Identifier: (1 byte) number to match the Request/Reply. Length: (2 bytes) length of the message, including Code, Identifier, Length, Authenticator, Attributes. Authenticator: The Authenticator field is 16 bytes. The most significant octet is transmitted first. This value is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm. Attributes: Seurity Context Management Attribute 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Length (2 bytes) | User's ID (1B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User's reauthentication ID (256 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |validity(1byte)| Key (64 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vamsi & Nazim Expires August 18, 2008 [Page 10] Internet-Draft Roaming Extensions for radius server February 2008 Type (1 byte) = NS_Request_Attribute = TBD (IANA consideration) Length (2 bytes) = Length of the message User's reauthentication ID: (256 bytes) home radius server assign this id and forwards this to the visiting networks radius server and as well as to client. Validity (1 byte) = the valid time of the key and the re authentication id. Key (64 bytes) = temporary key which is derived in the home radius server the visiting radius server reply to the home radius server with SC Accept message. Code = SC_Accept = TBD (IANA consideration) If there is any failure in the packet or the details of SC configuration on the visiting server, it sends the faliure to the home radius server. Code = SC_Reject = TBD (IANA consideration) 4.4. Mobility Management When the Radius server receives the MM request from the client the home radius server prepares a request for mobility and sends the packet to the visiting network AAA server. This packet contains the details of mobile terminal, SPI, keys, Home address of the mobile terminal and the home agent address. The transfer of these details to the network entities such as MPA or HA or FA is out of this draft context. 4.4.1. Packet format Mobility Request format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code (1 byte)| Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator (16 bytes) | | | Vamsi & Nazim Expires August 18, 2008 [Page 11] Internet-Draft Roaming Extensions for radius server February 2008 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code = (1 byte) Mobility_Request = TBD (IANA consideration) Identifier: (1 byte) number to match the Request/Reply. Length: (2 bytes) length of the message, including Code, Identifier, Length, Authenticator, Attributes. In the case that there is only mobility attribute, length = 350 Authenticator: The Authenticator field is 16 bytes. The most significant octet is transmitted first. This value is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm. Attributes: Mobility Attribute 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Length (2 bytes) | User's ID (1B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User's ID (256 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (1byte) | Key (64 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = (1 byte) Mobility_Request_Attribute = TBD (IANA consideration) Length (2 bytes) = Length of the message = 332. User's ID: (256 bytes) extracted from the name of the user (ex: userID@realm). Vamsi & Nazim Expires August 18, 2008 [Page 12] Internet-Draft Roaming Extensions for radius server February 2008 HA address: (4 bytes) Home Agent's IP address, filled with Zeros. Home Address: (4 bytes) Mobile Node's Home Address, filled with Zeros. SPI: 1 byte, filled with Zeros. Key: (64 bytes) public key of the HA, filled with Zeros. The visiting radius server reply to the home radius server with Mobility Accept message, the Code field for this message is: Mobility_Accept = TBD (IANA consideration) If there is faliure in retreiving and processing the data the visiting radius server must reply the home radius server with a Mobility Reject message, with Code Mobility_Reject = TBD (IANA consideration) 5. Security Considerations The information exchanges between the client and the radius server proposed in this architecture must be secured, the information exchange between the radius servers must support security for every modules proposed in this draft for roaming and handover support. 6. IANA Considerations The codes and attributes discussed in the above sections are to be assigned by the IANA. There will be different codes which are to be assigned individually for every single extensions proposed in this draft. 7. Conclusions The proposed extensions for radius support different functionalities to provide seamless services during mobile terminal movement. Most of the issues of the network selection, security context management and MM are addressed in this draft. Even though the proposed solution in this draft is robust and efficient there are still issues to be solved such as security, privacy and policy of the access networks. Vamsi & Nazim Expires August 18, 2008 [Page 13] Internet-Draft Roaming Extensions for radius server February 2008 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [3] Blunk, L., "Extensible Authentication Protocol (EAP)", RFC 3748 (work in progress), June 2004. 8.2. Informative References [4] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [5] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [6] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. Author's Addresses Vamsi Krishna Gondi, LRSM Research Lab, University of Evry Evry, France 91000 Email: vamsi.gondi@gmail.com Nazim Agoulmine, LRSM Research Lab, University of Evry Evry, France 91000 Email: nazim.agoulmine@iup.univ-evry.fr Vamsi & Nazim Expires August 18, 2008 [Page 14] Internet-Draft Roaming Extensions for radius server February 2008 Intellectual Property Statement 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. Disclaimer of Validity 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, THE IETF TRUST 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vamsi & Nazim Expires August 18, 2008 [Page 15]