Subject: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Apr 2007 13:43:29 -0400

Hi.

For the last couple of years, we've been believing that EAP and GSS
used the term channel bindings inconsistently.  For those of us
dealing with both, it's been a bit annoying.

I've been thinking about EAP a lot lately. and have come to the
conclusion that actually the terms are used consistently.

I'd like to see if people agree with the following change to Nico's channel binding draft:

old:

   Also unfortunately there is a conflict with the Extensible
   Authentication Protocol (EAP) [RFC3748] which uses "channel binding"
   to refer to a facility that is subtly different from the one
   described here.  (It does not seem feasible to adopt new terminology
   to avoid these problems now.  The GSS-API, NFSv4 and other
   communities have been using the terms "channel binding" and "channel
   bindings" in these ways for a long time, sometimes with variations
   such as "channel binding facility" and so on.)

new:

The Extensible Authentication Protocol (EAP) [RFC3748] includes two
facilities related to channel binding.  The first, called channel
binding, is used to bind the lower-layer channel created between the
peer and the authenticator to the authentication performed using EAP.
Specific detials of this facility have not been specified, but it is
likely that this channel would use endpoint channel bindings carried
in the EAP method exchange.  The endpoint channel bindings would be
defined for the specific lower layer.  EAP also has a facility called
cryptographic binding, which is another instance of channel binding.
Cryptographic binding refers to binding the channel created by a
tunneling EAP method to an inner authentication performed within that
method.  Cryptographic binding will likely use unique channel
bindings.

Do these changes make sense to people?  Am I telling any lies or
conflating two architectures in a bad way?

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 6 Apr 2007 14:41:09 -0400 (EDT)

Sam,

In skimming through Nico's draft, it looks like EAP's crypto bindings look
something like GSS channel bindings.

EAP's channel bindings, on the other hand, don't really look like GSS
channel bindings.  In order for EAP's channel binding to look like GSS
channel binding, EAP channel binding would have to cryptographically bind
an L2 security association to EAP keys -- but that's not what it's doing. 
It's binding L2 identities to EAP keys.  In fact, there's no reason it has
to be an L2 identity.  It can be any identity that's meaningful to the
parties involved, and can serve as the basis for making authorization
decisions.

Perhaps you could abstract the definition of channel bindings even further
such that all three are subsets of some common terminology... but that
sounds painful.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 6 Apr 2007 15:13:04 -0400 (EDT)

> As long as it's cryptographically bound to the L2 channel and that
> channel provides suitable protection for the EAP method doing the EAP
> channel binding, THEN Sam's observation is correct: "EAP channel
> binding" uses what I termed "end-point channel binding" and "EAP
> cryptographic binding" uses what I termed "unique channel binding."

I don't think I'm convinced that EAP channel bindings are doing this
binding to the L2 channel.  The identity used in an EAP channel binding
must be bound to the AAA security association between the authenticator
and the peer  in order for everything to work, so it would be more likely
a NAS-ID than a MAC address.

That's not to say there isn't an L2 binding happening -- but I think it's
being performed by the L2 secure association phase that uses the EAP key
to derive L2 keys.  Then during that handshake, a MAC address may be
involved, binding in an L2 identity.

I guess I see EAP channel bindings as an EAP<->AAA binding, and the L2
secure association protocol as the EAP<->L2 binding.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Apr 2007 16:11:36 -0400

>>>>> "Charles" == Charles Clancy <[email-masked]> writes:

    >>> to be an L2 identity.  It can be any identity that's
    >>> meaningful to the parties involved, and can serve as the basis
    >>> for making authorization decisions.
    >>  As long as it's cryptographically bound to the L2 channel and
    >> that channel provides suitable protection for the EAP method
    >> doing the EAP channel binding, THEN Sam's observation is
    >> correct: "EAP channel binding" uses what I termed "end-point
    >> channel binding" and "EAP cryptographic binding" uses what I
    >> termed "unique channel binding."

    Charles> I don't think I'm convinced that EAP channel bindings are
    Charles> doing this binding to the L2 channel.  The identity used
    Charles> in an EAP channel binding must be bound to the AAA
    Charles> security association between the authenticator and the
    Charles> peer in order for everything to work, so it would be more

I'm not sure I'd describe the association between the peer and authenticator as an AAA association.
I agree with the rest.

    Charles> 
    Charles> likely a NAS-ID than a MAC address.
