Re: [Emu] Review of draft-clancy-emu-chbind-02.txt

[Charles Clancy <[e-mail]>]

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