[proxies] Comments on draft-hoeper-proxythreat-01

My comments on draft-hoeper-proxythreat-01 are below.

Thanks,
Yoshihiro Ohba

---------------------------------------------------------

1. Introduction  

   Currently, AAA proxies are implemented in many access networks 
   serving a variety of purposes. For example, proxies provide a 
   scalable solution for access management in large networks. 
   Furthermore, proxies can enable roaming because mobile nodes (MN) can 
   access other networks by authenticating to their home server through 
   local proxies. 

[YO] I think roaming is possible without proxies.  Perhaps this
paragraph needs more explanation.

Some of these tasks require proxies to possess AAA 
   keying material. 

[YO] An example of AAA keying material would be needed to understand
this paragraph.

   The introduction of proxies can change the security model of a 
   network as well as of the implemented protocols. As a consequence, 
   AAA proxies may introduce new security vulnerabilities. However, 

[YO] Since security threats described in this document is general
ones, I don't see new security vulnerabilities.

   currently the role of AAA proxies in networks and all their security 
   implications are not considered in many existing RFCs and Internet 
   drafts. The relationship with RFC 4962 [1] is the most glaring aspect 
   of the problem, but the progress of numerous drafts in a number of 
   working groups is affected by the so-called "proxy problem". 

[YO] This document would be useful if it gives some analysis on why
the "proxy problem" has been unsolved.  IMO, the "proxy problem" is
left unsolved due to lack of a practical and complete solution for
dynamically establishing end-to-end security associations betweeen AAA
clients and AAA servers.

   Recently, there have been attempts to reconcile the widespread 
   deployment of AAA proxies with the security requirements of 
   individual Internet protocols or protocol extensions.   

   While the re-occurrence of the proxy problem in several WGs may be 
   bothersome and slow down progress, the problems are more severe for 
   providers and users of already existing implementations with proxies. 
   Doubts exist whether current security claims stated in RFCs and 
   Internet Drafts are still valid for implementations with proxies. 

[YO] The above sentence require detailed explanation on what security
claims stated in which RFCs and I-Ds are doubtful.

   Hence, providers of networks with proxies that rely on such security 
   claims may have unknowingly introduced new vulnerabilities to their 
   systems that have not been covered in the respective protocol 
   specifications. For the same reasons, users of such systems may be 
   unknowingly exposed to attacks. 

   Concluding, the proxy problem may affect existing and future 
   implementations of Internet protocols whose specifications neglected 
   proxies in their security considerations. If security issues 
   introduced by proxies are not identified and addressed, future 
   protocol specifications will suffer from the same problems. 

1.1. Goals of this Document 

   Since the "proxy problem" challenges the credibility of existing RFCs 
   and slows down the progress of many IETF WGs, it seems necessary to 
   evaluate this problem in detail and make the results available to all 
   current and future IETF WGs and other standard bodies. 

   This document shows how AAA proxies may change the security models of 
   networks and their employed protocols in several use cases. Even more 
   importantly, the document analyses the feasibility as well as 
   severity of the identified threats. 

   As a result, this draft can be used as a tool for risk assessment of 
   a network with AAA proxies or protocols implemented in such networks. 
   This draft shows which attacks by proxies are feasible in particular 
   use cases under certain conditions. It is up to the 
   provider/implementer/protocol designer to decide whether the 
   identified threats justify the costs that would be introduced by 
   countermeasures such as infrastructure and/or protocol modifications  

   Current and future drafts that are subject to the "proxy problem" 
   could reference this document to point out possible vulnerabilities 
   and risks. 

   Technical solutions addressing the identified vulnerabilities are not 
   presented in this draft. However, authors of affected protocol 
   specifications are encouraged to use the presented threat model to 
   design a case-based security solution or at least highlight proxy-
   related security vulnerabilities. The threat model presented in this 
   draft could also serve as basis for designing more general solutions 
   in a separate draft.   

