-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Hoeper Katrin-QWKN37
Sent: Thursday, May 28, 2009 4:03 PM
To: klaas(mailer list)
Cc: [email protected]
Subject: Re: [Emu] review of chbind-01
Hello Klaas,
Thank you for your very thorough review!
And sorry that it took me so long to reply.
My replies are in-line and will be reflected in the next
draft version that I plan on posting shortly.
I would appreciate your and the group's feedback on whether I
addressed all your comments.
I'd like to ask the group to check Klaas' primary comment
since it is concerned with the scope of the draft. I'd be
interested to know who shares this concern and whether the
current draft should be modified accordingly. You'll find my
opinion on this matter among my other replies below.
Regards,
Katrin
-----Original Message-----
From: Klaas Wierenga [mailto:[email protected]]
Sent: Tuesday, April 28, 2009 3:26 AM
To: Hoeper Katrin-QWKN37
Cc: [email protected]
Subject: review of chbind-01
Hi Katrin,
I have reviewed your draft and I think the content is in
principle in pretty good shape, see my comments further
below. I have however a more fundamental concern that I would
like to hear your (and others') opinion
about.
I have the feeling that the draft is too complicated because
you mix two, only loosely related, problems. The way I see it
there are 2 fundamental issues:
1) the NAS talks to both the peer and to the authentication
server and the information given to both doesn't have to be
consistent
2) the NAS gives information to authentication server (via the peer
or
not) and the authentication server needs to evaluate that
information and make policy decisions based on that.
Issue 1 is for me the one that most needs solving, and I
would prefer this draft to focus on that one only. Issue 2 is
not so much a technical
problem as a business problem. The administrative entities
controlling respectively the NAS and the AuthN server need to
agree on the info they
exchange and it is than up to the administrative entity to
process that info (and log it for non-repudiation purposes
etc.) and make policy
decisions on them.
Wrt to issue 1 I wonder if it is not sufficient to just
"close the loop", i.e. have the NAS send the same info to
both peer and AuthN server. Or alternatively, have all the
info flow through the peer, that way you can be sure that
peer and AuthN server have a consistent view of
what the NAS offers.
[KH] I agree that the solution presented in the current draft
consists of a technical part (exchange end-to-end secured
information between the peer & server, verify it and notify
the peer about the result) and an administrative part
(setting up a database to support the consistency and
compliance checks of the exchanged channel binding information).
Introducing a database to the network model is absolute
essential for the solution to work. First of all, the
exchanged information cannot be directly compared because
peer and server may have a different view of the network
information provided by the NAS/authenticator. For example,
the peer may identify a NAS by its SSID, whereas the EAP
server may only know the NAS-IP-Address. In order for the
server to check whether both addresses belong to the same
device, a table look-up is required. Such look-up tables are
stored in the local database. Secondly, in roaming scenarios
the server cannot "know" each NAS of all visited networks
that the home network has a roaming agreement with. Here, the
server can only check whether the information broadcasted by
a NAS in a visited network complies with the roaming
agreement with this network. For that reason, rules derived
from the agreements and policies need to be stored in a
database, such that the server can use these rules for its
consistency/compliance checks.
I hope we can agree on that a database is absolute essential
for implementing meaningful channel bindings and that channel
bindings in roaming scenarios need to make use of rules that
have been derived from agreements and/or policies. The draft
does not say how these rules are derived, that is indeed
outside the scope.
Bernard suggested in one of his earlier reviews to utilize
such policy compliance checks to validate authorizations,
e.g. checking whether a peer is authorized to access a
particular part of a network or using a particular media. In
addition, the solution enables the server to check whether an
authenticator is authorized to grant access to a peer under
the given circumstances. These authorization checks are
included in the draft and are carried out by additional
compliance checks. IMO this is a nice feature that can be
achieved using channel bindings without changing the
underlying protocol. It only requires additional information
to be stored in the database. If there is a consensus that
this feature should be outside the scope of the draft, it
could be moved to a separate draft. Again, though, the local
database and some compliance checks would still be a part of
the remaining channel binding solution.
------------------------------------------------------
My concrete comments:
1, par 2: "while there may be some identity tied to that
security association"
What do you mean with "identity", are you talking about
NAS-identifier, or something more generic?
[KH] Yes, we are referring to NAS-IP-Address, NAS-Identifier and
such.
Proposed solution: "While there may be some identity tied to
that security association, such as the NAS-Identifier,
there's no reason the access point needs to advertize a
consistent identity to clients."
1, par 4: "consistent with the defined network policy"
I think it is not so much consistent as well as that is
'satisfies' the defined network policies
[KH] Agree. What about 'compliant' instead? In addition, I
think its best to explicitly distinguish between the
consistency and the compliance checks.
Proposed solution: "This allows the server to verify the
authenticator is providing information to the peer that is 1)
consistent with the information stored about this
authenticator and 2) compliant with the defined network
policy. In addition, the presented solution allows the server
to verify that the peer is authorized to access the network
in the manner described by the NAS."
3, par 1: I think you should call out here that proxy's are
an example of that, you mention it later but it helps to give
the reader an idea what you are talking about.
[KH] Agree.
Proposed solution: "Additionally, while an authenticator may
not be compromised, other compromised elements in the
networks (such as proxies), could provide false information
to the authenticator..."
3, examples: I don't find the examples very compelling, how
about for example a NAS giving wrong billing info to the peer
"5$ all you can eat,
while sending per minute rates to the Auth server?
[KH] The current roaming example was chosen to illustrate an
attack where victims are not aware of that they are actually
roaming. If you (or anybody else) can come up with a more
compelling example for the enterprise case, please let me know.
Proposed solution: I will add another simple example to the
Service Provider Network case along the lines of what you suggested.
4: "...do not ensure the binding different layers..." ->
"...the binding
OF different layers..."
[KH] Corrected.
4.1: is the fact whether it is plaintext or opaque the unique
difference? I would argue that it is whether it is in a
separate channel
or inline in the session key derivation. I think the
plaintext vs opaque
doesn't add anything here, later in your requirements you
point out that
the info sent needs to be protected, that seems enough to me.
[KH] Here, we wanted to emphasize that only the exchange of
the data allows an analysis of the information rather than a
bitwise comparison.
Latter only works for identical information (not always
feasible, see different address/identifier discussion) that
is exactly encoded in the same way (not really practical).
Proposed solution: "The peer and server can both uniquely
encode their respective view of the network information
without exchanging it, resulting into an opaque blob that can
be included directly into the derivation of EAP session keys."
4.2.: is it not enough to just say that the AuthN server and
the peer need to get the same info? isConsistent would become
isEqual, much easier to compute...... ;-)
Unfortunately, isEqual is not feasible (see earlier
discussion and address/identifier example). Another way to
put it: Let's imagine peer and NAS/authenticator speak Dutch
with each other, whereas the NAS/authenticator and the
authentication server speak German. The isConsistent check
allows us to verify whether both pieces of information have
the same meaning (using the dictionary stored in the local
database). On the other hand, the isEqual check will always fail.
Proposed solution: none.
5.1, par 1: isConsistant -> isConsistent
[KH] Corrected.
5.2, par 1: conistency of i1 and i2 and evaluating the policy
is indeed nontrivial, but policy evaluation should imo be out
of scope for this draft anyway. Policy verification is a
local problem at the Auth server side, it has nothing to do
withy the communication protocols.
[KH] See my reply to your first comment.
6.2: "EAP methods MUST be able to import channel binding data
from the lower layer...."
I don't understand this requirement, what type of data are we
talking about?
[KH] For example, a peer should include the SSID received in
the Beacon of a NAS/authenticator in i1. Consequently, a peer
must be able to include information in i1 that has not been
received as part of the EAP method. In order to do this, the
EAP method must be able to access this kind of information
from a lower layer.
Proposed solution: none
7.2: NAS-Port-Type
Why a MUST? I can imagine many use cases where from a policy
point of view I couldn't care less what medium type I am using
[KH] Agree
Proposed solution: change to SHOULD
7.3: again, why a MUST?
[KH] Disagree. This is not a policy question. This AVP is
essential for mitigating lying NAS attacks and thus should be a MUST.
Proposed solution: none
7.3.?: I think it worthwhile including 802.11u, after all
this deals with NASes communicating data about their network
to the peers, that is exactly what 11u does.
[KH] Older draft versions included additional link-layers
(admittedly not 11u), but were removed due to lack of
feedback from the group on which AVPs should be included.
Instead a few general attributes are provided that are useful
to all link-layers (Section 7.2) and attributes for .11, 11r
and 11s are listed as an example (Section 7.3). This is
intended to provide a guideline for implementers to choose
appropriate attributes when implementing channel bindings on
different link layers.
If you (or somebody else) happen to know which 11u AVPs
should be used here, please let me know and I include them.
Proposed solution: none, unless feedback from group is received
9.1:
There is also trust between NAS/Authenticator and AuthN
server. The Authenticator relies on the Authentication server
for policy decisions.
[KH] The trust model for channel bindings assumes that peer
and server are honest, while the authenticator is the
potential attacker (e.g.
lying NAS attack, etc). In a trust model you usually don't
care who the attacker trusts.
10.1, par 4: I don't think you put contractual info about
roaming partners in the database, but the rules in the policy
engine are rather the results of that.
[KH] Agree
Proposed solution: "In the service provider case, there
should be a mechanism for entering policy rules that have
been derived from the contractual information about roaming
partners."
Cheers,
Klaas
[KH] Prost, Katrin
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
