HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:13:22 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 27 Nov 1996 00:16:00 GMT ETag: "361bbd-90e2-329b8840" Accept-Ranges: bytes Content-Length: 37090 Connection: close Content-Type: text/plain ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation The Network Access Identifier 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 June 1, 1997. Please send comments to the authors. 2. Abstract This document describes issues relating to user identification in pro- vision of "roaming capability" for dialup Internet users. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a for- mal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confedera- tions" and ISP-provided corporate network access support. 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 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 Aboba [Page 1] INTERNET-DRAFT 26 November 1996 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 and L2TP. This document focuses on issues of user identification for use in roaming services. However, since roaming and tunneling are closely related, it is believed that the considerations described here will also be of interest to those working on tunneling. 3.1. Terminology This document frequently uses the following terms: Network Access Identifier The Network Access Identifier (NAI) is the userID submitted by the client during the PPP negotiation. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. As such, the NAI may be presented either in the form of an authentication route, or a pointer to such a route. Please note that the NAI may not necessarily be the same as the user's e-mail address or the userID submitted in an applica- tion layer authentication (i.e. HTTP authentication). In order to avoid confusion on this point, a new term was coined. Network Access Server The Network Access Server (NAS) is the device that clients dial in order to get access to the network. In PPTP termi- nology this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). RADIUS server This is a server which provides for authentica- tion/authorization via the protocol described in [3], and for accounting 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 acts as a RADIUS server, and to the RADIUS server, the proxy acts as a RADIUS client. 3.2. Purpose As described in reference [1], there are now at least four services implementing dialup roaming, and the number of Internet Service Aboba [Page 2] INTERNET-DRAFT 26 November 1996 Providers involved in roaming consortia is increasing rapidly. In order to be able to offer roaming capability, one of the require- ments is to be able to identify the user and route the authentication request to the user's home RADIUS server. These functions are accom- plished via the NAI submitted by the user to the NAS in the initial PPP authentication. This document proposes syntax and semantics for the NAI. It is expected that this will be of interest for support of roaming as well as tunneling. For example, references [5] and [6] refer to use of the NAI in determining the tunnel endpoint. However, these references do not provide guidelines for how RADIUS or tunnel routing is to be accomplished. In order to avoid the possibility of conflicting and non-interoperable implementations, references [7] and [8] describe how RADIUS and tunneling protocols may be integrated. This document pro- vides guidance in the use of the NAI that is relevant to both the roaming and tunneling communities. 4. Requirements for roaming authentication What requirements must a roaming authentication scheme satisfy to be successful? These include: Scalability requirements As described in [2], it is highly desirable that a roaming implementation be scalable so as to accommodate at least 40 members within a roaming consortia, each serving at least 10 corporate clients. It is also desired than a roaming imple- mentation be able to handle an unlimited number of users. Ease of administration It is desirable that the chosen NAI approach be easy to administer. This means that the number of table entries or zone files maintained by service providers or corporations should be kept to a minimum. It also means that users should be forced to change their NAIs only on very rare occasions. Security The NAI approach taken must be secure, in that it must guard against attacks which could result in theft of service, or submission of fraudulent charges. In particular, the NAI approach must provide for secure determination of the loca- tion of the settlement agent. Chain of trust A successful roaming authentication scheme must be able to establish a chain of trust between remote NAS devices and home ISP servers. This can be accomplished via a variety of methods, including (in the case of RADIUS) hierarchical authentication routing, or (in the case of certificates) a Web of trust. In either case, it is necessary that it be possible to construct the hierarchical authentication route Aboba [Page 3] INTERNET-DRAFT 26 November 1996 or trust Web based on the NAI. This does not necessarily imply that the NAI is itself a representation of an authen- tication route or trust web. 4.1. Alternatives for authentication of roaming users In order to authenticate roaming users, it is necessary to be able to route the authentication requests from the NAS of the remote ISP to a server maintained by the home ISP. Since the RADIUS protocol is com- monly implemented both by NAS vendors as well as by ISPs, it is pro- posed that RADIUS be used as the mechanism for roaming authentication. Although the choice of RADIUS is expedient, it has significant draw- backs. In particular, routing of RADIUS authentication/authorization messages is complicated by the security architecture of the RADIUS protocol. The RADIUS protocol requires the maintenance of a shared secret between the NAS and the RADIUS server or proxy. Therefore, were RADIUS authentication requests to be routed directly, the result would be a requirement for maintenance of shared secrets between every NAS device and every RADIUS server. This would get out of hand very quickly. As a result, hierarchical authentication routing is a requirement for scalable authentication of roaming users via RADIUS. Authentication routes can be maintained by a number of means, includ- ing propagation of configuration files, and as described in this docu- ment, use of DNS. Note that even if DNS is used, configuration files are still necessary, since they provide the RADIUS proxy with the list of shared secrets. This list of shared secrets is also a list of sys- tems whose owners have a business relationship with the configuring ISP. Note that hierarchical authentication routing would not necessarily be required if an authentication protocol supporting certificates were used. This is because shared secrets would no longer be necessary in order for the two authentication endpoints to engage in a secure con- versation. Thus a NAS server would be able to contact the home ISP server directly. This is not necessarily as desirable as it seems at first glance. For one thing, direct contact between the NAS and the home ISP has the potential to exacerbate interoperability problems since it implies, for example, that the two end systems must be running the same accounting protocol and that the home ISP's server must be able to return configuration attributes that the remote NAS understands. Thus RADIUS proxies are useful for more than just authentication routing. Moreover, even with certificates it is still necessary for the two parties to determine whether they have a business relationship with each other. This is equivalent to verifying the validity of the cer- tificate within the web or hierarchy of trust used by the roaming con- sortium. Aboba [Page 4] INTERNET-DRAFT 26 November 1996 Thus while certificates may provide a way of automating the configura- tion process, they do not eliminate it entirely. In effect, use of certificates substitute verification of the chain of trust for routing of RADIUS authentication requests. Since certificates are not a panacea and we do not yet have a certifi- cate infrastructure in place, it is recommended that in the short to medium term, RADIUS authentication forwarding be used for authentica- tion of roaming users. 4.2. Hierarchical authentication routing Hierarchical authentication routing is implemented via a multi-tier RADIUS proxy system, with individual ISPs running their own proxies, and allowing authentication requests to be routed directly only to other members of the roaming consortium. This allows ISPs to maintain shared secrets only with the other consortium members, as well as with customers with whom they have a direct business relationship. For example, let us assume that we have n members of a roaming consor- tia, each of which have m distinct corporate customers whom they wish to provide access for. These corporate customers wish to maintain their own RADIUS servers so as to be able to manage their users more efficiently. Thus we have n * m corporate entities that wish to allow their users to have access to the facilities of the roaming consor- tium. If the RADIUS proxy of a given ISP were to contact each RADIUS server directly, each RADIUS proxy would need to maintain n * m + n - 1 shared proxy secrets. This is a shared secret for each corporate entity, plus a shared secret for each member of the roaming consor- tium. For the case of 40 roaming consortia members, each with 10 cor- porate customers, this translates to 439 shared secrets per ISP. This would be unmanageable. On the other hand, let us assume that we implement hierarchical authentication routing. In this case, the RADIUS proxy of a given ISP would only need to contact the RADIUS proxies of the other ISPs in ISPGROUP as well as the RADIUS servers of its own corporate customers. To do this, it would only need to maintain n-1+m shared secrets. For the case of 40 roaming consortia members, each with 10 corporate cus- tomers, this translates to 49 shared secrets per ISP, a dramatic reduction. 5. Authentication routing Given that hierarchical authentication routing appears to be a requirement, how can this be implemented? Several approaches have been suggested. These include: Hierarchical naming Authentication and Accounting Route (AR) records Aboba [Page 5] INTERNET-DRAFT 26 November 1996 We will explore each of these alternatives in turn. 5.1. Hierarchical naming In hierarchical naming, a combination of the authentication route and the username is used as the NAI. As a result, a RADIUS proxy acquiring an NAI will be able to determine the next hop by examination of the authentication route. Since an authentication route may have an arbi- trary number of hops, the syntax for description of such routes must not be limited in the number of hops it can represent. While many syntaxes may be used to used to denote an authentication route, in this document it is proposed that the the "/" separator character be used to separate the elements of an authentication route. Therefore, an authentication route that passed from the roaming con- sortium ISPGROUP1 to ISPA to BIGCO would be represented as ISP- GROUP1.COM/ISPA.COM/BIGCO.COM/, and the full NAI would be ISP- GROUP1.COM/ISPA.COM/BIGCO.COM/fred. This approach has the advantage of being simple. Since the authentica- tion route is embedded within the NAI, no indirection is needed to retrieve the route. Since such indirection typically depends on propa- gation of a file or a lookup in the DNS, it is likely that use of indirection will increase code complexity, as well as introduce sev- eral new error conditions. This approach also has several disadvantages. The first of these is that if BIGCO changes their ISP relationships, then it will need to change the NAIs of its users. In practice it is to be expected that corporations will reevaluate their ISP relationships on a periodic basis, and that ISPs will join and leave roaming consortia, so that this is likely to be a considerable problem, particularly for ISPs and corporations with large numbers of users. The second disadvantage is that this representation of the NAI is sub- stantially different from a typical e-mail address, which is of the form fred@bigco.com. It also may be possible that BIGCO has multiple ISP relationships. This may occur for example, if the ISPGROUP1 roam- ing consortia does not cover all of the countries that BIGCO's employ- ees wish to visit. In this case, BIGCO may also establish a relation- ship with another ISP that is a member of a consortia ISPGROUP2 that covers the desired countries. As a result, a single authentication route embedded in the NAI is not adequate to describe the ISP rela- tionships of BIGCO. In addition, the embedding of a route within the NAI may not provide information on the settlement agent to use for a given route. For example, it may be possible that ISPA and ISPB are members of two roaming consortia. In this case, the route ISPA.COM/BIGCO.COM/ does not identify which consortia's billing policies are to be in effect for the length of the call, and which settlement server to submit the accounting record to when the session is complete. Aboba [Page 6] INTERNET-DRAFT 26 November 1996 As a result, it is believed that the hierarchical naming approach is not sufficient to handle all the requirements. 5.2. Authentication and Accounting Route (AR) records One way to support hierarchical routing as well as to provide addi- tional flexibility, is to allow for indirection in the determination of authentication and accounting routes. When this approach is taken, the NAI is used to embed a pointer to an authentication and accounting route, rather than embedding the route itself. For the purposes of this specification, the convention user@domain syntax is used, with the domain portion of the NAI being used to retrieve the authentica- tion and accounting route via DNS. 5.2.1. Definition of the Authentication and Accounting Route (AR) record The Authentication and Accounting Route (AR) record uses semantics similar to that of the Mail Exchange (MX) record, in that it includes a priority as well as the authentication route. The AR record is of the form: bigco.com. IN AR 10 ispgroup1.com/ispa.com/bigco.com/ ispgroup1.com. Here 10 refers to the priority of the AR record, isp- group1.com/ispa.com/bigco.com/ is the authentication route, and isp- group1.com. represents the domain of the settlement agent. The use of a priority field allows multiple relationships to be represented, with authenticating ISPs checking the relationships in ascending order of priority. Thus, an AR record of priority 10 would be checked before a record of priority 20. 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 be avoided. 5.2.2. Example One Let us say Fred is an employee of BIGCO, who has established account relationships with ISPA and ISPC, both of which are members of roaming consortia ISPGROUP. BIGCO also has a relationship with clearing houses ISPGROUP1 and ISPGROUP2. Fred is now traveling, and logs into ISPB as fred@bigco.com. The ISPB RADIUS proxy receives this NAI. ISPB then checks bigco.com in its list of firms with whom it has a direct business relationship. This check will fail since BIGCO is not a direct customer of ISPB, and is not an ISP or roaming consortia. Aboba [Page 7] INTERNET-DRAFT 26 November 1996 ISPB now looks up the Authentication and Accounting Route Record for bigco.com, and receives the following reply: bigco.com. IN AR 10 ispa.com/bigco.com/ ispgroup.com. bigco.com. IN AR 20 ispc.com/bigco.com/ ispgroup.com. bigco.com. IN AR 30 ispgroup2.com/bigco.com/ ispgroup2.com. bigco.com. IN AR 40 ispgroup1.com/bigco.com/ ispgroup1.com. The ISPB RADIUS proxy now checks the AR records in order of priority so as to determine whether it has a business relationship with any of the domains listed in the returned AR records. The RADIUS proxy will select the first record in which there is a valid business relation- ship. In this case, ISPB's RADIUS proxy discovers that ISPA is a member of the ISPGROUP roaming consortia. As a result, the authentication request is forwarded to the authentication proxy operated by ISPA.COM. The method by which this authentication server is determined, and the method by which ISPB verifies ISPA's membership in ISPGROUP is described in a subsequent section. If ISPA was not a member of the ISPGROUP roaming consortia, ISPB's proxy would continue down the list. For example, if ISPC were a member of ISPGROUP, then it would forward the authentication request to ISPC's RADIUS proxy. If ISPB had no relationship with ISPC, then it would check to see if it had a business relationship with ISPGROUP2. In the case where a business relationship existed, the authentication would be forwarded to the authentication proxy within the isp- group2.com domain. If no business relationship existed with ISPGROUP2, then ISPB's proxy would check for a relationship with ISPGROUP1, and failing that, would send a RADIUS Access-Reject message. Let us assume that ISPA has received the forwarded authentication request. It will then check the domain portion of the NAI (bigco.com) to see if there is a direct business relationship. Since this is the case, ISPA will then retrieve the location of BIGCO's authentication server and forward the authentication request to that server. After the session is over, ISPB's RADIUS proxy will route the accounting record to the settlement agent identified in the AR record. 5.2.3. 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. In this case, the AR records for BIGCO will appear as follows: bigco.com. IN AR 10 ispa.com/bigco.com/ ispgroup1.com. bigco.com. IN AR 20 ispc.com/bigco.com/ ispgroup2.com. Aboba [Page 8] INTERNET-DRAFT 26 November 1996 As a result, when Fred attempts to authenticate with ISPB while in the United States, the authentication request will be routed to ISPA, assuming that ISPB has a business relationship with ISPA. In this case, the accounting record will be submitted to ISPGROUP1 for settle- ment. When Fred travels to Israel, and dials into ISPD, it will also check the authentication routes, and presumably will find that it has a relationship with ISPC, but not with ISPA. As a result, the authen- tication request will be forwarded to ISPC rather than ISPA, and the accounting record will be submitted to ISPGROUP2 for settlement. 6. Accounting Issues Since billing rates may differ between roaming consortia, it is neces- sary that the accounting records include the relevant authentication route and settlement agent. Since it is possible that ISPB and ISPA may both be members of more than one roaming consortia, an authentica- tion route of ispa.com/bigcom.com/ does not uniquely determine the consortia to whom the accounting record should be submitted for set- tlement. In the case of hierarchical naming, including the authentication route in the accounting record is as simple as including the NAI within the accounting record, since in this case the route is embedded within the NAI. However, using the hierarchical naming approach, information on the settlement agent is not available. As a result, ISPs using this naming approach will need to ensure that their RADIUS proxies are con- figured with information on the relevant settlement agents. For the case where a DNS AR record is used, the situation is more com- plicated. In this case, the RADIUS proxy needs to keep a forwarding table mapping RADIUS domains to authentication routes and settlement agents. When the proxy receives a RADIUS Accounting-Request message (START or STOP), it will find the authentication route and settlement agent corresponding to the NAI in the forwarding table, and will insert this in the accounting record for the session. The forwarding table is filled in as DNS AR records are received. Ordinarily an AR record is kept in the forwarding table until it times out. This implies that the forwarding table will typically remain con- stant between the time that the authentication is processed and when the accounting records are generated. The possible exceptions to this behavior are when the TTL expires in mid-session or if the RADIUS proxy server is restarted, causing a rebuilding of the forwarding table. In these cases if the AR record has changed it is possible that the existing sessions may be accounted for incorrectly. To avoid this, the RADIUS proxy MUST NOT modify the forwarding table entry for a domain with a session in progress. Aboba [Page 9] INTERNET-DRAFT 26 November 1996 7. Security issues So far, we have not described how ISPB determines whether it has a valid business relationship with ISPA, ISPC, ISPGROUP1, or ISPGROUP2. We also have not discussed how ISPB verifies the authenticity of the authentication route or settlement agent domain that it obtains from the DNS. 7.1. Verification of business relationships RADIUS proxies typically require a configuration file listing the sys- tems with which they can communicate, and the shared secrets used in that communication. Proxies will typically check this list in order to make choices among the routes included in the DNS response. 7.2. Verification of authentication and accounting routes Were an attack on the DNS to be successful, it would be possible to insert authentication and accounting route records, to change the pri- ority of existing authentication and accounting route records, or to change SRV records. We discuss the effects of each of these attacks in turn. 7.2.1. Insertion of authentication and accounting route records By insertion of authentication and accounting route records, it would be possible for an attacker to deny service. However, as long as the RADIUS proxy performed a proper check on the business relationships between itself and the domains indicated in the AR record, it would not forward authentications to the indicated domains. In addition, the use of mutual authentication in the accounting record transfer process means that the attacker would also have to steal the appropriate shared secrets or private keys in order to be able to masquerade as a legitimate settlement agent. 7.2.2. Changing the priority of existing authentication and account- ing route records Since changing the priority of existing records does not result in denial of service, or require the theft of shared secrets or private keys, it is the subtlest form of attack. The result of this attack would be a shift in business toward the ISPs or consortia that would be moved up in priority. This constitutes a theft, but would not be detectable without the use of secure DNS. 7.2.3. Changing of SRV records Were an attacker to change the RADIUS SRV records, it would be possi- ble to divert forwarded authentications to a bogus server. However, Aboba [Page 10] INTERNET-DRAFT 26 November 1996 unless the attacker had also stolen the shared secrets, the result would be denial rather than theft of service. 8. Formal Definition of the NAI As proposed in this specification, the Network Access Identifer may represent either an authentication route, or a pointer to such a route. In order to clearly distinguish the two formats, the route form of the NAI uses the "/" character as a separator, while the pointer form of the NAI uses a user@domain or user:domain format, where the domain is a fully qualified domain name (FQDN). Where a pointer is used, the domain portion of the NAI is then used to retrieve the route via DNS lookup. A new DNS record, the Authentication and Accounting Route (AR) record is used for this purpose. 8.1. BNF for the NAI The grammar for the NAI is given below, using the augmented BNF nota- tion described in reference [9]. NAI = (ROUTE [REALM "/"] USERNAME) | (USERNAME ("@" | ":") FQDN) ROUTE = *[FQDN "/"] FQDN = token "." token *[ "." token ] REALM = token USERNAME = token As defined above, the route may consist of zero or more fully quali- fied domain names (FQDNs), separated by a "/" character. Examples of valid routes include: ispgroup2.com/ispa.com/bigco.com/ ispa.com/bigco.com/ Examples of invalid routes include: ispgroup2.com/ispa/bigco.com/ ispa.com/bigco/ Examples of valid embedded-route NAIs include: ispgroup2.com/ispa.com/bigco.com/fred ispa.com/bigco/fred ispa.com/bigco.com/fred Examples of valid Authentication and Acounting Route (AR) records include: bigco.com. IN AR 10 ispgroup2.com/ispa.com/bigco.com/ ispgroup2.com. bigco.com. IN AR 10 ispa.com/bigco.com/ ispgroup.com. eng.bigco.com. IN AR 10 ispa.com/eng.bigco.com/ ispgroup2.com. Aboba [Page 11] INTERNET-DRAFT 26 November 1996 9. Resolution of authentication server addresses In order to make use of the authentication routes, it is necessary to be able to resolve the location of a domain's RADIUS authentication server, given the fully qualified domain name. The DNS SRV record, defined in [10] is used for this purpose. This SRV record uses type 33. When used to provide information on the location of the RADIUS server within a given domain, the SRV records will be of the following form: radiusauth.udp.bigco.com. IN SRV 10 0 1645 rad1.bigco.com. radiusauth.udp.bigco.com. IN SRV 20 0 1645 rad2.bigco.com. radiusacct.udp.bigco.com. IN SRV 10 0 1646 rad1.bigco.com. radiusacct.udp.bigco.com. IN SRV 20 0 1646 rad2.bigco.com. Here radiusauth denotes the RADIUS authentication service, while radiusacct denotes RADIUS accounting. Since the authentication service typically runs on port 1645 while the accounting service typically runs on port 1646, two SRV records are required to allow them to be resolved. Within each service, two records are used so as to provide backup capabilities. Thus if the server rad1.bigcom.com is not avail- able (priority 10), the server rad2.bigco.com. should be used (prior- ity 20). The weight is used in load balancing records of the same pri- ority level, and is set to zero when there is only one record at a given priority level. Further details on the SRV record format are available in [10]. 10. Resolution of settlement agent addresses SRV records will also be used for resolution of the settlement domain (included in the AR record) to an IP address and port number. When used to provide information on the location of the settlement server within a given domain, the SRV records will be of the following form: roamacct.tcp.ispgroup.com. IN SRV 10 0 1648 acct1.ispgroup.com. roamacct.tcp.ispgroup.com. IN SRV 20 0 1648 acct2.ispgroup.com. Here roamacct denotes the roaming accounting service. The port of 1648, as well as the TCP transfer method are used purely for illustra- tion, since we do not yet have a proposal for the accounting transfer protocol. 11. Acknowledgements Thanks to Glen Zorn and Gurdeep Singh Pall of Microsoft, Richard Perl- man of Pacific Bell, Pat Calhoun of USR, Michael Robinson of Asiainfo, and Ian Duncan of Newbridge Networks, for many useful discussions of this problem space. Aboba [Page 12] INTERNET-DRAFT 26 November 1996 12. References [1] B. Aboba, L. Liu, J. Alsop, J. Ding. "Review of Roaming Imple- mentations." draft-ietf-roamops-imprev-00.txt, Microsoft, Aimnet, i- Pass Alliance, Asiainfo, September, 1996. [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." draft-ietf- roamops-roamreq-00.txt, Microsoft, October, 1996. [3] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authen- tication Dial In User Service (RADIUS)." draft-ietf-radius- radius-05.txt, Livingston, Merit, Daydreamer, July 1996. [4] C. Rigney. "RADIUS Accounting." draft-ietf-radius- accounting-05.txt, Livingston, July 1996. [5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft- ietf-pppext-l2tp-00.txt, Ascend Communications, August, 1996. [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. "Point-to-Point Tunneling Protocol -- PPTP." draft-ietf-pppext- pptp-00.txt, Ascend Communications, June, 1996. [7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft- zorn-radius-tunnel-auth-00.txt, Microsoft Corporation, October, 1996. [8] B. Aboba. "Implementation of Mandatory Tunneling via RADIUS." draft-aboba-radius-tunnel-imp-01.txt, Microsoft Corporation, October, 1996. [9] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. [10] 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. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 13]