Glen Zorn wrote: > Alan DeKok [mailto:al...@deployingradius.com] writes: >> 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).
And EAP-Success. Exactly. >> 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). This happens a lot in roaming configurations. > 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. It also contains a Called-Station-Id attribute with the SSID of X. So the home server can verify that SSID against the channel bindings. >> 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. It motivates the technical solution. Having a security protocol which doesn't verify the identities of those involved is... surprising. Channel bindings closes a security issue in current deployments of the EAP protocol. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
