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

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 17 November 2008 12:46 UTC

Return-Path: <proxies-bounces@ietf.org>
X-Original-To: proxies-archive@ietf.org
Delivered-To: ietfarch-proxies-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E413A6924; Mon, 17 Nov 2008 04:46:15 -0800 (PST)
X-Original-To: proxies@core3.amsl.com
Delivered-To: proxies@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619B73A682E for <proxies@core3.amsl.com>; Mon, 17 Nov 2008 04:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.417
X-Spam-Level:
X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=1.181, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb3-iTq2DvvU for <proxies@core3.amsl.com>; Mon, 17 Nov 2008 04:46:12 -0800 (PST)
Received: from blu0-omc2-s23.blu0.hotmail.com (blu0-omc2-s23.blu0.hotmail.com [65.55.111.98]) by core3.amsl.com (Postfix) with ESMTP id EF51828C0E9 for <proxies@ietf.org>; Mon, 17 Nov 2008 04:46:04 -0800 (PST)
Received: from BLU137-W33 ([65.55.111.73]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 04:46:04 -0800
Message-ID: <BLU137-W333556ADC7F652C409736093130@phx.gbl>
X-Originating-IP: [130.129.77.140]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Yoshihiro Ohba <yohba@tari.toshiba.com>, <proxies@ietf.org>
Date: Mon, 17 Nov 2008 04:46:04 -0800
Importance: Normal
In-Reply-To: <20081117094507.GA18657@steelhead.localdomain>
References: <20081117094507.GA18657@steelhead.localdomain>
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Nov 2008 12:46:04.0369 (UTC) FILETIME=[73F69C10:01C948B2]
Subject: Re: [proxies] Comments on draft-hoeper-proxythreat-01
X-BeenThere: proxies@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <proxies.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/proxies>
List-Post: <mailto:proxies@ietf.org>
List-Help: <mailto:proxies-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1202805927=="
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

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

The problem is greater than AAA. 

In AAA and SIP, a number of "end-to-end" security proposals have been
put forward.  In SIP, we have S/MIME for message bodies; in AAA we
had Diameter CMS.  There are no known implementations of either. 
In AAA we have had an implementation of Kerberos/RADIUS; however, 
there is little or no deployment of Kerberos for the purposes of
federation either within RADIUS or SIP (where Kerberos has also been
implemented).  Both Diameter and SIP have included the concept 
of Redirects; while this functionality is widely implemented, I don't
believe it is widely deployed for either protocol.  There are now 
new initiatives in SIP for e2e keying (ZRTP, DTLS/SRTP).  
We will see if these are successful.  

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

Not all AAA intermediaries are proxies.  For example, in
Diameter there are also Redirects and Relays.  I'd also note
that SIP proxies (as opposed to SBCs) have very restricted
header modification behavior. 

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

Note sure what "AAA keys" means here.  Are we talking about 
keying material used to protect AAA?  The term "AAA keys" was
deprecated by RFC 5247. 

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

Right.  These threats are discussed in detail in RFC 5247. 

>    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?

In the PSTN, can we really say that all parties trust each other?
For example, does AT&T really trust rural Iowa phone companies?
I would suggest not:
http://www.msnbc.msn.com/id/17752411/

If not, are we talking about trust or "Trust but Verify"?



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

It should be understood that data and signaling traffic do not
necessarily follow the same path, either for AAA or SIP. 

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

I would suggest using a term other than "data packets" for AAA
traffic.  We're really talking about signaling here. 

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

Any proxy on the AAA roaming relationship path by 
definition has access to AAA signaling traffic, right? 

Routers can redirect AAA packets, but they lack the credentials
necessary to fool other AAA intermediaries into accepting them.  

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

Are we talking about data traffic here or AAA traffic?  As described in 
RFC 5247, it is not necessarily true that possession of the MSK/EMSK
can allow an attacker to decrypt data between the user and the NAS. 
For example, this is not true in IKEv2 using EAP authentication 
(e.g. transient keys are not derived from EAP keying material). 

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

In particular, it can be used to gather geographic location information,
Network Access Control Posture or Statement of Health info, etc.


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

What kind of data are we talking about?  AAA signalling? 

Possession of EAP keying material does not necessarily imply the
ability to forge data packets on behalf of the user. 

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

For this attack to work, the fake authentication would need to 
succeed -- otherwise the accounting data would have no corresponding
successful authentication, which would be suspicious.  Posession of
AAA shared secrets is not sufficient for this -- the attack would need to
possess user credentials (or mount a successful replay attack). 

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

By data we mean AAA signaling, right?

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

I'm told that it is common for Diameter deployments to provide no
security at all (e.g. no integrity, authentication, confidentiality, etc.).


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

Does "protected" mean "hidden" here?  Just because an attribute
isn't "hidden" doesn't mean that any entity can modify it without
detection (e.g. the AAA packets can still be integrity protected). 

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

Why is out-of-band negotiation required?  This was not the case in say,
Diameter CMS or RADIUS/Kerberos.
> [YO] Is it always the case both ends of the proxy chain have direct
> roaming agreements with each other?

With roaming brokers (e.g. Boingo) this is typically not the case. 

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

If a company makes a roaming agreement with Boingo they might trust
them, but do they trust all the entities that Boingo might make an 
agreement with, including Fred's Bait and Sushi shop? 

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

I would be interested in understanding why the solutions that have
already been proposed (and in some cases, implemented) were not
deployed. 
_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies