Internet DRAFT - draft-gondi-radext-radius-roaming
draft-gondi-radext-radius-roaming
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-01.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.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Mobility and Roaming Support for Radius servers................4
4. Radius server interactions.....................................5
4.1. Mobile terminal Interactions..............................5
4.2. Interactions with visiting networks Radius server.........6
5. Handover and roaming extensions................................6
5.1. Network Selection.........................................6
5.1.1. Packet format........................................6
5.2. Handover Initiation.......................................8
5.2.1. Packet format........................................8
5.3. Security Context Management..............................10
5.3.1. Packet format.......................................10
5.4. Mobility Management......................................11
5.4.1. Packet format.......................................12
6. Security Considerations.......................................13
7. IANA Considerations...........................................13
8. Conclusions...................................................14
9. References....................................................15
9.1. Normative References.....................................15
9.2. Informative References...................................15
Author's Addresses...............................................15
Intellectual Property Statement..................................16
Disclaimer of Validity...........................................16
Vamsi & Nazim Expires August 18, 2008 [Page 2]
Internet-Draft Roaming Extensions for radius server February 2008
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
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 3 of this draft we explain detail process mechanisms with
the new extensions to the radius server. Section 4 deals with the
radius server interaction with the client and with another radius
server. Section 5 provides information about the different modules
used in the radius roaming extensions in detailed with the packet
formats the attributes.
2. 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.
Mobile Terminal (MT):
The user terminal which has the capability of mobility
traditionally a mobile phone or a laptop.
Network Selection (NS):
Vamsi & Nazim Expires August 18, 2008 [Page 3]
Internet-Draft Roaming Extensions for radius server February 2008
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):
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.
3. 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
Vamsi & Nazim Expires August 18, 2008 [Page 4]
Internet-Draft Roaming Extensions for radius server February 2008
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
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.
4. Radius server interactions
4.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.
Vamsi & Nazim Expires August 18, 2008 [Page 5]
Internet-Draft Roaming Extensions for radius server February 2008
4.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.
5. Handover and roaming extensions
5.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.
5.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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vamsi & Nazim Expires August 18, 2008 [Page 6]
Internet-Draft Roaming Extensions for radius server February 2008
| |
| Authenticator (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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).
Vamsi & Nazim Expires August 18, 2008 [Page 7]
Internet-Draft Roaming Extensions for radius server February 2008
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)
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)
5.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.
5.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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Vamsi & Nazim Expires August 18, 2008 [Page 8]
Internet-Draft Roaming Extensions for radius server February 2008
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.
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)
Vamsi & Nazim Expires August 18, 2008 [Page 9]
Internet-Draft Roaming Extensions for radius server February 2008
5.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.
5.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
Vamsi & Nazim Expires August 18, 2008 [Page 10]
Internet-Draft Roaming Extensions for radius server February 2008
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
5.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.
Vamsi & Nazim Expires August 18, 2008 [Page 11]
Internet-Draft Roaming Extensions for radius server February 2008
5.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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vamsi & Nazim Expires August 18, 2008 [Page 12]
Internet-Draft Roaming Extensions for radius server February 2008
| 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).
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)
6. 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.
7. 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
Vamsi & Nazim Expires August 18, 2008 [Page 13]
Internet-Draft Roaming Extensions for radius server February 2008
assigned individually for every single extensions proposed in this
draft.
8. 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 14]
Internet-Draft Roaming Extensions for radius server February 2008
9. References
9.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.
9.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 15]
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 16]