1.2. Scope 

   This document focuses on security issues related to AAA proxies and 
   the discussions and results in this memo should not be applied to 
   other types of proxies. However, it is encouraged to work on similar 
   documents for other kind of proxies. 

   This document solely identifies security-related issues introduced by 
   AAA proxies and their severity but neither provides solutions to 
   address these problems nor discusses non-security related issues 
   (such as routing, performance, etc.). Furthermore, this document does 
   not consider AAA proxies that are configured to solely serve as a re-
   direct (as supported by Diameter), because such proxies do not need 
   to gain access to attributes and/or keying material.    

1.3. Terminology 

   This section defines terms that are frequently used in this document. 

   AAA                                                                
      Authentication, Authorization, and Accounting (AAA). AAA protocols
      include RADIUS [2] and Diameter [3]. 

   AAA Server                                                         
      A server which provides AAA services via an implemented AAA  
      protocol to mobile nodes. 

[YO] Add a statement "AAA proxy can act as AAA server."

   AAA Client                                                         
      A network entity sending AAA requests to the AAA server and  
      receiving AAA replies from the AAA server. NAS and AAA proxy can
      both act as AAA client. 

   AAA Proxy                                                              
      An AAA proxy provides routing for AAA requests and replies. An 
      AAA proxy appears to act as an AAA client to the AAA server and 
      as AAA server to the AAA client. In this draft, pure re-direct 
      proxies as supported by Diameter are not considered. Only AAA 
      proxies that are capable of modifying attributes and may possess 
      cryptographic keying material are considered. 

   MN                                                                 
      A mobile node (MN) that wishes to access the network. 

   NAS                                                             
      The Network Access Server (NAS) is the network entity that mobile
      nodes contact in order to obtain access to the network. 

   Proxy Chain                                                        
     A routing path through a sequence of AAA proxies. In roaming   
     scenarios, when a proxy chain is across different administrative 
     domains, roaming agreements exist between the first and last proxy 
     of the chain as well as between each neighboring pair of proxies. 

   Roaming agreement 
     Roaming agreements include agreements between companies and 
     Internet Service Providers (ISPs), agreements among peer ISPs 
     within a roaming association, and relationships between an ISP and 
     a roaming consortium. These agreements require a certain level of 
     trust among all parties of a roaming agreement. 
     In the context of this draft, roaming agreements between two 
     administrative domains imply that AAA proxies in these domains may 
     share pairwise AAA keys with each other or may be capable of 
     establishing such pairwise keys. 

2. Problem Statement  

   Unlike some other network entities that simply forward packets in the 
   network, AAA proxies are designed to have additional capabilities and 
   properties such that the AAA protocols executed through AAA proxies 
   may have the following features:  

   o  AAA proxies are able to modify and/or delete AAA attributes 

   o  AAA proxies share pairwise AAA keys with the AAA server and/or 
      other AAA proxies; 

   o  AAA proxies and NAS cannot be distinguished by AAA server; 

   o  AAA proxies and AAA server cannot be distinguished by NAS; 

   o  AAA proxy chains cannot be distinguished from single proxies by 
      neither NAS nor AAA server.  

   The above special features may lead to new security vulnerabilities. 
   For example, a proxy could modify or delete some attributes of an AAA 
   request/reply. Or a proxy in possession of AAA keying material can 
   break the end-to-end integrity and/or confidentiality between NAS and 
   AAA server that is assumed in some protocols. 

[YO] Are these new security vulnerabilities?  I don't think so.

The last three bullets 
   show that the other communicating entities might not even be aware of 
   the proxies on the communication path. In the case of a single proxy 
   or a chain of proxies [4] between NAS and AAA server, not every party 
   authenticates to all parties it communicates with as required in RFC 
   4962[1]. The sum of these and other security issues imposed by AAA 
   proxies is referred to as "proxy problem" in this document. 

