RFC 2607

Proxy Chaining and Policy Implementation in Roaming

📅 published June 1999, from ietf

RFC 2607 Title Block 🎀

Okay bestie, here's the paperwork! 📋

  • RFC number: 2607 🦋
  • Title: Proxy Chaining and Policy Implementation in Roaming 🌸
  • Authors: B. Aboba (Microsoft Corporation) and J. Vollbrecht (Merit Networks, Inc.) 👑
  • Category: Informational 💜
  • Date: June 1999 ✨
  • Obsoletes/updates: The title block doesn't list any RFCs that this one obsoletes or updates. 🧚
  • Network Working Group: This one came from the Network Working Group 🫶

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Abstract 🔥

So this doc is all about how proxy chaining and policy implementation can work in roaming systems. The mechanisms in here are actually in use right now, so it's not just theory, it's real life! 💖

BUT (and this is a big but) the security considerations section explains that these techniques can be attacked by outside parties, and roaming partners themselves could commit fraud with them. 😭 So these methods are NOT suitable for wide-scale deployment on the Internet. Be careful, bestie! 🙈

2. Terminology 🦋

This doc uses the following terms a lot, so let's get them down first. 🧚

Network Access Server The Network Access Server (NAS) is the device that clients contact to get access to the network. It's the front door! 🚪

RADIUS server A server that handles authentication/authorization using the protocol described in [3], and accounting as described in [4]. 💜

RADIUS proxy To route RADIUS authentication and accounting requests, you can use a RADIUS proxy. It's giving middleman. To the NAS, the proxy acts like a RADIUS server, and to the RADIUS server, the proxy acts like a RADIUS client. It's a whole double life 💅

Network Access Identifier To route RADIUS authentication and accounting requests, the userID field used in PPP (known as the Network Access Identifier or NAI) and in the RADIUS authentication and accounting requests that follow can contain structure. That structure is how the RADIUS proxy figures out which RADIUS server should get the request. The NAI is defined in [6]. 🗺️

Roaming relationships Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming association, and relationships between an ISP and a roaming consortia. The whole set of relationships that forms a path between a local ISP's authentication proxy and the home authentication server is called the roaming relationship path. It's like a group chat chain of friends passing a message along! 🌈

3. Requirements language 📜

In this document, the key words "MAY", "MUST, "MUST NOT", optional, recommended, "SHOULD", and "SHOULD NOT" are to be interpreted as described in [5]. So when you see those capital words, they're serious business. 💀

4. Introduction 🌸

Today, as described in [1], proxy chaining is widely deployed for roaming services. 🌍 In these systems, authentication/authorization and accounting packets get routed between a NAS device and a home server through a series of proxies. Consulting the home server is required for password-based authentication, because the home server keeps the password database. So the NAS has to talk to the home authentication server to verify the user's identity. No shortcuts, bestie! 🔐

4.1. Advantages of proxy chaining 💖

Proxies do a bunch of jobs in roaming, including:

  • Scalability improvement
  • Authentication forwarding
  • Capabilities adjustment
  • Policy implementation
  • Accounting reliability improvement
  • Atomic operation

Scalability improvement 📈

In big roaming systems, you need scalable management of the keys used for integrity protection and authentication. It's giving key management energy. 🔑

Proxy chaining makes hierarchical forwarding possible inside roaming systems. This improves scalability in roaming consortia that use authentication protocols without automated key management. RADIUS, described in [3], needs a shared secret for every client-server pair. So if a consortium has 100 roaming partners and each partner talks to every other partner directly, that's 4950 shared secrets, one for each partner pair. 😱 But if the partners route their authentication requests through a central proxy, only 100 shared secrets are needed, one per partner. Way less drama! ✨ Fewer partner pairs also means fewer bilateral agreements and less accounting and auditing overhead. So hierarchical routing might be desirable even when an authentication protocol with automated key exchange is available. 🫶

Capabilities adjustment 🎀

As part of the authentication exchange with the home server, the NAS gets authorization parameters that describe the service to be given to the roaming user. RADIUS, described in [3], doesn't support capabilities negotiation. So the authorization parameters sent by the home server might not match what the NAS needs. For example, the home server could specify a static IP address that the NAS can't route. 💀 That's why capabilities adjustment is done by proxies, so NASes and home servers with very different feature sets can still communicate. Proxies really be holding things together! 🧚