Are you sure that the binding happens between the mac address and NAS
ID?  I don't understand how the peer ever confirms the NAS ID at layer
two unless it also happens to be a MAC address.

I do agree with you though that EAP channel bindings include the
peer's lower layer identity and the identity of the authenticator that
the peer will later be able to verify.

    Charles> That's not to say there isn't an L2 binding happening --
    Charles> but I think it's being performed by the L2 secure
    Charles> association phase that uses the EAP key to derive L2
    Charles> keys.  Then during that handshake, a MAC address may be
    Charles> involved, binding in an L2 identity.

ANd if things are secure some L2 identity of the authenticator.

    Charles> I guess I see EAP channel bindings as an EAP<->AAA
    Charles> binding, and the L2 secure association protocol as the
    Charles> EAP<->L2 binding.

The L2 secure association protocol cannot be an eap->anything binding:
it does not typically use EAP level identifiers.

    Charles> -- t. charles clancy, ph.d.  <> [email-masked] <>
    Charles> www.cs.umd.edu/~clancy

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Apr 2007 16:13:46 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Also, I think my draft's definition of "end-point channel
    Nicolas> bidning" needs to be tightened just a bit: not only must
    Nicolas> the end-point IDs be cryptographically bound into the
    Nicolas> channel, it must also be the case that the IDs
    Nicolas> meaningfully identify the channel end-points -- that is,
    Nicolas> that one nodes cannot assert the same ID as another
    Nicolas> without sharing credentials with it.  I think my text
    Nicolas> implies this but does not make it sufficiently explicit.

Be careful.  A DN given a trust anchor seems like a find end-point
identifier.  However two nodes can share the same DN without sharing
the same credential.  Under 3280 rules either the CA issued a
certificate it should not have issued or the two nodes are the same
subject.  That's strong enough for the channel binding to be useful
even though the nodes may not share a credential.

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 6 Apr 2007 13:37:17 -0700

Yup, specifically 3280 says that a issuer, as represented by its DN will
guarantee unique serial numbers within its scope and issue within its
scope non-ambiguous subject DNs (e.g. no dupes).

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 1:14 PM
To: Nicolas Williams
Cc: Bernard Aboba; [email-masked]; [email-masked]
Subject: [Emu] Re: Last call
comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings

---

From: Charles Clancy <[email-masked]>
Date: Sat, 07 Apr 2007 16:44:54 -0400

> I'm not sure I'd describe the association between the peer and authenticator as an AAA association.

Ah, I mistyped.  I meant AAA security association between the 
authenticator and EAP server.

> two unless it also happens to be a MAC address.

This is one of the fundamental issues with EAP channel bindings.  The 
NAS ID is bound to the AAA security association between the 
authenticator and the EAP server.  The MAC address is visible to the 
client.  Thus the peer and EAP server each know a different identity for 
the authenticator.  Whatever identity is used must be channel-bound to 
the AAA security association, otherwise the authenticator could lie to 
the EAP server about its identity.

I see two solutions:

1. The NAS ID is broadcast to the peer before EAP authentication (e.g. 
in an 802.11 beacon)

2. The EAP server maintains a static mapping between NAS IDs and MAC 
addresses, manually binding MAC addresses to AAA security associations

> the peer will later be able to verify.

Right -- but there needs to be some way for the EAP server to know the 
authenticator's lower-layer information in such a way that the 
authenticator can't lie about its lower-layer information to the EAP server.

> it does not typically use EAP level identifiers.

It uses EAP keys though.  If from a higher layer we know EAP keys could 
have only been delivered to a particular EAP/AAA identity, and those 
keys are exported to the lower layer, then I'd think you have a binding 
from the EAP identity to the EAP keys to the lower-layer keys to the 
lower-layer identity.

---

From: Jouni Malinen <[email-masked]>
Date: Sat, 7 Apr 2007 17:08:18 -0700

