idnits 2.17.1 draft-yegin-mip6-aaa-fwk-01.txt: -(1): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(98): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(142): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(356): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 527), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 118 has weird spacing: '...DIUS or ser...' == Line 315 has weird spacing: '...o learn the M...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2005) is 7006 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 350 == Unused Reference: 'RFC2119' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 471, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 == Outdated reference: A later version (-12) exists of draft-ietf-aaa-diameter-sip-app-06 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-auth-protocol-04 == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-01 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-mipv6-mib-06 == Outdated reference: A later version (-02) exists of draft-jang-dhc-haopt-00 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ���Network Working Group A. Yegin 2 Internet-Draft Samsung AIT 3 Expires: August 19, 2005 February 18, 2005 5 AAA Mobile IPv6 Application Framework 6 draft-yegin-mip6-aaa-fwk-01.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 19, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document describes a framework for using AAA backend protocols 40 (e.g., RADIUS, Diameter) between home agents and AAA servers for 41 centralizing Mobile IPv6 service management. Implementation of this 42 framework requires definition of a new AAA application on the 43 aforementioned protocols. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3. New AAA Application . . . . . . . . . . . . . . . . . . . . . 8 50 3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 51 4. Relation to Mobile IPv6 Bootstrapping . . . . . . . . . . . . 10 52 5. Other Ways to Talk About Mobile IPv6 and AAA . . . . . . . . . 11 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 55 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 56 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 57 8.2 Informative References . . . . . . . . . . . . . . . . . . . 14 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 59 Intellectual Property and Copyright Statements . . . . . . . . 17 61 1. Introduction 63 AAA backend protocols, such as RADIUS [RFC2865] and Diameter 64 [RFC3588], enable centralized management of authentication, 65 authorization, and accounting (AAA) for a limited type of services 66 (Mobile IPv4 [I-D.ietf-aaa-diameter-mobileip], network access 67 [I-D.ietf-aaa-diameter-nasreq], SIP [I-D.ietf-aaa-diameter-sip-app]). 68 Currently there is no standard mechanism to centralize AAA for Mobile 69 IPv6 [RFC3775]" services. 71 The current Mobile IPv6 protocol design assumes pre-established 72 static configuration between a mobile node (MN, the client) and a 73 home agent (HA, the server) for authentication and authorization of 74 the mobility service. Although there are no standard protocols to 75 retrieve accounting information from a HA yet, SNMP will be useful in 76 the near future with the development of Mobile IPv6 MIBs 77 [I-D.ietf-mip6-mipv6-mib]. 79 The distributed AAA management model could be sufficient in the 80 presence of one static HA per MN, but this is not always the case. 81 In the presence of multiple HAs on a home subnet, reliance on 82 pre-configuration increases the network management overhead. 83 Additionally, there may be more than one home subnet that can be used 84 by a mobile node, in which case the number of possible HAs is further 85 increased. A central AAA infrastructure that is in charge of 86 authentication, authorization, and accounting for the Mobile IPv6 87 service between any MN and any HA in a domain would benefit 88 deployments by preventing AAA information replication and management 89 across the domain. 91 Furthermore, at times Mobile IPv6 service may have to cross operator 92 domain boundaries. For example, an (serving) operator may wish to 93 provide Mobile IPv6 service to another operator's customers for whom 94 it does not have any per-MN configuration in its local servers. A 95 scalable and secure Mobile IPv6 roaming service 96 [I-D.ietf-mip6-bootstrap-ps] cannot be made possible by solely 97 relying on the HA pre-configuration. The MN can only be 98 authenticated and authorized by an entity in its home operator���s 99 domain. The serving HA has to get in touch with the local AAA 100 infrastructure, which in turn must contact the AAA infrastructure of 101 the home operator. Upon successful authorization and delivery of the 102 service, associated accounting information can be delivered from the 103 serving operator to the home operator. 105 This document describes AAA Mobile IPv6 application framework that 106 enables AAA centralization and roaming for Mobile IPv6 services. 107 There is more than one way to use AAA technologies with Mobile IPv6. 108 The reader should note that the framework advocated in this document 109 constitutes only a subset of those possibilities. See Section 5 for 110 more on this subject. 112 2. Framework 114 The following figure depicts the interaction among various entities 115 using AAA for Mobile IPv6. 117 Mobile <---------------> Home agent/ <--------------> AAA 118 node Mobile IPv6, AAA client RADIUS or server 119 IKE Diameter 121 Figure 1: MIP6-AAA framework 123 In this framework, Mobile IPv6 protocol is executed between the MN 124 and the HA, as it normally would. Unlike a HA that relies on the 125 preconfigured information, the AAA-enabled HA (more precisely: AAA 126 client on HA) communicates with a AAA server in order to authenticate 127 and authorize the MN before starting the Mobile IPv6 service, and 128 later for making the accounting information available. 130 The current Mobile IPv6 design relies on use of IPsec for 131 authentication of protocol signaling between the MN and the HA. The 132 associated IPsec SA is created by running IKE [RFC3776] between the 133 two. The initial authentication and authorization of MN and HA 134 should be performed during the IKE execution. This is where HA must 135 consult the AAA infrastructure. The authorization at this stage is 136 for establishing an IPsec SA for Mobile IPv6 service. Authorization 137 parameters (e.g., max allowed lifetime) for the subsequent Mobile 138 IPv6 binding updates may also be delivered to the HA at this stage. 140 Upon successful IPsec SA establishment for Mobile IPv6 service, MN 141 can send binding updates to the HA. By the help of IPsec SA, the HA 142 can authenticate the MN without AAA server���s help. Furthermore, 143 the HA can also authorize the binding update if it already has the 144 authorization parameters from its earlier interaction with the AAA 145 server. Otherwise, the HA must contact the AAA server again to 146 perform binding update authorization. 148 Figure 2 is an illustration of a Mobile IPv6 session that starts with 149 IPsec SA establishment and includes one initial and one refreshing 150 binding updates. 152 MN HA AAA server 154 | | Auth/Authz for | 155 | IKE | MIPv6 IPsec SA | 156 |<------------------->|<-------------------->| 157 | | | 158 | Binding Update | Authz for BU | 159 |<------------------->|<-------------------->| 160 | | | 161 | | | 162 | | | 163 | Binding Update | Authz for BU | 164 |<------------------->|<-------------------->| 165 | | | 166 v 167 time 169 Figure 2: Message flow 171 Accounting-oriented HA-AAA interaction can take place any time MN is 172 authorized for the service, and it can be piggybacked with the 173 authentication/authorization messaging. 175 This framework is built upon following trust model. 177 (1) (2) 178 HA <------> AAA server <------> MN 179 ^ ^ 180 . . 181 ................................ 182 (3) 184 Figure 3: Trust model 186 It is assumed that HA-AAA (1) and MN-AAA (2) trust relations are 187 pre-configured. HA-AAA may have an indirect trust relation, that 188 spans multiple intermediate server and operator domains. MN-HA (3) 189 trust relation is dynamically created as a result of the AAA 190 interaction. MN can create trust relations with several HAs. These 191 trust relations should not outlive neither the MN-AAA nor the HA-AAA 192 trust relations. 194 An instance of this framework that relies on EAP-based authentication 195 is depicted in Figure 4. 197 Mobile <---------------> Home agent/ <--------------> AAA 198 node Mobile IPv6, AAA client EAP/RADIUS server 199 EAP/IKEv2 201 Figure 4: EAP-based IKE authentication 203 EAP [RFC3748] can provide end-to-end authentication between the MN 204 and AAA server. It can be used for IPsec SA authentication and 205 authorization by being transported on IKEv2 between the MN and HA, 206 and by a AAA-backend protocol between the HA and AAA. EAP framework 207 enables authentication between the peer (MN) and authentication 208 server (AAA server) via an authenticator (HA), and produces a 209 security association between the peer and the authenticator as a 210 result. While the produced security association is not an IPsec SA, 211 it can be used in building one. EAP is not used with Mobile IPv6 212 binding update authentication and authorization. 214 This framework can also be used with scenarios where other 215 authentication methods (non-EAP-based) are used with IKE. 216 Furthermore, future extensions to Mobile IPv6 specification may 217 involve IPsec/IKEless operation [I-D.ietf-mip6-auth-protocol]. They 218 should readily fit this framework as well. 220 [TBD: Consider using AAA with the CN as well. Now that alternatives 221 to RR-based BU security are being considered, and MN-CN pre-shared 222 key concept is around, leveraging AAA may come into the picture.] 224 3. New AAA Application 226 The architectural differences between Mobile IPv4 and Mobile IPv6 227 necessitate different AAA application framework for each. 229 Mobile IPv4 involves an intermediate server between the MN and the 230 HA, namely foreign agent (FA) which can be co-located with a network 231 access server (NAS). This impacts the end-to-end AAA flow. 233 The signaling authentication is built-in with the Mobile IPv4 234 protocol, whereas an additional protocol (IPsec) is used for Mobile 235 IPv6. Use of IPsec requires yet another protocol (IKE) for session 236 establishment. This nature of Mobile IPv6 leads to additional 237 authentication and authorization exchanges between the HA and AAA 238 server. The triggering event dictates the nature of exchange (e.g., 239 for authentication and authorization of a Mobile IP IPsec SA 240 creation, vs. authorization of a Mobile IPv6 binding update). In 241 Mobile IPv4, a single interaction between the serving agent (FA or 242 HA) and the AAA server is sufficient to accomplish authentication and 243 authorization of a registration request (equivalent of a Mobile IPv6 244 binding update). 246 The new AAA application is required to associate a given 247 authorization and accounting to the Mobile IPv6 service. When a AAA 248 client contacts a AAA server, it should be able to convey that the 249 request is for Mobile IPv6 service, as opposed to any other services 250 (network access, SIP, etc.). Additionally, service authorization 251 should take into account parameters like home address and binding 252 lifetime, which are specific to a Mobile IPv6 service. Finally, 253 accounting should support Mobile IPv6-specific MIBs 254 [I-D.ietf-mip6-mipv6-mib]. 256 3.1 Requirements 258 It is assumed that the AAA client to server interface will be a new 259 AAA application on RADIUS and Diameter protocols. The following 260 requirements capture specific needs of this application in addition 261 to what is already available in the base AAA protocols. 263 In a typical deployment, the same node will implement both the Mobile 264 IPv6 Home Agent and AAA client functionalities. The interface 265 discussed in this document is the one between the AAA client and the 266 AAA server. The interface between the HA and the AAA client is 267 outside the scope of this document. Although it is abbreviated as HA 268 interfacing with the AAA server, in fact there is a AAA client 269 between the two. 271 The interface MUST be able to identify the service as "Mobile IPv6". 273 This is necessary in order to differentiate the sought/authorized 274 service from others, such as network access, SIP, Mobile IPv4, etc. 275 [a]. 277 The interface MUST serve authentication, authorization, and 278 accounting purposes [b]. 280 The interface MUST perform authentication and authorization of MN and 281 HA for building an IPsec SA for Mobile IPv6 service. EAP/IKEv2 is 282 used for this step [c]. The interface MUST be able to carry EAP 283 between the HA and the AAA server [d]. This step produces a shared 284 secret between the MN and HA. The secret key is generated on the MN 285 by the EAP protocol and method. On the other hand, the same secret 286 key is generated by the AAA server and MUST be delivered to the HA 287 via this new interface [e]. This step MAY also deliver Mobile IPv6 288 authorization parameters to the HA (e.g., maximum allowed lifetime) 289 [f]. 291 The interface MUST perform authorization of MN for creating or 292 updating a binding cache entry on the HA for EAP/IKEv2-based 293 deployments [g]. This step MUST take place within the lifetime of 294 the IPsec SA produced in the previous step [h]. The interface does 295 not deal with the authentication of the MN as this is already taken 296 care of by the IPsec processing on the HA. The interface MUST allow 297 the content of the Binding Update communicated from the HA to the AAA 298 server [i]. The AAA server needs the Binding Update values in order 299 to make an authorization decision. The authorization result returned 300 by the AAA server MUST include the authorized lifetime and an error 301 code if the update request is rejected [j]. The authorized lifetime 302 cannot exceed the IPsec SA lifetime. 304 The interface MUST perform authentication and authorization of the MN 305 for creating or updating a binding cache entry on the HA for IPsec/ 306 IKEless deployments [I-D.ietf-mip6-auth-protocol] [k]. There is no 307 IPsec SA building step in these deployments. The interface MUST 308 support delivery of Binding Update values from the HA to the AAA 309 server, and the authorization decision along with the lifetime and 310 error codes (if available) in return [l]. The authorized lifetime 311 cannot exceed the MN-AAA security association lifetime. The AAA 312 server MAY also assign a home address for the MN and deliver its 313 value via this interface [m]. 315 The AAA server MUST be able to learn the Mobile IPv6 accounting 316 information maintained by the HA [n]. The accounting information 317 includes the counts of BUs, HoTIs, HoTs, forward and reverse tunneled 318 IP packets for a given MN. 320 4. Relation to Mobile IPv6 Bootstrapping 322 Mobile IPv6 bootstrapping mechanisms [I-D.ietf-mip6-bootstrap-ps] are 323 potentially useful for providing three pieces of information to a MN: 324 HA address or home subnet prefix, home address, and a security 325 association between the MN and HA. The security association does not 326 have to be an IPsec SA, but something that helps creation of an IPsec 327 SA eventually. 329 Use of this framework assumes the MN already knows the HA address. 330 Hence an implementation of this framework cannot help with HA 331 discovery. 333 The security association between MN and HA can be created by using 334 the HA-AAA interface (see EAP-based example). 336 Home address can be obtained before or after running the AAA 337 protocol. For example, the home address may be known by the MN by 338 the time it engages in IKE or Mobile IPv6 with the HA, or it may be 339 dynamically assigned by the HA or the AAA server. An implementation 340 of the framework should work with any of these options. 342 Overall, this framework can be used as part of a Mobile IPv6 343 bootstrapping operation, but not necessarily as a complete solution 344 to that problem. 346 5. Other Ways to Talk About Mobile IPv6 and AAA 348 Talking about AAA does not make sense without specifying the 349 associated service. There is a difference between AAA for network 350 access and AAA for Mobile IPv6 services [8]. This distinction may be 351 blurry in certain cases (e.g., when Mobile IPv4 authentication is 352 used for network access as well), but otherwise they are at least 353 logically separate services. 355 There are several ways to mix the keywords �ǣMobile IPv6�ǥ with 356 �ǣAAA�ǥ in addition the one described in this document. They are 357 listed here for the sake of identification, but not necessarily for 358 advocating them. 360 (a) Using network access AAA to deliver Mobile IPv6 bootstrapping 361 information directly to a node (MN) 362 [I-D.giaretta-mip6-authorization-eap] 363 [I-D.le-aaa-mipv6-requirements] 364 [I-D.ohnishi-mip6-aaa-problem-statement]. 366 (b) Using network access AAA to deliver Mobile IPv6 bootstrapping 367 information to the network access server (NAS) 368 [I-D.chowdhury-mip6-bootstrap-radius]. It is assumed that the 369 information is delivered from NAS to the MN via some additional 370 protocol [I-D.jang-dhc-haopt] 372 (c) Piggybacking Mobile IPv6 signaling with network access AAA 373 [I-D.le-aaa-mipv6-requirements] This approach assumes that the AAA 374 servers for network access and Mobile IPv6 services are the same. 376 6. Security Considerations 378 The framework defined in this document is aligned with the AAA 379 backend protocols and the existing AAA applications. Therefore there 380 are no new security considerations stemming from the general 381 framework. 383 Details of the authorization are Mobile IPv6 specific. Exact 384 parameters, their semantics and processing details must be described 385 in an implementation of this framework. 387 7. Acknowledgements 389 Thanks to Kent Leung and Alpesh Patel for useful feedback. 391 8. References 393 8.1 Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 8.2 Informative References 400 [I-D.chowdhury-mip6-bootstrap-radius] 401 Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile 402 IPv6 bootstrapping", 403 draft-chowdhury-mip6-bootstrap-radius-01 (work in 404 progress), November 2004. 406 [I-D.giaretta-mip6-authorization-eap] 407 Giaretta, G., "MIPv6 Authorization and Configuration based 408 on EAP", draft-giaretta-mip6-authorization-eap-02 (work in 409 progress), October 2004. 411 [I-D.ietf-aaa-diameter-mobileip] 412 Calhoun, P., Johansson, T., Perkins, C. and T. Hiller, 413 "Diameter Mobile IPv4 Application", 414 draft-ietf-aaa-diameter-mobileip-20 (work in progress), 415 August 2004. 417 [I-D.ietf-aaa-diameter-nasreq] 418 Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 419 Network Access Server Application", 420 draft-ietf-aaa-diameter-nasreq-17 (work in progress), July 421 2004. 423 [I-D.ietf-aaa-diameter-sip-app] 424 Garcia-Martin, M., "Diameter Session Initiation Protocol 425 (SIP) Application", draft-ietf-aaa-diameter-sip-app-06 426 (work in progress), February 2005. 428 [I-D.ietf-mip6-auth-protocol] 429 Leung, K., "Authentication Protocol for Mobile IPv6", 430 draft-ietf-mip6-auth-protocol-04 (work in progress), 431 February 2005. 433 [I-D.ietf-mip6-bootstrap-ps] 434 Patel, A., "Problem Statement for bootstrapping Mobile 435 IPv6", draft-ietf-mip6-bootstrap-ps-01 (work in progress), 436 October 2004. 438 [I-D.ietf-mip6-mipv6-mib] 439 Keeni, G., Nagami, K., Koide, K. and S. Gundavelli, 440 "Mobile IPv6 Management Information Base", 441 draft-ietf-mip6-mipv6-mib-06 (work in progress), January 442 2005. 444 [I-D.jang-dhc-haopt] 445 Yegin, A., "DHCP Option for Home Agent Discovery in 446 MIPv6", draft-jang-dhc-haopt-00 (work in progress), June 447 2004. 449 [I-D.le-aaa-mipv6-requirements] 450 Faccin, S., "Mobile IPv6 Authentication, Authorization, 451 and Accounting Requirements", 452 draft-le-aaa-mipv6-requirements-03 (work in progress), 453 February 2004. 455 [I-D.ohnishi-mip6-aaa-problem-statement] 456 Ohnishi, H., "Mobile IPv6 AAA Problem Statement", 457 draft-ohnishi-mip6-aaa-problem-statement-00 (work in 458 progress), February 2004. 460 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 461 "Remote Authentication Dial In User Service (RADIUS)", RFC 462 2865, June 2000. 464 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 465 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 467 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 468 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 469 3748, June 2004. 471 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 472 in IPv6", RFC 3775, June 2004. 474 [RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 475 Protect Mobile IPv6 Signaling Between Mobile Nodes and 476 Home Agents", RFC 3776, June 2004. 478 Author's Address 480 Alper E. Yegin 481 Samsung Advanced Institute of Technology 482 75 West Plumeria Drive 483 San Jose, CA 95134 484 USA 486 Phone: +1 408 544 5656 487 EMail: alper.yegin@samsung.com 489 Intellectual Property Statement 491 The IETF takes no position regarding the validity or scope of any 492 Intellectual Property Rights or other rights that might be claimed to 493 pertain to the implementation or use of the technology described in 494 this document or the extent to which any license under such rights 495 might or might not be available; nor does it represent that it has 496 made any independent effort to identify any such rights. Information 497 on the procedures with respect to rights in RFC documents can be 498 found in BCP 78 and BCP 79. 500 Copies of IPR disclosures made to the IETF Secretariat and any 501 assurances of licenses to be made available, or the result of an 502 attempt made to obtain a general license or permission for the use of 503 such proprietary rights by implementers or users of this 504 specification can be obtained from the IETF on-line IPR repository at 505 http://www.ietf.org/ipr. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights that may cover technology that may be required to implement 510 this standard. Please address the information to the IETF at 511 ietf-ipr@ietf.org. 513 Disclaimer of Validity 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 518 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 519 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 520 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Copyright Statement 525 Copyright (C) The Internet Society (2005). This document is subject 526 to the rights, licenses and restrictions contained in BCP 78, and 527 except as set forth therein, the authors retain all their rights. 529 Acknowledgment 531 Funding for the RFC Editor function is currently provided by the 532 Internet Society.