1. Security Considerations
RADIUS protocol was designed for intra-domain use where a proxy may be considered as a trusted component.
In roaming the NAS, proxies and home server will typically be managed by different administrative entities.
This results in a number of security threats.
There are three primary issues that cause difficulties when providing roaming capabilities: security, accounting and scalability. Creating a secure authentication scheme over a publicly accessible network can be extremely difficult.
The RADIUS protocol was designed for intra-domain use, where the NAS, proxy, and home server exist within a single administrative domain, and proxies may be considered a trusted component. However, in roaming the NAS, proxies, and home server will typically be managed by different administrative entities. As a result, roaming is inherently an inter-domain application, and proxies cannot necessarily be trusted. This results in a number of security threats, including:
Message editing Attribute editing Theft of passwords Theft and modification of accounting data Replay attacks Connection hijacking Fraudulent accounting

2. Message Editing
If only hop-by-hop security is available then un-trusted proxies may perpetrate a number of man-in-the-middle attacks.
Example: Proxies sends to NAS Access-Reject instead of Access-Accept. The home server will have an accounting log entry for this session. If proxy does not forward accounting packets to home server, this will pass undetected until a bill is received.
Through the use of shared secrets it is possible for proxies operating in different domains to establish a trust relationship. However, if only hop-by-hop security is available then un-trusted proxies are capable of perpetrating a number of man-in-the-middle attacks. These include modification of messages.
For example, an Access-Accept could be substituted for an Access-Reject, and without end-to-end integrity protection, there is no way for the NAS to detect this. On the home server, this will result in an accounting log entry for a session that was not authorized. However, if the proxy does not forward accounting packets or session records to the home server, then the home server will not be able to detect the discrepancy until a bill is received and audited.

3. Message Editing contd…
Example: Proxy sends Access-Reject to NAS after receiving Access-Accept from home server. Authentication log without corresponding accounting log. If proxy doesn’t send Accounting-Request with Acct-Status-Type=Proxy-Stop to home server, the home server can’t distinguish between policy implementation or loss of accounting packets.
Note that a proxy can also send an Access-Reject to the NAS after receiving an Access-Accept from the home server. This will result in an authentication log entry without a corresponding accounting log entry. Without the proxy sending an Accounting-Request with Acct-Status-Type=Proxy-Stop (6) to the home server, then there will be no way for the home server to determine whether the discrepancy is due to policy implementation or loss of accounting packets. Thus the use of Acct-Status-Type=Proxy-Stop can be of value in debugging roaming systems.

4. Message Editing contd…
If there were end-to-end security
End points would be able to detect modified messages.
What should be done?
Discard modified packet?
Affects home server accepting Acct-Status-Type=Proxy-Stop message as it would not be signed by NAS.
Retransmission is driven by the NAS, therefore home server does not receive acks for Access-Accepts. Doesn’t know if its response is honored.
It should be noted that even if end-to-end security were to be available, a number of sticky questions would remain. While the end-points would be able to detect that the message from the home server had been modified by an intermediary, the question arises as to what action should be taken. While the modified packet could be silently discarded, this could affect the ability of the home server to accept an Acct-Status-Type=Proxy-Stop message from an intermediate proxy. Since this message would not be signed by the NAS, it may need to be dropped by the home server. This is similar to the problem that IPSEC-capable systems face in making use of ICMP messages from systems with whom they do not have a security association. The problem is more difficult here, since in RADIUS retransmission is driven by the NAS. Therefore the home server does not receive acknowledgement for Access-Accepts and thus would have no way of knowing that its response has not been honored.

5. Attribute Editiing
RADIUS does not support capabilities negotiation. Can’t securely negotiate mutually acceptable configuration with NAS or proxies.
Example: EAP attributes modified to cause client to authenticate with MD5 or PAP instead of a stronger authentication method. Or tunnel attributes removed or modified to remove encryption, redirect tunnel to rogue tunnel server, or lessen security.
RADIUS as defined in does not provide for end-to-end security or capabilities negotiation. As a result there is no way for a home server to securely negotiate a mutually acceptable configuration with the NAS or proxies. As a result, a number of attribute editing attacks are possible. 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.

