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