Proxies can edit attributes within the Access-Accept so it's compatible with the NAS. That editing can include adding, deleting, or modifying attributes. Proxies may also want to edit attributes within an Access-Request to clean up or even hide information meant for the home server. 🙈 But here's the tea: if a proxy edits the Access-Accept, the service the user actually gets might not be the same as what the home server asked for. That can lead to disputes over inappropriate capabilities adjustment. Yikes! 😬

Also, if roaming were built on an authentication/authorization protocol with built-in capability negotiation, proxy-based capabilities adjustment would probably not be necessary. 👑

Authentication forwarding 🦋

Roaming associations often use hierarchical forwarding to improve scalability. So for a NAS and a home server to talk, one or more proxies have to forward the authentication and accounting packets. The path those packets take, the roaming relationship path, is determined from the Network Access Identifier (NAI), described in [6]. Most NAS devices don't have forwarding logic, so a proxy is needed to forward the authentication and accounting packets. 🌈 For reasons explained in the security section, it's desirable in proxy systems for accounting and authentication packets to follow the same path. Same path, same vibe! 🛤️

Note: How a proxy learns the mapping between an NAI and the home server is beyond the scope of this document. The mapping could come from static configuration in the proxy, or from some protocol that isn't defined yet and provides dynamic mapping. For this document, we just assume the proxy has a mapping capability. 🧚

Policy implementation 💅

In roaming systems, it's often desirable to implement policy. For example, a partner might only be allowed to use a certain NAS at certain times of day. ⏰ To implement policies like this, proxies can sit at the interface between administrative domains and be programmed to modify the authentication/authorization packets forwarded between the NAS and the home server. So from a security point of view, a proxy implementing policy acts as a "man in the middle." 👀 Iconic behavior, but a little sus! 💀

Accounting reliability improvement 📊

In roaming systems based on proxy chaining, accounting information has to be forwarded between the NAS and the home server. So roaming is inherently an interdomain application. 🌍

That's a problem, because the RADIUS accounting protocol, described in [4], isn't designed for use at Internet scale. Accounting packets in roaming travel between administrative domains, so they often pass through network access points (NAPs) where packet loss can be substantial. That can lead to unacceptable rates of accounting data loss. 😭

For example, in a proxy chaining system with four systems, a one percent failure rate on each hop can lose 3.9 percent of all accounting transactions. Yikes, the math is not mathing! 🧮 Putting an accounting proxy near the NAS may improve reliability. It can store accounting records persistently and retry over a long duration. Persistent storage, long retries, we love to see it! 💖

Atomic operation ⚛️

To keep everyone who needs to process accounting data consistent, it can be desirable to make sure accounting data transmission is handled as an atomic operation. That means every party on the roaming relationship path has to receive the accounting data and acknowledge receipt for the operation to complete. 🤝 Proxies can ensure atomic delivery by delivering the accounting data in a serial fashion, as discussed in section 5.2. Everybody gets it or nobody does, no half-finished tea! ☕

5. Proxy chaining 🔗

Here's an example of a proxy chaining system. 🧚

     (request)          (request)          (request)
 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
     (reply)            (reply)            (reply)     Server
     <---------         <---------         <---------

In the diagram above, the NAS generates a request and sends it to Proxy1. Proxy1 forwards the request to Proxy2, and Proxy2 forwards it to the Home Server. The Home Server generates a reply and sends it to Proxy2. Proxy2 gets the reply, matches it with the request it sent earlier, 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 requests, including Access Requests and Accounting Requests. It's the whole relay race! 🏃‍♀️🏃‍♀️

Except for the two cases described below, a proxy server such as Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1 without first having received a Reply packet initiated by the Home Server. The two exceptions are when the proxy is enforcing policy, as described in section 5.1, and when the proxy is acting as an accounting store (as in store and forward), as described in section 5.2. Rules with exceptions, classic! 📜✨

The RADIUS protocol described in [3] doesn't provide end-to-end security services. That includes integrity or replay protection, authentication, or confidentiality. As the security considerations section notes, this omission causes several security problems in proxy chaining systems. 😭🔥 Read that section, bestie, it's serious!

