Subject: Re: [Emu] review of chbind-01

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Thu, 28 May 2009 19:03:04 -0400

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-masked]] 
Sent: Tuesday, April 28, 2009 3:26 AM
To: Hoeper Katrin-QWKN37
Cc: [email-masked]
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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 31 May 2009 15:42:53 -0700

I'm not sure I quite understand the differences between the two cases. 
 
I think Klaas is saying that we need a protocol to exchange channel
binding information, but we should stop before we define rules on how to
evaluate this information.   While I think that the requirements for the
protocol are absolutely necessary, I believe the analysis would be
incomplete if we did not provide information on how the data is expected
to be evaluated.    In many cases this evaluation needs to be done
against stored data to validate the correct operation of the system.  

Joe

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hoeper Katrin-QWKN37
> Sent: Thursday, May 28, 2009 4:03 PM
> To: klaas(mailer list)
> Cc: [email-masked]
> Subject: Re: [Emu] review of chbind-01
> 
> Hello Klaas,
> 
> 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
> 
> 
> 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
> 
> 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 
> 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.
> 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?
> 
> 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." 
> 
> 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,
> 
> [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.
> 
> [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.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.
> 
> 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
> 
> [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.
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/emu
>