HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:12:52 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 05 Mar 1997 00:15:00 GMT ETag: "361bba-a321-331cbb04" Accept-Ranges: bytes Content-Length: 41761 Connection: close Content-Type: text/plain ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation 1 March 1997 The Roaming Relationship (RR) Record in the DNS 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires September 1, 1997. Please send comments to the authors. 2. Abstract This document describes the use of the Roaming Relationship (RR) record in the DNS for the description of roaming relationships. In the absence of DNS security, RR records may be used for determining the existence of a roaming relationship path between the local ISP and the user's home domain, as well as the location of an appropriate account- ing agent. However, since the RR records are not secured, other meth- ods (such as hierarchical authentication routing) must be used in order to validate the roaming relationship path. When DNS security is implemented, the roaming relationship path is authenticated via digi- tal signatures, and as a result, additional services may be provided, such as non-repudiation of proxied authentications and signed receipts for accounting record transfers. 3. Introduction Considerable interest has arisen recently in a set of features that fit within the general category of "roaming capability" for dialup Internet users. Interested parties have included: Regional Internet Service Providers (ISPs) operating within a Aboba [Page 1] INTERNET-DRAFT 1 March 1997 particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service over a wider area. National ISPs wishing to combine their operations with those of one or more ISPs in another nation to offer more comprehensive dialup service in a group of countries or on a continent. Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services may include Internet access as well as secure access to corporate intranets via a Virtual Private Network (VPN), enabled by tunnel- ing protocols such as PPTP, L2F, or L2TP. This document describes the use of the Roaming Relationship (RR) record in the DNS for the description of inter-domain roaming rela- tionships, as required for enabling of roaming and other inter- provider services. In the absence of DNS security, RR records may be used for determining the existence of a roaming relationship between the local ISP and the user's home domain, as well as the location of an appropriate accounting agent. However, since the RR records are not secured, other methods (such as hierarchical authentication routing) must be used in order to validate the roaming relationship path. When DNS security is implemented as described in [13], the roaming rela- tionship path is authenticated via digital signatures, and as a result, additional services may be provided, such as non-repudiation of proxied authentications and signed receipts for accounting record transfers. The latter capability is described in references [5] - [11]. 3.1. Terminology This document frequently uses the following terms: roaming relationship path The roaming relationship path is the series of roaming rela- tionships that link together a local ISP and user's home domain. The roaming relationship path may or may not be the same as the authentication route, depending on whether the local proxy is able to directly contact the home authentica- tion server. authentication route The route that an authentication will take in traveling between the local ISP's authentication proxy and the home authentication server. Where RADIUS proxy authentication is used, the authentication route follows the roaming relation- ship path. Network Access Server The Network Access Server (NAS) is the device that clients dial in order to get access to the network. Aboba [Page 2] INTERNET-DRAFT 1 March 1997 RADIUS server This is a server which provides for authentication/autho- rization via the protocol described in [3], and for account- ing as described in [4]. RADIUS proxy In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy may employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client. RADIUS domain In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP and in the subsequent RADIUS authentication and accounting requests, may contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. 3.2. Requirements language This specification uses the same words as [14] for defining the sig- nificance of each particular requirement. These words are: MUST This word, or the adjectives "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the speci- fication. MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- nition is an absolute prohibition of the specification. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in par- ticular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before imple- menting any behavior described with this label. MAY This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interop- erate with another implementation which does include the Aboba [Page 3] INTERNET-DRAFT 1 March 1997 option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another imple- mentation which does not include the option.(except, of course, for the feature the option provides) An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "uncondition- ally compliant"; one that satisfies all the must and must not require- ments but not all the should or should not requirements for its proto- cols is said to be "conditionally compliant." 4. The Roaming Relationship (RR) Record In order to enable roaming, it is necessary for a local provider to be able to determine whether a roaming relationship path exists between itself and the user's home domain, so as to enable the local provider to be paid for the use of its resources. These roaming relationships are typically of two types: the relationship between a firm and a provider, in which the firm delegates roaming authority to the provider; or the relationship between a provider and a roaming associ- ation, in which the provider agrees to allow members of the consortium to access its network resources, in exchange for compensation. How- ever, it is also possible for a company or even an individual to form a direct relationship with a roaming consortia, or for consortia to form a relationship with another consortia. Inter-domain roaming relationships may extend to several levels. For example, BIGCO may delegate roaming authority to ISPA, who may in turn join roaming association ISPGROUP. When Fred dials into ISPB and attempts to authenticate as fred@bigco.com, it is necessary for ISPB to determine whether it has a means for being paid for the resources consumed by Fred. This is accomplished by tracing the web of roaming relationships backwards from the bigco.com domain, in order to deter- mine whether a path of roaming relationships exists between ISPB and BIGCO. Please note that the task of determining the path of roaming relation- ships is orthogonal to the issue of authentication routing. Where authentication proxy chaining is used, authentication routing is required in order to improve scalability. However, when public key authentication is available, it is possible for an authentication proxy to directly contact a home authentication server. However, regardless of how the authentication is routed, it is still necessary for the local ISP to determine the path of roaming relationships so that it can determine whether it can be paid for the transaction. The purpose of the Roaming Relationship (RR) record is to document inter-domain roaming relationships. Where DNS Security is enabled, it is possible for these relationships to be authenticated via use of the KEY and SIG RRs. In order to authenticate the existence of a roaming Aboba [Page 4] INTERNET-DRAFT 1 March 1997 relationship, the domain to which roaming authority has been delegated signs the KEY RR of the domain which has done the delegation. The sig- nature includes an expiration date, as well as the KEY RR itself, and it is expected that the expiration dates SHOULD NOT be far in the future. As a result, it is expected that the roaming authority will update the SIG RR periodically in order to enable the relationship to continue. Please note that Roaming Relationship (RR) records may be retrieved in a variety of ways. When hierarchical authentication routing is being used, RR records are typically retrieved by the local ISP's authenti- cation proxy, and used both for the determination of a roaming rela- tionship, and for use in authentication routing. When public key authentication, IPSEC and DNS security are available, then it is pos- sible for the local ISP's authentication proxy to contact the home domain's authentication server directly. In this case, hierarchical authentication routing is not necessary, and it is possible for the home domain's authentication server to return signed Roaming Relation- ship resource records to the local ISP's authentication proxy as attributes within the authentication reply. If this is done, then the local ISP's authentication proxy may not need to look up any Roaming Relationship resource records itself, and as a result, the total time required for the authentication will be decreased. This will lessen the probability of a timeout. 4.1. Roaming Relationship resource record RDATA format The RDATA for a Roaming Relationship resource record is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Domain / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1. Preference The Preference field, which is two octets, specifies the preference given to this record versus other records of the same type and owner. Lower values are preferred. 4.1.2. Flags The flags field, which is two octets, is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba [Page 5] INTERNET-DRAFT 1 March 1997 |U P C S I F H R R R R R R R R R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U = User. If U=1, then the Roaming Relationship record represents an individual user or account. The user name is represented the same way as in the SOA or RP resource records. As a result, fred@bigco.com will be represented as fred.bigco.com. Since the DNS was not intended for use as a user database, it is expected that this flag will only be set on rare occasions. P = Provider. If P=1, then the Roaming Relationship record represents delegation of roaming authority from a non-ISP to an ISP or a roaming consortia. C = Consortia. If C=1, then the Roaming Relationship record represents delegation of roaming authority from an ISP to a roaming consortia. S = Accounting agent. If S=1, then a accounting agent exists within the domain. I = Internet access. If I=1, then the Roaming Relationship record may be used for provisioning of Internet access. In roaming applications this bit MUST be set. F = Fax. If F=1, then the Roaming Relationship record may be used for provisioning of Internet fax. H = H.323. If H=1, then the Roaming Relationship may be used for pro- visioning of H.323 conferencing. R = Reserved. 4.1.3. Domain The domain field represents the domain name to which roaming authority has been delegated by the owner name. 4.2. Use of the Roaming Relationship (RR) Record The Roaming Relationship (RR) record uses semantics similar to that of the Mail Exchange (MX) record, in that it includes a priority as well as the domain to which roaming authority has been delegated. The RR record is of the form: bigco.com. IN RR 10 ;priority P I ;flags. P = Provider, I = Internet Access ispa.com. ;domain with roaming authority Here 10 refers to the priority of the RR record, and ispa.com is the domain to which BIGCO has delegated roaming responsibilities. The use of a priority field allows multiple relationships to be represented, Aboba [Page 6] INTERNET-DRAFT 1 March 1997 with authenticating ISPs checking the relationships in ascending order of priority. Thus, an RR record of priority 10 would be checked before a record of priority 20. As described in the previous section, letters are used to denote flag bits. Routes for a given domain SHOULD be given different priorities, so as to allow for predictable behavior. Since routes at the same priority will be round-robined, this will result in alternation of routes. Unless there is a good reason for balancing the load this way, this approach SHOULD NOT be used. 5. Examples 5.1. Example One Let us assume that Fred is an employee of BIGCO, who has established roaming relationships with ISPA and ISPC, both of which are members of roaming consortia ISPGROUP1. BIGCO also has a relationship with clear- ing houses ISPGROUP2 and ISPGROUP3. ISPB is a member of the ISPGROUP1 roaming consortia. The Roaming Relationship records for BIGCO appear as follows: bigco.com. IN RR 10 P I ispa.com. bigco.com. IN RR 20 P I ispc.com. bigco.com. IN RR 30 P I ispgroup3.com. bigco.com. IN RR 40 P I ispgroup2.com. The RR records for ISPA, ISPB, ISPC, ISPGROUP1, ISPGROUP2 and ISP- GROUP3 appear as follows: ispa.com. IN RR 10 C I ispgroup1.com. ispb.com. IN RR 10 C I ispgroup1.com. ispc.com. IN RR 10 C I ispgroup1.com. ispgroup1.com. IN RR 10 C I S ispgroup1.com. ispgroup2.com. IN RR 10 C I S ispgroup2.com. ispgroup3.com. IN RR 10 C I S ispgroup3.com. 5.1.1. Sequence of events Fred logs into ISPB as fred@bigco.com; as a result the ISPB authenti- cation proxy receives this NAI. ISPB's authentication proxy first checks for the presence of a user record for fred.bigco.com. If so, then it retrieves the RR resource records for the domain to whom Fred has delegated roaming authority. If there is no user record, then it checks its configuration files to see whether bigco.com is one of the Aboba [Page 7] INTERNET-DRAFT 1 March 1997 domains with whom it has a direct roaming relationship. This check will fail since BIGCO has no direct roaming relationship with ISPB. As a result, ISPB's authentication proxy will need to retrieve resource records either from its own cache or from the bigco.com zone. Assuming that ISPB's authentication proxy does not support public key authentication and IPSEC, then hierarchical authentication routing will be used. In this case, ISPB's authentication proxy will need to retrieve RR resource records from the bigco.com zone. If ISPB's authentication proxy supports public key authentication and ISPEC, then rather than immediately retrieving RR resource records, it will retrieve the SRV, KEY and SIG resource records for the bigco.com zone. Using the SRV resource record, ISPB's authentication proxy can locate the authentication proxy for the bigco.com domain. The SIG resource records for the bigco.com zone can then be retrieved in order to determine whether the bigco.com authentication server supports IPSEC. If so, then ISPB's authentication proxy may contact the bigco.com authentication server directly. In this case, only the IPSEC AH header need be used, since only authentication services are required. In its authentication reply, the bigco.com authentication server may return the RR records for its zone as well as those of the zones to which it has delegated roaming authority, in the form of attributes within the Access-Reply. If so, then ISPB's authentication proxy will be saved the work of having to retrieve these resource records itself prior to forwarding the authentication reply on to the NAS. Once the RR resource records have been retrieved by one mechanism or another, a depth first search is performed in order to select the roaming relationship path. In this case, ISPB determines whether it has a direct roaming relationship with ISPA (priority 10 record from the bigco.com zone). If not, then it looks at the RR records for the ispa.com domain, and determines whether it has a direct roaming rela- tionship with any of the domains to whom ISPA has delegated roaming responsibility. In this case, ISPB determines that it has a direct roaming relationship with ISPGROUP1 (priority 10 record from the ispa.com zone). As a result, the roaming relationship path bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 operates a accounting agent within its domain, accounting records for the transaction will be sent to ISPGROUP1's accounting agent. If ISPA had not been a member of the ISPGROUP1 roaming consortia, then the depth-first search would have terminated, and ISPB would proceed to check for a business relationship on the branch represented by the priority 20 record in the bigco.com zone (ispc.com). In this case the roaming relationship path bigco.com/ispc.com/ispgroup1.com/ispb.com would have been selected. If ISPB were a member of the ISPGROUP3 roaming consortia, and not a member of the ISPGROUP1 or ISPGROUP2 consortia, then the breadth-first search would fail on both the priority 10 and 20 branches of the bigco.com tree. In this case, the business relationship path bigco.com/ispgroup3.com/ispb.com would have been selected. Aboba [Page 8] INTERNET-DRAFT 1 March 1997 5.2. Example Two Let us assume that BIGCO has branch offices in multiple locations. The BIGCO branch office in Illinois has a contract with ISPA, which is a member of ISPGROUP1 while the branch office in Israel has a contract with ISPC, which is a member of ISPGROUP2. As a result, it is desired that Fred be able to login either from Illinois or from Israel, with the authentication being done by the appropriate ISP. When logging in from Illinois, Fred uses the POPs of ISPB, while in Israel, he uses the POPs of ISPD. In this case, the RR records for BIGCO will appear as follows: bigco.com. IN RR 10 P I ispa.com. bigco.com. IN RR 20 P I ispc.com. The records for ISPA, ISPB, ISPC, ISPD, ISPGROUP1 and ISPGROUP2 appear as follows: ispa.com. IN RR 10 C I ispgroup1.com. ispb.com. IN RR 10 C I ispgroup1.com. ispc.com. IN RR 10 C I ispgroup2.com. ispd.com. IN RR 10 C I ispgroup2.com. ispgroup1.com. IN RR 10 C I S ispgroup1.com. ispgroup2.com. IN RR 10 C I S ispgroup2.com. 5.2.1. Sequence of events While in the United States, Fred logs into ISPB as fred@bigco.com; as a result the ISPB authentication proxy receives this NAI. ISPB's authentication proxy first checks for the presence of a user record for fred.bigco.com. If so, then it retrieves the RR resource records for the domain to whom Fred has delegated roaming authority. If there is no user record, then it checks its configuration files to see whether bigco.com is one of the domains with whom it has a direct roaming relationship. This check will fail since BIGCO has no direct roaming relationship with ISPB. As a result, ISPB's authentication proxy will need to retrieve resource records either from its own cache or from the bigco.com zone. Once the RR resource records have been retrieved by one mechanism or another, a depth first search is performed in order to select the roaming relationship path. In this case, ISPB determines whether it has a direct roaming relationship with ISPA (priority 10 record from the bigco.com zone). If not, then it looks at the RR records for the ispa.com domain, and determines whether it has a direct roaming rela- tionship with any of the domains to whom ISPA has delegated roaming responsibility. In this case, ISPB determines that it has a direct Aboba [Page 9] INTERNET-DRAFT 1 March 1997 roaming relationship with ISPGROUP1 (priority 10 record from the ispa.com zone). As a result, the roaming relationship path bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 operates a accounting agent within its domain, accounting records for the transaction will be sent to ISPGROUP1's accounting agent. While in Israel, Fred logs into ISPD as fred@bigco.com; as a result, the ISPD authentication proxy receives this NAI. ISPD's authentication proxy then checks its configuration files to see whether bigco.com is one of the domains with whom it has a direct roaming relationship. This check will fail since BIGCO has no direct roaming relationship with ISPD. As a result, ISPD's authentication proxy will need to retrieve resource records either from its own cache or from the bigco.com zone. Once the Roaming Relationship resource records have been retrieved by one mechanism or another, a depth first search is performed in order to select the roaming relationship path. In this case, ISPD determines whether it has a direct roaming relationship with ISPA (priority 10 record from the bigco.com zone). If not, then it looks at the RR records for the ispa.com domain, and etermines whether it has a direct roaming relationship with any of the domains to whom ISPA has dele- gated roaming responsibility. In this case, ISPD determines that no roaming relationship path exists going through ISPA. As a result, ISPD checks for a roaming relationship on the ISPC branch (priority 20 record from the bigco.com zone). First, it determines whether there is a direct roaming relationship between ISPD and ISPC (there is not). Then it looks at the RR records for the ispc.com domain, and determines whether it has a direct roaming relationship with any of the domains to whom ISPC has delegated roaming responsi- bility. In this case, ISPD determines that it has a direct roaming relationship with ISPGROUP2 (priority 10 record from the ispc.com zone). As a result, the roaming relationship path bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. Since ISPGROUP2 operates a accounting agent within its domain, accounting records for the transaction will be sent to ISPGROUP2's accounting agent. 5.3. Example Three Let us assume that Fred wishes to travel to a country which is not served by the roaming consortia that BIGCO's provider ISPA has joined. In this case, Fred will wish to make use of the user roaming relation- ship resource record. In this case, the RR records for BIGCO will appear as follows: bigco.com. IN RR 10 P I ispa.com. fred.bigco.com. IN RR 10 U I ispe.com. The records for ISPA, ISPB, ISPD, ISPGROUP1 and ISPGROUP2 appear as follows: Aboba [Page 10] INTERNET-DRAFT 1 March 1997 ispa.com. IN RR 10 C I ispgroup1.com. ispb.com. IN RR 10 C I ispgroup1.com. ispb.com. IN RR 10 C I ispgroup2.com. ispe.com. IN RR 10 C I ispgroup2.com. ispgroup1.com. IN RR 10 C I S ispgroup1.com. ispgroup2.com. IN RR 10 C I S ispgroup2.com. 5.3.1. Sequence of events While traveling, Fred logs into ISPB as fred@bigco.com; as a result the ISPB authentication proxy receives this NAI. ISPB's authentication proxy first checks for the presence of a user record for fred.bigco.com. If so, then it retrieves the RR resource records for the domain to whom Fred has delegated roaming authority. In this case, a user record exists for fred@bigco.com, so that the authentication proxy determines whether it has a direct roaming relationship with ISPE (priority 10 record from the fred.bigco.com zone). If not, then it looks at the RR records for the ispe.com domain, and determines whether it has a direct roaming relationship with any of the domains to whom ISPE has delegated roaming responsibility. In this case, ISPB determines that it has a direct roaming relationship with ISPGROUP2 (priority 10 record from the ispe.com zone). As a result, the roaming relationship path fred.bigco.com/ispe.com/ispgroup2.com/ispb.com is selected. Since ISPGROUP2 operates a accounting agent within its domain, accounting records for the transaction will be sent to ISP- GROUP2's accounting agent. Please note that even though Fred has a user Roaming Relationship record, the authentication conversation will still be conducted between ISPB's authentication proxy and BIGCO's authentication server. 6. Prevention of looping topologies Since it is possible to create looping topologies using Roaming Rela- tionship records, a mechanism must be provided to prevent endless loops. As a result, it is recommended that authentication proxies be configured with a default maximum of four hops. This would support the scenario of an authentication passing from a NAS to an authentication proxy, from the proxy to ISPGROUP, from ISPGROUP to ISPA, and from ISPA to BIGCO. 7. Use of the RR Record Without DNS Security When Roaming Relationship resource records are utilized without DNS security, no assurance can be provided as to the authenticity of the roaming relationships represented by these records. As a result, it is necessary to verify the validity of the roaming relationship path by Aboba [Page 11] INTERNET-DRAFT 1 March 1997 another means. This can be accomplished by causing the authentication to be routed along the roaming relationship path. As an example, let us assume that the roaming relationship path bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. If this path has not been authenticated via DNS Security, then ISPD's authentica- tion proxy will forward it's authentication request to ISPGROUP2, including the business relationship path as a source route. ISPGROUP2 will then in turn forward the authentication to ISPC, who will forward it to BIGCO. At each step of the way, a pre-existing relationship will need to exist between hops in order for this authentication forwarding to proceed. As a result, the act of authenticating Fred via the roam- ing relationship path acts to validate the roaming relationship as determined from the RR resource records. Note that such hop by hop forwarding is required even if IPSEC and public key authentication is available for use between the local ISP's authentication proxy and the home authentication server, as long as the roaming relationship path has not been authenticated via DNS Secu- rity. This is because while the authentication end-points might be able to communicate securely without need for hierarchical authentica- tion routing, the local ISP still needs to validate the roaming rela- tionship path. Please also note that DNS Security will also typically be used in order to enable signed receipts to be returned by the accounting agent in response to receipt of digitally signed accounting record bundles. Accounting agent support for MIME Security Multiparts is indicated via use of the Email bit within the KEY resource record flag field. DNS Security may also be used to indicate that a home authentication server supports IPSEC. This is indicated via use of the IPSEC bit within the KEY resource record flag field. 8. Use of the RR Record With DNS Security When used in concert with DNS Security, RR resource records may be authenticated. When used along with IPSEC, this permits direct commu- nication between the local ISP's authentication proxy and the home authentication server. In addition, support for DNS Security allows for provision of additional services, such as non-repudiation of authentication replies, as well as for return of signed receipts for accounting record transfers. This is accomplished via use of the KEY, and SIG resource records. 8.1. Use of KEY Resource Record The KEY resource record is used in order to allow a public key to be associated with a zone. Aboba [Page 12] INTERNET-DRAFT 1 March 1997 8.1.1. Flag Field No additional flags need to be defined for use in roaming. When used to secure Roaming Relationship resource records, bit 0 of the Key resource record flag field MUST be cleared, indicating that use of the key is allowed for authentication. Bit 1 may or may not be set to indicate use for confidentiality. If the Roaming Relationship record is for a user, then bit 5 will be set, indicating the use of the KEY for a user or account. Bits 6 and 7 (none-zone entity and zone bits) may or may not be set. If the KEY resource record is for an authenti- cation server supporting IPSEC, then bit 8 will be set. If the KEY resource record is for a accounting server supporting MIME Security Multiparts, then bit 9 will be set. Bits 12-15, the signatory bits, may or may not be set. 8.1.2. Protocol field When used to secure Roaming Relationship resource records, the value 192 will be used in the protocol octet, in order to denote experimen- tal use. Should roaming technology be deployed on a widespread basis, then a value between 1 and 191 will be assigned by IANA. 8.2. Use of the SIG Resource Record Since the Roaming Relationship record is signed by the zone to whom roaming authority has been delegated, rather than the parent zone, a zone that has delegated roaming responsibility will typically have at least two SIG records, one signed by the superzone, and at least one additional SIG record, signed by the provider(s) to who roaming authority has been delegated. The SIG resource record used for roaming will have a type covered of RR. It will also contain a signature expiration date and the time when the record was signed. Since the roaming relationship will be assumed to be in force until the signature expiration, ISPs or roaming consor- tia will typically only sign records for short periods of time. Finally, the SIG resource record will contain the domain to whom roam- ing responsibility has been delegated, and will be signed by that domain. 8.2.1. Example BIGCO delegates roaming authority to ISPA. As a result, ISPA provides the following SIG resource record in the bigco.com zone: bigco.com. SIG RR 1 2 (; type-cov=RR, alg=1, labels=2 1997040102030405 ; signature expiration 1997030112130408 ; time signed 31273 ; key footprint ispa.com. ; signer Z2fWBj8L=wevdKjOwJbakr2s4Ns=/Mox32X1rQntZPud1Fws/yIpbj7WBtIBug2w5ZrN Aboba [Page 13] INTERNET-DRAFT 1 March 1997 2sWgTDnrOZd9=/U94gor9k8XCsV5gOr1+2SuGnU/ ;signature (640 bits) In order to secure the bigco.com zone, there will also be other SIG resource records. Given the size of these records, it is possible that the resource records will exceed the maximum DNS UDP packet size, and a TCP transfer will be required to return all of the associated zone records. 9. Acknowledgements Thanks to Glen Zorn of Microsoft, Pat Calhoun of USR, and Michael Robinson of Global One for many useful discussions of this problem space. 10. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, January, 1997. [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf- roamops-roamreq-02.txt, Microsoft, January, 1997. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, Daydreamer, January, 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1997. [5] R. Fajman. "An Extensible Message Format for Message Disposition Notifications." draft-ietf-receipt-mdn-02.txt, National Institute of Health, November, 1996. [6] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." RFC 2015, The Aerospace Corporation, October, 1996. [7] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages." RFC 1892, Octel Network Ser- vices, January, 1996. [8] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo- ber, 1995. [9] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran- denburg Consulting, March, 1995. [10] M. Jansson, C. Shih, N. Turaj, R. Drummond. "MIME-based Secure EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp, Drummond Group, November, 1996. Aboba [Page 14] INTERNET-DRAFT 1 March 1997 [11] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for Inter-operable Internet EDI." draft-ietf-ediint-req-01.txt, Actra, LiNK, Drummond Group, May, 1995. [12] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- prises, October 1996. [13] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August, 1996. [14] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." draft-bradner-key-words-02.txt, Harvard University, August, 1996. [15] C. Malmud, M. Rose. "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy." RFC 1530, Internet Multi- casting Service, Dover Beach Consulting, Inc., October, 1993. 11. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 15]