5.1. Policy implementation 🛡️

okay so proxies are literally the policy gatekeepers in roaming situations 💅 Proxies implementing policy MAY reply directly to Access-Requests without forwarding the request. When a proxy replies directly to an Access-Request, it MUST reply with either an Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply directly with an Access-Accept. 🙅‍♀️ For example, a proxy might refuse all connections from a particular realm during prime time. In that case the home server never even receives the Access-Request. 🌙 Here's the flow:

         (request)          (request)
     NAS ----------> Proxy1 ----------> Proxy2             Home
         (reply)            (reply)                        Server
         <---------         <---------

A proxy MAY also decide to Reject a Request that the home server has already accepted ✨ This could be based on the set of attributes the home server sent back. In that case the Proxy SHOULD send an Access-Reject to the NAS, plus an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server. This lets the home server know that the session it approved got denied downstream by the proxy. 🫶 Still, a proxy MUST NOT send an Access-Accept after receiving an Access-Reject from a proxy or from the home server. No takebacks, bestie 😤

         (Access-Req)       (Access-Req)       (Access-Req)
     NAS ----------> Proxy1 ----------> Proxy2 ---------->     Home
         (Access-Reject)    (Access-Accept)    (Access-Accept) Server
         <---------         <---------         <---------
                            (AcctPxStop)       (AcctPxStop)
                            ---------->        ---------->

5.2. Accounting behavior 🧾

As we just covered, a proxy MUST NOT reply directly with an Access-Accept, and it MUST NOT reply with an Access-Accept when it has received an Access-Reject from another proxy or Home Server. 🚫 So where an accounting record is supposed to be generated (accepted sessions), no direct replies have happened, and the Access-Request and Access-Accept have gone through the same set of systems. Iconic consistency. 💚

Now, to let proxies match incoming Accounting-Requests with the Access-Requests and Access-Accepts they already handled, a proxy SHOULD route the Accounting-Request along the same realm path that the authentication/authorization traveled 🗺️ But this does NOT mean accounting packets take the identical path, machine by machine, as the auth packets did. 🙃 A proxy could have gone down, so the Accounting-Request might need to be forwarded to an alternate server. It's also possible that authentication/authorization and accounting get handled by different servers within a realm.

