Subject: Re: [Emu] Review of draft-clancy-emu-chbind-03

From: Charles Clancy <[email-masked]>
Date: Mon, 03 Nov 2008 18:38:00 -0500

Bernard,

Version v04 was just submitted and should address most of your comments.

We added some clarifications to discuss the "lying NAS" vs "lying 
provider" problems.  Really all we can reasonably validate is the last 
hop in a AAA proxy chain.  In an enterprise network, that's the NAS.  In 
a service provider network, it's either the proxy for your roaming 
partner, or a gateway like IPass.  If anything down your proxy chain is 
malicious, we consider the entire chain malicious, as we cannot 
determine the origin of an attack within the chain.

We also added a lot more text about AAA attributes received by the EAP 
server by the NAS / last-hop AAA proxy, and which can be validated and how.

Unfortunately I won't be at the EMU meeting -- Katrin will present the 
changes since the last meeting.  I'll in Minneapolis starting Wednesday, 
so hopefully Katrin and I can meet offline with those who have specific 
comments.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Bernard Aboba wrote:
> Wow. The EMU WG mail exploder seems to have badly mangled this email, so 
> let's try again.
> 
> ====================  snip snip =====================
> 
> 
> Food for the exploder....
> 
> 
> ====================  snip snip =====================
> 
> Thanks for the improvements in -03.  Some additional comments:
> 
> Section 1
> 
> "  A concrete example of this may be an IEEE 802.11 access point with a
>    security association to a particular AAA server.  While there may be
>    some identity tied to that security association, there's no reason
>    the access point needs to advertise a consistent identity to clients.
>    In fact, it may include whatever information in its beacons (e.g.
>    different SSID or security properties) it desires.  This could lead
>    to situations where, for example, a client joins one network that is
>    masquerading as another."
> 
> I think there is also a potential MITM attack that channel bindings can address. 
> 
> In IEEE 802.11r, the SSID is bound to the TSK calculation, so that the
> TSK needs to be consistent with the SSID advertised in the Beacon.  
> This would seem to preclude an external attacker from spoofing a Beacon
> and then modifying an Association-Request, but would not avoid a 
> "lying NAS" from sending an intentionally bogus Beacon (and 
> calculating the TSKs accordingly).  
> 
> In IEEE 802.11i, there is no SSID/TSK binding, so both a spoofing and a 
> "lying NAS" attack are possible.  For example, an attacker could spoof
> a Beacon and then modify an unauthenticated Association-Request, so
> as to cause a client to think it's connecting to a network other than
> the one it's actually connected to.  This will work as long as the 
> credentials and method provisioned for the spoofed and actual network
> are the same.  In a "lying NAS" attack, the NAS can provide an incorrect 
> Called-Station-Id), to the AAA server, which will authorize it as long
> as it is one of the networks that could conceivably be authorized via the
> proxy from which the request came (e.g. the NAS can also impersonate another
> NAS from an entirely different network or even a different provider). 
>  
> This could cause the AAA server to believe it had granted access to a 
> different network or even provider than the one the client got access to.  
> However, typically  both the network the client actually got on and the 
> one the AAA server authorized need to be provisioned on the client, right? 
> 
> Section 3
> 
> "     A compromised
>       access point connected to the guest network could advertise the
>       SSID of the corporate network in an effort to lure clients to
>       connect to a network with a false sense of security regarding
>       their traffic.
> "
> 
> This scenario also would appear to assume that the corpnet and the guest network
> utilize the same credentials and EAP method.  Otherwise, the AAA server wouldn't
> provide keys and grant access, right? 
> 
> "     This would cause
>       unknowing handsets to associate with an unintended operator, and
>       consequently be subject to high roaming fees without realizing
>       they had roamed off their home provider's network.
> "
> 
> This scenario (variants of which have actually occurred in practice) seems
> to go beyond the "lying NAS" to the "lying provider" issue.  That seems
> worth highlighting, since it influences the degree to which the AAA server
> can depend on the local proxy.  If the local proxy can't be trusted, then
> this throws doubt on whether channel bindings should be included in 
> cleartext AAA attributes modifiable by the proxy. 
> 
> There might be some even nastier attacks worth mentioning.  For example, a 
> compromised NAS might send a Beacon known to generate a buffer
> overflow within certain (unpatched) drivers.  This Beacon might reflect a
> correct SSID, but might include other bugs IEs.  Once authenticated, the
> compromised client could be used to attack other nodes on the network it
> has gained access to (including the AAA server). 
> 
> Section 4
> 
> "   o  After keys have been derived during an EAP authentication, the
>       peer and server can, in an integrity-protected channel, exchange
>       plaintext information about the network with each other, and
>       verify consistency and correctness.
> "
> Or maybe just log the info (e.g. in the case of the buffer overflow Beacon). 
> 
>    "Advantages of
>    exchanging plaintext information include:"
> 
> You might also mention that this approach works even for access mechanisms that 
> don't subsequently use EAP keying material to protect data (e.g. wired
> 802.1X).  The key-derivation approach cannot do this, since the keys would
> never be used. 
> 
> "  Consequently, information such as the NAS IP address may not be known
>    to the EAP server.  This affects the ability of the EAP server to
>    verify specific NAS properties.  However, often verification of the
>    MAC or IP address of the NAS is not useful for improving the overall
>    security posture of a network."
> 
> I think this understates the issues creates by proxies that do not check
> the validity of information passed to them by the NAS.  If the proxy is
> handling requests from many different providers/networks and does not
> validate them, then what the AAA server can do on its end can be 
> very limited, such much of the useful information will have been "laundered". 
> 
>    Also, a peer's expectations of a network may also differ.  In a
>    mobile phone network, peers generally don't care what the name of the
>    network is, as long as they can make their phone call and are charged
>    the expected amount for the call.  
> 
> This is correct in the sense that the largest threat for provider networks
> is fraud.  However, sometimes it can be difficult to determine what the
> correct "expected amount" is, and frauds of the type you mention earlier
> have actually been perpretrated.
> 
>   Any deployment of channel bindings should take into consideration
>    both what information the EAP server is likely to know, and also what
>    type of network information the peer would want and need
>    authenticated.
> 
> Beyond what an EAP server can know, there is also the issue of how much
> work is required to configure that knowledge.  For example, in theory an
> IT admin can know the BSSID of every AP in their network and where
> they are located.  In practice, collating and configuring all this information
> can be quite difficult (and unlikely to happen in the absence of a legal mandate,
> such as a requirement for E911 support). 
> 
>    This information, i1, could include an authenticator identifier and
>    the identity of the network it represents, in addition to advertised
>    network information such as offered services and roaming information.
>    To prevent attacks by rogue authenticators, the EAP server must be
>    able to verify that i1 either matches its knowledge of the network
>    (enterprise model) or is consistent with the contractual agreement
>    between itself and the roaming partner network to which the client is
>    connected (service provider model).  Additionally, it should verify
>    that this information is consistent with i2.
> 
> I'd suggest you also need to say something about the proxy's obligation to
> verify the correctness of the i2 information.  If this doesn't happen, the
> ability of the AAA server to do so may be quite limited.  In fact, one
> might argue that the burden of i2 verification is largely the proxy's, not
> the AAA server, so that a database should be checked by the proxy). 
> 
>    It must be possible to pass the
>    channel binding data in AAA attributes to proxy AAA if a proxy AAA
>    will need to evaluate the data.
> 
> Does this make sense in a "lying provider" scenario?  I think some more
> justification is required for this "must".  
> 
> Section 7.2
> 
>    [TODO: Need a way to transport the RSN-IE.]
> 
> Is the issue only the RSN-IE?  Or might it be useful to transport other info
> too (e.g. in the malformed Beacon case).  
> 
> Section 8.1
> 
> It also seems that the AAA server has to trust that the AAA proxy has done a
> consistency check on the i2 info it receives, no?  Otherwise, by the time it
> gets to the AAA server it might not be possible to determine whether it was
> correct or not (e.g. IP source address has been "laundered" by the proxy, so
> that Called-Station-Id/NAS-Identifier/NAS-Address/NAS-IPv6-Address can't be
> verified any more.  If many SSIDs are handled by a proxy, then the AAA server
> might not even be able to verify whether the SSID is correct, just that it
> matched what the client received. 
> 
> Section 8.2
> 
>    Dishonest servers can send EAP-Failure messages and abort the EAP
>    authentication even if the received i1 is valid.  
> 
> This is true of proxies as well, but it only works for EAP methods that
> act on the EAP-Failure.  Where method-specific result indications are
> available, the method could ignore the EAP-Failure if the result indications
> indicate success.  A somewhat worse attack can be launched via spoofed
> EAP-Success frames. 
> 
> Section 9.1
> 
>    Additionally, an interface is necessary for populating the EAP server
>    database with the appropriate parameters.  In the enterprise case,
>    when a NAS is provisioned, information about what it should be
>    advertising to peers needs to be entered into the database.  In the
>    service provider case, there should be a mechanism for entering
>    contractual information about roaming partners.
> 
> The potential cost of assembling the "local policy database" from scratch is
> considerable, so you might talk about how this cost could be minimized.  
> For example, it might be possible  to use "leap of faith" to auto-generate 
> the database, using info provided by i2.  For example, if we can assume that
> APs aren't compromised on arrival, but become so over time, when an AP is 
> provisioned the AAA server, the initial Request (i2) could be used to provide
> info stored in the database.  Alternatively, the same info might be needed
> for other reasons (e.g. mapping of BSSID to AP location for the purpose of
> E911 support), so that channel binding support could piggyback on that info. 
> 
> 
> 
> 
> 
>  
>  
> 
>  
> 
> 
> 
> 
> 
> 
> 
> i'm EMAILING FOR THE GREATER GOOD
> Join me <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu