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

From: Joe Salowey <[email-masked]>
Date: Thu, 16 Sep 2010 14:13:43 -0700

I like the direction the document is taking.  I think the following are the biggest open issues in the document;

- Refinement of use cases -  not all of the examples in the document are compelling (see detailed comments below).  These need refining and we should also look for use cases dealing with 802.11u and perhaps using EAP in other environments (ABFAB).  

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

Detailed comments follow:

1. Introduction

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

2. Section 3

In the Enterprise network case its not clear to me that channel bindings alone can alleviate this attack.  The peer does not know which VLAN its traffic is going to, it just knows the SSID.  Likewise the AAA server does not know what VLAN the authenticator is switching the peers traffic to, it only knows what it told the authenticator to do, if the authenticator is compromised, it need not comply.  It is possible that this may be detected by another part of the infrastructure, but this would involve more than the authenticator, peer and AAA.  

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

3. Section 4

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

4. Section 4.2

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

5.  Section 4.3

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

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

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

6.  Section 5.1

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

7. Section 7

Called-Station-ID needs to reference RFC 3580

Since 802.11u is dealing with advertising services we need someone familiar with 11u to check to see if there is anything we need to include here. 

If we are carrying username it seems we would want to know what NAI the client specified?

8. Section 8

General question: If the attributes are not used in section 7 should they be included in section 8?  If an attribute is include in section 7 shouldn't it be included in section 8?

I think we may need to be more specific about what we want the username comparison to do.  For example are we comparing against the authenticated name?  WHat about the realm part or other decoration?  

Called station Id and calling station ID formats depend upon the media/port type.