[Emu] Review of draft-clancy-emu-chbind-03.txt

[Bernard Aboba <[e-mail]>]

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. 





 
 

 







> Date: Wed, 15 Oct 2008 14:15:39 -0400
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> Subject: Re: [Emu] Review of draft-clancy-emu-chbind-02.txt
> 
> Bernard,
> 
> The recently-submitted -03 addresses most of your comments.  You 
> suggested two additional sections which are TBD -- an appendix 
> describing how channel bindings addresses a number of specific attacks, 
> and a cost-benefit analysis.
> 
> Can you be more specific about the cost-benefit analysis?  Do you mean a 
> monetary one?  Cost to operators or cost to equipment providers?
> 
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
> 
> 
> Bernard Aboba wrote:
> > Overview:  This version of the document still has some issues remaining.
> >  
> > Section 1
> >  
> >    The so-called "lying NAS" problem is a well-documented problem with
> >    the current Extensible Authentication Protocol (EAP) architecture
> >    [RFC3748] when used in pass-through authenticator mode.  Here, a
> >    Network Access Server (NAS), or pass-through authenticator, may
> >    represent one set of information (e.g. identity, capabilities,
> >    configuration, etc) to the backend Authentication, Authorization, and
> >    Accounting (AAA) infrastructure, while representing contrary
> >    information to EAP clients.
> > 
> > [BA] As noted in the review of -00, the issue isn't just whether the
> > NAS is sending different information to the EAP peer and
> > AAA server.  It also is possible that the NAS will send the same
> > information to the peer and AAA server, but that both could be
> > wrong.
> >  
> > Section 3
> >  
> >    There are two different types of networks to consider: enterprise
> >    networks and service provider networks.  In enterprise networks, we
> >    assume a single administrative domain, making it feasible for an EAP
> >    server to have information about all the authenticators in the
> >    network.  In service provider networks, global knowledge is
> >    infeasible due to indirection via roaming.  When a client is outside
> >    its home administrative domain, the goal is to ensure that the level
> >    of service received by the client is consistent with the contractual
> >    agreement between the two service providers.
> >  
> > [BA] While the AAA server might have information about all the 
> > authenticators
> > in the enterprise case, if it is more than one hop removed from the NAS, 
> > then
> > it might not be able to check the validity of the AAA attributes.  For 
> > example,
> > a first hop AAA server can check if the NAS-IP-Address/NAS-IPv6-Address
> > attributes match the IP source address corresponding to the shared secret.
> > A AAA server multiple hops away cannot verify this.
> >  
> >    o  Service Provider Network: An EAP-enabled mobile phone provider
> >       operating along a geo-political boundary could boost their cell
> >       towers' transmission power and advertise the network identity of
> >       the neighboring country's indigenous provider.  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.
> > 
> > [BA]  This seems like a good example.  My understanding is that
> > power boosting actually does occur.  It might be worthwhile to consider
> > adding an Appendix to talk about how channel bindings might address
> > this or other potential examples. 
> >  
> >    o  It allows for fuzzy comparisons of network properties, rather than
> >       requiring absolute comparisons.  This allows for a broader
> >       definition of consistency, rather than bitwise equality.
> > 
> > [BA] As discussed during the EMU WG meeting, a term other than "fuzzy"
> > would probably be better.  Also, there probably needs to be more discussion
> > on why enabling bit-by-bit comparisons is undesirable or not important.
> >  
> > Section 4
> >  
> >    o  Given it doesn't affect the key derivation, exact use of the
> >       results can be subject to policy, to facilitate debugging,
> >       incremental deployment, and backward compatibility.
> > 
> > [BA] I think the major issue with the key derivation approach is that in
> > practice, "canonicalization" and formatting issues are highly likely in
> > a channel bindings implementation, even if formats are well specified.
> > The implication of this is that requiring enforcement may not be 
> > practical; rather
> > logging, or evidence gathering may be all that can be achieved.  The key
> > derivation approach can't support such a "logging only" mode; enforcement
> > is required.
> >  
> >    The scope of EAP channel bindings differs somewhat depending on the
> >    type of deployment in which they are being used.  In enterprise
> >    networks, they can be used to authenticate very specific properties
> >    of the authenticator (e.g.  MAC address, supported link types and
> >    data rates, etc), while in service provider networks they can
> >    generally only authenticate broader information about a roaming
> >    partner's network (e.g. network name, roaming information, link
> >    security requirements, etc).  The reason for the difference has to do
> >    with the amount of information you expect your home EAP server to
> >    know about the authenticator and/or network to which you are
> >    connected.  In roaming cases, they are likely to only know
> >    information contained in their roaming agreements.
> > 
> > [BA] It would probably also be worth talking about the inability to directly
> > verify the correctness of some parameters in the multi-hop case (in either
> > enterprise or service provider scenarios).
> >  
> > Section 5
> >  
> >    Channel bindings are always provided between two communication
> >    endpoints, here the EAP client and server, who communicate through an
> >    authenticator in pass-trough mode.  During network advertisement,
> >    selection, and authentication, the authenticator presents
> >    unauthenticated information, labeled i1 for convenience, about the
> >    network to the peer.  As there is no established trust relationship
> >    between the peer and authenticator, there is no way for the peer to
> >    validate this information.  Our goal is to transport i1 from the peer
> >    to the server, and allow the server to validate it against
> >    information i2 it has stored in its local database, labeled DB.
> > 
> > [BA] As we discussed in the EMU WG meeting, is Channel Bindings only about
> > the AAA server verifying the info sent from the NAS to the EAP peer, or 
> > is it
> > also about comparing the AAA attributes against that information?  For 
> > example,
> > would it be ok if the peer got the correct information, but the AAA 
> > attributes
> > are incorrect?
> >  
> >    This information, i1, could include the identity of the authenticator
> >    and 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).
> >  
> > [BA] The term "authenticator identity" is used in multiple places, without
> > being defined.  RFC 5247 defines this as the NAS-Identifier/NAS-IP-Address/
> > NAS-IPv6-Address attributes, but I'm not sure this is what you mean here.
> > One issue with highlighting this particular problem is that even in IEEE 
> > 802.11r,
> > the NAS-Identifier is not advertised in the Beacon. 
> >  
> >    Note that in addition to just returning a validation result
> >    indicating whether i1 and i2 are consistent, the EAP server can
> >    optionally return i2 in its entirety.  This would allow the EAP
> >    server to provide additional, authenticated information about network
> >    or authenticator to which the client has connected that the client
> >    may wish to use in deciding whether the authenticator is authorized
> >    to provide the type of service the client desires.  This goes beyond
> >    the general definition of channel binding, but allows for additional
> >    flexibility.
> > 
> > [BA] How does the EAP server/AAA server obtain the information i2?  For
> > example, is it indexed via some key AAA attributes (e.g. NAS-Identifier)?
> >  
> > 
> >    One way to transport the single round-trip exchange is as a series of
> >    Diameter AVPs formatted and encapsulated in EAP methods per
> >    [I-D.clancy-emu-aaapay].  For each lower layer, this document defines
> >    the parameters of interest, and the appropriate Diameter AVPs for
> >    transporting them.  Additionally, guidance on how to perform
> >    consistency checks on those values will be provided.
> > 
> > [BA] One potential complicating factor will be RADIUS extended attributes.
> > These will be encoded as Diameter vendor-specific AVPs, potentially with
> > grouping.  It might make sense to explicitly state that attributes 
> > useful for
> > Channel Bindings should probably be allocated in the standard RADIUS space,
> > to avoid this potential "gotcha".  It also might be useful to state how the
> > comparison is to be done (e.g. ignore Diameter AVP 'M' bit). 
> >  
> > Section 7.1
> >  
> >    The client SHOULD transmit to the server the following fields,
> >    encapsulated within the appropriate Diameter AVP:
> > 
> >       SSID
> >       BSSID
> >       RSN IE (if present)
> > 
> >    The server MAY send the Cost-Information AVP from the Diameter
> >    Credit-Control Application [RFC4006] to the peer indicating how much
> >    peers will be billed for service.
> > 
> > [BA] There is currently no AAA attribute for sending the SSID by itself,
> > only the combination BSSID/SSID (e.g. Called-Station-Id).   The RSN IE
> > currently isn't carried either.  You might want to review
> > draft-aboba-radext-wlan-08.txt for a list of the new attributes that
> > are being proposed for usage with various IEEE 802 media (including
> > IEEE 802.11, 802.16, 802.1X-REV, etc.).
> >  
> > Having the server send the Cost-Information AVP is an interesting idea.
> > However, is this information 802.11-specific or might it be useful in many
> > media?
> >  
> > Section 9
> >  
> >    The EAP peer will need an API between the EAP lower layer and the EAP
> >    method that exposes the necessary information from the NAS to be
> >    validated to the EAP peer, which can then feed that information into
> >    the EAP methods for transport.  For example, an IEEE 802.11 system
> >    would need to make available the various information elements that
> >    require validation to the EAP peer which would properly format them
> >    and pass them to the EAP method.  Additionally, the EAP peer will
> >    require updated EAP methods that support transporting channel binding
> >    information.  While most method documents are written modularly to
> >    allow incorporating arbirary protected information, implementations
> >    of those methods would need to be revised to support these
> >    extensions.
> > 
> > [BA] The issue is not just about modification of the EAP lower layer --
> > in many cases, drivers will need to be changed as well to provide the
> > required information, and in the interim before this happens, there may
> > be cased where an EAP method that is Channel-Binding capable will not
> > be able to obtain channel binding information. 
> >  
> > Overall, I'd suggest that a section be added laying out the cost/benefit
> > analysis.  Although multiple vendors have attempted to implement Channel
> > Bindings, to my knowledge none of those implementations have shipped, 
> > because
> > the cost are easy to identify (and are high)  and the benefits are more 
> > difficult
> > to get a handle on (and are less amenable to quantification).   
> >  
> >    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.
> > 
> > [BA] Do we really expect operators to enter in all potential AAA
> > parameters into the database?  This seems like a substantial
> > operational burden.  Instead, I'd suggest that for some parameters,
> > auto-registration might be helpful -- allowing the database to be
> > populated based on the AAA attributes first obtained from the NAS when
> > it is provisioned.  While this trusts that the NAS isn't sent to the
> > operator in a compromised state, but only becomes compromised later,
> > it would ease the operational burden.
> > 
> > i'm EMAILING FOR THE GREATER GOOD
> > Join me <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > Emu mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/emu