3. Related Work 

   [Editor's note: what other references should be mentioned here?] 

   The "Security Consideration" Section of RFC 2607 [4] outlines 
   security threats introduced by proxies in roaming scenarios using 
   RADIUS. These observations and other threats will be further analyzed 
   in this draft in a more general context. For instance, threats 
   introduced by AAA proxies are analyzed in several use cases. In 
   addition, this draft allows an application-based risk analysis. 

4. Use Cases 

   [Editor's note: Any more use cases?] 

   For easier identification of vulnerabilities as well as analysis of 
   feasibility and severity of attacks, a representative set of use 
   cases for AAA proxies in networks are supplied here. 

(snip)

5. Threat Model 

   To be able to analyze security vulnerabilities introduced by AAA 
   proxies and their risks, a threat model needs to be established 
   first. Section 5.1. describes the different players in the threat 
   model. Section 5.2. defines the attacks an AAA proxy may launch in 
   any of the use cases that have been described in Section 4.  

5.1. Network Entities and their Trust Relationships 

   Since this document focuses on potential security risks introduced by 
   AAA proxies, all other network entities (such as AAA servers and NAS) 
   and MNs are assumed to execute all protocol steps faithfully and do 
   not behave maliciously in any way. The practicability of these 
   assumptions is out of scope of this document.  

[YO] I would say all other AAA protocol elements are assumed to
execute all protocol steps faithfully.  For example, MNs that are not
AAA protocol elements may not be considered as faithful if we want to
discuss a malicous AAA proxy and a malicous MN work together to do
some malicious attempt on the roaming services.

   The above assumptions are generally based on the following trust 
   relationships: 

   o  Within a home domain (can be also considered as an intra-domain) 
      it is assumed that all entities are correctly configured and not 
      controlled by a malicious party. This can be achieved by intrusion 
      detection systems or other means to detect so-called malicious 
      insiders. 

[YO] The above is an assumption not a trust relationship.  Also, I am
not sure if there is any difference between home domain and other
domains in terms of existence of a malicious party and
mis-configuration.

   o  The trust relationships between a home network and other local 
      networks are specified in roaming agreements. These roaming 
      agreements imply that the home network trusts the local network to 
      faithfully carry out the roaming services that have been agreed on 
      under specified conditions (e.g. roaming fees).  

[YO] Do you also assume that AAA proxies in the local network
faithfully carry out the roaming services?  If yes, then what is the
problem with AAA proxies?

   This document deals with potential security threats introduced by AAA 
   proxies. The attacks (as specified in the next Section) are executed 
   by an AAA proxy that is either controlled by an adversary or mis-
   configured. In this threat model the following types of malicious 
   proxies are distinguished: 

     1. Proxies in the home network 

     2. Proxies in the visited network 

     3. Proxies in a proxy chain between the home and the visited 
        networks 

   Furthermore, these three proxy types are split into authentication 
   and accounting proxies.  

5.2. Potential Attacks 

   A malicious or misconfigured AAA proxy may launch the following 
   attacks: 

[YO] Should we include issues with misconfigured AAA proxies in the
scope of the proxy problem?  If yes, then it may be difficult to find
out a solution for it based on security solutions.  I would suggest
focusing on issues with malicious AAA proxies only.

     1. Passively eavesdrop on network traffic  

     Monitoring network traffic is feasible for any entity with access 
     to the network. It does not require any special capabilities or 
     privileges, such as the knowledge of cryptographic keying material. 
     Consequently, this attack is not limited to AAA proxies. 

     Traffic analysis can be used to track the activity and/or mobility 
     of particular users. 

     2. Replay data packets  

     This attack consists of two phases: (i) the recording of data 
     packets of previous network authentications and (ii) the replaying 
     of this data at a later time. This requires access to the network 
     but no knowledge of keying material. Hence, the attack is not 
     limited to proxies. 

     Replay attacks are typically prevented by the AAA protocol itself 
     with the aid of time variant information. There are legacy 
     operation modes in RADIUS that can be replayed easily (Access-
     Request packets without the Message-Authenticator attribute, which 
     is against the Recommendation of RFC 5080[6]). 

     3. Re-direct data packets 

     Any proxy could maliciously re-direct AAA data packets. This 
     requires access to the routing path but no knowledge of keying 
     material. Hence, the attack can also be carried out by routers and 
     is not specific to proxies. 

     It appears that this attack can only be exploited for Denial of 
     Service (DoS) attacks [Editor's note: Is this true?] which are 
     typically not preventable by cryptographic means.  

     4. Drop data packets 

     As for re-direction attacks, any proxy can drop packets causing re-
     transmissions that can lead to a denial of service. [Editor's note: 
     Is there any other attack?]. This attack can be executed by all 
     entities on the routing paths, i.e. it is not limited to proxies 
     and, e.g., can also be executed by routers. 

     Note that this attack cannot easily be distinguished from "natural" 
     packet losses. 

     5. Actively extract confidential information from network traffic 

     Where AAA protocols do not encrypt their payload or parts of it on 
     the wire, an attacker may extract confidential information from the 
     packet without knowledge of encryption keys. In this case, any 
     intermediate hop (like routers) can eavesdrop on the non-encrypted 
     parts of the protocol payload. 

     If the protocol payload is encrypted as a whole, this attack 
     requires the knowledge of the encryption key(s). If shared AAA keys 
     are used for encrypting data, then a proxy in possession of these 
     keys can decrypt the data.  

     For example, this attack can be used to gather personal user 
     information or accounting information (such as roaming fees and 
     offered services) of competitive networks. 

     6. Fabricate fake data packets 

     This attack requires the knowledge of the keying material used to 
     protect data packets. If shared AAA keys are used for protecting 
     data, then a proxy in possession of these keys can generate fake 
     data packets.  

     For instance, a malicious proxy could fabricate valid 
     authentication packets for an unauthorized mobile node or fabricate 
     fake accounting data to charge for unused services. 

     7. Modify messages 

     If shared AAA keys are used for protecting AAA messages, then a 
     proxy in possession of these keys can modify the data.  

     If an AAA message is not protected, any proxy or any other network 
     entity can modify it.  

     If an AAA message (protected or unprotected) is not bound to any 
     other protected message it can be dropped by any proxy or other 
     network entity on the routing path.  

     8. Modify AAA attributes 

     If shared AAA keys are used for protecting AAA attributes, then a 
     proxy in possession of these keys can modify the attributes.  

     If an AAA attribute is not protected, any proxy or any other 
     network entity can modify it.  

     If an AAA attribute (protected or unprotected) is not bound to any 
     other protected AAA message or attribute it can be dropped by any 
     proxy or other network entity on the routing path. 

     Current AAA protocols provide shared keying material for payload 
     protection and thus expose packet contents to proxies. There are 
     key wrapping schemes to protect individual attributes though, which 
     can encrypt AAA attributes between any two AAA servers while not 
     exposing them to intermediate AAA proxies. These key wrapping 
     schemes require out of band negotiation of wrapping keys, which is 
     hardly scalable.  

[YO] In addition to the above security issues, I think there is
another security issue in which a malicous AAA proxy provides keying
material to a malicous MN offline to launch security attacks on the
roaming services, and it may not be considered as violation of the
roaming agreement if there is no evidence that AAA proxy provided the
keying material to the malicous MN.

6. Risk Analysis 

   This section uses the threat model in Section 5. to analyze the 
   feasibility and severity of the identified attacks 5. in each of the 
   uses cases discussed in Section 4. An attack is only considered a 
   risk, if the attack is feasible and the impact is sufficiently severe 
   to justify the attack's costs from an attacker's perspective. 

6.1. Feasibility 

   It can be observed that the feasibility of attacks by proxies depend 
   on the use case, the type of employed proxies, and whether the proxy 
   possesses keying material required for an attack.  

   In general, the existence of malicious home proxies in an enterprise 
   network (and thus the feasibility of attacks in such networks) is 
   fairly unlikely because enterprise networks can be efficiently 
   protected. For such an attack, the trust assumption in the home 
   network must be violated (see Section5.1. ). 

   On the other hand, in roaming scenarios, the attacks by proxies (as 
   listed in Section 5.2. ) can be classified as more feasible because 
   they can be carried out by local proxies and/or proxies in a proxy 
   chain between home and visited network. The trustworthiness of 
   visited proxies is specified in the respective roaming agreements, 
   while the trustworthiness of proxies in proxy chains may depend on a 
   chain of roaming agreements. In a proxy chain, both ends of the chain 
   (i.e. home and visited network) have roaming agreements with each 
   other as well as neighboring pairs of proxies in the chain. Only if 

[YO] Is it always the case both ends of the proxy chain have direct
roaming agreements with each other?

   the chain consists of three or less proxies, the home network 
   directly trusts all proxies (up to two) in the chain. For chains 

[YO] I don't understand why the home network can directly trusts all
proxies (up to two) in the chain.

   longer than three (including the end points) trust is transitive, 
   i.e. the home proxy does not directly trust all proxies on the chain 
   but rather trusts its direct neighbor to only have agreements with 
   other trusted proxies and so forth. This results into a chain of 
   trust. It can be observed, that a violation of this chain of trust is 
   more likely than a direct trust violation in the home or visited 
   network. Furthermore, the longer the proxy chain, the more diluted 
   may the trust relations become and the more likely is a compromised 
   or mis-configured proxy as part of the proxy chain. 

[YO] Why the longer the proxy chain, the more diluted may the trust
relations become?

   In any case, attacks in roaming use cases require that a trust 
   relation as part of the roaming agreements is violated (see Section 
   5.1. .  

[YO] There may be some attacks that may not require that a trust
relation as part of the roaming agreements is violated.  See my
earlier comment.

   In addition, the feasibility of attacks depend whether they require 
   knowledge of keying material. For instance, attacks 1-4 in Section 
   5.2. do not require the knowledge of keying material and thus can be 
   executed by any proxy. On the other hand, attacks 5-8 require the 
   knowledge of the AAA keying material that has been used to protect 
   the data under attack. However, the possession of keying material is 
   likely because AAA protocols are often based on hop-by-hop security 
   using shared keys. In addition, proxies often need to be able to 
   adjust (protected) AAA attributes to meet local requirements. 

6.2. Severity  

   In enterprise networks, the severity of attacks are rather limited, 
   because the exchanged data would not be of great value for an 
   attacker and the exploitation of fabricated of modified packets is 
   limited (e.g. because of the lack of accounting data and mobility 
   pattern of users). 

[YO] Are you saying that information exchanged over enterprise
networks is not be of great value?  If so, I have to disagree.

     The severity of all attacks in roaming scenarios is higher due to 
     the higher value of the exchanged information and offered services. 
     For instance, traffic analysis attacks (attack 1) could be of 
     interest to track the movements of particular mobile users. DoS 
     attacks (attacks 3 and 4) could bring down the entire services, so 
     the risk can be considered moderate to severe depending on the 
     offered services. 

     Especially accounting information is an attractive target for an 
     adversary. However, the information of free roaming services (use 
     case 2) can be of value as well. For example, in [5] data can 
     contain the age, nationality, and other personal information of the 
     mobile user wishing to access the network. Modification attacks can 
     also be a severe risk, e.g. under aged users can control proxies to 
     modify the age in order to pass the age limit for a requested 
     service or local proxies may modify the roaming information to make 
     their network services more attractive but later charge more. In 
     addition modification attacks can be used for the downgrading of 
     negotiated security credentials. Fabrication attacks can be 
     classified as extremely severe in use case 3, because a malicious 
     accounting proxy could fabricate false accounting information, such 
     that the home network is charged for roaming fees even though no 
     mobile node actually roamed. 

7. Security Considerations 

   TBD 

8. IANA Considerations 

   This document has no IANA considerations. 

9. Conclusions 

   This draft facilitates implementers and providers of networks with 
   AAA proxies as well as protocols designers to carry out a risk 
   analysis of threats introduced by AAA proxies. The result of such 
   analysis enables to decide whether the potential security 
   vulnerabilities introduced by AAA proxies in the network justify the 
   costs of necessary system or protocol modifications to thwart the 
   identified attacks. 

   Furthermore, as another result of this draft, it can be observed that 
   security solutions thwarting proxy attacks can be expected not to be 
   of pure technical nature. The feasibility of attacks highly depends 
   on the reliability of trust assumptions in enterprise networks and 
   roaming agreements in roaming applications. 

[YO] I am not sure whether the above paragraph can be observed by
reading this document.  How do you define the reliability of trust
assumptions in the first place?

   Technical solutions such as providing end-to-end protection of AAA 
   attributes and messages can prevent modifications and fabrication 
   attacks and should be carefully studied in future works. 

[YO] I would be much interested in technical solutions...

(snip)
-------------------------------------------------------------------------

_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies