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
Re: [Emu] Review of draft-clancy-emu-chbind-02.txt
Hi, 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. I second that, as I'm living close to a geo-political border and am *constantly* in the foreign network. It can easily happen even without boosting when the base stations are placed in a challenging geological shape (hill regions...). Well at least the GSM network ID is not faked in my case and I can see that I'm roaming on the handset. Also apart from that, the problem of facing the same network ID in a roam/non-roam scenario is popping in our WiFi deployment eduroam in real life. We advertise the same SSID globally to ease roaming. Meanwhile, some hotspots are so close to one another that a user may not notice if he's being logged into his home network (a university) or a roaming network nearby (the pub next door to that university). Having a negotation mechanism within EAP to be able to tell supplicants if they are in a roaming state or not would be very beneficial. 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). Depending on the amount of AVPs in the EAP round-trip, also EAP methods with currently little amounts of data to be transferred from supplicant to RADIUS server might become too large to fit into a UDP datagram and the pain of fragmentation as we already see it with EAP-TLS might become relevant. That appears to be unavoidable though (and can be mitigated by using a reliable transport). 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 second that demanding a full set to be entered is operationally very difficult, if not prohibitive, in larger environments. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Review of draft-clancy-emu-chbind-02.txt
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 p
