Subject: [Emu] review of chbind-01

From: Klaas Wierenga <[email-masked]>
Date: Tue, 28 Apr 2009 10:26:22 +0200

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.

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?

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

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.

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?

4: "...do not ensure the binding different layers..." -> "...the binding 
OF different layers..."

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.

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...... ;-)

5.1, par 1: isConsistant -> isConsistent

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?

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

7.3: again, why a MUST?

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.

9.1:

There is also trust between NAS/Authenticator and AuthN server. The 
Authenticator relies on the Authentication server for policy decisions.

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.

Cheers,

Klaas