Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-roamops-auth-00.txt < prev next >

Wrap

Text File | 1997-03-26 | 30KB | 722 lines

ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation <draft-ietf-roamops-auth-00.txt > 26 March 1997 The Authentication and Authorization Problem in Roaming 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 <draft- ietf-roamops-auth-00.txt>, and expires October 1, 1997. Please send comments to the authors. 2. Abstract This document describes the authentication and authorization problems that arise in the provisioning of dialup roaming capabilities. These include issues relating to authentication routing as well as non-repu- diation of Access-Accepts. 3. Introduction As detailed in [2], solution of the authentication and authorization problem in roaming requires several elements to be put in place: 1. A method must be provided for authentications to be routed between the local ISP and the home authentication server. If RADIUS as described in [3] is used for authentication, then hierarchical authentication routing must be used in order to provide for scala- bility, as described below. 2. A mechanism must be put in place to allow local ISP RADIUS proxies to edit authorization attributes so as to allow these attributes to relate to the local network. Aboba [Page 1] INTERNET-DRAFT 26 March 1997 3. A mechanisms must be employed to deter fraud and allow for auditing. Such mechanisms may include non-repudiation for Access- Accepts. This document describes a proposed architecture for roaming authenti- cation and authorization. Issues relevant to hierarchical authentica- tion routing and non-repudiation are discussed. 3.1. Terminology This document frequently uses the following terms: Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network. 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 can be 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. Network Access Identifier In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP (known as the Network Access Identifier or NAI) and in the subse- quent RADIUS authentication and accounting requests, can contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. Roaming relationships Roaming relationships include relationships between compa- nies and ISPs, relationships among peer ISPs within a roam- ing association, and relationships between an ISP and a roaming consortia. Together, the set of relationships form- ing a path between a local ISP's authentication proxy and the home authentication server is known as the roaming rela- tionship path. 4. Overview of the roaming authentication and authorization architec- ture The goal of the roaming authentication and authorization architecture is to enable roaming users to be authenticated and authorized when dialing phone numbers belonging to ISPs other than their home ISP. The Aboba [Page 2] INTERNET-DRAFT 26 March 1997 authentication and authorization architecture, which is shown below, involves interactions between network devices such as NASes and routers, authentication proxies, and authentication servers. In this architecture, authentication proxies are used to relay authen- tication requests from the local ISP to the home authentication server. While the local ISP authentication proxy may edit authoriza- tion attributes returned by the home authentication server, so as to make them compatible with the local network, intermediate proxies MUST NOT edit the attribute set passed to it by another proxy or the home authentication server. This is necessary in order to ensure that crit- ical attributes relating to security (such as tunnel attributes or EAP-Message attributes) are not modified along the way. In the discussion that follows, we assume that BIGCO has contracted with ISPA to provide roaming services. In turn ISPA has joined a roam- ing consortia ISPGROUP. User Fred then travels to another part of the world and dials into a NAS device operated by ISPB, who has also joined roaming consortia ISPGROUP. Fred attempts to authenticate to the NAS device as fred@bigco.com, using the PPP protocol and an authentication protocol such as PAP, CHAP, or EAP. +------------+ +------------+ +------------+ | | | | | | | ISPB | | BIGCO | | ISPA | | Router | | RADIUS |<---------| RADIUS | | | | Server | | Proxy | | | | | | | +------------+ +------------+ +------------+ | ^ | | RADIUS | | Protocol | Inter-organizational | | Authentication Events | | | | | V V +------------+ +------------+ | | | | | ISPB | Inter-organizational | ISPGROUP | | RADIUS |<----------------------------->| RADIUS | | Proxy |\ Authentication Events | Proxy | | | \ | | | | \ | | +------------+ \ +------------+ ^ \ | \ Intra-organizational RADIUS | \ Authentication Events Protocol | \ | \ | \ | \ | \ +------------+ +------------+ Aboba [Page 3] INTERNET-DRAFT 26 March 1997 | | | | | ISPB | | ISPB | | NAS | | RADIUS | | | | Server | | | | | +------------+ +------------+ ^ | PPP | Protocol | | V +------------+ | | | | | Fred | | | | | +------------+ 5. Authentication and authorization recommendations 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. How the authentication is routed depends on the security mechanisms employed by the protocols used to communicate between the NAS and the home ISP's authentication server, as well the roaming relationships established between the parties. 5.1. Hierarchical authentication routing and RADIUS Use of proxy RADIUS and hierarchical authentication routing is pro- posed for use in situations where the members of the roaming consortia desire to use RADIUS as described in [3] as their authentication pro- tocol. In these cirumstances, authentication traffic will be secured via shared secrets, and hierarchical authentication routing must be employed to enhance scalability. In order to support hierarchical authentication routing, it is recommended that a Roaming Relationship (REL) record be added to the DNS, as described in [8]. Note that direct contact between the local NAS and the home RADIUS server is not necessarily desirable, regardless of whether public key authentication technology is available. Direct contact between the local NAS and the home RADIUS server 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 RADIUS server must be able to return configuration attributes that the remote NAS understands. Thus authentication prox- ies are useful for more than just authentication routing. Aboba [Page 4] INTERNET-DRAFT 26 March 1997 5.2. Use of RADIUS over IPSEC In situations where members of the roaming consortia are able to sup- port public key authentication as well as DNS Security, IPSEC and ISAKMP, it is recommended that the working group consider optional support for RADIUS running over IPSEC. Where RADIUS is run over IPSEC, the RADIUS authenticator field will not be utilized, and the Signature attribute will not be processed. Where RADIUS over IPSEC is used, the local ISP's RADIUS proxy may be able to contact the home ISP server directly, and negotiate a session key without the need for a shared secret. However, in order for direct contact to be feasible between the local ISP proxy and the home authentication server, the home authentication server must be prepared to return its roaming credentials to the local ISP proxy. This is required in order for the local ISP proxy to be able to verify the roaming relationship path. As a result, it will not be necessary for the authentication to traverse this path in order to verify it. Roaming credentials consist of a series of tokens testifying to the validity of the roaming relationship path stretching between the local ISP and the home authentication server. For example, if BIGCO has del- egated roaming authority to ISPA, then its roaming credentials will include a token signed by ISPA testifying to the validity of the roam- ing relationship between BIGCO and ISPA. The tokens returned by the home authentication server would include the following: {PK_BIGCO, Expiration date}^SK_ISPA {PK_ISPA, Expiration date}^SK_ISPGROUP1 5.3. Non-repudiation of Access-Accepts In situations where members of the roaming consortia are able to sup- port public key authentication, it may be desirable to support non- repudiation of Access-Accepts as an optional capability. This capabil- ity is supported via inclusion of a token by the home authentication server within the Access-Accept. This token consists of a message digest, signed by the home authentication server. The message digest is computed over the Access-Accept, with the portions of the packet which may be acceptably modified (such as the authenticator field) set to zero. In order to proof of a user login, it has been suggested that the signature also be applied to a transcript of the authentication conversation between the NAS and the authenticating peer. Please note that support for non-repudiation in Access-Accepts is only valuable as an integrity-checking mechanism when the local ISP proxy cannot contact the home authentication server directly, and thus there is concern over modification of the Access-Accept by intermediate proxies. However, in addition, it may be desirable to include the non- repudiation token with the accounting record in order to demonstrate its authenticity. Aboba [Page 5] INTERNET-DRAFT 26 March 1997 6. Hierarchical authentication routing architecture 6.1. Justification for hierarchical authentication routing Since the RADIUS protocol is commonly implemented both by NAS vendors as well as by ISPs, RADIUS is today commonly used as a mechanism for roaming authentication and authorization. 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 either in proxy configuration files or via DNS as described in [8]. Note that even if DNS is used, configuration files are still necessary in cases where proxy RADIUS is employed, since they provide the RADIUS proxy with the list of shared secrets. This list of shared secrets is also a list of systems whose owners have a Roaming relationship with the configuring ISP. Hierarchical authentication routing is implemented via a multi-tier RADIUS proxy system. This allows ISPs to maintain shared secrets only with the roaming consortia itself or other consortium members, as well as with customers who have delegated roaming responsibilities to them. 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 500 roaming consortia members, each with 500 corporate customers, this translates to 250499 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 Aboba [Page 6] INTERNET-DRAFT 26 March 1997 the case of 500 roaming consortia members, each with 500 corporate customers, this translates to 999 shared secrets per ISP, a dramatic reduction. If the RADIUS proxies of each ISP contact a consortium proxy, the num- ber of shared secrets is further reduced. In this case, a given proxy needs to maintain m+1 shared secrets, while the consortium proxy needs to maintain n shared secrets, one for each consortium member. 6.2. Details of hierarchical authentication routing As described in [8], Roaming Relationship (REL) RRs in the DNS are used in order to construct the roaming relationship path. Please note that while DNS Security may be used to verify the integrity and authenticity of the REL RRs, it does not vouch for the validity of the roaming relationships themselves. As a result, where it is not possi- ble for the local ISP proxy to contact the home authentication server directly and retrieve roaming credentials, it is necessary for the local ISP to route the authentication over the roaming relationship path in order to verify it. As a result, in cases where hierarchical authentication routing is required, the roaming relationship path is used as the authentication route. The route is typically constructed by the local ISP proxy, which includes it within the Authentication-Route attribute included in the RADIUS Access-Request. In order to ensure that the accounting agent, who will subsequently receive an accounting record has also had the opportunity to vouchsafe for the validity of the roaming relation- ship path, the accounting agent is typically included as the first hop in the roaming relationship path. In order to construct the roaming relationship path, the local ISP proxy begins by checking whether the home authentication domain is listed in its configuration files as an accounting agent. If so, then the authentication request (and the subsequent accounting record) is routed to the home authentication server directly; if not, then the local ISP queries for the REL RR of the home authentication domain. Typically such a query will return one or more ISPs or roaming consor- tia to whom the home authentication domain has delegated roaming authority. Once again, the local ISP proxy checks whether one of these domains is listed within its configuration files as a valid accounting agent. If so, then it routes the authentication (and subsequently the accounting record) to the accounting agent. If not, then it queries the DNS for the REL RRs for these ISPs and/or roaming consortia. The process typically results in a roaming relationship path within a max- imum of two hops. Once the roaming relationship path has been constructed by the local ISP, it is included in an Authentication-Route attribute within the Access-Request. Intermediate proxies MUST forward the authentication along the requested Authentication-Route if it is possible to do so. Aboba [Page 7] INTERNET-DRAFT 26 March 1997 7. Proposed RADIUS attributes for roaming 7.1. Authentication-Route Description This attribute allows an authentication route to be included within a RADIUS Access-Request or Access-Reply sent between RADIUS prox- ies. RADIUS proxies receiving a message with an Authentication- Route attribute MUST honor the attribute if it is possible to do so. A summary of the Authentication-Route attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 73 for Authentication-Route Length >=3 String The String field includes the authentication route, which is represented as a series of domains separated by /. For example, a valid authentication route is ispb.com/isp- group.com/ispa.com/bigco.com/ 7.2. Authentication-Token Description This attribute allows an authentication server to include a signed token within a RADIUS Access-Accept, in order to provide for non- repudiation. A summary of the Authentication-Token attribute format is shown below. The fields are transmitted from left to right. 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 Aboba [Page 8] INTERNET-DRAFT 26 March 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 74 for Authentication-Token Length ? String The String field includes the authentication token. 7.3. Roaming-Credentials Description This attribute allows a home authentication server to include its roaming credentials within a RADIUS Access-Accept, thus enabling direct contact between the local ISP proxy and the home authentica- tion server. More than one Roaming-Credentials attribute may be included within an Access-Accept, in order to allow the home authentication server to present sufficient credentials to validate the roaming relationship path between itself and the local ISP. A summary of the Roaming-Credentials attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 75 for Roaming-Credentials Length ? String The String field includes the roaming credentials, which consist of tokens with the following structure: Aboba [Page 9] INTERNET-DRAFT 26 March 1997 {PK_DelegatingEntity, Expiration date}^SK_SigningEntity 8. Security Concerns 8.1. Attacks on the DNS servers In the absence of DNS security, an attacker were to gain control of the DNS server hosting the BIGCO zone files, they could change the REL and SRV records to route roaming authentication and accounting requests to bogus servers. However, since RADIUS is secured by a shared secret, this attack would not result in more than a denial of service, as long as the attacker did not also obtain the shared secrets which would allow the bogus RADIUS server's Access-Reply message to be accepted. This is why it is important that roaming relationship paths be verified either via roam- ing credentials or via hierarchical authenticaton routing. 8.2. Attacks against RADIUS proxies Without non-repudiation of Access-Accepts, it is possible that a prox- ied authentication may be modified in transit between the home authen- tication server and the local ISP proxy. Thus, it is possible for a compromised RADIUS proxy to modify security attributes returned by the home ISP, or even to change a NAK to an ACK. Without non-repudiation, it is also not possible for an accounting agent to confirm that the home ISP authentication server authorized a session. This may present problems if a dispute should arise over the home ISP's roaming charges. Note that even with public key authentication facilities, there is no guarantee that the local ISP proxy will not modify security attributes. In order to guarantee that the authorization attributes will be compatible with the local network, the local ISP proxy will typically edit the authorization attributes returned by the home ISP's authentication server. 9. Acknowledgments Thanks to Glen Zorn of Microsoft and Pat Calhoun of USR for 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 Aboba [Page 10] INTERNET-DRAFT 26 March 1997 Alliance, Asiainfo, January, 1997. [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf- roamops-roamreq-03.txt, Microsoft, March, 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. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. [6] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- prises, October 1996. [7] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August, 1996. [8] B. Aboba. "The Roaming Relationships (REL) Record in the DNS. " draft-ietf-roamops-dnsrr-03.txt, Microsoft, March, 1997. [9] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius- ext-00.txt, Livingston, January, 1997. [10] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [11] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." draft-bradner-key-words-02.txt, Harvard University, August, 1996. [12] B. Aboba. "The Network Access Identifier (NAI)." draft-ietf- roamops-nai-02.txt, Microsoft, March, 1997. 11. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 11]