Subject: Re: [Emu] Comments on draft-ietf-emu-chbind-05

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2010 18:00:34 -0400

>>>>> "Joe" == Joe Salowey <[email-masked]> writes:

As I discussed with the chairs, I'm making an update, but it's more of
an update to address specific detailed comments than to really move the
document forward.  There have been some issues in my availability, which
I believe are very close to being resolved.  This work is a dependency
for draft-ietf-abfab-gss-eap, which is one of my major projects so I
definitely do have the interest to move it forward.  I'm sorry that did
not happen as much as we'd all like this cycle.

    Joe> - Protocol definition - there is general consensus that we
    Joe> should include the protocol definition within this document.  I
    Joe> think it would be good to flesh out the following approach in
    Joe> the document to see if it meets working group expectations:
    Joe> define a Channel-Binding-TLV to hold channel binding data;
    Joe> define channel binding data as diameter AVPs.  The protocol
    Joe> should define attributes for at least one case (probably
    Joe> 802.11) and provide guidance for creating binds for other
    Joe> EAP/AAA usages in other follow-on documents.

Agreed.
Very little happened here.

    Joe> Detailed comments follow:

    Joe> 1. Introduction

    Joe> I think it would be good discuss that the problem is manifested
    Joe> when the same set of credentials are used to access different
    Joe> classes or types of services.  This is discussed later in
    Joe> section 4.3, but I believe this to be fundamental to channel
    Joe> binding problem and should be discussed in the introduction.
    Joe> When the EAP server is centralized and accessed from different
    Joe> for different services it typically uses the same set of
    Joe> credentials to authenticate itself to the peer for each service
    Joe> so the peer cannot differentiate between services.  The server
    Joe> could also attempt to detect any discrepancy by forcing the
    Joe> client to use different credentials for each services.  Using
    Joe> different credentials for each different class or type of
    Joe> service has numerous problems.

I added a brief mention in the introduction.
Let me know if more is needed.

    Joe> 2. Section 3

    Joe> In the Enterprise network case its not clear to me that channel
    Joe> bindings alone can alleviate this attack.  The peer does not
    Joe> know which VLAN its traffic is going to, it just knows the
    Joe> SSID.  Likewise the AAA server does not know what VLAN the
    Joe> authenticator is switching the peers traffic to, it only knows
    Joe> what it told the authenticator to do, if the authenticator is
    Joe> compromised, it need not comply.  It is possible that this may

    Joe> be detected by another part of the infrastructure, but this
    Joe> would involve more than the authenticator, peer and AAA.

The unstated assumption here is that the authenticator was only trusted
to attach to one of the networks.
I.E. separate physical infrastructure for enforcing separate security
policy.
That's been stated.
It does diminish the applicability of the use case.

I also added the abfab use case; since that's been chartered it's
reasonable to mention here.

    Joe> One mechanism that deployment use to avoid the "enterprise and
    Joe> provider" problem today is to use different credentials for
    Joe> remote access versus enterprise access.  This is often not
    Joe> ideal, but it addresses the problem.

mentioned.

    Joe> 3. Section 4

    Joe> It could be possible to use EAP channel bindings to address
    Joe> some more traditional channel bindings uses cases by carrying
    Joe> information from the lower layer or encapsulating tunnel in the
    Joe> transported method.

Mentioned.
I dread writing or reading "The use of EAP Channel Bindings to Provide
RFC 5056 Channel Binding for EAP"
(draft-something-eap-chbind-for-chbind-for-eap)
I think it's an illustrative example of the difference, but at this time
I definitely don't want to get into whether it's a good idea.

For your information, I considered and rejected using EAP channel
binding for RFC 2743 channel binding (GSS) in
draft-ietf-abfab-gss-eap. Using the MSK and an exchange between the peer
and authenticator was simpler and didn't depend on the server verifying
I1 against I2 for that particular attribute.  ABFAB still depends on EAP
channel binding in a number of other respects though.

    Joe> 4. Section 4.2

    Joe> This section states that for the system to function the EAP
    Joe> server has to have access to a local database.  THis doesn't
    Joe> sound right to me.  I wouldn't expect many systems would be
    Joe> designed this way.  The accuracy of the AAA attributes would be
    Joe> verified by the AAA server that hosts the EAP server, but
    Joe> perhaps this is too fine a distinction for this document.  I
    Joe> would expect any processing of AAA attributes to be done in the
    Joe> AAA server.

I have added text to loosen the architecture in this regard.
However, it is very messy  if your AAA server and EAP server are
decoupled and you want to make the decision in the AAA server.

Somehow the EAP server needs to communicate the set of attributes
supplied in I1 to the AAA server before generating the success
indication.
Then, the AAA server needs to make a decision and communicate that
decision along with what attributes from I1 were used to the EAP server.
The EAP server needs to encapsulate that  in EAP and then eventually
return the decision.

ABFAB participants  who have discussed the issue would like to depend on being able to get a list of
attributes that were actually considered. I think our reasons are
fairly general: without that it's easy for you to run into situations
where you fail insecure.  We think that will apply to other
situations. Where you want to have a security policy on a peer that
actually involves the channel binding being checked, you need to depend
on this indication.

I think that for decoupled EAP and AAA servers the best you can do is as
follows.

The AAA server has the database. It verifies I2 against the database.
The AAA server passes along to the EAP server information on what its
requirements are for I1. That way the EAP server can verify I1 and
indicate what attributes are used. The "requirements" on I1 may be as
simple as a set of attributes that if present in I1 must match one of
several possible values enumerated by the AAA server.
For some applications it may be sufficient to give a list of attributes
that if present MUST match the values found in the AAA message.

    Joe> 5.  Section 4.3

    Joe> I don't think the RSNIE containing security parameters is not
    Joe> currently carried in a AAA attribute.  Do we still want to use
    Joe> this as an example?

I don't care much.
I left it in until someone provides an example they like more.
I don't think anything in this section is actually wrong.

    Joe> I'm not sure what the 3rd paragraph is getting at.  The peer
    Joe> usually does not have any clue as to what specific VLANs are in
    Joe> use, so its not clear to me what this is saying.

I tried to clean this up.

    Joe> This section probably should briefly cover that in some cases
    Joe> it is possible that the EAP-Server is collocated with the
    Joe> authenticator and AAA is not involved.

I did touch on that in the document; I don't think it ended up here.

    Joe> 6.  Section 5.1

    Joe> In this section I have the same comment about the EAP Server
    Joe> accessing the database.  I think the EAP server interfaces with
    Joe> AAA and AAA maintains and process the AAA
    Joe> attributes. Conceptually the result is the same, so maybe its
    Joe> not such a big deal.  Maybe it would be helpful to describe
    Joe> that other architectural choices are valid.  Separating out the
    Joe> i2 consistency check form the i1 validation could allow the
    Joe> consistency of some attributes to be checked on a different AAA
    Joe> server.

I talked about some parts of I2 being checked on a different AAA server.

    Joe> 7. Section 7

I have no strong opinions about section 7 and 8.  I think I'm going to
need help/text on these sections from someone who has strong opinions.

--Sam