Subject: [Emu] EAP and authorization

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 17 Aug 2009 23:41:23 -0700

Steve Hanna said:

"However, I agree that it would be better to get IESG clarification

that carrying authorization data in EAP is permissible. As Alan

suggested, the first step is probably to have a WG consensus

check to verify that we have rough consensus that this should

be permitted. After that, maybe we would ask the IESG for a

clarification of the applicability statement for EAP.

I will note that the IESG has already approved a change to the

EMU charter to add a work item for channel bindings. So they

have already indicated their support for that effort."

Do we really need "IESG clarification" or a "consensus check" to verify that

IESG approval of a work item for channel bindings should be

interpreted as approval to actually work on channel bindings???

Given that Channel Bindings is discussed in both RFC 3748 and 5247,  I

think we can say definitively that regardless of whether Channel Bindings

are actually useful (personally, I have doubts) that they are within the

the scope of applicability of RFC 3748.  

However, since those documents make it clear that Channel Bindings were 

not intended as a generic authorization exchange (despite the confusion on 

that point within the Channel Bindings document).   Therefore IESG approval
of 

a Channel Bindings work item should not be construed as a license to change 

the definition of Channel Bindings to satisfy another distinct need.   Doing

so would require updating of RFC 3748 and 5247, which is not within the EMU

WG charter.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Aug 2009 09:40:07 +0200

Bernard Aboba wrote:
> Do we really need “IESG clarification” or a “consensus check” to verify
> that IESG approval of a work item for channel bindings should be

  No.

> the scope of applicability of RFC 3748. 

  Yes.

> that point within the Channel Bindings document).   Therefore IESG
> approval of

  The discussion here is (a) if we can get *some* generic authorization
passed via methods used for Channel Bindings, and (b) is that a good idea.

  I think that the answer to (a) is "yes", and (b) is "some say yes,
some say no".

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Aug 2009 06:53:45 -0700

>   I think that the answer to (a) is "yes", and (b) is "some say yes,

Existing RFCs are clear that Channel Bindings have a specific purpose and 
are not a generic authorization mechanism.  For example, RFC 3748 
Section 7.15 states:

"   In order to address this vulnerability, EAP methods may support a
   protected exchange of channel properties such as endpoint
   identifiers, including (but not limited to): Called-Station-Id
   [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-
   Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address
   [RFC3162].

   Using such a protected exchange, it is possible to match the channel
   properties provided by the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  Where discrepancies
   are found, these SHOULD be logged; additional actions MAY also be
   taken, such as denying access.
"

Given the above (and similar material in RFC 5247),  it would seem (surprise!) 
that channel bindings relate to properties of the channel.   Despite the confusion 
introduced by Section 1 of the Channel Bindings document, the parameters 
actually discussed in the Channel Bindings document generally appear consistent 
with existing work.  

I say "generally" because the document does appear to need an update or two.
For example,  Section 7.3.2 of the Channel Bindings document
introduces the Mesh-Key-Distributor-Domain-Id.  My understanding is that
this parameter has been removed from 11s, so this section is now out of date.