Hannes,
Another quick comment on the value derived by operators for deploying
channel bindings -- channel bindings will give operators the ability to
apply detailed authorization policies to EAP-based network access.
Right now EAP is primarily just an authentication facility, and
authorization is based on only information about the peer. Now
authorization can also be based on information about the NAS, and the
properties of the network to which the peer is connecting.
Using channel bindings, for example, an EAP server could ensure that
certain users only connect to 802.11 networks using AES for link-layer
security or with certain SSIDs, for example, while other users could
connect to any network.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Charles Clancy wrote:
Hannes,
Thanks for the comments. I'm working on a revision that addresses the
"fuzzy comparison" issue. Certainly there's a cost to implementing
channel bindings. EAP methods already support carrying the information,
so the only changes would be to their implementations, which could be
done incrementally.
Having the authenticator send information to the EAP server for
comparison doesn't work. The authenticator could simply provide the
same false information to both the peer and server. The server needs
some way to know whether the information the authenticator is sending is
consistent with network policy. Therefore it needs a policy database.
If it has the policy database, it no longer needs the authenticator to
send this information to it during every transaction.
The exact AVPs exchanged are still open for debate. The text there is
mostly just a place holder. We need to know what types of things people
thing are appropriate for validation.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Tschofenig, Hannes (NSN - FI/Espoo) wrote:
* When I have to introduce this work to our AAA server folks then they
will obviously ask me the following question: What is the benefit and
what does it cost? As you mentioned in the operational considerations
section there is cost associated with updating the EAP methods, putting
new information into the AAA server database, providing additional
policies into the AAA server to accomplish the authorization check. Now,
the question really is whether folks are so concerned about the attack.
I know the Lying NAS problem but the current text isn't scary enough.
Have you ever seen some data that this attack is a real issue? In case
you do then it would certainly be valuable information to convey this to
the reader.
* Reading the operational consideration section I get the impression
that you consider that the AAA server database is populated with
information about the access points and what information they are going
to send to their peers. That might be one way of doing it.
Another way would be for the AAA client to send the same set of
parameters to the AAA server for comparison.
* I am not sure how this fuzzy comparison would look like and how one
would do that in practice. Does it mean that you just compare some
parameters?
Incorporating channel binding information into the key derivation
functions would, for sure, get things to break even if the operator
running the AAA server decides not to enforce it. It is good that you
did not go for that approach.
* Figure 1
I think that there is a possible information exchange missing in Figure
1. Shouldn't you also include an arrow between the Authenticator and the
EAP server?
* You write:
"
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.
"
To my knowledge, this is not done for network access. This may be done
for higher layer applications but AoC isn't really something that you
find quite often...
* IEEE 802.16
The case is somewhat different here since the access network can
actually be authenticated.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
