idnits 2.17.1 draft-ietf-mip4-radius-requirements-04.txt: 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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 390. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Enhancing security properties of RADIUS are a specific non-goal for the RADIUS extensions providing support for Mobile IP. Also, as this is a requirement document and not a solution specification document, no new security considerations aside from those that already exist for RADIUS are noted. As such, the existing RADIUS security considerations described previously apply, and no additional security considerations are added here. For instance, the assumption in RADIUS is that intermediary nodes are trusted, while at the same time there is a concern on using AAA protocols that use hop by hop security to distribute keys. Use of hop by hop security for key distribution can be in conflict with some of the requirements stated in [housley-aaa-key-mgmt], such as the requirement on binding a key to its context and the requirement on limitation of the key scope. The former for instance states that a key Must be bound to the parties that are expected to have access to the keying material, while the latter implies that parties that do not require access to a key to perform their role MUST not have access to the key. Both of these requirements rule against trusting intermediary nodes and proxies with distribution of keys. Due to lack of end to end security mechanisms for RADIUS, imposing a MUST requirement for not trusting proxies is not possible. RADIUS extension working group is in the process of specifying procedures for wrapping key materials within RADIUS attributes. For the time being, support of Mobile IP within RADIUS may need to be based on trust of intermediaries, despite the security considerations described. -- 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 (July 20, 2007) is 6125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nakhjiri, Ed. 3 Internet-Draft Huawei USA 4 Intended status: Informational K. Chowdhury 5 Expires: January 21, 2008 Starent Networks 6 A. Lior 7 Bridgewater Systems 8 K. Leung 9 Cisco Systems 10 July 20, 2007 12 Mobile IPv4 RADIUS requirements 13 draft-ietf-mip4-radius-requirements-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 21, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document provides an applicability statement as well as a scope 47 definition for specifying RADIUS extensions to support Mobile IPv4. 48 The goal is to allow specification of RADIUS attributes to assist the 49 Mobile IPv4 signaling procedures. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6. Security considerations . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . . . 10 68 1. Introduction 70 To kick start the Mobile IPv4 [RFC3344] processing of its packets by 71 Mobile IP agents, a mobile node (MN) needs to be able to acquire a 72 pair of home and care of addresses (HoA and CoA, respectively), find 73 a willing agent to act as a Home Agent, HA, for the MN and perform a 74 registration process with the HA. The registration process consists 75 of an exchange of a registration request and reply message between 76 the MN and the HA. The specification in [RFC3344] allows an MN to 77 start the registration process prior to having acquired its home 78 address or the address of its HA. Acquiring those parameters by the 79 MN is typically part of a process referred to as bootstrapping. 81 Successful processing of registration requests, and replies among 82 other things depends on successful creation and verification of a 83 number of authentication extensions developed specifically to protect 84 the integrity and security of the registration requests and replies 85 and the entities processing them, i.e. MN, HA and some times, 86 foreign agents, FA [RFC3344]. Creation as well as verification of 87 these extensions requires existence of trust relationships and shared 88 keys between MN and each of the mobility agents. However, creation 89 of these trust relationships, typically referred to as mobility 90 security associations, MSA, is considered outside scope of the base 91 Mobile IPv4 specification defined in [RFC3344]. It is desired to 92 avoid the scalability issues arising from creating static security 93 associations between an MN and all possible mobility agents. Thus it 94 is preferred to establish the associations dynamically using the pre- 95 existing relationship between the MN and the AAA server. 97 To allow for utilization of an existing AAA infrastructure in the 98 bootstrapping of the Mobile IPv4 parameters and security 99 relationships, the Mobile IPv4 working group has developed extensions 100 to allow the MN to authenticate to the home AAA server [RFC4721] and 101 to request assistance from the AAA server in creation of security 102 associations [RFC3957] with the mobility agents, all based on the 103 pre-established trust relationship between the MN and its home AAA 104 server. 106 However, utilization of the AAA infrastructure for Mobile IPv4 107 purposes, involves both Mobile IP and AAA signaling, where the 108 interaction between the MN and the mobility agents (HA and FA) is 109 based on Mobile IP signaling, while the signaling beyond the mobility 110 agents to the AAA server is based on AAA protocols. Around the same 111 time, when the specification was being developed, the AAA community 112 was in the process of designing Diameter as a successor to RADIUS. 113 Thus, the Mobile IP group developed a set of guidelines and 114 requirements specifically from Mobile IP standpoint [RFC2977] for 115 such a successor. These requirements, led to development of an 116 specification for use of Diameter in Mobile IPv4 bootstrapping 117 [RFC4004], while the requirement document is essentially standardized 118 [RFC2977] after standardization of RADIUS [RFC2865] 120 Thus it is obvious that RADIUS does not and cannot meet all the 121 requirements listed In [RFC2977] without undergoing an extensive 122 design change and thus no RADIUS attributes have been standardized 123 for Mobile IP support thus far. However, in the absence of IETF 124 standardized RADIUS attributes for support of MIPv4, different 125 wireless SDOs have taken the path of developing VSAs for dynamic 126 bootstrapping of Mobile IPv4 registration procedure. The use of 127 different VSAs and different RADIUS procedures for the same purpose 128 of Mobile IPv4 bootstrapping at different SDOs will cause a lack 129 interoperability between these wireless standards, potentially 130 hindering mobility across these wireless networks. 132 To respond to the described issue, it is desired to standardize a set 133 of RADIUS attributes within IETF to allow a consistent and 134 interoperable interaction with RADIUS based AAA infrastructure during 135 the Mobile IPv4 Registration procedure. The bootstrapping attributes 136 can include configuration parameters as well as material used for 137 provisioning security of Mobile IPv4 messaging (authentication) as 138 defined by [RFC4721] and [RFC3957]. 140 Given that RADIUS as it stands today cannot meet all the requirements 141 in [RFC2977], the purpose of this requirement is to define a set of 142 goals and nongoals specifically defined for RADIUS when it comes to 143 assisting mobile nodes and mobility agents in bootstrapping Mobile 144 IPv4 operation. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 3. Goals and Non-Goals 154 Since this document serves as requirement specification for RADIUS 155 extensions supporting Mobile IPv4 interaction with RADIUS 156 infrastructure, the goals and non-goals refer to only those RADIUS 157 extensions that are required for support of Mobile IPv4. 159 3.1. Goals 161 The scope of the work is to standardize RADIUS attributes and to 162 define the procedure by which the Mobile IPv4 agents, e.g. Home 163 agent (HA) and Foreign Agent (FA) map the Mobile IP registration 164 message fields into the proposed RADIUS attributes and vice versa. 165 o It is required of the RADIUS servers to be able to understand and 166 process the attributes to be defined for Mobile IPv4 support and 167 to perform verification of authentication extensions specified in 168 [RFC4721]. RADIUS proxies are expected to be able to forward 169 messages including the Mobile IPv4 related attributes as they 170 would with any other RADIUS messages and attributes. 171 o All RADIUS work MUST be backward compatible with existing RADIUS 172 RFCs, including RFCs as follows: [RFC2865], [RFC2866], [RFC2867], 173 [RFC2868], [RFC2869], [RFC3576], [RFC3579], and [RFC3580]. 174 o It is also required of the Mobile IP agents (FA and HA) to operate 175 as RADIUS clients (NASes in context of [RFC2865]) when translating 176 RADIUS signaling into Mobile IP signaling and vice versa. Details 177 on the behavior of Mobile IP agents as RADIUS clients are to be 178 provided by the solution draft describing the RADIUS extensions 179 for Mobile IP support. 181 3.2. Non-Goals 183 The scope of this work is to only standardize RADIUS attributes and 184 to define the procedure by which the Mobile IPv4 agents, e.g. Home 185 agent (HA) and Foreign Agent (FA) map the Mobile IP registration 186 message fields into the proposed RADIUS attributes and vice versa. 187 It is not the intention to extend the functionality of existing 188 RADIUS servers or protocol. More specifically, the following are 189 NON-GOALS: 190 o Enhancing RADIUS Security: Creating new security properties for 191 RADIUS, such as creating key transport capabilities is not the 192 goal. No new security mechanisms are to be defined for the 193 transport of RADIUS Access Requests in relation to support of 194 Mobile IPv4 bootstrapping. Existing RADIUS authentication 195 procedures, e.g. Message-Authenticator (80) described in 196 [RFC2869], are used. The security considerations for use of 197 RADIUS in bootstrapping Mobile IPv4 are described in a later 198 section of this document. 199 o Enhancing RADIUS transport reliability: Transport properties of 200 RADIUS remain intact. No new reliability mechanisms are defined 201 in the transport of such Access Requests. 202 o Extending RADIUS message set: RADIUS extensions for bootstrapping 203 Mobile IPv4 are not to define new RADIUS messages. Diameter 204 Mobile IP application [RFC4004] has defined new command codes for 205 support of Mobile IP signaling, depending on whether Diameter 206 server is dealing with a Mobile IP HA or an FA. RADIUS currently 207 does not have any messages that correspond to these Diameter 208 commands. Instead, RADIUS extensions for Mobile IPv4 209 bootstrapping need to provide proposals for new RADIUS attributes 210 that facilitates Diameter-RADIUS messaging translation without 211 defining any new RADIUS messaging. At the same time, the RADIUS 212 extensions for Mobile IPv4 need to re-use Diameter AVPs to the 213 fullest extent possible. 214 o RFC2977 compatibility: Extending RADIUS in a way that fulfills the 215 full list of requirements in [RFC2977] will not be attempted. 217 4. Attributes 219 A specification of the RADIUS extensions for Mobile IPv4 needs to 220 describe the full set of attributes required for RADIUS-Mobile IP 221 interaction. While some of the attributes may already be 222 standardized, others will require standardization and IANA type 223 assignments. 225 5. IANA Considerations 227 This requirement document does not allocate any numbers, so there are 228 no IANA considerations. On the other hand, solution documentations 229 for RADIUS support of Mobile IPv4 will likely introduce new RADIUS 230 attributes. Thus those documents will need new attribute type 231 numbers assigned by IANA. 233 6. Security considerations 235 Enhancing security properties of RADIUS are a specific non-goal for 236 the RADIUS extensions providing support for Mobile IP. Also, as this 237 is a requirement document and not a solution specification document, 238 no new security considerations aside from those that already exist 239 for RADIUS are noted. As such, the existing RADIUS security 240 considerations described previously apply, and no additional security 241 considerations are added here. For instance, the assumption in 242 RADIUS is that intermediary nodes are trusted, while at the same time 243 there is a concern on using AAA protocols that use hop by hop 244 security to distribute keys. Use of hop by hop security for key 245 distribution can be in conflict with some of the requirements stated 246 in [housley-aaa-key-mgmt], such as the requirement on binding a key 247 to its context and the requirement on limitation of the key scope. 248 The former for instance states that a key Must be bound to the 249 parties that are expected to have access to the keying material, 250 while the latter implies that parties that do not require access to a 251 key to perform their role MUST not have access to the key. Both of 252 these requirements rule against trusting intermediary nodes and 253 proxies with distribution of keys. Due to lack of end to end 254 security mechanisms for RADIUS, imposing a MUST requirement for not 255 trusting proxies is not possible. RADIUS extension working group is 256 in the process of specifying procedures for wrapping key materials 257 within RADIUS attributes. For the time being, support of Mobile IP 258 within RADIUS may need to be based on trust of intermediaries, 259 despite the security considerations described. 261 When it comes to protecting attributes in Access Request, [RFC2868] 262 section 3.5 provides a mechanism for encrypting RADIUS attributes, 263 such as passwords. There is also work under progress for specifying 264 wrapping of sensitive attributes, such as key material within RADIUS 265 Access Accept messages. This work is currently considered as part of 266 RADIUS crypto-agility extensions and when completed can be used in 267 the process of distributing sensitive attributes, such as keying 268 material from RADIUS servers. 270 It is also possible to protect RADIUS transactions using IPsec (e.g. 271 as in RFC3579). 273 7. Acknowledgements 275 The authors would like to thank Alan DeKok for review and feedback, 276 Pete McCann and Jari Arkko for diligent shepherding of this document. 278 8. References 280 8.1. Normative References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", March 1997. 285 [RFC2865] Rigney, C., "Remote Authentication Dial In User Service", 286 June 2000. 288 [RFC2866] Rigney, C., "RADIUS Accounting", June 2000. 290 [RFC2867] Zorn, G., "Remote Accounting Modification for Tunnel 291 Protocol Support", June 2000. 293 [RFC2977] Glass, S. and Perkins, "Mobile IP Authentication, 294 Authorization, and Accounting Requirements", October 2000. 296 [RFC3344] Perkins, C., "IP Mobility Support", August 2002. 298 [RFC3957] Perkins, C. and P. Calhoun, "AAA Registration Keys for 299 Mobile IP", March 2005. 301 [RFC4004] Calhoun, P. and C. Perkins, "Diameter Mobile IP 302 application", May 2004. 304 [RFC4721] Perkins, C. and P. Calhoun, "Mobile IP Challenge/Response 305 Extensions (Revised)", January 2007. 307 [housley-aaa-key-mgmt] 308 Housley, R., "Guidance for AAA key management", 309 draft-housley-aaa-key-mgmt-09 (work in progress). 311 8.2. Informative References 313 [RFC2868] Zorn, G., "RADIUS Attributes for Tunnel Protocol Support", 314 June 2000. 316 [RFC2869] Rigney, C., "RADIUS Extensions", June 2000. 318 [RFC3576] Chiba, M., "Dynamic Authorization Extensions to Remote 319 Authentication Dial In User Service (RADIUS)", July 2003. 321 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 322 Dial In User Service) Support For Extensible 323 Authentication Protocol (EAP)", September 2003. 325 [RFC3580] Cogdon, P., "IEEE 802.1X Remote Authentication Dial In 326 User Service (RADIUS) Usage Guidelines", September 2003. 328 Authors' Addresses 330 Madjid Nakhjiri (editor) 331 Huawei USA 333 Email: mnakhjiri@huawei.com 335 Kuntal Chowdhury 336 Starent Networks 338 Email: kchowdhury@starentnetworks.com 339 Avi Lior 340 Bridgewater Systems 342 Email: avi@bridgewatersystems.com 344 Kent Leung 345 Cisco Systems 346 170 West Tasman Drive 347 San Jose, CA 95134 348 US 350 Email: kleung@cisco.com 352 Full Copyright Statement 354 Copyright (C) The IETF Trust (2007). 356 This document is subject to the rights, licenses and restrictions 357 contained in BCP 78, and except as set forth therein, the authors 358 retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Intellectual Property 370 The IETF takes no position regarding the validity or scope of any 371 Intellectual Property Rights or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; nor does it represent that it has 375 made any independent effort to identify any such rights. Information 376 on the procedures with respect to rights in RFC documents can be 377 found in BCP 78 and BCP 79. 379 Copies of IPR disclosures made to the IETF Secretariat and any 380 assurances of licenses to be made available, or the result of an 381 attempt made to obtain a general license or permission for the use of 382 such proprietary rights by implementers or users of this 383 specification can be obtained from the IETF on-line IPR repository at 384 http://www.ietf.org/ipr. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights that may cover technology that may be required to implement 389 this standard. Please address the information to the IETF at 390 ietf-ipr@ietf.org. 392 Acknowledgment 394 Funding for the RFC Editor function is provided by the IETF 395 Administrative Support Activity (IASA).