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-03.txt < prev next >

Wrap

Text File | 1997-09-10 | 47KB | 1,052 lines

ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Best Current Practice John R. Vollbrecht <draft-ietf-roamops-auth-03.txt> Merit Networks, Inc. 8 September 1997 Glen Zorn Microsoft Guidelines for the Operation of RADIUS Proxies 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-03.txt>, and expires March 1, 1998. Please send comments to the authors. 2. Abstract Today, while RADIUS proxy chaining is widely deployed for the purposes of providing roaming services, interoperation between roaming systems is difficult. This document provides guidelines for the operation of RADIUS proxies within roaming systems. 3. 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]. Aboba, Vollbrecht & Zorn [Page 1] INTERNET-DRAFT 8 September 1997 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. Requirements language This specification uses the same words as [8] for defining the signif- icance 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 Aboba, Vollbrecht & Zorn [Page 2] INTERNET-DRAFT 8 September 1997 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 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." 5. Introduction Today, as described in [1], RADIUS proxy chaining is widely deployed for the purposes of providing roaming services. In such systems, RADIUS authentication and accounting packets are routed between a NAS device and a home RADIUS server through a series of RADIUS proxies. The purpose of this document is to provide guidelines for the opera- tion of such systems. An example of a proxy chaining system is shown below. (request) (request) (request) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS (reply) (reply) (reply) Server <--------- <--------- <--------- In the above diagram, the NAS generates a RADIUS request and sends it to Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the request to the Home Server. The Home Server generates a reply and sends it to Proxy2. Proxy2 receives the reply, matches it with the request it had sent, and forwards a reply to Proxy1. Proxy1 matches the reply with the request it sent earlier and forwards a reply to the NAS. This model applies to all RADIUS requests, including Access Requests and Accounting Requests. Except where policy is being imple- mented (described below), a proxy server such as Proxy2 in the diagram below SHOULD NOT send a Reply packet to Proxy1 without first having received a Reply packet initiated by the home RADIUS server. While the RADIUS protocol described in [3] does not provide for authentication of Access-Requests, such authentication is possible using the Signature attribute described in [5]. Proxies SHOULD include the Signature attribute in Access-Requests. Since the RADIUS protocol, described in [3], does support authentication of Access-Reply packets, the Signature attribute is not required in an Access-Reply. Aboba, Vollbrecht & Zorn [Page 3] INTERNET-DRAFT 8 September 1997 5.1. Route determination In RADIUS proxy chaining, the forwarding function is carried out based on the realm portion of the Network Access Identifier (NAI), defined in [9]. While the mechanism by which the path is selected is implemen- tation dependent, existing implementations typically use static for- warding tables set in their configuration files. If source routing is desired, a local proxy may use the Route attribute described in [10] to define a loose or strict source route. Intermediate proxies that cannot honor the loose or strict source route request SHOULD send an Access-Reject to the upstream proxy or NAS and an Accounting message with Acct-Status-Type=Proxy-Stop to the Home Server. If a traceroute is desired, a local proxy may use the Route attribute described in [10] to request a traceroute be performed. Through use of multiple Route attributes, a traceroute may be performed along with a loose source route request. Note that in forwarding an Access-Request, a proxy may choose to route a request through an alternate realm if the proxies for a downstream realm are not available. In the case where alternate routes may be chosen, a traceroute request SHOULD be included within the Access- Request. On receiving an Access-Request containing a traceroute, the home server SHOULD respond with an Access-Reply containing a strict source-route request, with the strict source-route set to the route contained in the traceroute. This ensures that the Access-Reply is sent back over the same path travelled by the Access-Request. On receiving an Access-Accept containing a traceroute or source-route, the local proxy SHOULD include a source-route request within the Accounting-request for that session. This will ensure that the Accounting-request will follow the same realm path as did the Access- Request and Access-Accept. 5.2. Policy implementation RADIUS proxies are frequently used to implement policy in roaming sit- uations. RADIUS proxies implementing policy MAY reply directly to Access-Requests without forwarding the request. When replying directly to an Access-Request, the proxy MUST reply either with an Access- Reject or an Access-Challenge packet. A RADIUS proxy MUST NOT reply directly with an Access-Accept. An example of this would be when the proxy refuses all connections from a particular realm during prime time. In this case the home server will never receive the Access- Request. This situation is shown below: (request) (request) NAS ----------> Proxy1 ----------> Proxy2 Home RADIUS (reply) (reply) Server <--------- <--------- Aboba, Vollbrecht & Zorn [Page 4] INTERNET-DRAFT 8 September 1997 A proxy MAY also decide to Reject a Request that has been accepted by the home server. This could be based on the set of attributes returned by the home server. In this case the Proxy SHOULD send an Access-Reject to the NAS and an Accounting message with Acct-Status- Type=Proxy-Stop to the home server. This lets the Home Server know that the session it approved has been denied downstream by the Proxy. However, a proxy MUST NOT send an Access-Accept after receiving an Access-Reject from a proxy or from the home server. (Access-Req) (Access-Req) (Access-Req) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS (Access-Reject) (Access-Accept) (Access-Accept) Server <--------- <--------- <--------- (AcctPxStop) (AcctPxStop) ----------> ----------> 5.3. Accounting behavior As described above, a proxy MUST NOT reply directly with an Access- Accept, and MUST NOT reply with an Access-Accept when it has received an Access-Reject from another proxy or Home Server. As a result, in all cases where an accounting record is to be generated (accepted ses- sions), no direct replies have occurred, and the Access-Request and Access-Accept have passed through the same set of systems. In order to allow proxies to match incoming Accounting-Requests with previously handled Access-Requests and Access-Accepts, a proxy SHOULD route the Accounting-Request along the same realm path travelled in authentication/authorization. Note that this does not imply that accounting packets will necessarily travel the identical path as did authentication/authorization packets, machine by machine. This is because it is conceivable that a RADIUS proxy may have gone down, and as a result the Accounting-request may need to be forwarded to an alternate server. It is also conceivable that authentication/autho- rization and accounting may be handled by different servers within a realm. The Class attribute can be used to match accounting requests with prior access requests. It can also be used to match session log records between the home Server, proxies, and NAS. This matching can be accomplished either in real-time (in the case that authentication and accounting packets follow the same path, machine by machine), or after the fact. Home servers SHOULD insert a unique session identifier in the Class attribute in an Access-Accept and Access-Challenge. Proxies and NASes MUST forward the Class attribute. The NAS MUST include the Class attribute in subsequent requests, in particular for Accounting- Requests. The sequence of events is shown below: Authentication/Authorization Aboba, Vollbrecht & Zorn [Page 5] INTERNET-DRAFT 8 September 1997 --------> --------> ---------> NAS Proxy1 Proxy2 Home (add class) <-class-- <-class- <-class-- Accounting (Accounting-req) (Accounting-req) (Accounting-req) w/class w/class w/class NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS (Accounting-reply) (Accounting-reply)(Accounting-reply) Server <--------- <--------- <--------- Since there is no need to implement policy in RADIUS accounting, a proxy SHOULD NOT reply directly to Accounting-Requests, and a proxy server such as Proxy2 in the diagram below SHOULD NOT send an Account- ing-Reply packet to Proxy1 without first having received an Account- ing-Reply packet initiated by the home RADIUS server. This ensures when a NAS receives an Accounting-Reply the Accounting-Request will have been received by all systems along the authentication/authoriza- tion path. Note that there are cases where a proxy may need to forward an Accounting packet to more than one system. For example, in order to allow for proper accounting in the case of a NAS that is shutting down, the proxy may need to send an Accounting-Request with Acct-Sta- tus-Type=Accounting-Off to all realms that it forwards to. In turn, these proxies will also flood the packet to their connected realms. 6. Allowable editing behavior One of the biggest obstacles to interoperation of proxies today results from editing behavior. As roaming grows in popularity, attribute editing problems are becoming common. Today several proxy implementations remove attributes that they do not understand, or can be set up to replace attribute sets sent in the Access-Accept with sets of attributes appropriate for a particular network. In order to prevent inappropriate modification of RADIUS attributes this document describes what attributes may be added, edited, deleted, or processed by authentication and accounting prox- ies. A local proxy (a proxy downstream from a NAS) MAY edit or delete attributes within Access-Requests, as described in the table below. An intermediate proxy (a proxy downstream from another proxy) SHOULD NOT edit or delete attributes when forwarding Access-Requests. Local proxies MAY edit or delete attributes in an Access-Reply, if the downstream server is a NAS which is not able to interpret some attributes, and if the attributes are marked with edit or delete per- mission in the table below. If edit or delete permission is not indi- cated, then if a NAS is not able to interpret these attributes, then Aboba, Vollbrecht & Zorn [Page 6] INTERNET-DRAFT 8 September 1997 the proxy SHOULD send an Access-Reject to the NAS and an Accounting message with Acct-Status-Type=Proxy-Stop to the home server. Interme- diate proxies SHOULD NOT edit or delete attributes in an Access-Reply. A local Proxy may need to translate some attributes in the Access- Accept to support a particular service. For example, translation could be done to support a common set of IP filters on NASs from different vendors. However, translation should be done only to support a common service. Intermediate proxies SHOULD NOT translate attributes. Local or intermediate proxies MAY interpret attributes they receive and MAY add attributes to Access-Request, Access-Reply, Access-Chal- lenge, and Accounting-Request messages, as noted in the table below. A Proxy that adds attributes MUST precede the additional attributes with a "Proxy-State" attribute containing as its leading string the IP- Address of the Proxy. This permits downstream proxies to understand what attributes have been added and aids in debugging. Proxies MUST maintain attribute order when forwarding. An intermediate proxy SHOULD NOT edit or delete attributes within Accounting-Requests. A local proxy MAY edit or delete attributes within Accounting-Requests, as described in the table below. However, since proxies will already have had the opportunity to edit the attributes while forwarding authentication/authorization packets, the attributes sent in the Accounting-Request reflect the actual parame- ters in effect for the session. As a result, the intermediate proxy or the home server MAY wish to match the attributes sent in the Access- Request, Access-Challenge, or Access-Accept against those in the Accounting-Request in order to generate an audit trail or aid in debugging. In order to support the auditing and debugging process, the scope for editing or deletion of attributes in Accounting-Requests is reduced. AUTHENTICATION Request Accept Reject Challenge # Attribute E A 1 User-Name [note 1] PD 2 User-Password [note 2] A 3 CHAP-Password [note 2] AED 4 NAS-IP-Address [note 4] AE 5 NAS-Port AE AE 6 Service-Type AE AE 7 Framed-Protocol AE AE 8 Framed-IP-Address AE AE 9 Framed-IP-Netmask AED 10 Framed-Routing AE 11 Filter-Id [note 5] AE 12 Framed-MTU AE AE 13 Framed-Compression AE AE 14 Login-IP-Host AE 15 Login-Service AE 16 Login-TCP-Port AE AE AE 18 Reply-Message AE AE 19 Callback-Number [note 3] Aboba, Vollbrecht & Zorn [Page 7] INTERNET-DRAFT 8 September 1997 A 20 Callback-Id AED 22 Framed-Route AED 23 Framed-IPX-Network AE AE AE 24 State AE 25 Class AED AED AED 26 Vendor-Specific AE AE 27 Session-Timeout AE AE 28 Idle-Timeout AE 29 Termination-Action AE 30 Called-Station-Id [note 3] AE 31 Calling-Station-Id [note 3] AE 32 NAS-Identifier [note 4] AP AP AP AP 33 Proxy-State AE AE 34 Login-LAT-Service AE AE 35 Login-LAT-Node AE AE 36 Login-LAT-Group AE 37 Framed-AppleTalk-Link AED 38 Framed-AppleTalk-Network AED 39 Framed-AppleTalk-Zone 60 CHAP-Challenge AE 61 NAS-Port-Type AE AE 62 Port-Limit AE AE 63 Login-LAT-Port 64 Tunnel-Type 65 Tunnel-Medium-Type 67 Tunnel-Server-Endpoint P 69 Tunnel-Password AP 70 ARAP-Password AE AE 71 ARAP-Features AE 72 ARAP-Zone-Access A A 73 ARAP-Security A A 74 ARAP-Security-Data ED 75 Password-Retry AE 76 Prompt 77 Connect-Info AED 78 Configuration-Token 79 EAP-Message AP 80 Signature P P P P ? Route ED ? Acct-Interim-Interval Request Accept Reject Challenge # Attribute The following table defines the meaning of the entries above. A This attribute MAY be added E This attribute MAY be edited. Editing is defined as a change beyond that required in hop-by-hop processing as described in [3]-[5]. D This attribute MAY be deleted. P This attribute MUST be processed as described in [3]-[5]. Notes 1. A proxy may strip the realm from the User-Name, so as to provide Aboba, Vollbrecht & Zorn [Page 8] INTERNET-DRAFT 8 September 1997 compatibility with proxies that cannot handle this. 2. Use of PAP is considered undesirable in roaming, since each RADIUS proxy handling the Access-Request will have access to the cleartext password. As a result, if the user uses PAP to authenticate with the NAS, and the NAS sends the User-Password to the proxy (secure network) the proxy MAY convert it to CHAP before sending it to the home server (insecure network). In some situations this would be desirable (fewer proxies would have access to the password), and in others it would be undesirable (the home NAS has no way to know that it was only PAP that was done). 3. A proxy may edit these attributes in order to make them more spe- cific. For example, the proxy might need to change Callback-Number = "7771111" to Callback-Number = "5107771111". 4. A local proxy may replace the NAS-IP-Address attribute with a NAS- Identifier attribute in order to releave other proxies or servers of the need to understand the underlying network topology, making it eas- ier for those proxies to make a decision whether to permit the Access- Request. For example, a local proxy might replace a NAS-IP-Address of 128.10.13.1 with a NAS-Identifier of "BIG ISP NAS 1." 5. Editing of the Filter-Id attribute may be undertaken only by a local proxy, in order to provide a common filter service between NASes of different types. ACCOUNTING Request Reply # Attribute 1 User-Name 2 User-Password 3 CHAP-Password AED 4 NAS-IP-Address AE 5 NAS-Port A 6 Service-Type A 7 Framed-Protocol A 8 Framed-IP-Address A 9 Framed-IP-Netmask A 10 Framed-Routing A 11 Filter-Id A 12 Framed-MTU A 13 Framed-Compression A 14 Login-IP-Host A 15 Login-Service A 16 Login-TCP-Port 18 Reply-Message AE 19 Callback-Number [note 3] A 20 Callback-Id A 22 Framed-Route A 23 Framed-IPX-Network 24 State A 25 Class A 26 Vendor-Specific Aboba, Vollbrecht & Zorn [Page 9] INTERNET-DRAFT 8 September 1997 A 27 Session-Timeout A 28 Idle-Timeout A 29 Termination-Action AE 30 Called-Station-Id [note 3] AE 31 Calling-Station-Id [note 3] AED 32 NAS-Identifier AP 33 Proxy-State A 34 Login-LAT-Service A 35 Login-LAT-Node A 36 Login-LAT-Group A 37 Framed-AppleTalk-Link A 38 Framed-AppleTalk-Network A 39 Framed-AppleTalk-Zone 40 Acct-Status-Type 41 Acct-Delay-Time [note 1] 42 Acct-Input-Octets 43 Acct-Output-Octets E 44 Acct-Session-Id [note 2] 45 Acct-Authentic 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause E 50 Acct-Multi-Session-Id [note 2] 51 Acct-Link-Count 60 CHAP-Challenge A 61 NAS-Port-Type A 62 Port-Limit A 63 Login-LAT-Port 64 Tunnel-Type 65 Tunnel-Medium-Type 66 Acct-Tunnel-Client-Endpoint 67 Tunnel-Server-Endpoint 68 Acct-Tunnel-Connection-ID 69 Tunnel-Password 70 ARAP-Password A 71 ARAP-Features A 72 ARAP-Zone-Access A 73 ARAP-Security A 74 ARAP-Security-Data 75 Password-Retry 76 Prompt 77 Connect-Info 78 Configuration-Token 79 EAP-Message 80 Signature P P ? Route A ? Acct-Interim-Interval Accounting Accounting Request Reply # Attribute 1. If the proxy can calculate the additional delay it is introducing, it should increment this. Aboba, Vollbrecht & Zorn [Page 10] INTERNET-DRAFT 8 September 1997 2. The proxy may need to modify the NAS identification to hide private network information. In that case, it may forward packets with itself as the NAS, and will need to construct an Acct-Session-Id that is guaranteed to be unique. For example, if the proxy gets packets from 16 NASs, session '3478617' on the 11th NAS might be given the new ses- sion ID 'A3478617'. 3. A proxy may edit these attributes in order to make them more spe- cific. For example, the proxy might need to change Callback-Number = "7771111" to Callback-Number = "5107771111". 7. Security issues Since current roaming implementations operate in more than 150 coun- tries and service millions of users, it is critical that RADIUS proxy chaining implementations be secure. In particular, protection must be provided against the following attacks: Rogue proxies Theft of passwords Theft of accounting data Replay attacks Attribute editing Connection hijacking Authentication routing attacks Fraudulent accounting 7.1. Rogue proxies In conventional ISP application, the NAS, RADIUS proxy, and RADIUS server typically exist within a single administrative entity. As a result, the RADUS proxy and RADIUS server may be considered to be trusted components. However, in a roaming system implemented with proxy chaining, the NAS, RADIUS proxies, and RADIUS server may be managed by different adminis- trative entities. Through the use of shared secrets it is possible for RADIUS proxies operating in different domains to establish a trust relationship. However, since RADIUS packets are only authenticated on a hop-by-hop basis, proxy chaining systems deployed in roaming operate without end-to-end authentication. This means that in such systems security is only as strong as the weakest link in the proxy chain. Among other things, this implies that it is advisable to keep the chain as short as possible. To date, as described in [1], existing roaming implementations have been limited in scale, forwarding RADIUS packets over a maximum of two hops, or implementing star configura- tions with all systems connecting to a single trusted entity. Such configurations minimize trust issues. Aboba, Vollbrecht & Zorn [Page 11] INTERNET-DRAFT 8 September 1997 Through use of the Route attribute described above, it is possible for a RADIUS proxy or server to decide whether it wishes to trust a packet arriving via a particular route. Since it is the receiving proxy that adds the previous hop to the route, without collusion a rogue proxy cannot avoid having itself listed in the route, although it can add, delete, or alter prior entries. A proxy or server may decide not to trust any route including a par- ticular system or set of systems as an intermediate proxy, or as an originating or terminating system. 7.2. Theft of passwords In the case where clients authenticate using PAP, each RADIUS proxy along the path between the local NAS and the home RADIUS server will have access to the cleartext password. In many circumstances, this represents an unacceptable security risk, and as a result, it is rec- ommended that PAP SHOULD NOT be used in roaming. A possible exception to this recommendation occurs in situations where PAP is used in order to pass a one time password or token. 7.3. Theft of accounting data Since RADIUS accounting does not provide for encryption of accounting data, when real-time accounting is used, it is possible for an inter- mediate system to gain access to accounting information passing over the wire. Such access may or may not be possible when session record accounting is used, depending on whether encryption is used in the accounting record transfer. 7.4. Replay attacks In this attack, a man in the middle or rogue RADIUS proxy collects CHAP-Challenge and CHAP-Response attributes, and later replays them. If this attack is performed in collaboration with an unscrupulous ISP, it can be used to subsequently submit fraudulent accounting records to the accounting agent for payment. The system performing the replay need not necessarily be the one that initially captured the CHAP Chal- lenge/Response pair. While such an attack has always been possible, without roaming the threat is restricted to RADIUS proxies operating in the home server's domain. With roaming, such an attack can be mounted by any RADIUS proxy capable of reaching the home RADIUS server. In order to detect replay attacks, RADIUS servers used in roaming SHOULD keep a log of CHAP challenges, so as to allow the log to be checked for replays. CHAP replay attacks can be defeated by means of an end-to-end chal- lenge-response exchange. For example, if the home RADIUS server Aboba, Vollbrecht & Zorn [Page 12] INTERNET-DRAFT 8 September 1997 returns an Access-Challenge packet containing a CHAP-Challenge attribute and maintains state with respect to outstanding challenges, replay attacks will not work. However, it should also be noted that end-to-end challenges (as prac- ticed within the EAP MD5 authentication method, or in the CHAP-Chal- lenge method described above) are subject to attacks by rogue RADIUS proxies. In such an attack a RADIUS proxy substitutes a static chal- lenge for the challenge sent by the home RADIUS server, and on receiv- ing the response, checks it against a databases of hashes applied against a dictionary. Use of the CHAP and PAP authentication methods may be avoided entirely by instructing the PPP authenticating peer to refuse these authentica- tion methods if offered. 7.5. Attribute editing In this attack, a RADIUS proxy modifies an Access-Accept sent by the RADIUS server so as to lessen the security obtained by the client. For example, EAP attributes might be removed or modified so as to cause a client to authenticate with EAP MD5 or PAP, instead of a stronger authentication method. Alternatively, tunnel attributes might be removed or modified so as to remove encryption, redirect the tunnel to a rogue tunnel server, or otherwise lessen the security provided to the client. Since RADIUS only provides for hop-by-hop authentication, it is not possible to provide end-to-end integrity checks within proxy chaining systems. However, in order to provide for detection of inappropriate attribute editing, local RADIUS proxies and home RADIUS servers SHOULD implement auditing functionality. For example, the local RADIUS proxy SHOULD include RADIUS attributes received in the Access-Accept within the session record or Accounting- Start message for the session. Similarly, home RADIUS servers SHOULD log the contents of RADIUS Access-Replies sent, and SHOULD periodi- cally check for discrepancies between attributes sent in RADIUS Access-Replies, and attributes received by local proxies. Proxy Servers that modify or add attributes in any RADIUS Request MUST log the Request as received and as modified in order to make it possi- ble to audit requests in both directions. In order to allow for detection of modification of accounting packets by intermediate proxies, roaming consortia may implement both real- time and session record accounting. In this case, session records SHOULD NOT travel the same path taken by RADIUS accounting packets. Instead, session records SHOULD be sent directly between the local proxy and the systems requiring copies of the session records. Aboba, Vollbrecht & Zorn [Page 13] INTERNET-DRAFT 8 September 1997 7.6. Connection hijacking In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the home RADIUS server. RADIUS as described in [3] is vulnerable to such attacks since only Access-Reply and Access-Challenge packets are authenticated. In order to provide for authentication of Access-Request packets, RADIUS proxies operating in roaming systems MUST support the Signature attribute, as decribed in [9]. RADIUS proxies used in roaming imple- mentations MUST check for the presence of the Signature attribute in Access-Requests forwarded to them from other proxies, and MUST silently discard Access-Request packets missing the Signature attribute or failing authentication. RADIUS proxies operating in roam- ing systems also MUST include a Signature attribute in all forwarded Access-Request packets. 7.7. Authentication routing attacks In roaming, one of the functions of the RADIUS proxy is to route authentications between domains. Authentication routing attacks affect the core of a roaming system by modifying authentication rout- ing information, thus disabling the system or causing RADIUS packets to be routed inappropriately. Since to date roaming has been implemented on a relatively small scale, existing implementations perform authentication routing based on local knowledge expressed in proxy configuration files. To date implementations have not found a need for dynamic routing protocols, or propagation of global routing information. Since authentication routing information is fundamental to the opera- tional of a roaming system, routing information SHOULD be propagated using an transfer method supporting mutual authentication, such as Kerberized rcp, SSH or TLS. Since all RADIUS packets used in roaming are secured by a shared secret, such attacks will not rsult in more than a denial of service, as long as the attacker did not also obtain the shared secrets. As with attribute editing, it is expected that most problems of this type will result from misconfiguration of RADIUS proxies. In order to detect such misconfigurations, RADIUS proxies participating in roaming MUST implement the Route attribute described below. The Route attribute provides trace route and/or source route capabilities. This allows a local RADIUS proxy to specify a route through which an Access-Request must travel, or for a home RADIUS server to determine whether to authorize Access-Requests routed on a given roaming rela- tionship path. A RADIUS proxy receiving a Route attribute with the Trace option set MUST append the domain of the system from which it received the packet to the end of the Route attribute prior to forwarding it. Aboba, Vollbrecht & Zorn [Page 14] INTERNET-DRAFT 8 September 1997 7.8. Fraudulent accounting In this form of attack, a local RADIUS proxy transmits fraudulent accounting packets or session records in an effort to collect fees to which they are not entitled. This includes submission of packets or session records for non-existent sessions, or submission of exagger- ated session times for actual sessions. Such behavior will only be easily detectable in the event that roaming users are making use of voluntary or compulsory tunneling, in which case the tunnel server (presumed to exist at BIGCO) will generate its own accounting record, which may be compared to that generated by the local ISP. However, tunneling is expected to represent only a small percentage of roaming use. In order to detect submission of fraudulent accounting packets or ses- sion records, the the accounting gateway SHOULD send copies of session records to all parties with a financial interest in the session. Par- ties receiving copies of these session records SHOULD reconcile them with logs of proxied authentications. In order to make it easier to match RADIUS authentication logs with accounting records, RADIUS servers involved in roaming SHOULD include a Class attribute in the Access-Accept. The Class attribute should uniquely identify a session, so as to allow an authentication log entry to be matched with a corresponding accounting log. In order to be able to match accounting logs with logs of proxied RADIUS authentications, accounting agents SHOULD require that they act as an authentication proxy for all sessions for which an accounting record will subsequently be submitted. 8. Acknowledgments Thanks to Pat Calhoun of 3COM, Mark Beadles of CompuServe, Aydin Edguer of Morningstar, and Steven P. Crain of Shore.Net for useful discussions of this problem space. 9. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." Internet draft (work in progress), draft-ietf- roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, June, 1997. [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." Internet draft (work in progress), draft-ietf-roamops-roamreq-04.txt, Microsoft, June, 1997. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Daydreamer, April, 1997. Aboba, Vollbrecht & Zorn [Page 15] INTERNET-DRAFT 8 September 1997 [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April, 1997. [5] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997. [6] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC 2068, UC Irvine, January, 1997. [7] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [8] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [9] B. Aboba. "The Network Access Identifier." Internet draft (work in progress), draft-ietf-roamops-nai-06.txt, Microsoft, July 1997. [10] B. Aboba and J.R. Vollbrecht. "RADIUS Extensions for Roaming." Internet draft (work in progress), draft-ietf-roamops-radius-00.txt, Microsoft, Merit Networks, September 1997. 10. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 Phone: 313-763-1206 EMail: jrv@merit.edu Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-703-1559 EMail: glennz@microsoft.com Aboba, Vollbrecht & Zorn [Page 16]