> 1. The NAS ID is broadcast to the peer before EAP authentication (e.g. 

This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the
identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as
the backend protocol) and this identifier is sent to the peer during
association (before EAP authentication). In addition, both the R0KH-ID
(NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in
into the key derivation after the EAP authentication.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 17:22:43 -0700

>into the key derivation after the EAP authentication.

I would also add that IEEE 802.11r binds the R1KH-ID and the AP BSSID/MAC 
address during the post-EAP handshake.  IEEE 802.11r also advertises the set 
of authenticators within which fast handoff is possible via the Mobility 
Domain IE.  Currently there is no equivalent AAA attribute to carry that, 
but once there is (it has been discussed in RADEXT WG), it will also be 
possible to verify this parameter within EAP Channel Bindings.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Apr 2007 14:06:20 -0500

Sam,

Your observation is brilliant.  Yes, I agree, "EAP channel binding" and
"EAP cryptographic binding" map to what my draft calls "end-point
channel binding" and "unique channel binding," respectively.  I had not
noticed this before.

Also, I think my draft's definition of "end-point channel bidning" needs
to be tightened just a bit: not only must the end-point IDs be
cryptographically bound into the channel, it must also be the case that
the IDs meaningfully identify the channel end-points -- that is, that
one nodes cannot assert the same ID as another without sharing
credentials with it.  I think my text implies this but does not make it
sufficiently explicit.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Apr 2007 14:06:20 -0500

Sam,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Apr 2007 13:48:54 -0500

> something like GSS channel bindings.

Note: my I-D does not describe GSS channel binding -- it describes
channel binding.  The reference to GSS channel binding is there as an
informative, historical note.

> It's binding L2 identities to EAP keys.  In fact, there's no reason it has
               ^^^^^^^^^^^^^

When the identities of the two end-points of a channel are: a)
cryptographically bound into that channel b) such that other channels
between different pairs of end-points could not have the same end-point
identities, THEN we can call that pair of channel end-points identities
"end-point channel bindings" -- as my I-D explains.

> such that all three are subsets of some common terminology... but that

No, I think we did just that, but I had not noticed that, in fact, the
two kinds of EAP binding map to the two kinds of channel binding
described in my draft.  Thanks Sam!

Nico
-- 

ntral.sun.com (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2)
	with ESMTP id l36Inq2m005351; Fri, 6 Apr 2007 12:49:52 -0600 (MDT)
Date: Fri, 6 Apr 2007 13:48:54 -0500
From: Nicolas Williams <[email-masked]>
To: Charles Clancy <[email-masked]>
Subject: Re: [Emu] Last call comments:
	draft-williams-on-channel-binding-01.txt: EAP channel bindings
Cc: [email-masked], Sam Hartman <[email-masked]>, [email-masked],
	[email-masked]

> something like GSS channel bindings.

Note: my I-D does not describe GSS channel binding -- it describes
channel binding.  The reference to GSS channel binding is there as an
informative, historical note.

> It's binding L2 identities to EAP keys.  In fact, there's no reason it has
               ^^^^^^^^^^^^^

When the identities of the two end-points of a channel are: a)
cryptographically bound into that channel b) such that other channels
between different pairs of end-points could not have the same end-point
identities, THEN we can call that pair of channel end-points identities
"end-point channel bindings" -- as my I-D explains.

> such that all three are subsets of some common terminology... but that

No, I think we did just that, but I had not noticed that, in fact, the
two kinds of EAP binding map to the two kinds of channel binding
described in my draft.  Thanks Sam!

Nico
--

---

From: [email-masked]
Date: Mon, 09 Apr 2007 18:38:36 -0400

>>  I'm not sure I'd describe the association between the peer and
    >> authenticator as an AAA association.  I agree with the rest.

    Charles> Ah, I mistyped.  I meant AAA security association between
    Charles> the authenticator and EAP server.

I'd define the EAP channel binding problem as follows.  There are two
sets of identities that the peer and authenticator use: one at the EAP
layer and one at a lower layer.  There is an additional identity that
the authenticator may use to authenticate to the AAA server.  The
channel binding problem is to make sure that the EAP server authorizes
the authenticator's use of the lower layer identity to the peer and
the peer's use of a given lower layer identity.

In performing this authorization the EAP server must authorize that
the authenticator is actually allowed to claim the lower layer
identity it wants to claim.  In doing that it will have to make an
authorization decision about whether the identity the authenticator
uses to authenticate to the AAA server is authorized to claim the
given lower layer identity.  However that identity--between the NAS
and the AAA server doesn't inherently appear anywhere else.  It sounds
like 802.11R does plan to expose that identity, but that's a design
decision for that lower layer.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 11 Apr 2007 23:03:29 -0700

Hi Sam,

Here is my take on this topic:

After having reviewed "draft-williams-on-channel-binding-01," I feel 
that putting EAP in scope of that document would require a rather 
involved revision of the document.  As Charles noted it might require 
further abstraction of the concept of channel binding as defined in 
draft-williams.