6. Attribute Editing contd…
Mismatch between request & received service may only be detectable after comparing Access-Accept attributes against Accounting-Request attributes. End-to-end security will cover this risk.
Can add end-to-end security by defining non-editable attributes by integrity-protection.
The mismatch between requested and received services may only be detectable after the fact by comparing the Access-Accept attributes against the attributes included in the Accounting-Request. However, without end-to-end security services, it is possible for a rogue proxy to cover its tracks. Due to the complexity of proxy configuration, such attacks need not involve malice, but can occur due to mis-configuration or implementation deficiencies. 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 NAS. In practice, it is not possible to define a set of guidelines for attribute editing, since the requirements are very often implementation-specific. At the same time, protection against inappropriate attribute editing is necessary to guard against attacks and provide assurance that users are provisioned as directed by the home server. Since it is not possible to determine beforehand whether a given attribute is editable or not, a mechanism needs to be provided to allow senders to indicate which attributes are editable and which are not, and for the receivers to detect modifications of "non-editable" attributes. Through implementation of end-to-end security it may be possible to detect unauthorized addition, deletion, or modification of integrity-protected attributes. However, it would still possible for a rogue proxy to add, delete or modify attributes that are not integrity-protected. If such attributes influence subsequent charges, then the possibility of fraud would remain.

7. Theft of Passwords RADIUS does not offer end-to-end confidentiality.
Where clients use PAP, each proxy along the path between local NAS & home server will have access to password.
Hidden Attribute used to provide end-to-end confidentiality.
RADIUS as defined in does not provide for end-to-end confidentiality. As a result, where clients authenticate using PAP, each proxy along the path between the local NAS and the home server will have access to the clear-text password. In many circumstances, this represents an unacceptable security risk.

8. Theft & Modification of Accounting Data
In roaming systems, accounting packets are provided to everyone in roaming relationship path in order to allow auditing.
Without end-to-end integrity security, proxies may modify accounting packets or session records.
End-to-end confidentiality.
IPSEC can prevent snooping.
End-to-end-signature may be used to prevent modification. Hidden attribute may be used for confidentiality.
Typically in roaming systems, accounting packets are provided to all the participants along the roaming relationship path, in order to allow them to audit subsequent invoices. RADIUS as described in does not provide for end-to-end security services, including integrity protection or confidentiality. Without end-to-end integrity protection, it is possible for proxies to modify accounting packets or session records. Without end-to-end confidentiality, accounting data will be accessible to proxies. However, if the objective is merely to prevent snooping of accounting data on the wire, then IPSEC ESP can be used.

9. Replay Attacks
Man in the middle collects CHAP-Challenge and CHAP-Response attributes and replays them.
Can be used to submit fraudulent accounting records for payment.
Hidden attribute may be used to prevent this type of attack.
In this attack, a man in the middle or rogue 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 for payment. The system performing the replay need not necessarily be the one that initially captured the CHAP Challenge/Response pair.
While RADIUS is vulnerable to replay attacks, without roaming the threat is restricted to proxies operating in the home server's domain. With roaming, such an attack can be mounted by any proxy capable of reaching the home server.

10. Connection Hijacking
Attacker injects packets into conversation between NAS and home server.
RADIUS is vulnerable as only Access-Reply and Access-Challenge packets are authenticated.
End-to-End-Signature may be used to prevent this attack.
In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the home server. RADIUS is vulnerable to such attacks since only Access-Reply and Access-Challenge packets are authenticated.

