idnits 2.17.1 draft-chowdhury-mip6-bootstrap-radius-01.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 472. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 489), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 196: '... The attributes MAY be present in Acc...' RFC 2119 keyword, line 358: '... This attribute MUST NOT be present....' RFC 2119 keyword, line 359: '...ance of this attribute MAY be present....' RFC 2119 keyword, line 364: '... such as [MIP6-DHC-AGENTOP] the MN MUST check whether the parameter...' RFC 2119 keyword, line 366: '... MUST compute a secure hash as follo...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 26, 2004) is 7121 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) -- Possible downref: Normative reference to a draft: ref. 'MIP6-DHC-AGENTOP' ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Chowdhury 2 Internet-Draft Nortel Networks 3 Expires: April 26, 2005 A. Lior 4 Bridgewater Systems 5 October 26, 2004 7 RADIUS Attributes for Mobile IPv6 bootstrapping 8 draft-chowdhury-mip6-bootstrap-radius-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document defines new attributes to facilitate Mobile IPv6 42 bootstrapping via a RADIUS infrastructure. In an access network 43 where the user attaches to get IPv6 access, there may be a Network 44 Access Server (NAS) or an Access Gateway that will require 45 authentication and authorization. In some cases, this type of access 46 authentication takes place via RADIUS infrastructure. As part of the 47 authentication setup the NAS may receive useful configuration 48 information from the home RADIUS server of the user. In case of 49 Mobile IPv6 access, the Home RADIUS server may assign various 50 information relevant to the user's device for bootstrapping. 52 Table of Contents 54 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2 Home Link Prefix . . . . . . . . . . . . . . . . . . . . . 5 58 2.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4 Authenticity payload . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. RADIUS attributes to carry Mobile IPv6 parameters . . . . . . 7 62 4.1 Home Agent Attribute . . . . . . . . . . . . . . . . . . . 7 63 4.2 Home Link Prefix Attribute . . . . . . . . . . . . . . . . 8 64 4.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.4 MIP6 Parameter Authenticity Attribute . . . . . . . . . . 9 66 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 11 67 6. MN Considerations . . . . . . . . . . . . . . . . . . . . . . 12 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 71 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . . 16 75 1. Motivation 77 Mobile IPv6 specification [RFC3775] requires a Mobile Node (MN) to 78 perform registration with a Home Agent with information about its 79 current point of attachment (Care-of Address). The Home Agent 80 creates and maintains binding between the MN's Home Address and the 81 MN's Care-of Address. 83 In order to register with a Home Agent, the MN needs to know 84 information such as, the Home Link prefix, the Home Agent Address, 85 the Home Address, the Home Link prefix Length etc. 87 The aforementioned set of information may be statically provisioned 88 in the MN. However, static provisioning of this information has its 89 drawbacks. It increases provisioning and network maintenance burden 90 for the operator. Moreover, static provisioning does not allow load 91 balancing, failover, opportunistic home link assignment etc. For 92 example, the user may be accessing the network from a location that 93 may be geographically far away from the preconfigured home link; or 94 the cost of the link between the NAS and the Home Link is too great. 95 In these situations static provisioning may not be desirable. 97 Dynamic assignment of Mobile IPv6 home registration information is a 98 desirable feature for ease of deployment and network maintenance. 99 For this purpose, the RADIUS infrastructure, which is used for access 100 authentication, can be leveraged to assign some or all of the 101 necessary parameters. The RADIUS server in the Serving or Home 102 Mobility Service Provider's network (RADIUS-MIP) may return these 103 parameters to the NAS. 105 The NAS may convey the received information to the MN using various 106 techniques. One such technique may utilize the role of the NAS as a 107 relay agent for Dynamic Host Configuration Protocol. In this case, 108 upon receiving the information from the RADIUS-MIP server, the NAS 109 forwards the set of parameters to the DHCP Client along with REPLY or 110 ADVERTISE messages [MIP6-DHC-AGENTOP]. 112 2. Overview 114 | 115 Access Service Provider | Serving or Home Mobility 116 | Service Provider 117 | 118 +-------+ | +-------+ 119 | | | | | 120 |Access |----------|--------|RADIUS | 121 |RADIUS | | | -MIP | 122 | | | | | 123 +-------+ | +-------+ 124 | | 125 | | 126 | | 127 | | 128 | | 129 | | 130 | | 131 +-----+ | +-----+ 132 +----+ | | | | Home| 133 | MN |--------------| NAS/| | |Agent| 134 +----+ |Relay| | | | 135 +----- 136 + | +-----+ 138 In the typical Mobile IPv6 access scenario as shown above, the MN 139 attaches in a Access Service Provider's network. During this attach 140 procedure, the NAS or the Access Router authenticates and authorizes 141 the MN for IPv6 access service. In the scenario shown, the 142 authentication and authorization happens via a RADIUS infrastructure. 144 At the time of authorizing the user for IPv6 access, the RADIUS 145 server in the Home or Serving Mobility Service Provider's (MSP) 146 network (RADIUS-MIP) detects that the user is authorized for Mobile 147 IPv6 access. Based on the MSP's policy, the RADIUS-MIP server may 148 allocate several parameters to the MN for use during the subsequent 149 Mobile IPv6 registration. A list of such parameters is described in 150 the following sub sections. 152 2.1 Home Agent 154 The Home or the Serving MSP may decide to assign a Home Agent to the 155 MN that is in close proximity to the point of attachment (e.g. 156 determined by the NAS-ID). There may be other reasons for assigning 157 Home Agents to the MN, e.g. load sharing in the network. The 158 attribute also contains the prefix length so that the MN can easily 159 infer the Home Link prefix from the Home Agent address. 161 2.2 Home Link Prefix 163 For the same reason as the HA assignment, the Home or the Serving MSP 164 may assign a Home Link that is in close proximity to the point of 165 attachment (NAS-ID). The MN can perform [RFC3775] specific 166 procedures to discover other information for Mobile IPv6 167 registration. 169 2.3 Home Address 171 The RADIUS-MIP server may assign a Home Address to the MN. This 172 allows the network operator to support mobile devices that are not 173 configured with static addresses. The attribute also contains the 174 prefix length so that the MN can easily infer the Home Link prefix 175 from the Home Agent address. 177 2.4 Authenticity payload 179 The RADIUS-MIP server includes a secure hash of all the MIP6 related 180 assigned parameters. The secure hash is computed with the shared 181 secret that the RADIUS-MIP has with the MN. This helps maintain the 182 integrity of the assigned values while the Access Service Provider 183 and the Mobility Service Provider do not a share trust relationship. 185 3. Terminology 187 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 189 this document are to be interpreted as described in RFC 2119. 191 4. RADIUS attributes to carry Mobile IPv6 parameters 193 This section defines format and syntax for the attribute that carries 194 the Mobile IPv6 parameters described in section 2. 196 The attributes MAY be present in Access-Accept, Accounting-Request. 198 4.1 Home Agent Attribute 200 This attribute is sent by the RADIUS-MIP server to the NAS in an 201 Access-Accept message. The attribute carries the assigned Home Agent 202 address. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | Reserved | Prefix-Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 | | 211 | IPv6 address of assigned Home Agent | 212 | | 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Type: 218 ASSIGNED-HA-TYPE to be defined by IANA. 220 Length: 222 = 20 octets 224 Reserved: 226 Reserved for future use. All bits set to 0. 228 Prefix-Length: 230 This field indicates the prefix length of the Home Link. 232 IPv6 address of assigned Home Agent: 234 128-bit IPv6 address of the assigned Home Agent. 236 4.2 Home Link Prefix Attribute 238 This attribute is sent by the RADIUS-MIP server to the NAS in an 239 Access-Accept message. The attribute carries the assigned Home Link 240 prefix. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type | Length | Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 | | 249 | Home Link Prefix | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Type: 255 ASSIGNED-HL-TYPE to be defined by IANA. 257 Length: 259 >= 4 octets + the minimum length of a prefix. 261 Reserved: 263 Reserved for future use. All bits set to 0. 265 Home Link Prefix: 267 Home Link prefix (upper order bits) of the assigned Home Link 268 where the MN should send binding update. 270 4.3 Home Address 272 This attribute is sent by the RADIUS server to the NAS in an 273 Access-Accept message. The attribute carries the assigned Home IPv6 274 Address for the MN. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | Reserved | Prefix-Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 | | 283 | Assigned IPv6 Home Address | 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Type: 289 ASSIGNED-HOA-TYPE to be defined by IANA. 291 Length: 293 = 20 octets. 295 Reserved: 297 Reserved for future use. All bits set to 0. 299 Prefix-Length: 301 This field indicates the prefix length of the Home Link. 303 Assigned IPv6 Home Address: 305 IPv6 Home Address that is assigned to the MN. 307 4.4 MIP6 Parameter Authenticity Attribute 309 This attribute is sent by the RADIUS-MIP server to the NAS in an 310 Access-Accept message. The attribute carries a authenticator to 311 validate the integrity of the MIP6 parameters that are assigned by 312 the RADIUS-MIP server. The authenticator is calculated by taking 313 HMAC-SHA-1 of the all the MIP6 related assigned parameter values and 314 a shared secret that the RADIUS-MIP server has for the MN. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type | Length | Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 | | 323 | Authenticator | 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Type: 329 MIP6-PARM-AUTH-TYPE to be defined by IANA. 331 Length: 333 = 20 octets. 335 Reserved: 337 Reserved for future use. All bits set to 0. 339 Authenticator: 341 HMAC-SHA-1 (shared secret between the MN and the RADIUS-MIP, 342 assigned MIP6 values). 344 5. Table of Attributes 346 The following table provides a guide to which attributes may be found 347 in RADIUS message and in what number. 349 Request Accept Reject Challenge # Attribute 350 0 0-1 0 0 TBD Home Agent 351 0 0-1 0 0 TBD Home Link Prefix 352 0 0-1 0 0 TBD Home Address 353 0 0-1 0 0 TBD MIP6 Parameter 354 Authenticity 356 The following table defines the meaning of the above table entries. 358 0 This attribute MUST NOT be present. 359 0-1 Zero or one instance of this attribute MAY be present. 361 6. MN Considerations 363 Upon receiving the MIP6 parameters from the network via mechanisms 364 such as [MIP6-DHC-AGENTOP] the MN MUST check whether the parameter 365 set contains the MIP6 Parameter Authenticity value. If yes, the MN 366 MUST compute a secure hash as following: 368 HMAC-SHA-1 (shared secret between the MN and the RADIUS-MIP, received 369 MIP6 values) 371 The MN matchs the output of the above hash with the MIP6 Parameter 372 Authenticity value received from the network. If the values match 373 the MN accept the received MIP6 parameters to be from a trusted 374 source. If the comparison results in a mismatch, the MN MUST 375 silently discard the received MIP6 parameters. 377 If the received MIP6 parameter set does not contain the MIP6 378 Parameter Authenticity value, the MN MAY accept the received MIP6 379 parameters. 381 7. Security Considerations 383 Assignment of these values to a user should be based on successful 384 authentication of the user's access at the NAS. The RADIUS-MIP 385 server should only assign these values to an user who is authorized 386 for Mobile IPv6 service (this check could be performed with the 387 user's subscription profile in the Home Network). 389 The NAS to the Home RADIUS server transactions must be adequately 390 secured. Otherwise there is a possibility that the user may receive 391 fraudulent values from a rogue RADIUS server potentially hijacking 392 the user's Mobile IPv6 session. 394 If the RADIUS-MIP server has a shared secret with the MN, the 395 RADIUS-MIP server MUST include the MIP6 Parameter Authenticity 396 attribute while assigning other MIP6 bootstrap information to the MN. 397 This enables the MN to verify that the received MIP6 bootstrap 398 information is from a trusted source. 400 These new attributes do not involve additional security 401 considerations besides the one identified in [RFC2865]. 403 8. IANA Considerations 405 The RADIUS attribute types: ASSIGNED-HA-TYPE, ASSIGNED-HL-TYPE, 406 ASSIGNED-HOA-TYPE, and MIP6-PARM-AUTH-TYPE MUST be assigned by IANA. 408 9. Acknowledgements 410 Thanks to the following individuals for their review and constructive 411 comments during the development of this document: 413 Mark Watson, Jayshree Bharatia. 415 10 Normative References 417 [MIP6-DHC-AGENTOP] 418 Chowdhury et. al., K., "DHCP Relay Agent Option to Support 419 Mobile IPv6 bootstrapping", 420 draft-chowdhury-dhc-mip6-agentop-00.txt (work in 421 progress), October 2004. 423 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 424 "Remote Authentication Dial In User Service (RADIUS)", RFC 425 2865, June 2000. 427 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 428 in IPv6", RFC 3775, June 2004. 430 Authors' Addresses 432 Kuntal Chowdhury 433 Nortel Networks 434 2221 Lakeside Blvd. 435 Richardson, TX 75082 436 US 438 Phone: +1 972-685-7788 439 EMail: chowdury@nortelnetworks.com 441 Avi Lior 442 Bridgewater Systems 443 303 Terry Fox Drive, Suite 100 444 Ottawa, Ontario 445 Canada K2K 3J1 447 Phone: +1 613-591-6655 448 EMail: avi@bridgewatersystems.com 450 Intellectual Property Statement 452 The IETF takes no position regarding the validity or scope of any 453 Intellectual Property Rights or other rights that might be claimed to 454 pertain to the implementation or use of the technology described in 455 this document or the extent to which any license under such rights 456 might or might not be available; nor does it represent that it has 457 made any independent effort to identify any such rights. Information 458 on the procedures with respect to rights in RFC documents can be 459 found in BCP 78 and BCP 79. 461 Copies of IPR disclosures made to the IETF Secretariat and any 462 assurances of licenses to be made available, or the result of an 463 attempt made to obtain a general license or permission for the use of 464 such proprietary rights by implementers or users of this 465 specification can be obtained from the IETF on-line IPR repository at 466 http://www.ietf.org/ipr. 468 The IETF invites any interested party to bring to its attention any 469 copyrights, patents or patent applications, or other proprietary 470 rights that may cover technology that may be required to implement 471 this standard. Please address the information to the IETF at 472 ietf-ipr@ietf.org. 474 Disclaimer of Validity 476 This document and the information contained herein are provided on an 477 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 478 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 479 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 480 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 481 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 482 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 484 C 485 opyright Statement 487 Copyright (C) The Internet Society (2004). This document is subject 488 to the rights, licenses and restrictions contained in BCP 78, and 489 except as set forth therein, the authors retain all their rights. 491 Acknowledgment 493 Funding for the RFC Editor function is currently provided by the 494 Internet Society.