>>>>> "Joe" == Joe Salowey <[email protected]> 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
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
