idnits 2.17.1 draft-ietf-mobileip-radius-challenge-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 368 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [6], [8], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 94: '... o MUST, SHALL, or MANDATORY -...' RFC 2119 keyword, line 97: '... o SHOULD or RECOMMEND -- This...' RFC 2119 keyword, line 100: '... o MAY or OPTIONAL -- This ite...' RFC 2119 keyword, line 218: '... Authenticator, MUST be at least 20....' RFC 2119 keyword, line 236: '...Each mobile node MUST support the abil...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 91 has weird spacing: '...e items of...' == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (June 1999) is 9081 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) == Unused Reference: '3' is defined on line 315, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 319, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-07 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-02 ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-02 ** Obsolete normative reference: RFC 2138 (ref. '7') (Obsoleted by RFC 2865) -- Possible downref: Normative reference to a draft: ref. '8' Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Yingchun Xu 2 Ken Peirce 3 Ed Campbell 4 INTERNET DRAFT 3Com Corporation 5 Category: Internet Draft 6 Title: draft-ietf-mobileip-radius-challenge-00.txt 7 Date: June 1999 9 Mechanism to Support CHAP Mobile Node Authentication 10 for RADIUS/DIAMETER Hybrid AAA Networks 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full 16 conformance with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them 26 other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 To learn the current status of any Internet-Draft, please 35 check the ``1id-abstracts.txt'' listing contained in the 36 Internet-Drafts Shadow Directories on ftp.is.co.za 37 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 38 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 39 West Coast). Distribution of this memo is unlimited. 41 Abstract 43 Mobile IP Authentication is a requirement for the TR 45.6 44 CDMA wireless packet data service architecture[8]. 45 Diameter AAA, as described in [1] and [2], is used to 46 support Mobile IP authentication. This requires that both 47 the foreign and home network deploy Diameter servers. 48 Currently, RADIUS servers have been deployed and are 49 widely used in the Internet Service Provider(ISP) 50 arena.While DIAMETER is required to provide the advanced 51 AAA support required by the TR 45.6 architecture, a smooth 52 transition from RADIUS AAA to Diameter AAA is required. At 53 a minimum,the Diameter AAA server located in a foreign 54 network must inter-operate with RADIUS AAA located in Home 55 Network. 57 In this specification, a new SPI is specified to support 58 Home RADIUS and Foreign DIAMETER AAA interaction. The 59 specification requires extensions as specified in [6]. 61 Applicability 63 This specification is intended for those DIAMETER servers 64 that wish to interoperate with current RADIUS servers using 65 PPP CHAP authentication. 67 1.0 Introduction 69 Diameter AAA, as described in [1] and [2] supports Mobile IP 70 authentication. This requires both foreign network and home 71 network to deploy Diameter servers. Currently, RADIUS servers 72 have been deployed and are used widely in the Internet. To 73 support a smooth transition from RADIUS AAA to Diameter AAA, 74 the minimum requirement is for the Diameter AAA server 75 located in foreign network to inter-operate with RADIUS AAA 76 located in Home Network. 78 In this specification, a new SPI is specified to support Home 79 RADIUS AAA in Mobile IP service. The specification requires 80 extensions as specified in [6]. A default algorithm is 81 described in [6] for computation of the authenticator field 82 from the MN-AAA Authentication Extension. The default 83 algorithm calculates the authenticator by using MD5 in 84 "prefix+suffix" mode.In this specification, a new SPI is 85 specified to support CHAP authentication. This algorithm 86 calculates the MN-AAA authenticator field by using MD5 in 87 "Prefix Only" mode. 89 2.0 Conventions 91 The following language conventions are used in the items of 92 specification in this document: 94 o MUST, SHALL, or MANDATORY -- This item is an 95 absolute requirement of the specification. 97 o SHOULD or RECOMMEND -- This item should generally 98 be followed for all but exceptional circumstances. 100 o MAY or OPTIONAL -- This item is truly optional and 101 may be followed or ignored according to the needs of 102 the implementor. 104 3.0 Acronynms ,sp1 105 mobile client(MC) - is a device that expects to be able to 106 maintain a network layer connection with its "home" network 107 despite have multiple short lived PPP connections with 108 different Foreign Agents. 110 Foreign Agent(FA) - is a device that issues advertisements, 111 via its PPP links with mobile nodes, that indicate its 112 willingness to act as an endpoint for a mobile IP tunnel. 113 Foreign Agents can change as the mobile node moves between 114 different regions. 116 Home Agent(HA) - is a device that maintains the connection 117 with the mobile node througout the mobile IP session. 119 Radio Network(RN) - The radio portion of the CDMA cellular 120 network. 122 4.0 Problem Space Overview 124 In this section we describe in high level terms the scope of 125 the problem being addressed.The two most likely scenarios to 126 encounter the problem are shown below. Figure 1 depicts a 127 mobile client(MC) connecting through a radio network(RN) to a 128 Mobile IP foreign agent(FA). The FA uses a series of DIAMETER 129 servers to handle the authorization, acquisition of the 130 client profile (QoS level etc.) , of the MC. The final 131 DIAMETER stage of the DIAMETER server chain is called a 132 broker. It is called a broker because it handles MIP sessions 133 for multiple Home networks. For example, a major carrier 134 could offer connectivity for multiple ISPs.( The CDMA and 135 Broker networks could belong to the same entity.) The Broker 136 interacts with the Home network's RADIUS server to obtain the 137 required client records. 139 Figure 2 depicts a similar scenario with the Home agent 140 functionality also out-sourced by the broker network. Note 141 that in both cases the RADIUS server is maintained by the 142 Home network. This allows the Home network operator to 143 maintain control over Home network access and relieves the 144 Broker from having to maintain client records. 146 Topologies: 147 | | 148 +----------+ | +----------+ | +--------+ 149 | DIAMETER |----|----| DIAMETER |--|--| RADIUS | 150 | Server | | | Server | | +--------+ 151 +----------+ | +----------+ | 152 | | | | 153 ------| | -------|--| 154 +--+ +---+ +-----+ | | +-------+ 155 |MN|---|RN |----|PDSN |-|------------------|--| HA | 156 | | | | | FA | | | | | 157 +--+ +---+ +-----+ | | +-------+ 158 | | 159 CDMA Provider | Broker | Home Network 160 Figure 1 162 +----------+ | +----------+ | +--------+ 163 | DIAMETER |----|----| DIAMETER |--|-| RADIUS | 164 | Server | | | Server | | +--------+ 165 +---+------+ | +----+-----+ | 166 | | | | 167 +-----| | | | 168 +--+ +---+ +-+---+ | +----+--+ | 169 |MN|---|RN |----|PDSN |-|----| HA | | 170 | | | | | FA | | | | | 171 +--+ +---+ +-----+ | +-------+ | 172 | | 173 CDMA Network | Broker | Home Network 175 Figure 2 177 The problem is that the CHAP authentication mechanism defined 178 for MIP differs from that of RADIUS.Therefore, when the 179 broker DIAMETER server attempts to perform a CHAP proxy 180 authentication with the Home network RADIUS server, it will 181 fail. 183 5.0 Challenge/Response Authentication Calculation Parameter 184 Mis-match 186 In [6],the Challenge/Response mechanism has been used to 187 support Foreign Agent Authentication and Authorization. 188 RADIUS based CHAP protocol also uses the Challenge/Response 189 mechanism. 191 The RADIUS server calculates the authenticator using MD5 on 192 the following data: 193 CHAP ID octet, KEY (or shared secret), CHAP challenge. 195 In [6], the Authenticator field from MC-AAA extension is 196 calculated by using MD5 in prefix + suffix mode over 197 following data: 199 Key || Preceding Mobile IP data || Type, Length, SPI || Key 201 This difference in the inputs to the hash function is what 202 causes the interoperability problem. In order to use CHAP and 203 inter-operate with RADIUS AAA, the MN-AAA extension is 204 defined as follows: 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type | Length | SPI ... 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 ... SPI (cont.) | Authenticator... 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 3: The MN-AAA Authentication Extension 215 Type 36 (not skippable) 217 Length 4 plus the number of bytes in the 218 Authenticator, MUST be at least 20. 220 SPI Security Parameters Index - TBD 222 Authenticator The variable length Authenticator field 223 consists of a random value of at 224 least 128 bits. 226 The algorithm for computation of the authenticator is MD5 [5] 227 computed on the following data, in the order shown: 229 Challenge-Octet || Key || Preceding Mobile IP data || Type, 230 Length, SPI 232 The Type, Length, and SPI are as shown above. The 233 Challenge-Octet is the last octet of the FA Challenge value 234 from the FA Challenge Extension. 236 Each mobile node MUST support the ability to produce the 237 authenticator by using MD5 as described above in order to 238 support Home RADIUS authentication. Again this is different 239 from the default algorithm as described in [6], which uses 240 MD5 in "prefix+suffix" mode. 242 6.0 Operation 244 In order to use a Home RADIUS server with a Diameter AAA 245 server for the first time Mobile IP registration 246 authentication as described in [1] and [2], the Mobile Node 247 and its corresponding Broker Diameter server will be 248 configured with the new SPI as described above. It is called 249 the "RADIUS Authentication SPI" 251 When a Mobile Node receives an Agent Advertisement message, 252 it MUST use the "RADIUS Authentication SPI" and the 253 corresponding algorithm to construct its Mobile Registration 254 Request message if RADIUS/DIAMETER CHAP authentication 255 interoperation is required.. 257 The FA will then send an AA-Mobile-Node-Request(AMR) message 258 to the Diameter AAA located in its serving network. 260 The Serving Diameter AAA server will then use the NAI 261 extension to locate the Broker Diameter AAA server and 262 forward it the AMR message. 264 The Broker Diameter AAA server MUST then generate a RADIUS 265 Access-Request message based on the MN-AAA Authentication 266 extension and the NAI extension. This message MUST then be 267 sent to the Home RADIUS server. 269 The Access-Request message MUST be constructed as follows: 271 The CHAP-ID octet of the RADIUS CHAP-password attribute will 272 contain the last byte of the Challenge value from MIP FA 273 Challenge extension[6]. The authenticator from the MN-AAA 274 Authentication extension MUST be used as the CHAP-Password 275 attribute. The User-Name attribute MUST be populated with the 276 user-name attribute from the AMR message. The following data 277 stream, as described earlier, MUST be included in the CHAP- 278 Challenge attribute: 280 Preceding Mobile IP data || Type, Length, SPI. 282 The RADIUS server now looks up a password based on the User- 283 Name. It then encrypts the challenge using MD5 on: 285 CHAP ID octet, locally stored password for this specific 286 User-Name, the CHAP challenge (from the CHAP-Challenge 287 attribute if present,otherwise from the Request 288 Authenticator), 290 The RADIUS server then compares this result with the CHAP- 291 Password(MN-AAA Authentication extension authenticator). If 292 these values match, the server MUST send back a RADIUS 293 Access-Accept, otherwise it MUST send back a RADIUS Access- 294 Reject. See [7] for details. 296 Upon receipt of a RADIUS Access-Accept message, the Broker 297 Diameter AAA server MUST generate a Home Agent MIP 298 Request(HAR)[1] and send it to the Home Agent. See [1] and 299 [2] for rest of the operation. 301 Upon receipt of a RADIUS Access-Reject message, the Broker 302 Diameter AAA server MUST generate an AA-Mobile-Node- 303 Answer(AMA)[1] with a result and send it back to serving 304 Diameter AAA server as described in [1] and [2]. 306 7.0 References 307 [1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP 308 Extensions. 309 draft-calhoun-diameter-mobileip-01.txt, November 1998. 310 (work in 311 progress). 312 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 313 draft-calhoun-diameter-07.txt, November 1998. (work in 314 progress). 315 [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 316 Address Identifier Extension. draft-ietf-mobileip-mn- 317 nai-02.txt, 318 May 1999. (work in progress). 319 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, 320 October 1996. 321 [5] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 322 1321, 323 April 1992. 324 [6] Charles E. Perkins and Pat R. Calhoun. Mobile IP 325 Challenge/Response Extensions. 326 draft-ietf-mobileip-challenge-02.txt, May 1999. 327 (work in progress). 328 [7] C. Rigney, etc. Remote Authentication Dial In User 329 Service (RADIUS), 330 RFC 2138, April 1997. 331 [8] Hiller et al., draft-hiller-3gwireless-00.txt, March 332 1999, 333 (work in progress). 335 11.0 Author's Addresses 337 Kenneth Peirce, Yingchun Xu, Ed Campbell 338 3Com Corporation 339 1800 W. Central Road 340 Mount Prospect 341 Illinois 60056 342 kenneth_peirce@mw.3com.com, yinchung_xu@mw.3com.com, 343 ed_campbell@mw.3com.com