Now, I must say, I do see the similarities between the two notions of 
channel binding.  But the EAP/AAA model is unique and it is not easy to 
map it to the other, let's say simpler, security models.  The notion of 
compound binding or crypto binding also has some similarities to the 
notion of channel binding in draft-williams-on-channel-binding-01, but 
there are also some differences.

Overall though, since expanding draft-williams-on-channel-binding-01's 
scope to EAP means that the requirements, recommendations and 
suggestions of Section 2.1 may be applied to EAP channel binding, it 
would be a rather painful exercise to sort it all out.  For now, I am 
comfortable with the guidance in Section 7.15 of 3748.

thanks,
Lakshminath

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Apr 2007 06:04:36 -0700

I agree with Lakshminath on this.  

________________________________

From: Lakshminath Dondeti [mailto:[email-masked]]
Sent: Wed 4/11/2007 11:03 PM
To: Sam Hartman
Cc: [email-masked]; Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings

Hi Sam,

thanks,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 10 Apr 2007 22:11:32 -0700 (PDT)

On Mon, April 9, 2007 3:38 pm, [email-masked] wrote:
[snip]
> the peer's use of a given lower layer identity.

  I don't agree. The channel binding problem is to make sure the EAP
server and the peer agree to whom the key is being disclosed. They
have to agree on a common identity that is relevant at the EAP layer.

  You're right that the authenticator can have 3 identities-- a lower
layer identity like a MAC address, a NAS ID, and some identity that was
used to create a security association with the AS. The AS doesn't know
and doesn't care what the lower layer identity of the authenticator is.
Likewise the peer doesn't know and doesn't care what identity the
authenticator used to establish a security association with the AS (most
likely an IP address). But they are both speaking EAP and there is an
identity of the authenticator that they can both agree on and that is
relevant at that layer-- the NAS ID.

  EAP channel binding is a protected exchange, between the peer and AS,
of this identity (the NAS ID not a lower layer identity) and the identity
passed in the protected exchange is verified with the identity established
in some out-of-band fashion (for instance, at provisioning time of the
NAS). If they are equal then all systems are go, if they are not then
houston we have a problem.

  Dan.

---

From: Charles Clancy <[email-masked]>
Date: Thu, 12 Apr 2007 22:29:33 -0400

On Mon, April 9, 2007 6:38 pm, [email-masked] wrote:
> identity it wants to claim.  

I think this is implicit -- you gave the MSK to an authenticator, 
therefore that authenticator's lower layer (regardless of its identity) 
is authorized to use that key.  Of course, this assumes an authenticator 
has a single lower layers.  I'm not sure the case of multiple lower 
layers been addressed.  EAP could simply forbid it (i.e. one lower layer 
per authenticator), or say that giving a key to an authenticator 
authorizes it for all lower layers.

 > In doing that it will have to make an
> given lower layer identity.  

Currently there's no AAA mechanism for an authenticator to "claim" a 
lower-layer identity to an EAP server.  Lower layer identities would 
have to be statically provided to the EAP server if the EAP server is 
going to use them for channel bindings.

> However that identity--between the NAS

I guess the point of all my commentary is that the SAP needs to be 
involved in your discussion of EAP channel bindings.  Most 
cryptographically binds an L2 identities to an EAP key, and some new 
ones (11r) even bind AAA identities to an EAP key.  If EAP channel 
bindings could include AAA identities, then the peer would actually have 
enough information to start doing identity comparisons and catch lying 
NASes.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 12 Apr 2007 22:30:27 -0700

Hi Nico,

Please see inline:

Nicolas Williams wrote:
> On Wed, Apr 11, 2007 at 11:03:29PM -0700, Lakshminath Dondeti wrote:
> My impression was that Sam's suggested text was introductory and
> informative, and not at all intended to cause this doc to normatively
> constrain EAP.

The draft is standards track and there is a lot of 2119 language in there.

> 
> I think that having a single abstraction that can describe what went by
> multiple names in different areas can be very useful because it
> facilitates cross-area communication.  And missing an opportunity to
> point out how two things are more similar than they look would help
> perpetuate a perception that those two things are more different than
> they actually are.

I can see your point of view.  The other thing to worry about is that 
the more we try to cover under a single abstraction, the more watered 
down it might become to satisfy all viewpoints of applicability to all 
of the domains.  In fact, I find the requirements and recommendations in 
the draft troublesome.

