idnits 2.17.1 draft-ietf-roamops-dnsrr-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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 279 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 422 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 7 instances of lines with non-RFC2606-compliant FQDNs 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 128: '... MUST This word, or the ad...' RFC 2119 keyword, line 132: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 135: '... SHOULD This word, or the adjec...' RFC 2119 keyword, line 141: '... SHOULD NOT...' RFC 2119 keyword, line 148: '... MAY This word, or the adjec...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (274 more instances...) -- 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 (6 March 1997) is 9910 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 693, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 697, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 711, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 714, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 718, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 722, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 725, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 733, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 745, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-roamops-imprev-01 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-imprev (ref. '1') == Outdated reference: A later version (-10) exists of draft-ietf-roamops-roamreq-02 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-roamreq (ref. '2') ** Obsolete normative reference: RFC 2058 (ref. '3') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '4') (Obsoleted by RFC 2139) == Outdated reference: A later version (-07) exists of draft-ietf-receipt-mdn-02 ** Obsolete normative reference: RFC 1892 (ref. '7') (Obsoleted by RFC 3462) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-02 == Outdated reference: A later version (-09) exists of draft-ietf-ediint-req-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ediint-req (ref. '11') ** Obsolete normative reference: RFC 2052 (ref. '12') (Obsoleted by RFC 2782) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 1530 (ref. '15') Summary: 21 errors (**), 0 flaws (~~), 24 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 5 6 March 1997 7 The Roaming Relationship (REL) Resource Record in the DNS 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires September 15, 1997. Please 28 send comments to the authors. 30 2. Abstract 32 This document describes the use of the Roaming Relationship (REL) 33 record in the DNS for the description of roaming relationships. In the 34 absence of DNS security, REL resource records may be used for deter- 35 mining the existence of a roaming relationship path between the local 36 ISP and the user's home domain, as well as the location of an appro- 37 priate accounting agent. However, without DNS security, hierarchical 38 authentication routing must be used in order to validate the roaming 39 relationship path. When DNS security is implemented, the roaming rela- 40 tionship path is authenticated via digital signatures, and as a 41 result, additional services may be provided, such as non-repudiation 42 of proxied authentications and signed receipts for accounting record 43 transfers. 45 3. Introduction 47 Considerable interest has arisen recently in a set of features that 48 fit within the general category of "roaming capability" for dialup 49 Internet users. Interested parties have included: 51 Regional Internet Service Providers (ISPs) operating within a 52 particular state or province, looking to combine their efforts 53 with those of other regional providers to offer dialup service 54 over a wider area. 56 National ISPs wishing to combine their operations with those of 57 one or more ISPs in another nation to offer more comprehensive 58 dialup service in a group of countries or on a continent. 60 Businesses desiring to offer their employees a comprehensive 61 package of dialup services on a global basis. Those services may 62 include Internet access as well as secure access to corporate 63 intranets via a Virtual Private Network (VPN), enabled by tunnel- 64 ing protocols such as PPTP, L2F, or L2TP. 66 This document describes the use of the Roaming Relationship (REL) 67 record in the DNS for the description of roaming relationships. In the 68 absence of DNS security, REL resource records may be used for deter- 69 mining the existence of a roaming relationship between the local ISP 70 and the user's home domain, as well as the location of an appropriate 71 accounting agent. However, without DNS security, hierarchical authen- 72 tication routing must be used in order to validate the roaming rela- 73 tionship path. When DNS security is implemented as described in [13], 74 the roaming relationship path is authenticated via digital signatures, 75 and as a result, additional services may be provided, such as non- 76 repudiation of proxied authentications and signed receipts for 77 accounting record transfers. The latter capability is described in 78 references [5] - [11]. 80 3.1. Terminology 82 This document frequently uses the following terms: 84 roaming relationship path 85 The roaming relationship path is the series of roaming rela- 86 tionships that link together a local ISP and user's home 87 domain. The roaming relationship path may or may not be the 88 same as the authentication route, depending on whether the 89 local proxy is able to directly contact the home authentica- 90 tion server. 92 authentication route 93 The route that an authentication will take in traveling 94 between the local ISP's authentication proxy and the home 95 authentication server. Where RADIUS proxy authentication is 96 used, the authentication route follows the roaming relation- 97 ship path. 99 Network Access Server 100 The Network Access Server (NAS) is the device that clients 101 dial in order to get access to the network. 103 RADIUS server 104 This is a server which provides for 105 authentication/authorization via the protocol described in 106 [3], and for accounting as described in [4]. 108 RADIUS proxy 109 In order to provide for the routing of RADIUS authentication 110 and accounting requests, a RADIUS proxy may employed. To the 111 NAS, the RADIUS proxy appears to act as a RADIUS server, and 112 to the RADIUS server, the proxy appears to act as a RADIUS 113 client. 115 RADIUS domain 116 In order to provide for the routing of RADIUS authentication 117 and accounting requests, the userID field used in PPP and in 118 the subsequent RADIUS authentication and accounting 119 requests, may contain structure. This structure provides a 120 means by which the RADIUS proxy will locate the RADIUS 121 server that is to receive the request. 123 3.2. Requirements language 125 This specification uses the same words as [14] for defining the sig- 126 nificance of each particular requirement. These words are: 128 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 129 that the definition is an absolute requirement of the speci- 130 fication. 132 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 133 nition is an absolute prohibition of the specification. 135 SHOULD This word, or the adjective "RECOMMENDED", means that there 136 may exist valid reasons in particular circumstances to 137 ignore a particular item, but the full implications must be 138 understood and carefully weighed before choosing a different 139 course. 141 SHOULD NOT 142 This phrase means that there may exist valid reasons in par- 143 ticular circumstances when the particular behavior is 144 acceptable or even useful, but the full implications should 145 be understood and the case carefully weighed before imple- 146 menting any behavior described with this label. 148 MAY This word, or the adjective "OPTIONAL", means that an item 149 is truly optional. One vendor may choose to include the 150 item because a particular marketplace requires it or because 151 the vendor feels that it enhances the product while another 152 vendor may omit the same item. An implementation which does 153 not include a particular option MUST be prepared to interop- 154 erate with another implementation which does include the 155 option, though perhaps with reduced functionality. In the 156 same vein an implementation which does include a particular 157 option MUST be prepared to interoperate with another imple- 158 mentation which does not include the option.(except, of 159 course, for the feature the option provides) 161 An implementation is not compliant if it fails to satisfy one or more 162 of the must or must not requirements for the protocols it implements. 163 An implementation that satisfies all the must, must not, should and 164 should not requirements for its protocols is said to be "uncondition- 165 ally compliant"; one that satisfies all the must and must not require- 166 ments but not all the should or should not requirements for its proto- 167 cols is said to be "conditionally compliant." 169 4. The Roaming Relationship (REL) Record 171 In order to enable roaming, it is necessary for a local provider to be 172 able to determine whether a roaming relationship path exists between 173 itself and the user's home domain, so as to enable the local provider 174 to be paid for the use of its resources. These roaming relationships 175 are typically of two types: the relationship between a firm and a 176 provider, in which the firm delegates roaming authority to the 177 provider; or the relationship between a provider and a roaming associ- 178 ation, in which the provider agrees to allow members of the consortium 179 to access its network resources, in exchange for compensation. How- 180 ever, it is also possible for a company or even an individual to form 181 a direct relationship with a roaming consortia, or for consortia to 182 form a relationship with another consortia. 184 Inter-domain roaming relationships may extend to several levels. For 185 example, BIGCO may delegate roaming authority to ISPA, who may in turn 186 join roaming association ISPGROUP. When Fred dials into ISPB and 187 attempts to authenticate as fred@bigco.com, it is necessary for ISPB 188 to determine whether it has a means for being paid for the resources 189 consumed by Fred. This is accomplished by tracing the web of roaming 190 relationships backwards from the bigco.com domain, in order to deter- 191 mine whether a path of roaming relationships exists between ISPB and 192 BIGCO. 194 Please note that the task of determining the path of roaming relation- 195 ships is orthogonal to the issue of authentication routing. Where 196 authentication proxy chaining is used, authentication routing is 197 required in order to improve scalability. However, when public key 198 authentication is available, it is possible for an authentication 199 proxy to directly contact a home authentication server. However, 200 regardless of how the authentication is routed, it is still necessary 201 for the local ISP to determine the path of roaming relationships so 202 that it can determine whether it can be paid for the transaction. 204 The purpose of the Roaming Relationship (REL) resource record is to 205 document inter-domain roaming relationships. Where DNS Security is 206 enabled, it is possible for these relationships to be authenticated 207 via use of the KEY and SIG resource records. In order to authenticate 208 the existence of a roaming relationship, the domain to which roaming 209 authority has been delegated signs the KEY resource record of the 210 domain which has done the delegation. The signature includes an expi- 211 ration date, as well as the KEY RR itself, and it is expected that the 212 expiration dates SHOULD NOT be far in the future. As a result, it is 213 expected that the roaming authority will update the SIG RR periodi- 214 cally in order to enable the relationship to continue. 216 Please note that REL resource records may be retrieved in a variety of 217 ways. When hierarchical authentication routing is being used, REL 218 resource records are typically retrieved by the local ISP's authenti- 219 cation proxy, and used both for the determination of a roaming rela- 220 tionship, and for use in authentication routing. When public key 221 authentication and DNS security are available, then it is possible for 222 the local ISP's authentication proxy to contact the home domain's 223 authentication server directly. In this case, hierarchical authentica- 224 tion routing is not necessary, and it is possible for the home 225 domain's authentication server to return signed tokens equivalent to 226 REL resource records to the local ISP's authentication proxy as 227 attributes within the authentication reply. If this is done, then the 228 local ISP's authentication proxy may not need to look up any REL 229 resource records itself, and as a result, the total time required for 230 the authentication will be decreased. This will lessen the probability 231 of a timeout. 233 4.1. REL resource record RDATA format 235 The RDATA for a REL resource record is as follows: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Preference | Flags | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 / / 243 / Domain / 244 / / 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 4.1.1. Preference 249 The Preference field, which is two octets, specifies the preference 250 given to this record versus other records of the same type and owner. 251 Lower values are preferred. 253 4.1.2. Flags 255 The flags field, which is two octets, is as follows: 256 0 1 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |U P C S I F H R R R R R R R R R| 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 U = User. If U=1, then the REL resource record represents an individ- 262 ual user or account. The user name is represented the same way as in 263 the SOA or RP resource records. As a result, fred@bigco.com will be 264 represented as fred.bigco.com. Since the DNS was not intended for use 265 as a user database, it is expected that this flag will only be set on 266 rare occasions. 268 P = Provider. If P=1, then the REL resource record represents delega- 269 tion of roaming authority from a non-ISP to an ISP or a roaming con- 270 sortia. 272 C = Consortia. If C=1, then the REL resource record represents delega- 273 tion of roaming authority from an ISP to a roaming consortia. 275 S = Accounting agent. If S=1, then a accounting agent exists within 276 the domain. 278 I = Internet access. If I=1, then the REL resource record may be used 279 for provisioning of Internet access. In roaming applications this bit 280 MUST be set. 282 F = Fax. If F=1, then the REL resource record may be used for provi- 283 sioning of Internet fax. 285 H = H.323. If H=1, then the REL resource record may be used for provi- 286 sioning of H.323 conferencing. 288 R = Reserved. 290 4.1.3. Domain 292 The domain field represents the domain name to which roaming authority 293 has been delegated by the owner name. 295 4.2. Use of the Roaming Relationship (REL) Resource Record 297 The Roaming Relationship (REL) resource record uses semantics similar 298 to that of the Mail Exchange (MX) record, in that it includes a prior- 299 ity as well as the domain to which roaming authority has been dele- 300 gated. The REL resource record is of the form: 302 bigco.com. IN REL 303 10 ;priority 304 P I ;flags. P = Provider, I = Internet Access 305 ispa.com. ;domain with roaming authority 307 Here 10 refers to the priority of the REL resource record, and 308 ispa.com is the domain to which BIGCO has delegated roaming responsi- 309 bilities. The use of a priority field allows multiple relationships to 310 be represented, with authenticating ISPs checking the relationships in 311 ascending order of priority. Thus, an REL resource record of priority 312 10 would be checked before a REL resource record of priority 20. As 313 described in the previous section, letters are used to denote flag 314 bits. 316 Routes for a given domain SHOULD be given different priorities, so as 317 to allow for predictable behavior. Since routes at the same priority 318 will be round-robined, this will result in alternation of routes. 319 Unless there is a good reason for balancing the load this way, this 320 approach SHOULD NOT be used. 322 5. Examples 324 5.1. Example One 326 Let us assume that Fred is an employee of BIGCO, who has established 327 roaming relationships with ISPA and ISPC, both of which are members of 328 roaming consortia ISPGROUP1. BIGCO also has a relationship with clear- 329 ing houses ISPGROUP2 and ISPGROUP3. ISPB is a member of the ISPGROUP1 330 roaming consortia. 332 The REL resource records for BIGCO appear as follows: 334 bigco.com. IN REL 10 P I ispa.com. 335 bigco.com. IN REL 20 P I ispc.com. 336 bigco.com. IN REL 30 P I ispgroup3.com. 337 bigco.com. IN REL 40 P I ispgroup2.com. 339 The REL resource records for ISPA, ISPB, ISPC, ISPGROUP1, ISPGROUP2 340 and ISPGROUP3 appear as follows: 342 ispa.com. IN REL 10 C I ispgroup1.com. 344 ispb.com. IN REL 10 C I ispgroup1.com. 346 ispc.com. IN REL 10 C I ispgroup1.com. 348 ispgroup1.com. IN REL 10 C I S ispgroup1.com. 350 ispgroup2.com. IN REL 10 C I S ispgroup2.com. 352 ispgroup3.com. IN REL 10 C I S ispgroup3.com. 354 5.1.1. Sequence of events 356 Fred logs into ISPB as fred@bigco.com; as a result the ISPB authenti- 357 cation proxy receives this NAI. ISPB's authentication proxy first 358 checks for the presence of a user record for fred.bigco.com. If so, 359 then it retrieves the REL resource records for the domain to whom Fred 360 has delegated roaming authority. If there is no user record, then it 361 checks its configuration files to see whether bigco.com is one of the 362 domains with whom it has a direct roaming relationship. This check 363 will fail since BIGCO has no direct roaming relationship with ISPB. As 364 a result, ISPB's authentication proxy will need to retrieve REL 365 resource records either from its own cache or from the bigco.com zone. 367 Assuming that ISPB's authentication proxy does not support public key 368 authentication, then hierarchical authentication routing will be used. 369 In this case, ISPB's authentication proxy will need to retrieve REL 370 resource records from the bigco.com zone. If ISPB's authentication 371 proxy supports public key authentication and ISPEC, then rather than 372 immediately retrieving REL resource records, it will retrieve the SRV, 373 KEY and SIG resource records for the bigco.com zone. Using the SRV 374 resource record, ISPB's authentication proxy can locate the authenti- 375 cation proxy for the bigco.com domain. The SIG resource records for 376 the bigco.com zone can then be retrieved in order to determine whether 377 the bigco.com authentication server supports public key authentica- 378 tion. If so, then ISPB's authentication proxy may contact the 379 bigco.com authentication server directly. In its authentication reply, 380 the bigco.com authentication server may return the REL resource 381 records for its zone as well as those of the zones to which it has 382 delegated roaming authority, in the form of attributes within the 383 Access-Reply. If so, then ISPB's authentication proxy will be saved 384 the work of having to retrieve these resource records itself prior to 385 forwarding the authentication reply on to the NAS. 387 Once the REL resource records have been retrieved by one mechanism or 388 another, a depth first search is performed in order to select the 389 roaming relationship path. In this case, ISPB determines whether it 390 has a direct roaming relationship with ISPA (priority 10 record from 391 the bigco.com zone). If not, then it looks at the REL resource records 392 for the ispa.com domain, and determines whether it has a direct roam- 393 ing relationship with any of the domains to whom ISPA has delegated 394 roaming responsibility. In this case, ISPB determines that it has a 395 direct roaming relationship with ISPGROUP1 (priority 10 record from 396 the ispa.com zone). As a result, the roaming relationship path 397 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 398 operates an accounting agent within its domain, accounting records for 399 the transaction will be sent to ISPGROUP1's accounting agent. 401 If ISPA had not been a member of the ISPGROUP1 roaming consortia, then 402 the depth-first search would have terminated, and ISPB would proceed 403 to check for a business relationship on the branch represented by the 404 priority 20 REL resource record in the bigco.com zone (ispc.com). In 405 this case the roaming relationship path bigco.com/ispc.com/isp- 406 group1.com/ispb.com would have been selected. 408 If ISPB were a member of the ISPGROUP3 roaming consortia, and not a 409 member of the ISPGROUP1 or ISPGROUP2 consortia, then the breadth-first 410 search would fail on both the priority 10 and 20 branches of the 411 bigco.com tree. In this case, the business relationship path 412 bigco.com/ispgroup3.com/ispb.com would have been selected. 414 5.2. Example Two 416 Let us assume that BIGCO has branch offices in multiple locations. The 417 BIGCO branch office in Illinois has a contract with ISPA, which is a 418 member of ISPGROUP1 while the branch office in Israel has a contract 419 with ISPC, which is a member of ISPGROUP2. As a result, it is desired 420 that Fred be able to login either from Illinois or from Israel, with 421 the authentication being done by the appropriate ISP. When logging in 422 from Illinois, Fred uses the POPs of ISPB, while in Israel, he uses 423 the POPs of ISPD. 425 In this case, the REL records for BIGCO will appear as follows: 427 bigco.com. IN REL 10 P I ispa.com. 428 bigco.com. IN REL 20 P I ispc.com. 430 The records for ISPA, ISPB, ISPC, ISPD, ISPGROUP1 and ISPGROUP2 appear 431 as follows: 433 ispa.com. IN REL 10 C I ispgroup1.com. 435 ispb.com. IN REL 10 C I ispgroup1.com. 437 ispc.com. IN REL 10 C I ispgroup2.com. 439 ispd.com. IN REL 10 C I ispgroup2.com. 441 ispgroup1.com. IN REL 10 C I S ispgroup1.com. 443 ispgroup2.com. IN REL 10 C I S ispgroup2.com. 445 5.2.1. Sequence of events 447 While in the United States, Fred logs into ISPB as fred@bigco.com; as 448 a result the ISPB authentication proxy receives this NAI. ISPB's 449 authentication proxy first checks for the presence of a user record 450 for fred.bigco.com. If so, then it retrieves the REL resource records 451 for the domain to whom Fred has delegated roaming authority. If there 452 is no user record, then it checks its configuration files to see 453 whether bigco.com is one of the domains with whom it has a direct 454 roaming relationship. This check will fail since BIGCO has no direct 455 roaming relationship with ISPB. As a result, ISPB's authentication 456 proxy will need to retrieve resource records either from its own cache 457 or from the bigco.com zone. 459 Once the REL resource records have been retrieved by one mechanism or 460 another, a depth first search is performed in order to select the 461 roaming relationship path. In this case, ISPB determines whether it 462 has a direct roaming relationship with ISPA (priority 10 record from 463 the bigco.com zone). If not, then it looks at the REL resource records 464 for the ispa.com domain, and determines whether it has a direct roam- 465 ing relationship with any of the domains to whom ISPA has delegated 466 roaming responsibility. In this case, ISPB determines that it has a 467 direct roaming relationship with ISPGROUP1 (priority 10 record from 468 the ispa.com zone). As a result, the roaming relationship path 469 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 470 operates a accounting agent within its domain, accounting records for 471 the transaction will be sent to ISPGROUP1's accounting agent. 473 While in Israel, Fred logs into ISPD as fred@bigco.com; as a result, 474 the ISPD authentication proxy receives this NAI. ISPD's authentication 475 proxy then checks its configuration files to see whether bigco.com is 476 one of the domains with whom it has a direct roaming relationship. 477 This check will fail since BIGCO has no direct roaming relationship 478 with ISPD. As a result, ISPD's authentication proxy will need to 479 retrieve REL resource records either from its own cache or from the 480 bigco.com zone. 482 Once the REL resource records have been retrieved by one mechanism or 483 another, a depth first search is performed in order to select the 484 roaming relationship path. In this case, ISPD determines whether it 485 has a direct roaming relationship with ISPA (priority 10 record from 486 the bigco.com zone). If not, then it looks at the REL resource records 487 for the ispa.com domain, and determines whether it has a direct roam- 488 ing relationship with any of the domains to whom ISPA has delegated 489 roaming responsibility. In this case, ISPD determines that no roaming 490 relationship path exists passing through ISPA. 492 As a result, ISPD checks for a roaming relationship path on the ISPC 493 branch (priority 20 REL resource record from the bigco.com zone). 494 First, it determines whether there is a direct roaming relationship 495 between ISPD and ISPC (there is not). Then it looks at the REL records 496 for the ispc.com domain, and determines whether it has a direct roam- 497 ing relationship with any of the domains to whom ISPC has delegated 498 roaming responsibility. In this case, ISPD determines that it has a 499 direct roaming relationship with ISPGROUP2 (priority 10 REL resource 500 record from the ispc.com zone). As a result, the roaming relationship 501 path bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. Since ISP- 502 GROUP2 operates a accounting agent within its domain, accounting 503 records for the transaction will be sent to ISPGROUP2's accounting 504 agent. 506 5.3. Example Three 508 Let us assume that Fred wishes to travel to a country which is not 509 served by the roaming consortia that BIGCO's provider ISPA has joined. 510 In this case, Fred will wish to make use of the user REL resource 511 record. 513 In this case, the REL resource records for BIGCO will appear as fol- 514 lows: 516 bigco.com. IN REL 10 P I ispa.com. 517 fred.bigco.com. IN REL 10 U I ispe.com. 519 The records for ISPA, ISPB, ISPD, ISPGROUP1 and ISPGROUP2 appear as 520 follows: 522 ispa.com. IN REL 10 C I ispgroup1.com. 524 ispb.com. IN REL 10 C I ispgroup1.com. 525 ispb.com. IN REL 10 C I ispgroup2.com. 527 ispe.com. IN REL 10 C I ispgroup2.com. 529 ispgroup1.com. IN REL 10 C I S ispgroup1.com. 531 ispgroup2.com. IN REL 10 C I S ispgroup2.com. 533 5.3.1. Sequence of events 535 While traveling, Fred logs into ISPB as fred@bigco.com; as a result 536 the ISPB authentication proxy receives this NAI. ISPB's authentication 537 proxy first checks for the presence of a user record for 538 fred.bigco.com. If so, then it retrieves the REL resource records for 539 the domain to whom Fred has delegated roaming authority. In this case, 540 a user record exists for fred@bigco.com, so that the authentication 541 proxy determines whether it has a direct roaming relationship with 542 ISPE (priority 10 REL resource record from the fred.bigco.com zone). 543 If not, then it looks at the REL resource records for the ispe.com 544 domain, and determines whether it has a direct roaming relationship 545 with any of the domains to whom ISPE has delegated roaming responsi- 546 bility. In this case, ISPB determines that it has a direct roaming 547 relationship with ISPGROUP2 (priority 10 REL resource record from the 548 ispe.com zone). As a result, the roaming relationship path 549 fred.bigco.com/ispe.com/ispgroup2.com/ispb.com is selected. Since ISP- 550 GROUP2 operates a accounting agent within its domain, accounting 551 records for the transaction will be sent to ISPGROUP2's accounting 552 agent. 554 Please note that even though Fred has a user REL resource record, the 555 authentication conversation will still be conducted between ISPB's 556 authentication proxy and BIGCO's authentication server. 558 6. Prevention of looping topologies 560 Since it is possible to create looping topologies using REL resource 561 records, a mechanism must be provided to prevent endless loops. As a 562 result, it is recommended that authentication proxies be configured 563 with a default maximum of four hops. This would support the scenario 564 of an authentication passing from a NAS to an authentication proxy, 565 from the proxy to ISPGROUP, from ISPGROUP to ISPA, and from ISPA to 566 BIGCO. 568 7. Use of the REL Resource Record Without DNS Security 570 When REL resource records are utilized without DNS security, no assur- 571 ance can be provided as to the authenticity of the roaming relation- 572 ships represented by these records. As a result, it is necessary to 573 verify the validity of the roaming relationship path by another means. 574 This can be accomplished by causing the authentication to be routed 575 along the roaming relationship path. 577 As an example, let us assume that the roaming relationship path 578 bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. If this path 579 has not been authenticated via DNS Security, then ISPD's authentica- 580 tion proxy will forward it's authentication request to ISPGROUP2, 581 including the roaming relationship path as a source route. ISPGROUP2 582 will then in turn forward the authentication to ISPC, who will forward 583 it to BIGCO. At each step of the way, a pre-existing relationship will 584 need to exist between hops in order for this authentication forwarding 585 to proceed. As a result, the act of authenticating Fred via the roam- 586 ing relationship path acts to validate the roaming relationship as 587 determined from the REL resource records. 589 Note that such hop by hop forwarding may be required even if public 590 key authentication is available for use between the local ISP's 591 authentication proxy and the home authentication server. As long as 592 the roaming relationship path has not been authenticated via some 593 method, such as DNS security, the local ISP will still need to vali- 594 date the roaming relationship path. This can be accomplished by forc- 595 ing the authentication to follow the roaming relationship path, vali- 596 dating the relationships between the proxies at each hop. 598 Please also note that public key authentication will also typically be 599 used in order to enable signed receipts to be returned by the account- 600 ing agent in response to receipt of digitally signed accounting record 601 bundles. DNS security can assist in determining what security features 602 are implemented at a given home authentication server or accounting 603 agent. Accounting agent support for MIME Security Multiparts is indi- 604 cated via use of the Email bit within the KEY resource record flag 605 field. DNS security may also be used to indicate that a home authenti- 606 cation server supports IPSEC. This is indicated via use of the IPSEC 607 bit within the KEY resource record flag field. 609 8. Use of the REL Resource Record With DNS Security 611 When used in concert with DNS Security, REL resource records may be 612 authenticated. As a result, hierarchical authentication routing is no 613 longer required in order to validate the roaming relationship path. 614 When used along with public key authentication, this permits direct 615 communication between the local ISP's authentication proxy and the 616 home authentication server. In addition, use of public key authentica- 617 tion allows for provision of additional services, such as non-repudia- 618 tion of authentication replies, as well as for return of signed 619 receipts for accounting record transfers. This section describes how 620 REL resource records may be used with DNS Security. 622 8.1. Use of KEY Resource Record 624 The KEY resource record is used in order to allow a public key to be 625 associated with a zone. 627 8.1.1. Flag Field 629 No additional flags need to be defined for use in roaming. When used 630 to secure REL resource records, bit 0 of the Key resource record flag 631 field MUST be cleared, indicating that use of the key is allowed for 632 authentication. Bit 1 may or may not be set to indicate use for confi- 633 dentiality. If the REL resource record is for a user, then bit 5 will 634 be set, indicating the use of the KEY for a user or account. Bits 6 635 and 7 (none-zone entity and zone bits) may or may not be set. If the 636 KEY resource record is for an authentication server supporting IPSEC, 637 then bit 8 will be set. If the KEY resource record is for a accounting 638 server supporting MIME Security Multiparts, then bit 9 will be set. 639 Bits 12-15, the signatory bits, may or may not be set. 641 8.1.2. Protocol field 643 When used to secure REL resource records, the value 192 will be used 644 in the protocol octet, in order to denote experimental use. Should 645 roaming technology be deployed on a widespread basis, then a value 646 between 1 and 191 will be assigned by IANA. 648 8.2. Use of the SIG Resource Record 650 Since the REL resource record is signed by the zone to whom roaming 651 authority has been delegated, rather than the parent zone, a zone that 652 has delegated roaming responsibility will typically have at least two 653 SIG records, one signed by the superzone, and at least one additional 654 SIG record, signed by the provider(s) to whom roaming authority has 655 been delegated. 657 The SIG resource record used for roaming will have a type covered of 658 REL. It will also contain a signature expiration date and the time 659 when the record was signed. Since the roaming relationship will be 660 assumed to be in force until the signature expiration, ISPs or roaming 661 consortia will typically only sign records for short periods of time. 662 Finally, the SIG resource record will contain the domain to whom roam- 663 ing responsibility has been delegated, and will be signed by that 664 domain. 666 8.2.1. Example 668 BIGCO delegates roaming authority to ISPA. As a result, ISPA provides 669 the following SIG resource record in the bigco.com zone: 671 bigco.com. SIG REL 1 2 (; type-cov=REL, alg=1, labels=2 672 1997040102030405 ; signature expiration 673 1997030112130408 ; time signed 674 31273 ; key footprint 675 ispa.com. ; signer 676 Z2fWBj8L=wevdKjOwJbakr2s4Ns=/Mox32X1rQntZPud1Fws/yIpbj7WBtIBug2w5ZrN 677 2sWgTDnrOZd9=/U94gor9k8XCsV5gOr1+2SuGnU/ ;signature (640 bits) 679 In order to secure the bigco.com zone, there will also be other SIG 680 resource records. Given the size of these records, it is possible that 681 the resource records will exceed the maximum DNS UDP packet size, and 682 a TCP transfer will be required to return all of the associated zone 683 records. 685 9. Acknowledgements 687 Thanks to Glen Zorn of Microsoft, Pat Calhoun of USR, and Michael 688 Robinson of Global One for many useful discussions of this problem 689 space. 691 10. References 693 [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- 694 tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass 695 Alliance, Asiainfo, January, 1997. 697 [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf- 698 roamops-roamreq-02.txt, Microsoft, January, 1997. 700 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 701 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 702 Daydreamer, January, 1997. 704 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 705 1997. 707 [5] R. Fajman. "An Extensible Message Format for Message Disposition 708 Notifications." draft-ietf-receipt-mdn-02.txt, National Institute of 709 Health, November, 1996. 711 [6] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." RFC 712 2015, The Aerospace Corporation, October, 1996. 714 [7] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting 715 of Mail System Administrative Messages." RFC 1892, Octel Network Ser- 716 vices, January, 1996. 718 [8] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed 719 and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo- 720 ber, 1995. 722 [9] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran- 723 denburg Consulting, March, 1995. 725 [10] M. Jansson, C. Shih, N. Turaj, R. Drummond. "MIME-based Secure 726 EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp, Drummond 727 Group, November, 1996. 729 [11] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for 730 Inter-operable Internet EDI." draft-ietf-ediint-req-01.txt, Actra, 731 LiNK, Drummond Group, May, 1995. 733 [12] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location 734 of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- 735 prises, October 1996. 737 [13] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security 738 Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August, 739 1996. 741 [14] S. Bradner. "Key words for use in RFCs to Indicate Requirement 742 Levels." draft-bradner-key-words-02.txt, Harvard University, August, 743 1996. 745 [15] C. Malmud, M. Rose. "Principles of Operation for the TPC.INT 746 Subdomain: General Principles and Policy." RFC 1530, Internet Multi- 747 casting Service, Dover Beach Consulting, Inc., October, 1993. 749 11. Authors' Addresses 751 Bernard Aboba 752 Microsoft Corporation 753 One Microsoft Way 754 Redmond, WA 98052 756 Phone: 206-936-6605 757 EMail: bernarda@microsoft.com