idnits 2.17.1 draft-ohnishi-mip6-aaa-problem-statement-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 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 are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 105 has weird spacing: '...7 shows the a...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2004) is 7369 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) -- Missing reference section? 'RFC3344' on line 235 looks like a reference -- Missing reference section? 'I-D.ietf-mobileip-ipv6' on line 237 looks like a reference -- Missing reference section? 'I-D.ietf-mip4-rfc3012bis' on line 240 looks like a reference -- Missing reference section? 'I-D.ietf-aaa-diameter-mobileip' on line 244 looks like a reference -- Missing reference section? 'I-D.ietf-mip4-aaa-nai' on line 248 looks like a reference -- Missing reference section? 'RFC3314' on line 252 looks like a reference -- Missing reference section? 'RFC2409' on line 262 looks like a reference -- Missing reference section? 'I-D.ietf-eap-keying' on line 265 looks like a reference -- Missing reference section? 'I-D.ietf-pana-usage-scenarios' on line 255 looks like a reference -- Missing reference section? 'RFC2977' on line 259 looks like a reference -- Missing reference section? 'I-D.ietf-ipsec-ikev2' on line 268 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Mobile IPv6 Working Group 3 Internet Draft H. Ohnishi 4 Expires: August 2004 M.Yanagiya 5 NTT 6 Y.Ohba 7 Toshiba 8 February 2004 10 Mobile IPv6 AAA Problem Statement 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 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 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Mobile IP achieves that Mobile Node(MN) moves from one subnet to 35 another. If MN moves across different administrative domains in a 36 commercial network, Mobile IPv6 requires AAA's support. This document 37 describes the problem statement to use AAA functions in Mobile IPv6. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC-2119 [i]. 45 Table of Contents 47 1. Introduction...................................................2 48 2. AAA usage scenario for Mobile IPv6.............................3 49 2.1 Roaming to foreign domain..................................3 50 2.2 Dynamic home address prefix assignment via AAA.............3 51 2.3 Dynamic HA address assignment via AAA......................3 52 2.4 Bootstrapping Mobile IPv6 SA from AAA......................3 53 3. Problem Statement..............................................4 54 4. Mobile IPv4 AAA solution (informative).........................4 55 5. Security Consideration.........................................5 56 Reference.........................................................6 57 Acknowledgments...................................................6 58 Author's Addresses................................................7 60 1. Introduction 62 Mobile IP(v4/v6) [RFC3344][I-D.ietf-mobileip-ipv6] achieves that 63 Mobile Node (MN) moves from one subnet to another. If MN moves 64 across different administrative domains where authentication, 65 authorization and accounting (AAA) is always an issue especially in 66 commercial-based deployments. Mobile IPv4 already defines an 67 interface to AAA functionality [I-D.ietf-mip4-rfc3012bis] 68 [I-D.ietf-aaa-diameter-mobileip] [I-D.ietf-mip4-aaa-nai]. Mobile 69 IPv6 requires an interface to AAA as well. However such an interface 70 has been a missing piece that needs to be filled with an appropriate 71 solution. 73 This document describes several usage cases that deemed necessary to 74 support when Mobile IPv6 is used in an environment where the users 75 subscribe to commercial Mobile IPv6 services with credentials 76 (username, password, certificate, etc.) that are used by the 77 operators as the basis to perform the task of AAA for the Mobile IPv6 78 services. 79 The usage cases are described in terms of service bootstrapping and 80 security, both are important in large-scale deployments. This 81 document then addresses the fundamental issue that needs to be taken 82 into account when designing an interface between AAA and Mobile IPv6. 83 This document also contains informative description on the approach 84 which is taken by Mobile IPv4 to support AAA, however, it should be 85 noted that the informative description is not advocating or 86 recommending the same approach adopted to Mobile IPv4 to be used for 87 Mobile IPv6. 89 For more information related to IPv6 address assignment in 90 3GPP, it is recommended to read [RFC3314]. 92 2. AAA usage scenario for Mobile IPv6 94 In this section, we show some application that we are going to solve 95 by using AAA function. 2.1 shows the application to authenticate an 96 MN when the MN accesses to the visiting network. From 2.2 to 2.4 97 shows service bootstrapping scenarios. Operators may choose a 98 combination of scenarios from these for their services. 100 2.1 Roaming to foreign domain 102 Mobile IPv6 supports MN's mobility. But if MN moves to a foreign 103 domain, the foreign domain requires the way of Authentication, 104 Authorization and Accounting. RFC2977 shows requirements for this 105 scheme. RFC2977 shows the applications of AAA to the Mobile IP, e.g. 106 the basic model, the local payment model, the local home agent model 107 and so on. 109 2.2 Dynamic home address prefix assignment via AAA 111 In some cases, operators want to assign home address prefix to mobile 112 node dynamically for the purpose of reducing management cost, etc. 113 Mobile IPv6 prescribes Mobile Prefix Solicitation(MPS) and Mobile 114 Prefix Advertisement(MPA). But in this method, MN needs to know HA 115 address previously. A solution for dynamically and securely assigning 116 home address prefix to mobile node with involving an appropriate 117 authentication and authorization protocol is demanded. 119 2.3 Dynamic HA address assignment via AAA 121 In some cases, operators want to assign HA to the MN dynamically from 122 the perspective of load balancing. Mobile IPv6 prescribes dynamic HA 123 allocation mechanism in which it sends anycast address to find HA and 124 the HA sends back HAs' list to the MN. HA sends this list without 125 authenticating the MN. A solution for dynamically and securely 126 assigning HA's address to mobile node with involving an appropriate 127 authentication and authorization protocol is demanded. 129 2.4 Bootstrapping Mobile IPv6 SA from AAA 131 Mobile IPv6 [I-D.ietf-mobileip-ipv6] requires an IPsec SA (Security 132 Association) established between mobile node and its home agent to 133 protect Binding Updates to the home agent. This SA is referred to as 134 Mobile IPv6 SA(MSA). When a home agent is dynamically allocated, it 135 is difficult to assume pre-established security association (such as 136 an IKE [RFC2409] pre-shared secret) between the mobile node and every 137 potential home agent, unless a trusted third-party is involved in the 138 authentication procedure between a mobile node and its home agent. 139 Among several alternative models (e.g., Kerberos) that rely on a 140 trusted third-party, there is demand for AAA-based solutions possibly 141 with leveraging the EAP keying framework [I-D.ietf-eap-keying] which 142 allows the key material generated by an EAP authentication algorithm 143 to turn into a credential needed for mutually authenticating mobile 144 node and home agent in the IPsec key management protocol. 146 3. Problem Statement 148 In Mobile IPv4, AAA for network access service and AAA for Mobile 149 IPv4 service are integrated for optimization purpose. These two 150 types of AAA are different in functionality 151 [I-D.ietf-pana-usage-scenarios], and such an integration is possible 152 in the architecture where an agent that acts as an AAA attendant for 153 both types of AAA is placed in the visiting network. In the case of 154 Mobile IPv4, mobility agent itself (i.e., FA) is such an integrated 155 agent. 157 In Mobile IPv6 architecture, there is no FA unlike Mobile IPv4. The 158 fundamental problem that needs to be solved is to support the usage 159 cases described in Section 2 without introducing FA in Mobile IPv6. 160 This would lead to a need to define a MIPv6 Service Aware AAA 161 Attendant (MSAAA), which is an AAA attendant to provide AAA for 162 Mobile IPv6 service for MN. The MSAAA may be integrated with an AAA 163 attendant of other protocol or service, or may be integrated with 164 MIPv6 home agent, depending on Mobile IPv6 service models. The 165 protocol to transfer information between HA and AAA server is needed 166 in every above MSAAA deployment scenarios. 168 4. Mobile IPv4 AAA solution (informative) 170 Mobile IPv4 defines two different registration procedures, one via 171 foreign agent that relays the registration to mobile node's home 172 agent, and the other directly with the mobile node's home agent. Both 173 registration procedures involve the exchange of Registration Request 174 and Registration Reply messages. In order to prevent spoofing, Mobile 175 IPv4 defines authentication extension in Registration Request and 176 Reply message [RFC3344]. MN sends Registration Request with 177 authentication extension which includes authenticator to FA or HA. FA 178 or HA evaluates the authenticator by using shared key or 179 public/private key pair. In a large scale roaming service network 180 such as public wireless LAN access service network, it is difficult 181 to distribute all key material to FA and/or HA. Thus, AAA 182 architecture is used to manage key materials of MNs or/and verify 183 credential. Fig 1 shows an example of sequence using RADIUS. It is 184 assumed that MN does not have a security association with FA. MN 185 sends Registration Request which includes challenge value and Network 186 Access Identifier (NAI). According to NAI, FA makes a decision on AAA 187 message routing, and passes the authenticator to AAA server. AAA 188 server verifies the authenticator and sends authentication reply. If 189 an authentication is success, FA sends Agent Reply to MN. 191 MN FA AAA 192 |Agent Advertisement | | 193 |[Challenge ext.] | | 194 |<---------------------| | 195 |Registration Request | | 196 |[MN-FA Challenge Ext.,| | 197 | MN-HA Auth. ext., | | 198 | MN-AAA Auth. ext., | | 199 | NAI. ext.] | | 200 |--------------------->| | 201 | |Authentication Request | 202 | |---------------------> | 203 | | | 204 | |Authentication Reply | 205 | |<--------------------- | 206 |Registration Reply | | 207 |(registration accept) | | 208 |<-------------------- | | 209 | | | 211 Figure 1: MN-FA authentication with AAA in Mobile IPv4 213 In [I-D.ietf-aaa-diameter-mobileip], a similar method is specified by 214 using Diameter application. MN sends Registration Request to FA. FA 215 invokes the local AAA infrastructure (AAAF) to request that a mobile 216 node be authenticated. If AAAF is not aware of the identity of MN, 217 AAAF will forward authentication data to home AAA server (AAAH). 219 5. Security Consideration 221 This draft identifies a need for bootstrapping Mobile IPv6 by 222 leveraging the AAA infrastructure. Although any solution is not 223 specified in this document, a AAA-based solution for dynamically 224 assigning Mobile IPv6 home agent address is expected to improve 225 Mobile IPv6 security by not relying on the anycast-based scheme built 226 in Mobile IPv6 but relying on the AAA infrastructure instead. More 227 security analysis on bootstrapping MSA should be made when designing 228 a solution. Although security consideration section of 229 [I-D.ietf-eap-keying] covers general security issues for EAP-based 230 service bootstrapping, there may be Mobile IPv6 specific security 231 issues in bootstrapping MSA. 233 Reference 235 [RFC3344] C. Perkins, "IP Mobility Support", RFC 3344, August 2002. 237 [I-D.ietf-mobileip-ipv6] Johnson, D., "Mobility Support in IPv6", 238 draft-ietf-mobileip-ipv6-24.txt, (work in progress), June 30 2003. 240 [I-D.ietf-mip4-rfc3012bis] C. Perkins, et al., "Mobile IPv4 241 Challenge/Response Extensions (revised)", 242 draft-ietf-mip4-rfc3012bis-00.txt (work in progress), 7 October 2003. 244 [I-D.ietf-aaa-diameter-mobileip] P. Calhoun, et al., "Diameter Mobile 245 IP Application", draft-ietf-aaa-diameter-mobileip-15.txt (work in 246 progress), November 2003. 248 [I-D.ietf-mip4-aaa-nai] F. Johansson and T. Johansson, "Mobile IPv4 249 Extension for carrying Network Access Identifiers", 250 draft-ietf-mip4-aaa-nai-02.txt (work in progress), December 12, 2003 252 [RFC3314] M. Wasserman, "Recommendations for IPv6 in Third Generation 253 Partnership Project (3GPP) Standards", RFC 3314, September 2002. 255 [I-D.ietf-pana-usage-scenarios] Y. Ohba, et al., "Problem Statement 256 and Usage Scenarios for PANA", draft-ietf-pana-usage-scenarios-06.txt 257 (work in progress), April 28, 2003. 259 [RFC2977] S. Glass, et al.,"Mobile IP Authentication, Authorization, 260 and Accounting Requirements", RFC 2977, October 2000 262 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 263 (IKE)", RFC 2409, November 1998. 265 [I-D.ietf-eap-keying] Aboba, B., "EAP Key Management Framework", 266 draft-ietf-eap-keying-01 (work in progress), October 2003. 268 [I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2) 269 Protocol", draft-ietf-ipsec-ikev2-12 (work in progress), January 2004. 271 Acknowledgments 273 We would like to thank Alper Yegin and Rafa Marin Lopez for their 274 valuable contributions to the discussions and preparation of this 275 document. 277 We also would like to thank Basavaraj Patil and Gopal Dommety for 278 their encouraging us to submit this document. 280 Author's Addresses 282 Hiroyuki Ohnishi 283 NTT Network service systems laboratories, NTT Corporation 284 9-11, Midori-Cho, 3-Chome 285 Musashino-Shi, Tokyo 180-8585 286 Japan 287 Phone: +81 422 59 4132 288 Email: ohnishi.hiroyuki@lab.ntt.co.jp 290 Mayumi Yanagiya 291 NTT Network service systems laboratories, NTT Corporation 292 9-11, Midori-Cho, 3-Chome 293 Musashino-Shi, Tokyo 180-8585 294 Japan 295 Phone: +81 422 59 6783 296 Email: yanagiya.mayumi @lab.ntt.co.jp 298 Yoshihiro Ohba 299 Toshiba America Information Systems, Inc. 300 9740 Irvine Blvd. 301 Irvine, CA 92619-1697 302 USA 303 Phone: +1 973 829 5174 304 EMail: yohba@tari.toshiba.com