The Class attribute is how you match Accounting Requests with earlier Access Requests 🔑 It can also be used to match session log records between the home Server, proxies, and NAS. That matching can happen in real time (when auth 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 unmodified Class attribute, and the NAS MUST include the Class attribute in subsequent requests, especially Accounting-Requests. 🎀 The whole sequence looks like this:

                      Authentication/Authorization

      -------->         -------->          --------->
 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
      (Accounting-reply) (Accounting-reply)(Accounting-reply) Server
      <---------         <---------         <---------

Since there's no need to implement policy in accounting, a proxy MUST forward all Accounting Requests to the next server on the path. 📦 The proxy MUST guarantee that the Accounting Request is received by the End Server and all intermediate servers. It can do this either by: 1) forwarding the Accounting Request and not sending a Reply until it gets the matching Reply from the upstream server, or 2) acting as a store point that takes responsibility for reforwarding the Accounting Request until it receives a Reply.

Option 1 is the strict one 🧐 If the proxy waits for the matching reply before sending its own, then Accounting Start and Stop messages get received and logged by every server along the roaming relationship path. If even one server is unavailable, the operation fails. So the whole accounting transaction either succeeds or fails as a unit, which means it can be called atomic. 💜

Where store and forward is in play, though, things get messy 😬 One or more servers along the roaming relationship path might get the accounting data while others don't. Then the operation doesn't succeed or fail as a unit, so it's NOT atomic. Because of that, the roaming partners might not be able to reconcile their audit logs, which opens up new chances for fraud 🚨 So where store and forward is implemented, forwarding of Accounting Requests SHOULD happen as soon as they're received, so downstream servers get them in a timely way ⚡

Also, sometimes a proxy needs to forward an Accounting packet to more than one system 🌊 For example, if a NAS is shutting down, the proxy can send an Accounting-Request with Acct-Status-Type=Accounting-Off (8) to all realms it forwards to. Those proxies will then flood the packet out to their connected realms too. 🌈

6. References 📚

  • [1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
  • [2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
  • [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
  • [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
  • [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.

7. Security Considerations 🔐💀

This part is SERIOUS, bestie 😭 The RADIUS protocol described in [3] was designed for intra-domain use, where the NAS, proxy, and home server all live inside a single administrative domain, and proxies could be considered a trusted component. 🏠 But in roaming, the NAS, proxies, and home server are usually managed by different administrative entities. So roaming is inherently an inter-domain application, and proxies cannot necessarily be trusted. That opens the door to a whole list of threats: 😱

  • Message editing
  • Attribute editing
  • Theft of passwords
  • Theft and modification of accounting data
  • Replay attacks
  • Connection hijacking
  • Fraudulent accounting

7.1. Message editing 🙈

Through shared secrets, proxies operating in different domains can establish a trust relationship 🤝 But if only hop-by-hop security is available, untrusted proxies can pull off a bunch of man-in-the-middle attacks. These include modifying messages.

For example, an Access-Accept could be swapped in for an Access-Reject, and without end-to-end integrity protection the NAS has no way to detect it. 😵 On the home server, this results in an accounting log entry for a session that was never authorized. Still, if the proxy doesn't forward accounting packets or session records to the home server, the home server won't catch the discrepancy until a bill arrives and gets audited 💸

A proxy can also send an Access-Reject to the NAS after receiving an Access-Accept from the home server. This leaves an authentication log entry with no matching accounting log entry 🤔 Without the proxy sending an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server, the home server has no way to tell whether the gap is due to policy implementation or lost accounting packets. So using Acct-Status-Type=Proxy-Stop can be really valuable when debugging roaming systems. 🔍

Even if end-to-end security were available, a bunch of sticky questions would still remain 🧩 The endpoints could detect that a message from the home server had been modified by an intermediary, but then what? The modified packet could be silently discarded, but that could hurt the home server's ability to accept an Acct-Status-Type=Proxy-Stop message from an intermediate proxy. Since that message wouldn't be signed by the NAS, the home server may need to drop it.

This is similar to the problem IPSEC-capable systems face when they try to use ICMP messages from systems they don't have a security association with 🙃 It's harder here, though, because in RADIUS, retransmission is driven by the NAS. So the home server never gets an acknowledgement for Access-Accepts, which means it would have no way of knowing that its response wasn't honored. 📭

7.2. Attribute editing 🎀

Okay, so RADIUS as defined in [3] has no end-to-end security and no capabilities negotiation 😭. That means a home server has no way to securely agree on a config with the NAS or the proxies, and that opens the door to a bunch of attribute editing attacks 💀.

Say the EAP attributes get removed or changed so the client ends up using EAP MD5 or PAP instead of a stronger auth method 🙈. Or the tunnel attributes get messed with so the encryption disappears, the tunnel gets redirected to a rogue tunnel server, or the client's security just gets lessened in general 🥀. The mismatch might only show up after the fact, when you compare the Access-Accept attributes against the ones in the Accounting-Request. And without end-to-end security, a rogue proxy can totally cover its tracks 🕵️‍♀️.

The wild part is that this doesn't even need a villain 🙃. Proxy configs are so complicated that mis-configuration or implementation deficiencies can cause the same problems. Right now, several proxy implementations just strip out attributes they don't understand, and some can be set up to swap the attribute set in the Access-Accept for one that fits a particular NAS 🫠.

Honestly, you can't write a single set of guidelines for attribute editing, because the requirements are very often implementation-specific 🤷‍♀️. But we still need protection against inappropriate editing to block attacks and to make sure users get provisioned exactly the way the home server wants 💖.

Here's the thing: you can't know ahead of time whether a given attribute is editable, so there needs to be a mechanism where senders can mark which attributes are editable and which aren't, and receivers can catch any changes to the "non-editable" ones 🔍. End-to-end security might let you detect unauthorized adding, deleting, or modifying of integrity-protected attributes ✨. But a rogue proxy could still add, delete, or modify attributes that aren't integrity-protected, and if those attributes affect later charges, the fraud risk is still there 😤.

7.3. Theft of passwords 🔐

RADIUS as defined in [3] doesn't give you end-to-end confidentiality either 😬. So when clients authenticate with PAP, every proxy between the local NAS and the home server can read the cleartext password. In a lot of situations, that's an unacceptable security risk 🚨.

7.4. Theft and modification of accounting data 🧾

Okay, in roaming systems, accounting packets usually get shared with every participant along the roaming relationship path, so they can audit later invoices 📑. But RADIUS as described in [3] doesn't have end-to-end security services, including integrity protection or confidentiality 🙃. Without end-to-end integrity protection, proxies can modify accounting packets or session records. Without end-to-end confidentiality, proxies can read the accounting data 👀. If all you want is to stop people snooping on accounting data over the wire, though, IPSEC ESP can do that 🛡️.

7.5. Replay attacks 🔁

So in this attack, a man in the middle or a rogue proxy grabs the CHAP-Challenge and CHAP-Response attributes and replays them later 😱. If they team up with an unscrupulous ISP, they can use that to send fraudulent accounting records for payment 💸. The system doing the replay doesn't have to be the one that originally captured the CHAP Challenge/Response pair.

RADIUS as described in [3] is vulnerable to replay attacks. Without roaming, though, the threat is limited to proxies inside the home server's domain 🏠. With roaming, any proxy that can reach the home server can pull this off 🌍.

7.6. Connection hijacking 🕸️

In this one, the attacker tries to inject packets into the conversation between the NAS and the home server 🦹‍♀️. RADIUS as described in [3] is vulnerable to this because only Access-Reply and Access-Challenge packets are authenticated.

7.7. Fraudulent accounting 💰

Here, a local proxy sends fraudulent accounting packets or session records to collect fees it isn't entitled to 🤑. That includes sending packets or session records for sessions that don't even exist. Since RADIUS as described in [3] has no end-to-end security, a rogue proxy can insert or edit packets without getting caught 😈.

To catch accounting packets or session records for non-existent sessions, it's smart for the parties receiving them to reconcile them against the authentication logs 🧐. This is usually only possible when that party acts as the authentication proxy for every session that will later get an accounting record.

To make reconciliation easier, home servers in roaming setups put a Class attribute in the Access-Accept 🎀. The Class attribute uniquely identifies a session, so an authentication log entry can be matched up with its accounting packet or session record.

If you set up reconciliation and reject every accounting log entry without a matching authentication, the attacker now needs a valid user password before they can submit accounting packets or session records for fake sessions 🔑. End-to-end security can stop unauthorized injection or editing of accounting or authentication packets by intermediate proxies 🙌. But other attacks are still possible. For example, unless replay protection is in place, an intermediate proxy can still resubmit authentication or accounting packets or session records 🔁. Plus, end-to-end security doesn't protect against attacks from the local proxy, because that's usually where end-to-end security gets started 😭. To catch those, you need other measures, like systems that spot unusual activity on ISP or user accounts, or checks on whether a user or ISP account is still within its credit limit 🚦.

Heads up: if you use the store and forward approach to proxy accounting, some systems on the roaming relationship path might get accounting records that others don't 📭. That can cause audit discrepancies. The best you can do in those cases is confirm the accounting data is missing by checking the authentication logs 🔍.

8. Acknowledgments 🫶

Huge thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of CompuServe, Aydin Edguer of Morningstar, Bill Bulley of Merit, and Steven P. Crain of Shore.Net for the useful chats about this problem space 💜.

9. 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

Copyright (C) The Internet Society (1999). All Rights Reserved.

Okay, the legal bit, and it matters 💅. You're allowed to copy and share this document and its translations, and you can write derivative works that comment on it, explain it, or help implement it, and publish and distribute those too, in whole or in part, with no restrictions of any kind 🎉. The one catch is that the copyright notice and this paragraph must be included on every copy and derivative work. The document itself may not be modified in any way, such as removing the copyright notice or the references to the Internet Society or other Internet organizations, except when it's needed for developing Internet standards (in which case the procedures for copyrights in the Internet Standards process must be followed), or when it's being translated into languages other than English 🌍.

These limited permissions are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️.

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫧.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 🌸.

📦 where this page comes from