As I thought about it, perhaps here is something that might make sense:

Define channel binding so that we can cover all uses of that term. 
Define properties and specify how one can achieve those properties.  Not 
sure this next one needs to be done in the current draft, define which 
properties apply to which protocol.  Alternatively, different protocol 
drafts may specify which of the properties are required or recommended 
in each case.

Does that make sense?

I know I am suggesting this, but until something like that is written, I 
am not sure we can get there (haven't put enough thought into whether a 
common consensus abstraction is possible here or not).  As I noted in my 
review of your draft, EAP model is different from some of the other 
security models in the IETF.

best regards,
Lakshminath

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Apr 2007 19:05:03 -0400

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:

    >>  I think that having a single abstraction that can describe
    >> what went by multiple names in different areas can be very
    >> useful because it facilitates cross-area communication.  And
    >> missing an opportunity to point out how two things are more
    >> similar than they look would help perpetuate a perception that
    >> those two things are more different than they actually are.

    Lakshminath> I can see your point of view.  The other thing to
    Lakshminath> worry about is that the more we try to cover under a
    Lakshminath> single abstraction, the more watered down it might
    Lakshminath> become to satisfy all viewpoints of applicability to
    Lakshminath> all of the domains.  In fact, I find the requirements
    Lakshminath> and recommendations in the draft troublesome.

    Lakshminath> As I thought about it, perhaps here is something that
    Lakshminath> might make sense:

    Lakshminath> Define channel binding so that we can cover all uses
    Lakshminath> of that term. Define properties and specify how one
    Lakshminath> can achieve those properties.  Not sure this next one
    Lakshminath> needs to be done in the current draft, define which
    Lakshminath> properties apply to which protocol.  Alternatively,
    Lakshminath> different protocol drafts may specify which of the
    Lakshminath> properties are required or recommended in each case.

    Lakshminath> Does that make sense?

That makes sense; I think that is exactly what we're doing.  I
continue to believe, having read all the messages here that my
original text is very close to correct in describing the EAP channel
bindings problems.  I'd love to talk to someone off-line to discuss
this, because there is some obvious confusion somewhere.  The more I
read what you, Bernard and Charles say, the more I'm convinced that I
agree with your description of EAP and that my text is correct.  The
more I talk, the more you're convinced that my text is wrong.
We're talking past each other somehow.

---

From: Charles Clancy <[email-masked]>
Date: Fri, 13 Apr 2007 19:52:17 -0400

Sam Hartman wrote:
 > The more I

I think your text was correct, but incomplete.  I think the SAP needs to 
be included, as it does channel bindings under Nico's broader 
definition.  The SAP does an EAP lower-layer to EAP layer binding -- it 
just doesn't provide the authorization you're looking for, hence why we 
need EAP channel bindings to prevent the lying NAS problem.

Sam's suggested text:

   The first, called channel
   binding, is used to bind the lower-layer channel created between the
   peer and the authenticator to the authentication performed using EAP.
   Specific detials of this facility have not been specified, but it is
   likely that this channel would use endpoint channel bindings carried
   in the EAP method exchange.

My suggestion for Sam's suggested text:

   The first, called channel
   binding, is used to bind the lower-layer channel created between the
   peer and the authenticator to the authentication performed using EAP.
   The Secure Association Protocol (SAP) defined by the EAP lower layer
   often binds lower-layer identities and sometimes even AAA identities
   into the key derivation, serving to bind EAP keys to the EAP lower
   layer.  However, as this binding is done by the lower layer, and not
   EAP, there is no explicit authorization by the EAP server for the
   lower layer to use the EAP keys.  Consequently, EAP channel bindings
   are defined in RFC 3748 to perform the binding at the EAP layer.
   Specific details of this facility have not been specified, but it is
   likely that this channel would use endpoint channel bindings carried
   in the EAP method exchange.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Apr 2007 16:21:58 -0500

On Mon, Apr 16, 2007 at 01:10:32AM -0500, Nicolas Williams wrote:
>  - New text about EAP channel binding

Actually, some of that text is incorrect -- I misunderstood the lying
NAS issue: it's not about MITM attacks but about making sure that the
client knows the correct name for the NAS so that it can make
authorization decisions based on it (e.g., applying a specific firewall
policy).

I'll fix the text and re-send.

Nico
--