Alan DeKok [mailto:[email protected]] writes:
> Glen Zorn wrote:
> > Indeed it could, but all you really seem to be asking for is a way for
> the
> > corporation to be able to control the configuration of the client.
>
> That is already done outside of the scope of EAP. (VPN config,
> Directory services, etc.) The only requirement I see for EAP is that it
> support channel bindings, and an indication that the home AAA approves
> of the connection.
Hmm. I could have sworn that this indication already existed, in the form
of "Access-Accept" (for RADIUS).
>
> > As you point out, it is reasonable to expect that the corporation
> knows the
> > identity of its own access points; why does it matter what the client
> > _thinks_ (for lack of a better word) that it is attached to? I cannot
> see
> > any purpose for the client sending the SSID of the network to which it
> > attached.
>
> It's part of the channel binding. It closes the loop between what the
> NAS tells the AAA, and what the NAS tells the client.
Only in the special case where (in your roaming example, below) roaming
partners X and Y have direct relationships with the home network. Suppose,
for example, that the client connects to partner X, which correctly
identifies itself. The "channel binding" is duly reported by the client
through EAP & by the NAS through AAA; however, the AAA traffic passes
through an intermediate realm (say, Z). So now the home AAA server has
received conflicting messages: the EAP "channel binding" says the attachment
is to X, as do the AAA attributes, but the AAA message came (as far as can
be determined) from Z. Of course this problem can be solved using e2e-ish
AAA integrity protection ("-ish" modulo the level of trust between realms &
within each realm) but I can't think of another way. No standard IETF AAA
protocol provides even e2e-ish security now, though.
>
> Right now in a commercial roaming scenario, the NAS could tell the
> user "we're partner X: $0.05 / minute". It could *really* be partner Y:
> $5.00 / minute. The user naively connects, and the bill is larger than
> expected. The partner gets paid, and the user gets blamed for not
> paying attention.
This is a legal/political problem, not a technical one.
...
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
