idnits 2.17.00 (12 Aug 2021) /tmp/idnits39943/draft-le-mobileip-authreq-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 0) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 110: '...tication Request MAY be sent in a pack...' RFC 2119 keyword, line 116: '...quest option, it SHOULD return an Auth...' RFC 2119 keyword, line 137: '... Data; SHOULD be at least 20...' RFC 2119 keyword, line 151: '...stination option MAY be sent in a pack...' RFC 2119 keyword, line 152: '... itself or MAY be included in any ex...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 21 has weird spacing: '... It is inapp...' == Line 234 has weird spacing: '...request inclu...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3012 (ref. '1') (Obsoleted by RFC 4721) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP WG Franck Le 2 INTERNET-DRAFT Stefano M. Faccin 3 Date: 23 February 2001 Basavaraj Patil 4 Expires: 23 August 2001 Nokia Research Center 6 Challenge-Response Authentication Request 7 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 A mobile IP node may share a security association with its home AAA 33 server to allow the mobile node to be authenticated when roaming to 34 different visited domains. The Mobile IP framework has defined some 35 extensions enabling challenge response based authentication 36 mechanisms. Currently, the challenge used for the authentication is 37 generated by the visited domain and broadcasted in Router 38 Advertisements messages. The mobile node uses this challenge to 39 compute authentication data when it wants to register to the network. 40 In order to allow for an easy deployment of Mobile IP for cellular 41 networks, the security of Mobile IP should be enhanced at least to 42 match the level of security available nowadays in cellular networks. 44 For this reason, the home domain need the ability to ask a user to 45 provide authentication information anytime during a session, and thus 46 to decide whether the session can be continued or has to be 47 terminated according to the result of the authentication. In 48 addition, the visited domain should be able as well to to ask a user 49 to provide authentication information anytime during a session, thus 50 allowing the visited domain more control on the roaming. In the same 51 way, the mobile node should also be able to authenticate the network 52 at any time. This document specifies extensions to Mobile IP 53 messages to enable the home domain and the visited domain at any time 54 during a session to ask a mobile node to provide authentication 55 credentials. This document also defines the extensions to enable the 56 mobile node to perform network authentication at any time during a 57 session. 59 1. Introduction 61 A mobile IP node may share a security association with its home AAA 62 server to allow the mobile node to be authenticated when roaming to 63 different visited domains. The Mobile IP framework has defined some 64 extensions [1], [2] enabling challenge response based authentication 65 mechanisms. Currently, the challenge used for the authentication is 66 generated by the visited domain and broadcasted e.g. in Router 67 Advertisements messages. The mobile node uses this challenge to 68 compute authentication data when it wants to register to the network. 70 As indicated above, the home and visited domain need the ability to 71 ask a user to provide authentication information anytime during a 72 session, and thus to decide whether the session can be continued or 73 has to be terminated according to the result of the authentication. 74 This is needed in order to limit frauds, e.g. to avoid that a 75 fraudulent mobile node impersonates a legitimate mobile node and 76 accesses the resources of the visited domain. Possible triggers for 77 a network initiated user authentication procedure include, e.g., a 78 periodic timer time-out, the presence of the mobile node in a high- 79 fraud area, a mobile node "marked" as possibly fraudulent by the home 80 domain, or an authorization request from the mobile node for certain 81 resources causing the network to require user re-authentication etc. 83 Challenge-response based authentication mechanisms provide strong 84 entity authentication, thus the network should be able at any time to 85 challenge the mobile node by sending an Authentication Request 86 message carrying a random number (the challenge) and requesting the 87 mobile node to authenticate. 89 Differently from the current challenge-response mechanisms, where the 90 challenge used for the authentication is generated by the visited 91 domain and broadcasted in Router Advertisements messages, this 92 mechanism proposed in this document is user specific. In fact, the 93 challenge generated by the network is directed to a particular MN 94 (rather than to all MNs able to receive the broadcasted information, 95 as it is currently defined). Since the random number for the 96 challenge is changed for each operation, the proposed authentication 97 mechanism provides a much more secure user authentication. Whether 98 the first authentication procedure succeeded or failed, the user 99 specific challenge authentication can serve as a double check on the 100 authenticity of the MN. 102 In the same way, the mobile node should also be able to authenticate 103 the network by generating a challenge at any time during a session 104 and sending it to the network. 106 2. Mobile IP Authentication Request Extension 108 The Authentication Request destination option is used to request a 109 mobile node or the network to authenticate. As a destination option, 110 the Authentication Request MAY be sent in a packet by itself or MAY 111 be included in any existing packet being sent to the mobile node when 112 initiated by the network or by the mobile node when iniated by the 113 mobile node. A packet containing a Authentication Request option is 114 sent in the same way as any packet to the receiving end point. When 115 a mobile node or the network receives a packet containing an 116 Authentication Request option, it SHOULD return an Authentication 117 Response to the source of the Authentication Request. 119 The Authentication Request option is encoded the format as follows: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type | Subtype | Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | SPI | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Challenge 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Type TBD 133 Subtype a number assigned to identify the way in 134 which the Challenge is to be used 136 Length 4 plus the number of bytes in the Subtype 137 Data; SHOULD be at least 20. 139 SPI Security Parameters Index 141 Challenge The Challenge to be used to compute the 142 Authentication data 144 3. Mobile IP Authentication Response Extension 146 The Authentication Response destination option is sent in response to 147 an Authentication Request option sent by the mobile node or the 148 network respectively to the network or the mobile node in order to 149 provide the authentication data. 151 Authentication Response destination option MAY be sent in a packet by 152 itself or MAY be included in any existing packet being sent to the 153 mobile node by the network or by the mobile node to the network. A 154 packet containing a Authentication Response option is sent in the 155 same way as any packet to the receiving end point. 157 The Authentication Response option is encoded the format as follows: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Subtype | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | SPI | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Authenticator 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Type TBD 171 Subtype a number assigned to identify the way in 172 which the Challenge is used 174 Length 4 plus the number of bytes in the Subtype 175 Data; SHOULD be at least 20. 177 SPI Security Parameters Index 179 Authenticator The variable length Authenticator field 181 4. Request-Response matching scheme 183 It is possible that the Home/Visited network or the MN sends an 184 authentication request respectively to the MN or the Home/Visited 185 network and, after a few seconds, it sends another authentication 186 request which has a different challenge encoded in it. The receiving 187 end point may never receive the first authentication request (e.g. a 188 message is lost on the access link) and receive only the second 189 authentication request. In this situation, when an authentication 190 response is sent back to the Home/Visited network or the MN (i.e. the 191 entity initiating the authentication procedure), the Home/Visited 192 network or the MN needs to know which authentication request the the 193 authentication response was received for in order to perform the 194 correct validation of the authentication data received. 196 Two options are possible: the entity receiving the authentication 197 request includes the challenge received in the authentication request 198 in the authentication response message, or the entity initiating the 199 authentication procedure includes a Challenge_Identifier in the 200 Authentication Request extension and the entity receiving the 201 authentication request includes the Challenge_Identifier in the 202 authentication response. 204 4.1. Basic Request-Response matching scheme 206 In this first option, the entity receiving the authentication request 207 includes the challenge received in the authentication request in the 208 authentication response message. 210 Consistently to [1], the additional destination option containing the 211 challenge used for the authentication is added to the message 212 containing the authentication response and has the following format. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type | Subtype | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | SPI | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Challenge 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 4.2. Optimized Request-Response Matching Scheme 226 There may be some cases where there is the need to optimize the 227 information used for authentication over the access link, e.g. 228 wireless links where the radio resources are limited. In such cases, 229 including the Challenge in the authentication response may make the 230 header too large. A solution for this case is that the entity 231 initiating the authentication procedure includes a 232 Challenge_Identifier in the Authentication Request extension, e.g. in 233 the format of a timestamp or a counter, and the entity receiving the 234 authentication request includes this Challenge_Identifier in the 235 authentication response for the authenticator can know which 236 challenge the response corresponds to. 238 5. Applicability to Mobile IPv4 240 The extensions defined in this document are specific to Mobile IPv6 241 but similar extensions can be defined for Mobile IPv4 enabling any 242 entity to request authentication at any time. The same concept can 243 therefore apply to Mobile IPv4. 245 6. Security Considerations 247 This document specifies extensions to Mobile IP messages to carry the 248 parameters to perform either user specific or network challenge 249 response based authentication mechanism, but does not define the 250 algorithms to use to process the authentication data. 252 7. References 254 [1] C. Perkins and P. Calhoun. Mobile IPv4 Challenge/Response 255 Extensions. Request for Comments 3012, Internet Engineering 256 Task Force, November 2000. 258 [2] N. Asokan, Patrik Flykt, Charles E. Perkins and Thomas 259 Eklund AAA for IPv6 Network Access. Internet Draft, 260 Internet Engineering Task Force, January 2000. 262 8. Authors' Addresses 264 Franck Le 265 Nokia Research Center 266 6000 Connection Drive 267 Irving, TX 75039 268 USA 270 Phone: +1 972 374-1256 271 E-mail: franck.le@nokia.com 273 Stefano M. Faccin 274 Nokia Research Center 275 6000 Connection Drive 276 Irving, TX 75039 277 USA 279 Phone: +1 972 894-4994 280 E-mail: stefano.faccin@nokia.com 282 Basavaraj Patil 283 Nokia Corporation 284 6000 Connection Drive 285 Irving, TX 75039 286 USA 288 Phone: +1 972-894-6709 289 E-Mail: Raj.Patil@nokia.com 290 Table of Contents 292 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 294 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 296 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 298 2. Mobile IP Authentication Request Extension . . . . . . . . . . . 2 300 3. Mobile IP Authentication Response Extension . . . . . . . . . . . 2 302 4. Request-Response matching scheme . . . . . . . . . . . . . . . . 3 303 4.1. Basic Request-Response matching scheme . . . . . . . . . . . 4 304 4.2. Optimized Request-Response Matching Scheme . . . . . . . . . 4 306 5. Applicability to Mobile IPv4 . . . . . . . . . . . . . . . . . . 5 308 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 5 310 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 312 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7