11. End-To-End Security
Assume a key has been established between the two endpoints. This key will be used to check end-to-end integrity and end-to-end encryption of attributes.
Security-Parameters-Index attribute is used to identify the security association within the End-to-End-Signature and Hidden attributes.
As noted in Roaming Requirements, there is a need for end-to-end security in roaming, including end-to-end integrity protection, and confidentiality. In roaming implementations based on proxy chaining, packets are routed between the NAS and home server through a series of proxies. Current roaming implementations provide only hop-by-hop security, guarding only against modification of packets in transit between hops. This makes it possible for un-trusted proxies to modify packets sent between a NAS and a home server without detection, as well as to decrypt PAP passwords, Tunnel passwords, and other hidden attributes which are available to it in clear-text. This document provides a framework for end-to-end security in roaming, making it possible to provide end-to-end message integrity and attribute hiding through addition of three new attributes.
Security-Parameter-Index, Hidden and End-to-End-Signature. In this document, it is assumed that a key has previously been established between the two endpoints. It is this key which is used in calculation of the mes sage integrity check, as well as in end-to-end encryption of attributes. Future documents will discuss key exchange issues The Security-Parameters-Index attribute is used to identify the secu rity association within which the End-to-End-Signature and Hidden attributes are to be evaluated. Note that in the case where an inter mediate proxy implements policy, it is possible for a security associ ation to be established between the intermediate proxy and the home server, NAS, or local proxy. For example, an intermediate proxy may immediately send an Access-Reject to the NAS in response to an Access Request, without having first forwarded it to the home server. In this case, the intermediate proxy and NAS would need to establish a secu rity association in order to permit verification of the authenticity of the Access-Reject.

12. Hidden Attribute
Hidden Attribute used to protect an attribute end-to-end.
Used by encapsulating and then encrypting another attribute within the hidden attribute.
Using the Hidden attribute, it is possible for the client or server to protect an attribute end-to-end. This is accomplished by encapsulating and then encrypting another attribute within the Hidden attribute.

13. End-to-End Signature
Used to provide a keyed MAC (Message Authentication Code) which will allow end-to-end integrity protection. HMAC-MD5.
Keyed MAC calculated over un-editable portions of packed header and attributes preceding End-to-End-Signature attribute.
Some or all attributes may be protected at users discretion.
Using the End-to-End-Signature attribute, it is possible for a client or server to provide a keyed MAC which will allow end-to-end integrity protection. The keyed MAC is calculated over the immutable portions of the packet header, as well as all of the attributes preceding the End-to-End-Signature attribute. This makes it possible for some or all of the attributes in the packet to be protected, at the sender's discretion. While a proxy may add, delete or modify unprotected attributes, it MUST NOT add, delete or modify protected attributes so that the validity of the keyed MAC can be maintained. A proxy also MUST NOT modify an End-to-End-Signature or Hidden attribute. On receiving a packet including an End-to-End-Signature attribute, an end system implementing end-to-end security MUST check the validity of the message integrity check and MUST silently discard the packet if the message integrity check cannot be verified. By allowing the message integrity check to be applied to a subset of attributes selected by the sender, and by allowing attributes to be hidden individually, these extensions enable end-to-end security functionality while at the same time enabling proxies to continue to implement policy. Policy function is a central part of the roaming architecture since roaming is inherently an inter-domain activity.

14. Bibliography
Bernard Aboba, Juan Lu, John Alsop, James Ding, and Wei Wang, “Review of Roaming Implementations”, RFC 2194, September 1997.
Bernard Aboba and Glen Zorn, “Criteria for Evaluating Roaming Protocols”, RFC 2477, January 1999.
Bernard Aboba and Mark A. Beadles, “The Network Access Identifier”, RFC 2486, January 1999.
Bernard Aboba and John Volbrecht, “Proxy Chaining and Policy Implementation in Roaming”, RFC 2607, June 1999.

15. Bibliography
Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
Yuan John Jiang, “Secure Radius Server Operation Guidelines for Dial Raoming”, draft-ietf-roamops-sec-00.txt, October 1997.
Pat Calhoun and Bernard Aboba, “End-to-End Security in Roaming”, draft-ietf-roamops-roamsec-02.txt, July 1998.
Pat R. Calhoun and Glen Zorn, “Roamops Authentication / Authorization Requirements”,draft-ietf-aaa-roamops-auth-req-00.txt, March 1999.
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.