idnits 2.17.1 draft-ietf-roamops-dnsrr-00.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-19) 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 267 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 414 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 126: '... MUST This word, or the ad...' RFC 2119 keyword, line 130: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 133: '... SHOULD This word, or the adjec...' RFC 2119 keyword, line 139: '... SHOULD NOT...' RFC 2119 keyword, line 146: '... 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...' == (262 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 (25 February 1997) is 9915 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 685, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 703, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 706, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 710, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 714, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 717, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 725, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 737, 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 25 February 1997 7 The Roaming Relationship (RR) 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 1, 1997. Please 28 send comments to the authors. 30 2. Abstract 32 This document describes the use of the Roaming Relationship (RR) 33 record in the DNS for the description of inter-domain business rela- 34 tionships, as required for enabling of roaming. In the absence of DNS 35 security, RR records may be used for determining the existence of a 36 business relationship between the local ISP and the user's home 37 domain, as well as the location of an appropriate settlement agent. 38 However, since the RR records are not secured, other methods (such as 39 hierarchical authentication routing) must be used in order to validate 40 the business relationship path. When DNS security is implemented, the 41 business relationship path is authenticated via digital signatures, 42 and as a result, additional services may be provided, such as non- 43 repudiation of proxied authentications and signed receipts for 44 accounting record transfers. 46 3. Introduction 48 Considerable interest has arisen recently in a set of features that 49 fit within the general category of "roaming capability" for dialup 50 Internet users. Interested parties have included: 52 Regional Internet Service Providers (ISPs) operating within a 53 particular state or province, looking to combine their efforts 54 with those of other regional providers to offer dialup service 55 over a wider area. 57 National ISPs wishing to combine their operations with those of 58 one or more ISPs in another nation to offer more comprehensive 59 dialup service in a group of countries or on a continent. 61 Businesses desiring to offer their employees a comprehensive 62 package of dialup services on a global basis. Those services may 63 include Internet access as well as secure access to corporate 64 intranets via a Virtual Private Network (VPN), enabled by tunnel- 65 ing protocols such as PPTP, L2F, or L2TP. 67 This document describes the use of the Roaming Relationship (RR) 68 record in the DNS for the description of inter-domain business rela- 69 tionships, as required for enabling of roaming and other inter- 70 provider services. In the absence of DNS security, RR records may be 71 used for determining the existence of a business relationship between 72 the local ISP and the user's home domain, as well as the location of 73 an appropriate settlement agent. However, since the RR records are not 74 secured, other methods (such as hierarchical authentication routing) 75 must be used in order to validate the business relationship path. When 76 DNS security is implemented as described in [13], the business rela- 77 tionship path is authenticated via digital signatures, and as a 78 result, additional services may be provided, such as non-repudiation 79 of proxied authentications and signed receipts for accounting record 80 transfers. The latter capability is described in references [5] - 81 [11]. 83 3.1. Terminology 85 This document frequently uses the following terms: 87 phone book 88 This is a database or document containing data pertaining to 89 dialup access, including phone numbers and any associated 90 attributes. 92 phone book server 93 This is a server that maintains the latest version of the 94 phone book. Clients communicate with phone book servers in 95 order to keep their phone books up to date. 97 Network Access Server 98 The Network Access Server (NAS) is the device that clients 99 dial in order to get access to the network. 101 RADIUS server 102 This is a server which provides for authentication/autho- 103 rization via the protocol described in [3], and for account- 104 ing as described in [4]. 106 RADIUS proxy 107 In order to provide for the routing of RADIUS authentication 108 and accounting requests, a RADIUS proxy may employed. To the 109 NAS, the RADIUS proxy appears to act as a RADIUS server, and 110 to the RADIUS server, the proxy appears to act as a RADIUS 111 client. 113 RADIUS domain 114 In order to provide for the routing of RADIUS authentication 115 and accounting requests, the userID field used in PPP and in 116 the subsequent RADIUS authentication and accounting 117 requests, may contain structure. This structure provides a 118 means by which the RADIUS proxy will locate the RADIUS 119 server that is to receive the request. 121 3.2. Requirements language 123 This specification uses the same words as [14] for defining the sig- 124 nificance of each particular requirement. These words are: 126 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 127 that the definition is an absolute requirement of the speci- 128 fication. 130 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 131 nition is an absolute prohibition of the specification. 133 SHOULD This word, or the adjective "RECOMMENDED", means that there 134 may exist valid reasons in particular circumstances to 135 ignore a particular item, but the full implications must be 136 understood and carefully weighed before choosing a different 137 course. 139 SHOULD NOT 140 This phrase means that there may exist valid reasons in par- 141 ticular circumstances when the particular behavior is 142 acceptable or even useful, but the full implications should 143 be understood and the case carefully weighed before imple- 144 menting any behavior described with this label. 146 MAY This word, or the adjective "OPTIONAL", means that an item 147 is truly optional. One vendor may choose to include the 148 item because a particular marketplace requires it or because 149 the vendor feels that it enhances the product while another 150 vendor may omit the same item. An implementation which does 151 not include a particular option MUST be prepared to interop- 152 erate with another implementation which does include the 153 option, though perhaps with reduced functionality. In the 154 same vein an implementation which does include a particular 155 option MUST be prepared to interoperate with another imple- 156 mentation which does not include the option.(except, of 157 course, for the feature the option provides) 159 An implementation is not compliant if it fails to satisfy one or more 160 of the must or must not requirements for the protocols it implements. 161 An implementation that satisfies all the must, must not, should and 162 should not requirements for its protocols is said to be "uncondition- 163 ally compliant"; one that satisfies all the must and must not require- 164 ments but not all the should or should not requirements for its proto- 165 cols is said to be "conditionally compliant." 167 4. The Roaming Relationship (RR) Record 169 In order to enable roaming, it is necessary for a local provider to be 170 able to determine whether a business relationship exists between 171 itself and the user's home domain, so as to enable the local provider 172 to be paid for the use of its resources. These business relationships 173 are typically of two types: the relationship between a firm and a 174 provider, in which the firm delegates roaming authority to the 175 provider; or the relationship between a provider and a roaming associ- 176 ation, in which the provider agrees to allow members of the consortium 177 to access its network resources, in exchange for compensation. How- 178 ever, it is also possible for a company or even an individual to form 179 a direct relationship with a roaming consortia, or for consortia to 180 form a relationship with another consortia. 182 Inter-domain business relationships may extend to several levels. For 183 example, BIGCO may delegate roaming authority to ISPA, who may in turn 184 join roaming association ISPGROUP. When Fred dials into ISPB and 185 attempts to authenticate as fred@bigco.com, it is necessary for ISPB 186 to determine whether it has a means for being paid for the resources 187 consumed by Fred. This is accomplished by tracing the web of business 188 relationships backwards from the bigco.com domain, in order to deter- 189 mine whether a path of business relationships exists between ISPB and 190 BIGCO. 192 Please note that the task of determining the path of business rela- 193 tionships is orthogonal to the issue of authentication routing. Where 194 authentication proxy chaining is used, authentication routing is 195 required in order to improve scalability. However, when public key 196 authentication is available, it is possible for an authentication 197 proxy to directly contact a home authentication server. However, 198 regardless of how the authentication is routed, it is still necessary 199 for the local ISP to determine the path of business relationships so 200 that it can determine whether it can be paid for the transaction. 202 The purpose of the Roaming Relationship (RR) record is to document 203 inter-domain business relationships. Where DNS Security is enabled, it 204 is possible for these relationships to be authenticated via use of the 205 KEY and SIG RRs. In order to authenticate the existence of an inter- 206 domain roaming relationship, the domain to which roaming authority has 207 been delegated signs the KEY RR of the domain which has done the dele- 208 gation. The signature includes an expiration date, as well as the KEY 209 RR itself, and it is expected that the expiration dates SHOULD NOT be 210 far in the future. As a result, it is expected that the roaming 211 authority will update the SIG RR periodically in order to enable the 212 relationship to continue. 214 Please note that Roaming Relationship (RR) records may be retrieved in 215 a variety of ways. When hierarchical authentication routing is being 216 used, RR records are typically retrieved by the local ISP's authenti- 217 cation proxy, and used both for the determination of a business rela- 218 tionship, and for use in authentication routing. When public key 219 authentication, IPSEC and DNS security are available, then it is pos- 220 sible for the local ISP's authentication proxy to contact the home 221 domain's authentication server directly. In this case, hierarchical 222 authentication routing is not necessary, and it is possible for the 223 home domain's authentication server to return signed RR records to the 224 local ISP's authentication proxy as attributes within the authentica- 225 tion reply. If this is done, then the local ISP's authentication proxy 226 may not need to look up any RR records itself, and as a result, the 227 total time required for the authentication will be decreased. This 228 will lessen the probability of a timeout. 230 4.1. Roaming Relationship Record RDATA format 232 The RDATA for a Roaming Relationship resource record is as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Preference | Flags | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 / / 240 / Domain / 241 / / 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 4.1.1. Preference 246 The Preference field, which is two octets, specifies the preference 247 given to this record versus other records of the same type and owner. 248 Lower values are preferred. 250 4.1.2. Flags 252 The flags field, which is two octets, is as follows: 253 0 1 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |U P C S I F H R R R R R R R R R| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 U = User. If U=1, then the Roaming Relationship record represents an 260 individual user or account. The user name is represented the same way 261 as in the SOA or RP resource records. As a result, fred@bigco.com will 262 be represented as fred.bigco.com. Since the DNS was not intended for 263 use as a user database, it is expected that this flag will only be set 264 on rare occasions. 266 P = Provider. If P=1, then the Roaming Relationship record represents 267 delegation of roaming authority from a non-ISP to an ISP or a roaming 268 consortia. 270 C = Consortia. If C=1, then the Roaming Relationship record represents 271 delegation of roaming authority from an ISP to a roaming consortia. 273 S = Settlement agent. If S=1, then a settlement agent exists within 274 the domain. 276 I = Internet access. If I=1, then the Roaming Relationship record may 277 be used for provisioning of Internet access. In roaming applications 278 this bit MUST be set. 280 F = Fax. If F=1, then the Roaming Relationship record may be used for 281 provisioning of Internet fax. 283 H = H.323. If H=1, then the Roaming Relationship may be used for pro- 284 visioning of H.323 conferencing. 286 R = Reserved. 288 4.1.3. Domain 290 The domain field represents the domain name to which roaming authority 291 has been delegated by the owner name. 293 4.2. Use of the Roaming Relationship (RR) Record 295 The Roaming Relationship (RR) record uses semantics similar to that of 296 the Mail Exchange (MX) record, in that it includes a priority as well 297 as the domain to which roaming authority has been delegated. The RR 298 record is of the form: 300 bigco.com. IN RR 301 10 ;priority 302 P I ;flags. P = Provider, I = Internet Access 303 ispa.com. ;domain with roaming authority 305 Here 10 refers to the priority of the RR record, and ispa.com is the 306 domain to which BIGCO has delegated roaming responsibilities. The use 307 of a priority field allows multiple relationships to be represented, 308 with authenticating ISPs checking the relationships in ascending order 309 of priority. Thus, an RR record of priority 10 would be checked before 310 a record of priority 20. As described in the previous section, letters 311 are used to denote flag bits. 313 Routes for a given domain SHOULD be given different priorities, so as 314 to allow for predictable behavior. Since routes at the same priority 315 will be round-robined, this will result in alternation of routes. 316 Unless there is a good reason for balancing the load this way, this 317 approach SHOULD NOT be used. 319 5. Examples 321 5.1. Example One 323 Let us assume that Fred is an employee of BIGCO, who has established 324 roaming relationships with ISPA and ISPC, both of which are members of 325 roaming consortia ISPGROUP1. BIGCO also has a relationship with clear- 326 ing houses ISPGROUP2 and ISPGROUP3. ISPB is a member of the ISPGROUP1 327 roaming consortia. 329 The Roaming Relationship records for BIGCO appear as follows: 331 bigco.com. IN RR 10 P I ispa.com. 332 bigco.com. IN RR 20 P I ispc.com. 333 bigco.com. IN RR 30 P I ispgroup3.com. 334 bigco.com. IN RR 40 P I ispgroup2.com. 336 The RR records for ISPA, ISPB, ISPC, ISPGROUP1, ISPGROUP2 and ISP- 337 GROUP3 appear as follows: 339 ispa.com. IN RR 10 C I ispgroup1.com. 341 ispb.com. IN RR 10 C I ispgroup1.com. 343 ispc.com. IN RR 10 C I ispgroup1.com. 345 ispgroup1.com. IN RR 10 C I S ispgroup1.com. 347 ispgroup2.com. IN RR 10 C I S ispgroup2.com. 349 ispgroup3.com. IN RR 10 C I S ispgroup3.com. 351 5.1.1. Sequence of events 353 Fred logs into ISPB as fred@bigco.com; as a result the ISPB authenti- 354 cation proxy receives this NAI. ISPB's authentication proxy first 355 checks for the presence of a user record for fred.bigco.com. If so, 356 then it retrieves the RR resource records for the domain to whom Fred 357 has delegated roaming authority. If there is no user record, then it 358 checks its configuration files to see whether bigco.com is one of the 359 domains with whom it has a direct business relationship. This check 360 will fail since BIGCO has no direct business relationship with ISPB. 361 As a result, ISPB's authentication proxy will need to retrieve 362 resource records either from its own cache or from the bigco.com zone. 364 Assuming that ISPB's authentication proxy does not support public key 365 authentication and IPSEC, then hierarchical authentication routing 366 will be used. In this case, ISPB's authentication proxy will need to 367 retrieve RR resource records from the bigco.com zone. If ISPB's 368 authentication proxy supports public key authentication and ISPEC, 369 then rather than immediately retrieving RR resource records, it will 370 retrieve the SRV, KEY and SIG resource records for the bigco.com zone. 371 Using the SRV resource record, ISPB's authentication proxy can locate 372 the authentication proxy for the bigco.com domain. The SIG resource 373 records for the bigco.com zone can then be retrieved in order to 374 determine whether the bigco.com authentication server supports IPSEC. 375 If so, then ISPB's authentication proxy may contact the bigco.com 376 authentication server directly. In this case, only the IPSEC AH header 377 need be used, since only authentication services are required. In its 378 authentication reply, the bigco.com authentication server may return 379 the RR records for its zone as well as those of the zones to which it 380 has delegated roaming authority, in the form of attributes within the 381 Access-Reply. If so, then ISPB's authentication proxy will be saved 382 the work of having to retrieve these resource records itself prior to 383 forwarding the authentication reply on to the NAS. 385 Once the RR resource records have been retrieved by one mechanism or 386 another, a depth first search is performed in order to select the 387 business relationship path. In this case, ISPB determines whether it 388 has a direct business relationship with ISPA (priority 10 record from 389 the bigco.com zone). If not, then it looks at the RR records for the 390 ispa.com domain, and determines whether it has a direct business rela- 391 tionship with any of the domains to whom ISPA has delegated roaming 392 responsibility. In this case, ISPB determines that it has a direct 393 business relationship with ISPGROUP1 (priority 10 record from the 394 ispa.com zone). As a result, the business relationship path 395 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 396 operates a settlement agent within its domain, accounting records for 397 the transaction will be sent to ISPGROUP1's settlement agent. 399 If ISPA had not been a member of the ISPGROUP1 roaming consortia, then 400 the depth-first search would have terminated, and ISPB would proceed 401 to check for a business relationship on the branch represented by the 402 priority 20 record in the bigco.com zone (ispc.com). In this case the 403 business relationship path bigco.com/ispc.com/ispgroup1.com/ispb.com 404 would have been selected. 406 If ISPB were a member of the ISPGROUP3 roaming consortia, and not a 407 member of the ISPGROUP1 or ISPGROUP2 consortia, then the breadth-first 408 search would fail on both the priority 10 and 20 branches of the 409 bigco.com tree. In this case, the business relationship path 410 bigco.com/ispgroup3.com/ispb.com would have been selected. 412 5.2. Example Two 414 Let us assume that BIGCO has branch offices in multiple locations. The 415 BIGCO branch office in Illinois has a contract with ISPA, which is a 416 member of ISPGROUP1 while the branch office in Israel has a contract 417 with ISPC, which is a member of ISPGROUP2. As a result, it is desired 418 that Fred be able to login either from Illinois or from Israel, with 419 the authentication being done by the appropriate ISP. When logging in 420 from Illinois, Fred uses the POPs of ISPB, while in Israel, he uses 421 the POPs of ISPD. 423 In this case, the RR records for BIGCO will appear as follows: 425 bigco.com. IN RR 10 P I ispa.com. 426 bigco.com. IN RR 20 P I ispc.com. 428 The records for ISPA, ISPB, ISPC, ISPD, ISPGROUP1 and ISPGROUP2 appear 429 as follows: 431 ispa.com. IN RR 10 C I ispgroup1.com. 433 ispb.com. IN RR 10 C I ispgroup1.com. 435 ispc.com. IN RR 10 C I ispgroup2.com. 437 ispd.com. IN RR 10 C I ispgroup2.com. 439 ispgroup1.com. IN RR 10 C I S ispgroup1.com. 441 ispgroup2.com. IN RR 10 C I S ispgroup2.com. 443 5.2.1. Sequence of events 445 While in the United States, Fred logs into ISPB as fred@bigco.com; as 446 a result the ISPB authentication proxy receives this NAI. ISPB's 447 authentication proxy first checks for the presence of a user record 448 for fred.bigco.com. If so, then it retrieves the RR resource records 449 for the domain to whom Fred has delegated roaming authority. If there 450 is no user record, then it checks its configuration files to see 451 whether bigco.com is one of the domains with whom it has a direct 452 business relationship. This check will fail since BIGCO has no direct 453 business relationship with ISPB. As a result, ISPB's authentication 454 proxy will need to retrieve resource records either from its own cache 455 or from the bigco.com zone. 457 Once the RR resource records have been retrieved by one mechanism or 458 another, a depth first search is performed in order to select the 459 business relationship path. In this case, ISPB determines whether it 460 has a direct business relationship with ISPA (priority 10 record from 461 the bigco.com zone). If not, then it looks at the RR records for the 462 ispa.com domain, and determines whether it has a direct business rela- 463 tionship with any of the domains to whom ISPA has delegated roaming 464 responsibility. In this case, ISPB determines that it has a direct 465 business relationship with ISPGROUP1 (priority 10 record from the 466 ispa.com zone). As a result, the business relationship path 467 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 468 operates a settlement agent within its domain, accounting records for 469 the transaction will be sent to ISPGROUP1's settlement agent. 471 While in Israel, Fred logs into ISPD as fred@bigco.com; as a result, 472 the ISPD authentication proxy receives this NAI. ISPD's authentication 473 proxy then checks its configuration files to see whether bigco.com is 474 one of the domains with whom it has a direct business relationship. 475 This check will fail since BIGCO has no direct business relationship 476 with ISPD. As a result, ISPD's authentication proxy will need to 477 retrieve resource records either from its own cache or from the 478 bigco.com zone. 480 Once the RR resource records have been retrieved by one mechanism or 481 another, a depth first search is performed in order to select the 482 business relationship path. In this case, ISPD determines whether it 483 has a direct business relationship with ISPA (priority 10 record from 484 the bigco.com zone). If not, then it looks at the RR records for the 485 ispa.com domain, and etermines whether it has a direct business rela- 486 tionship with any of the domains to whom ISPA has delegated roaming 487 responsibility. In this case, ISPD determines that no business rela- 488 tionship path exists going through ISPA. 490 As a result, ISPD checks for a business relationship on the ISPC 491 branch (priority 20 record from the bigco.com zone). First, it deter- 492 mines whether there is a direct business relationship between ISPD and 493 ISPC (there is not). Then it looks at the RR records for the ispc.com 494 domain, and determines whether it has a direct business relationship 495 with any of the domains to whom ISPC has delegated roaming responsi- 496 bility. In this case, ISPD determines that it has a direct business 497 relationship with ISPGROUP2 (priority 10 record from the ispc.com 498 zone). As a result, the business relationship path 499 bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. Since ISPGROUP2 500 operates a settlement agent within its domain, accounting records for 501 the transaction will be sent to ISPGROUP2's settlement agent. 503 5.3. Example Three 505 Let us assume that Fred wishes to travel to a country which is not 506 served by the roaming consortia that BIGCO's provider ISPA has joined. 507 In this case, Fred will wish to make use of the user roaming relation- 508 ship resource record. 510 In this case, the RR records for BIGCO will appear as follows: 512 bigco.com. IN RR 10 P I ispa.com. 513 fred.bigco.com. IN RR 10 U I ispe.com. 515 The records for ISPA, ISPB, ISPD, ISPGROUP1 and ISPGROUP2 appear as 516 follows: 518 ispa.com. IN RR 10 C I ispgroup1.com. 520 ispb.com. IN RR 10 C I ispgroup1.com. 521 ispb.com. IN RR 10 C I ispgroup2.com. 523 ispe.com. IN RR 10 C I ispgroup2.com. 525 ispgroup1.com. IN RR 10 C I S ispgroup1.com. 527 ispgroup2.com. IN RR 10 C I S ispgroup2.com. 529 5.3.1. Sequence of events 531 While traveling, Fred logs into ISPB as fred@bigco.com; as a result 532 the ISPB authentication proxy receives this NAI. ISPB's authentication 533 proxy first checks for the presence of a user record for 534 fred.bigco.com. If so, then it retrieves the RR resource records for 535 the domain to whom Fred has delegated roaming authority. In this case, 536 a user record exists for fred@bigco.com, so that the authentication 537 proxy determines whether it has a direct business relationship with 538 ISPE (priority 10 record from the fred.bigco.com zone). If not, then 539 it looks at the RR records for the ispe.com domain, and determines 540 whether it has a direct business relationship with any of the domains 541 to whom ISPE has delegated roaming responsibility. In this case, ISPB 542 determines that it has a direct business relationship with ISPGROUP2 543 (priority 10 record from the ispe.com zone). As a result, the business 544 relationship path fred.bigco.com/ispe.com/ispgroup2.com/ispb.com is 545 selected. Since ISPGROUP2 operates a settlement agent within its 546 domain, accounting records for the transaction will be sent to ISP- 547 GROUP2's settlement agent. 549 Please note that even though Fred has a user Roaming Relationship 550 record, the authentication conversation will still be conducted 551 between ISPB's authentication proxy and BIGCO's authentication server. 553 6. Prevention of looping topologies 555 Since it is possible to create looping topologies using Roaming Rela- 556 tionship records, a mechanism must be provided to prevent endless 557 loops. As a result, it is recommended that authentication proxies be 558 configured with a default maximum of four hops. This would support the 559 scenario of an authentication passing from a NAS to an authentication 560 proxy, from the proxy to ISPGROUP, from ISPGROUP to ISPA, and from 561 ISPA to BIGCO. 563 7. Use of the RR Record Without DNS Security 565 When Roaming Relationship resource records are utilized without DNS 566 security, no assurance can be provided as to the authenticity of the 567 business relationships represented by these records. As a result, it 568 is necessary to verify the validity of the business relationship path 569 by another means. This can be accomplished by causing the authentica- 570 tion to be routed along the business relationship path. 572 As an example, let us assume that the business relationship path 573 bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. If this path 574 has not been authenticated via DNS Security, then ISPD's authentica- 575 tion proxy will forward it's authentication request to ISPGROUP2, 576 including the business relationship path as a source route. ISPGROUP2 577 will then in turn forward the authentication to ISPC, who will forward 578 it to BIGCO. At each step of the way, a pre-existing relationship will 579 need to exist between hops in order for this authentication forwarding 580 to proceed. As a result, the act of authenticating Fred via the busi- 581 ness relationship path acts to validate the business relationship as 582 determined from the RR resource records. 584 Note that such hop by hop forwarding is required even if IPSEC and 585 public key authentication is available for use between the local ISP's 586 authentication proxy and the home authentication server, as long as 587 the business relationship path has not been authenticated via DNS 588 Security. This is because while the authentication end-points might be 589 able to communicate securely without need for hierarchical authentica- 590 tion routing, the local ISP still needs to validate the business rela- 591 tionship path. 593 Please also note that DNS Security will also typically be used in 594 order to enable signed receipts to be returned by the settlement agent 595 in response to receipt of digitally signed accounting record bundles. 596 Settlement agent support for MIME Security Multiparts is indicated via 597 use of the Email bit within the KEY resource record flag field. DNS 598 Security may also be used to indicate that a home authentication 599 server supports IPSEC. This is indicated via use of the IPSEC bit 600 within the KEY resource record flag field. 602 8. Use of the RR Record With DNS Security 604 When used in concert with DNS Security, RR resource records may be 605 authenticated. When used along with IPSEC, this permits direct commu- 606 nication between the local ISP's authentication proxy and the home 607 authentication server. In addition, support for DNS Security allows 608 for provision of additional services, such as non-repudiation of 609 authentication replies, as well as for return of signed receipts for 610 accounting record transfers. This is accomplished via use of the KEY, 611 and SIG resource records. 613 8.1. Use of KEY Resource Record 615 The KEY resource record is used in order to allow a public key to be 616 associated with a zone. 618 8.1.1. Flag Field 620 No additional flags need to be defined for use in roaming. When used 621 to secure Roaming Relationship resource records, bit 0 of the Key 622 resource record flag field MUST be cleared, indicating that use of the 623 key is allowed for authentication. Bit 1 may or may not be set to 624 indicate use for confidentiality. If the Roaming Relationship record 625 is for a user, then bit 5 will be set, indicating the use of the KEY 626 for a user or account. Bits 6 and 7 (none-zone entity and zone bits) 627 may or may not be set. If the KEY resource record is for an authenti- 628 cation server supporting IPSEC, then bit 8 will be set. If the KEY 629 resource record is for a settlement server supporting MIME Security 630 Multiparts, then bit 9 will be set. Bits 12-15, the signatory bits, 631 may or may not be set. 633 8.1.2. Protocol field 635 When used to secure Roaming Relationship resource records, the value 636 192 will be used in the protocol octet, in order to denote experimen- 637 tal use. Should roaming technology be deployed on a widespread basis, 638 then a value between 1 and 191 will be assigned by IANA. 640 8.2. Use of the SIG Resource Record 642 Since the Roaming Relationship record is signed by the zone to whom 643 roaming authority has been delegated, rather than the parent zone, a 644 zone that has delegated roaming responsibility will typically have at 645 least two SIG records, one signed by the superzone, and at least one 646 additional SIG record, signed by the provider(s) to who roaming 647 authority has been delegated. 649 The SIG resource record used for roaming will have a type covered of 650 RR. It will also contain a signature expiration date and the time when 651 the record was signed. Since the roaming relationship will be assumed 652 to be in force until the signature expiration, ISPs or roaming consor- 653 tia will typically only sign records for short periods of time. 654 Finally, the SIG resource record will contain the domain to whom roam- 655 ing responsibility has been delegated, and will be signed by that 656 domain. 658 8.2.1. Example 660 BIGCO delegates roaming authority to ISPA. As a result, ISPA provides 661 the following SIG resource record in the bigco.com zone: 663 bigco.com. SIG RR 1 2 (; type-cov=RR, alg=1, labels=2 664 1997040102030405 ; signature expiration 665 1997030112130408 ; time signed 666 31273 ; key footprint 667 ispa.com. ; signer 668 Z2fWBj8L=wevdKjOwJbakr2s4Ns=/Mox32X1rQntZPud1Fws/yIpbj7WBtIBug2w5ZrN 669 2sWgTDnrOZd9=/U94gor9k8XCsV5gOr1+2SuGnU/ ;signature (640 bits) 671 In order to secure the bigco.com zone, there will also be other SIG 672 resource records. Given the size of these records, it is possible that 673 the resource records will exceed the maximum DNS UDP packet size, and 674 a TCP transfer will be required to return all of the associated zone 675 records. 677 9. Acknowledgements 679 Thanks to Glen Zorn of Microsoft, Pat Calhoun of USR, and Michael 680 Robinson of Asiainfo for many useful discussions of this problem 681 space. 683 10. References 685 [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- 686 tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass 687 Alliance, Asiainfo, January, 1997. 689 [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf- 690 roamops-roamreq-02.txt, Microsoft, January, 1997. 692 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 693 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 694 Daydreamer, January, 1997. 696 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 697 1997. 699 [5] R. Fajman. "An Extensible Message Format for Message Disposition 700 Notifications." draft-ietf-receipt-mdn-02.txt, National Institute of 701 Health, November, 1996. 703 [6] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." RFC 704 2015, The Aerospace Corporation, October, 1996. 706 [7] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting 707 of Mail System Administrative Messages." RFC 1892, Octel Network Ser- 708 vices, January, 1996. 710 [8] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed 711 and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo- 712 ber, 1995. 714 [9] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran- 715 denburg Consulting, March, 1995. 717 [10] M. Jansson, C. Shih, N. Turaj, R. Drummond. "MIME-based Secure 718 EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp, Drummond 719 Group, November, 1996. 721 [11] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for 722 Inter-operable Internet EDI." draft-ietf-ediint-req-01.txt, Actra, 723 LiNK, Drummond Group, May, 1995. 725 [12] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location 726 of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- 727 prises, October 1996. 729 [13] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security 730 Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August, 731 1996. 733 [14] S. Bradner. "Key words for use in RFCs to Indicate Requirement 734 Levels." draft-bradner-key-words-02.txt, Harvard University, August, 735 1996. 737 [15] C. Malmud, M. Rose. "Principles of Operation for the TPC.INT 738 Subdomain: General Principles and Policy." RFC 1530, Internet Multi- 739 casting Service, Dover Beach Consulting, Inc., October, 1993. 741 11. Authors' Addresses 743 Bernard Aboba 744 Microsoft Corporation 745 One Microsoft Way 746 Redmond, WA 98052 748 Phone: 206-936-6605 749 EMail: bernarda@microsoft.com