idnits 2.17.00 (12 Aug 2021) /tmp/idnits26120/draft-ietf-roamops-mobileip-02.txt: ** The Abstract section seems to be numbered 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 the list of Shadow Directories. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 531 has weird spacing: '...t>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (25 June 1999) is 8359 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: '1' is defined on line 437, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 444, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 449, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 474, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 477, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 480, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 483, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 486, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '1') ** Obsolete normative reference: RFC 2138 (ref. '2') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '3') (Obsoleted by RFC 2866) == Outdated reference: draft-ietf-radius-ext has been published as RFC 2869 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '6') ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2486 (ref. '9') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '10') -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: draft-ietf-mobileip-mn-nai has been published as RFC 2794 ** Obsolete normative reference: RFC 2401 (ref. '13') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '14') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '15') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '16') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '17') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2052 (ref. '18') (Obsoleted by RFC 2782) Summary: 21 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ROAMOPS Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Standards Track 4 5 25 June 1999 7 Roaming Support in Mobile IP 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. Internet- 17 Drafts are draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 The distribution of this memo is unlimited. It is filed as , and expires December 1, 1999. Please send 30 comments to the authors. 32 2. Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 3. Abstract 38 RFC 2002 describes the framework for Mobile IP, while RFC 2290 describes 39 how a mobile node and a peer negotiate the appropriate use of Mobile IP 40 over a PPP link. RFC 2477 describes the roaming architecture as well as 41 criteria for evalution of roaming protocols, which include 42 reconciliation between roaming and mobile IP. 44 This document describes the relationship between the roaming 45 architecture and mobile IP and describes how support for secure roaming 46 may be provided within Mobile IP, while requiring only minimal changes 47 to the Mobile IP protocol. 49 4. Introduction 51 RFC 2002 [7] describes the framework for Mobile IP, while RFC 2290 [8] 52 describes how a mobile node and a peer negotiate the appropriate use of 53 Mobile IP over a PPP link, through use of the IPCP IP Address and 54 Mobile-IPv4 Configuration Options. RFC 2477 [6] describes the roaming 55 architecture as well as, which include reconciliation between roaming 56 and mobile IP. 58 This document describes the relationship between the roaming 59 architecture and mobile IP and describes how support for secure roaming 60 may be provided within Mobile IP, while requiring only minimal changes 61 to the Mobile IP protocol. 63 4.1. Requirements language 65 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 66 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 67 described in [4]. 69 4.2. Overview 71 The architectural framework for Internet roaming, described in [6], 72 permits a roaming user to make use of the facilities of multiple 73 Internet Service Providers while maintaining a formal account 74 relationship with only one. This framework makes use of the Network 75 Access Identifier (NAI), defined in [9], in order to identify the 76 roaming user, as well as to permit the location of the home 77 authentication server. The home authentication server is located either 78 via static configuration or via lookup of the SRV record, following the 79 procedure described in RFC 2052 [18]. 81 Within the roaming architecture the roaming user typically does not 82 maintain a pre-existing relationship with the local provider. As a 83 result, unless certificate-based authentication is used between the 84 roaming user and the local provider, it is necessary for the the local 85 provider to contact the home authentication server in order to validate 86 the user's identity. 88 When certificate-based authentication is used between the roaming user 89 and the local provider, as described in [11], the local provider is able 90 to determine whether the user possesses the private key corresponding to 91 the offered certificate, and thus authentication by the home provider is 92 not required. 94 Where it is necessary for the local provider to contact the home 95 authentication server, it is desirable for that communication be secured 96 using public key certificates, as supported in IKE [16]-[17]. Since the 97 local provider and home server typically do not maintain a pre-existing 98 relationship, without public key certificate support it is typically 99 necessary for one or more proxies to act as intermediaries in order to 100 reduce the shared secret management problem. As noted in [10] the 101 introduction of proxies creates a number of security problems and 102 therefore is undesirable. 104 4.3. Scenarios 106 This document discusses roaming within Mobile IP, based on the following 107 scenarios: 109 1. The mobile node supports certificate-based authentication with the 110 foreign agent. 112 2. The mobile node does not support certificate-based authentication 113 with the foreign agent, nor does it share a secret with the foreign 114 agent. However, the mobile node does share a secret with the home agent. 115 In this scenario, the foreign agent contacts the home authentication 116 server in order to validate the mobile node's identity. 118 3. PPP-based connectivity is established at layer 2 prior to Mobile IP 119 foreign agent discovery and Mobile Node Registration. In this scenario, 120 it cannot be assumed that a prior relationship exists between the mobile 121 node and the foreign agent. This scenario may support any authentication 122 mode type supported by PPP, including CHAP and Extensible Authentication 123 Protocol (EAP), which includes support for certificate-based 124 authentication. Where certificate-based authentication is used, the 125 foreign agent will be able to validate the mobile node's identity 126 without contacting the home authentication server. Where another means 127 of authentication is used, it will typically be necessary for the 128 foreign agent to contact the home authentication server. 130 In all scenarios it is assumed that the mobile node is operating with a 131 co-located care of address. However, it is not assumed that the foreign 132 agent and home agent have a pre-existing relationship and therefore it 133 cannot be assumed that a shared secret exists between the parties. As a 134 result, roaming support within Mobile IP does not make use of the 135 Foreign Agent-Home Agent authentication extension. 137 5. Support for roaming within Mobile IP 139 5.1. Support for certificate-based roaming in Mobile IP 141 In this scenario, it is assumed that the Mobile Node and Home Agent have 142 a security association, but that there is no security association 143 between the Foreign Agent and the Home Agent. An IPSEC security 144 association is negotiated between the Mobile Node and the Foreign Agent, 145 so that the Mobile Node-Foreign Agent authentication extension is not 146 needed. 148 In certificate-based roaming, the Mobile Node creates an IPSEC security 149 association with the Foreign Agent. For the IKE negotiation to be 150 carried out, the Mobile Node MUST obtain a co-located care-of-address 151 from the mobile node (used as the source address for IKE) and MUST 152 discover the IP address of the Foreign Agent (used as the destination 153 address for IKE). If the IP address of the Foreign Agent cannot be 154 obtained then the IKE negotiation cannot be carried out since the 155 destination address for the IKE negotiation cannot be the all-mobility- 156 agents multicast address, 224.0.0.11. During the IKE negotiation, user- 157 based certificates MUST be used in order for the Mobile Node to prove 158 its identity to the Foreign Agent. Machine-based certificates MUST NOT 159 be used since they do not demonstrate that the Mobile Node's identity 160 corresponds to the NAI that will be used by the Foreign Agent to bill 161 for services. 163 In order to permit the mobile node to make a claim of identity as well 164 as to validate that claim, the Mobile Node includes in the Registration 165 Request the NAI extension described in [12]. The realm portion of the 166 NAI is used by the Foreign Agent to locate the home agent via a lookup 167 of the mobileip-agent.udp.realm SRV record, following the procedure 168 described in RFC 2052 [18]. Note that the NAI extension provided by the 169 Mobile Node MUST correspond to the identity provided in the IKE 170 negotiation. 172 The Registration Request also MUST include the Mobile Node-Home Agent 173 authentication extension. Since the Mobile Node and Foreign Agent create 174 an IPSEC security association there is no need for an alternative 175 security association and the Mobile Node-Foreign Agent authentication 176 extension MUST NOT be included. 178 When the Foreign Agent receives the Registration Request, it may or may 179 not negotiate an IPSEC security association with the Home Agent prior to 180 forwarding the Registration Request to the Home Agent. Note that the 181 home agent may not have access to the secret shared with the mobile node 182 and therefore may not be able to validate the Mobile Node-Home Agent 183 authentication extension on its own without help from a central 184 authentication server. This can be achieved via use of the RADIUS 185 protocol and the MN-Registration attribute described below. 187 Please note that in mobile IP, certificate based roaming provides only 188 stronger authentication but does not reduce latency. Unlike dialup- 189 roaming, it is generally not possible for the Foreign Agent to avoid 190 contact with the Home Agent, even if it has already authenticated the 191 Mobile Node. This is because the Mobile Node will still need to register 192 its co-located care-of-address with the Home Agent, and the Foreign 193 Agent will need to be aware of the outcome of the Registration Request. 194 Thus in Mobile IP roaming, certificate-based authentication does not 195 save any round-trips. 197 5.2. Support for shared secret-based roaming in Mobile IP 199 In this scenario, it is assumed that the Mobile Node and Home Agent 200 share a security association, but that no security association exists 201 between the Mobile Node and Foreign Agent. Since an IPSEC security 202 association is negotiated between the Foreign Agent and the Home Agent, 203 there is no need for the Foreign Agent-Home Agent authentication 204 extension. 206 In order to permit the user to make a claim of identity as well as to 207 validate that claim, the Mobile Node Registration Request includes the 208 NAI extension described in [12], as well as the Mobile Node-Home Agent 209 authentication extension. Since the Mobile Node and Foreign Agent 210 typically do not have a security association, the Mobile Node-Foreign 211 Agent authentication extension is not included. 213 Since in shared-secret based roaming there is no IPSEC negotiation 214 between the Mobile Node and the Foreign Agent, there is no requirement 215 that the Mobile Node obtain a co-located care of address. This allows 216 the Foreign Agent to re-use the care-of-address if it desires. 218 When the Foreign Agent receives the Registration Request, it negotiates 219 an IPSEC security association with the Home Agent. The Foreign Agent 220 locates the home agent from the realm portion of the NAI via a lookup of 221 the mobileip-agent.udp.realm SRV record, following the procedure 222 described in RFC 2052 [18]. 224 As part of the IKE negotiation, the Foreign Agent and Home Agent will 225 authenticate using certificates from a mutually trusted party (the 226 roaming association). The foreign agent will subsequently bill this 227 trusted party for the resources consumed by the mobile node. Note that 228 this security association may be reused by the Foreign Agent for 229 handling of additional Mobile Nodes using the same Home Agent. 231 The IPSEC-protected Mobile IP registration message sent by the Foreign 232 Agent to the Home Agent MUST provide for integrity protection and 233 authenticity via the ESP null tranform. The Mobile IP Registration 234 Response serves to validate the identity of the Mobile Node both to the 235 Home Agent and to the Foreign Agent, and therefore provides assurance to 236 the Foreign Agent that it will be able to provide service. 238 Note that the home agent may not have access to the secret shared with 239 the mobile node and therefore may not be able to validate the Mobile 240 Node-Home Agent Authentication Extension on its own without help from a 241 central authentication server. This can be achieved via use of the 242 RADIUS protocol and the MN-Registration attribute described below. 244 5.3. Support for PPP-based roaming in Mobile IP 246 The steps involved in negotiating mobile access to the Internet while 247 roaming between PPP-based mobile IP providers are as follows: 249 1. The mobile node connects to the foreign agent via PPP, and 250 authenticates via LCP, identifying itself via the Network Access 251 Identifier (NAI), described in [9]. The NAI provides the local ISP with 252 the information necessary to contact the home authentication server. 254 2. The foreign agent then sends a RADIUS Access-Request to the home 255 authentication server, and receives a RADIUS Access-Reply. Based on the 256 Access-Reply, the foreign agent will grant access to the mobile node, or 257 will terminate the conversation. Note that since the RADIUS conversation 258 takes place in LCP, while mobile IP configuration takes place in IPCP, 259 an Access-Accept if sent must include the authorization information 260 required to assist the foreign agent in negotiating use of Mobile IP 261 with the mobile node. 263 3. The mobile node will indicate its preference for a foreign care-of- 264 address or a co-located care of address via use of the IP Address and 265 Mobile-IPv4 Configuration Options in IPCP, as described in [8]. If a co- 266 located care-of-address is preferred, this will typically be indicated 267 by setting the IP Address option to zero, and the Mobile-IPv4 268 Configuration option to the Home Address. If a foreign agent care-of- 269 address is preferred, this will typically be indicated by sending only a 270 Mobile-IPv4 Configuration option with the Home Address. 272 4. The Foreign Agent will respond to the mobile node's Configure-Request 273 as described in [8]. If the NAS is not Mobile-IP capable, then it will 274 respond with a Configure-Reject. If the mobile node has requested a co- 275 located care-of-address, and the foreign agent can comply, it will 276 typically reply with a Configure-NAK including an IP Address Option set 277 to the co-located care-of-address or home address, depending on whether 278 the mobile node is attached via a foreign link or home link. 280 If the foreign agent only supports a foreign agent care-of-address, it 281 will typically reply with a Configure-NAK including an IP Address Option 282 set to zero. If the mobile node has requested a foreign agent care-of- 283 address, and the foreign agent is Mobile-IP capable, then the foreign 284 agent MUST reply with a Mobile-IPv4 Configuration Option set to the Home 285 Address indicated by the mobile node. 287 As noted in [8], the foreign agent need not know the mobile node's Home 288 Address beforehand in order to decide how to reply. This information is 289 not useful because if the Home Address expected by the foreign agent did 290 not match that provided by the mobile node, there would be no way to 291 correct the problem, since as described in [8] a Configure-NAK is 292 undefined for the Mobile-IPv4 Configuration Option. 294 5. The IPCP negotiation concludes and the mobile node now has access to 295 the Internet. 297 6. The foreign agent sends a RADIUS Accounting Start packet to the 298 RADIUS accounting server. 300 7. The Foreign Agent sends an agent advertisement on the PPP link. 302 8. The mobile node sends a Registration Request and receives a Reply. As 303 noted in [8], the mobile node must receive an agent advertisement before 304 registering on a foreign link since even if the mobile node is using a 305 colocated care-of-address, the foreign agent may wish to enforce a 306 policy requiring registration. Note that in this registration the Mobile 307 Node SHOULD include the NAI extension even though the Foreign Agent has 308 already learned this by other means. The NAI MUST correspond to that 309 used in the PPP authentication. 311 In order to carry out the IPCP negotiation described above, the NAS 312 requires the following information: 314 a. Whether the mobile node is authorized to do mobile IP. This is 315 indicated by the Mobile-IP-Configuration Attribute defined below. Since 316 the mobile node may not always wish to do mobile IP, Mobile IP 317 authorization should not be interpreted as requiring mobile IP. 318 Similarly, the mobile node may not always contact an ISP that is Mobile- 319 IP capable, and as a result, while a home server may include Mobile-IP- 320 Configuration attribute in the Access-Accept, this attribute may be 321 stripped by a local ISP proxy. 323 b. Whether a co-located care-of-address is available for assignment to 324 the mobile node if requested. This is indicated by the inclusion or 325 absence of a Framed-IP-Address attribute in the Access-Accept. When a 326 Mobile-IP-Configuration attribute is present, the absence of a Framed- 327 IP-Address attribute should be interpetted as indicating that a co- 328 located care-of-address MUST NOT be assigned. If a Framed-IP-Address 329 attribute is included along with a Mobile-IP-Configuration attribute, 330 then a co-located care-of-address MAY be assigned. As described in [2], 331 a co-located care-of-address may assigned statically or dynamically. 333 6. RADIUS attributes 335 6.1. MN-Registration attribute 337 Description 339 This Attribute requests validation of the Mobile Node Registration. 340 It MAY be included in an Access-Request packet. 342 A summary of the MN-Registration Attribute format is shown below. The 343 fields are transmitted from left to right. 345 0 1 2 3 346 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 2 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | Flags | Registration 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Registration... 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Type 355 ? for MN-Registration 357 Length 359 varies 361 Flags 363 The flags, which indicate the authenticators whose validation is 364 requested, are encoded as follows: 366 0 1 2 3 4 5 6 7 8 367 +-+-+-+-+-+-+-+-+ 368 |M|F|H|R|R|R|R|R| 369 +-+-+-+-+-+-+-+-+ 370 M = Mobile Node-Foreign Agent 371 F = Foreign Agent-Home Agent 372 H = Home Agent-Mobile Node 373 R = reserved 375 If the flag is set for a particular authenticator, the appropriate 376 extension MUST be included in the enclosed Mobile IP registration 377 packet. If the indicated extension is missing, then the RADIUS server 378 MUST return an Access-Reject. 380 Registration 382 The entire contents of the Mobile IP registration packet, including 383 IP/UDP headers, registration request, and extensions. 385 Discussion 387 The MN-Registration attribute is designed to allow the foreign or 388 home agent to validate the authenticators enclosed in the Mobile IP 389 registration message. Allowing this validation to be carried out by 390 an authentication server alleviates the need for the Foreign Agent or 391 Home Agent to maintain its own authentication database. 393 6.2. Mobile-IP-Configuration attribute 395 Description 397 This Attribute indicates whether a user is authorized to do Mobile 398 IP. It MAY be included in Access-Accept, or Accounting-Request 399 packets. 401 A summary of the Mobile-IP-Configuration Attribute format is shown 402 below. The fields are transmitted from left to right. 404 0 1 2 3 405 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 2 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Length | Address 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Address (cont) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Type 414 ? for Mobile-IP-Configuration 416 Length 418 6 420 Address 422 The Address field is four octets, and encodes the Mobile Node's Home 423 Address. 425 Discussion 427 When included in an Access-Accept, the Address field MUST contain the 428 value 0xFFFFFFFF, indicating that Mobile-IP is authorized. Since the 429 absence of Mobile IP authorization is indicated by omission of the 430 attribute, no value is required to signal lack of authorization. 432 When included in an Accounting-Request, the Address field is set to 433 the Home Address supplied by the mobile node. 435 7. References 437 [1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming 438 Implementations", RFC 2194, September 1997. 440 [2] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 441 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 442 1997. 444 [3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 446 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 447 Levels", BCP 14, RFC 2119, March 1997. 449 [5] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 450 ietf-radius-ext-03.txt, Internet Draft (work in progress), January 451 1999. 453 [6] Aboba, B, Zorn, G., "Criteria for Evaluating Roaming Protocols", 454 RFC 2477, January 1999. 456 [7] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 458 [8] Solomon, J., Glass, S., "Mobile-IPv4 Configuration Option for PPP 459 IPCP", RFC 2290, February 1998. 461 [9] Aboba, B, Beadles, M. A., "The Network Access Identifier", RFC 462 2486, January 1999. 464 [10] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy 465 Implementation in Roaming", RFC 2607, June 1999. 467 [11] Aboba, B., "Certificate-based Roaming", Internet Draft (work in 468 progress), draft-ietf-roamops-cert-01.txt, April 1999. 470 [12] Calhoun, P. R., Perkins, C., "Mobile IP Network Access Identifier 471 Extension", Internet draft (work in progress), draft-ietf-mobileip- 472 mn-nai-02.txt, May 1999. 474 [13] Atkinson, R., Kent, S., "Security Architecture for the Internet 475 Protocol", RFC 2401, November 1998. 477 [14] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 478 November 1998. 480 [15] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 481 RFC 2406, November 1998. 483 [16] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 484 2409, November 1998. 486 [17] Piper, D., "The Internet IP Security Domain of Interpretation of 487 ISAKMP", RFC 2408, November 1998. 489 [18] Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the location 490 of services (DNS SRV)", RFC 2052, October 1996. 492 8. Acknowledgements 494 Thanks to Jim Solomon of Motorola and Pat Calhoun of Sun Microsystems 495 for useful discussions of this problem space. 497 9. Authors' Addresses 499 Bernard Aboba 500 Microsoft Corporation 501 One Microsoft Way 502 Redmond, WA 98052 504 Phone: 425-936-6605 505 EMail: bernarda@microsoft.com 506 10. Full Copyright Statement 508 Copyright (C) The Internet Society (1999). All Rights Reserved. 509 This document and translations of it may be copied and furnished to 510 others, and derivative works that comment on or otherwise explain it or 511 assist in its implmentation may be prepared, copied, published and 512 distributed, in whole or in part, without restriction of any kind, 513 provided that the above copyright notice and this paragraph are included 514 on all such copies and derivative works. However, this document itself 515 may not be modified in any way, such as by removing the copyright notice 516 or references to the Internet Society or other Internet organizations, 517 except as needed for the purpose of developing Internet standards in 518 which case the procedures for copyrights defined in the Internet 519 Standards process must be followed, or as required to translate it into 520 languages other than English. The limited permissions granted above are 521 perpetual and will not be revoked by the Internet Society or its 522 successors or assigns. This document and the information contained 523 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 524 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 525 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 526 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 529 11. Expiration Date 531 This memo is filed as , and expires 532 December 1, 1999.