Subject: 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?

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

---

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

On Fri, Apr 06, 2007 at 02:41:09PM -0400, Charles Clancy wrote:
> Sam,
> 
> In skimming through Nico's draft, it looks like EAP's crypto bindings look
> 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.

> 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
               ^^^^^^^^^^^^^

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.

> 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."

> 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.

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: 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: 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: Sam Hartman <[email-masked]>
Date: Fri, 06 Apr 2007 16:11:36 -0400

---

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

umd.edu>
	(Charles Clancy's message of "Fri, 6 Apr 2007 15:13:04 -0400 (EDT)")
Cc: [email-masked], [email-masked],
	Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: [Emu] Last call comments:
	draft-williams-on-channel-binding-01.txt: EAP channel bindings

>>>>> "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: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 17:22:43 -0700

>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.

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: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 17:22:43 -0700

---

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

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

)
	with Microsoft SMTP Server id 8.0.685.25; Fri, 6 Apr 2007 13:37:36 -0700
Content-Class: urn:content-classes:message
Date: Fri, 6 Apr 2007 13:37:17 -0700
From: Ryan Hurst <[email-masked]>
To: Sam Hartman <[email-masked]>, Nicolas Williams
	<[email-masked]>
Cc: [email-masked], Bernard Aboba <[email-masked]>, [email-masked]
Subject: RE: [Emu] Re: Last call
	comments:draft-williams-on-channel-binding-01.txt: EAP
	channel bindings

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

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 15:14:30 -0700

>peer and the authenticator to the authentication performed using EAP.

I think you need to be careful about the precise meaning of "bind" and 
"lower layer channel" here.

Properties of the lower layer channel such as ciphersuite negotiation are 
determined during the Secure Association Exchange.  During the SAP other 
parameters advertised or negotiated between the peer and authenticator can 
be cryptographically bound to the transient session keys used between peer 
and authenticator.  For example, within IEEE 802.11i, the peer and 
authenticator MAC address, ciphersuite
and capabilities are securely confirmed during the 4-way handshake.

In contrast, Channel Bindings as defined in RFC 3748 occur during the EAP 
exchange.  Its purpose is to confirm the consistency of channel properties 
advertised by the authenticator to the peer and EAP server.  However, 
negotiation of the lower layer channel properties occurs during the SAP.

>Specific details of this facility have not been specified, but it is
>in the EAP method exchange.

Secure Association Protocols are specified in considerable detail within 
IEEE 802.11i, IEEE 802.16e and IKEv2.  Also, both RFC 3748 and the EAP Key 
Management Framework discuss Channel Bindings. So saying it is "unspecified" 
doesn't seem accurate.

>The endpoint channel bindings would be defined for the specific lower 
>layer.

EAP Channel Bindings can be supported by an EAP method today without any 
modification to lower layer specifications, so I don't think this is 
correct.

>EAP also has a facility called cryptographic binding, which is another 
>instance of channel binding.

Cryptographic binding as defined in RFC 3748 is used to demonstrate that the 
endpoints of the EAP exchange participated in all portions of that exchange. 
  This does not relate to lower layer channel properties, per se.

>method.

This is correct.

>Cryptographic binding will likely use unique channel bindings.

Cryptographic binding doesn't ensure that the authenticator provides the 
same information to both the peer and server, so that it doesn't address the 
Channel Binding problem.

>conflating two architectures in a bad way?

In general, the changes are potentially confusing, but I do think that it 
would be worthwhile to continue to work on improving the text.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 15:14:30 -0700

This is correct.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 15:14:30 -0700

This is correct.

---

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

> 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.

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

---

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

On Sat, Apr 07, 2007 at 04:44:54PM -0400, Charles Clancy wrote:

> 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)

-- 
Jouni Malinen                                            PGP id EFC895FA

---

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.

I see two solutions:

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

Sam,

---

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

Sam,

---

From: [email-masked]
Date: Mon, 09 Apr 2007 18:30:23 -0400

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    >> 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.

    Bernard> I think you need to be careful about the precise meaning
    Bernard> of "bind" and "lower layer channel" here.

I'm using them consistently with the rest of the document.

    Bernard> Properties of the lower layer channel such as ciphersuite
    Bernard> negotiation are determined during the Secure Association
    Bernard> Exchange.  During the SAP other parameters advertised or
    Bernard> negotiated between the peer and authenticator can be
    Bernard> cryptographically bound to the transient session keys
    Bernard> used between peer and authenticator.  For example, within
    Bernard> IEEE 802.11i, the peer and authenticator MAC address,
    Bernard> ciphersuite and capabilities are securely confirmed
    Bernard> during the 4-way handshake.

This is a true statement.

    Bernard> In contrast, Channel Bindings as defined in RFC 3748
    Bernard> occur during the EAP exchange.  Its purpose is to confirm
    Bernard> the consistency of channel properties advertised by the
    Bernard> authenticator to the peer and EAP server.  However,
    Bernard> negotiation of the lower layer channel properties occurs
    Bernard> during the SAP.

Understood and I believe that to be consistent with my text.

    >> 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.

    Bernard> Secure Association Protocols are specified in
    Bernard> considerable detail within IEEE 802.11i, IEEE 802.16e and
    Bernard> IKEv2.  Also, both RFC 3748 and the EAP Key Management
    Bernard> Framework discuss Channel Bindings. So saying it is
    Bernard> "unspecified" doesn't seem accurate.

No one has defined the format of channel bindings and with the
possible exception of 802.11r I don't know of any lower layer that has
clearly defined what identity should be bound for that layer.

    >> The endpoint channel bindings would be defined for the specific
    >> lower layer.

    Bernard> EAP Channel Bindings can be supported by an EAP method
    Bernard> today without any modification to lower layer
    Bernard> specifications, so I don't think this is correct.

How do I know what the lower layer identity is unless the lower layer
spec tells me

    >> EAP also has a facility called cryptographic binding, which is
    >> another instance of channel binding.

    Bernard> Cryptographic binding as defined in RFC 3748 is used to
    Bernard> demonstrate that the endpoints of the EAP exchange
    Bernard> participated in all portions of that exchange. This does
    Bernard> not relate to lower layer channel properties, per se.

I did not claim that cryptographic binding was related to lower layer
channel properties in EAP's sense of lower layer.

    >> Cryptographic binding refers to binding the channel created by
    >> a tunneling EAP method to an inner authentication performed
    >> within that method.

    Bernard> This is correct.

    >> Cryptographic binding will likely use unique channel bindings.

    Bernard> Cryptographic binding doesn't ensure that the
    Bernard> authenticator provides the same information to both the
    Bernard> peer and server, so that it doesn't address the Channel
    Bernard> Binding problem.

This is a true statement; as best I can tell it is unrelated to
anything I've said.

---

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: Nicolas Williams <[email-masked]>
Date: Mon, 9 Apr 2007 18:07:40 -0500

So then the stuff to bind to exists but no spec says "the EAP channel
bindings for this kind of L2 association is XYZ" and we all have a good
idea of what that text should read like, right?

On Mon, Apr 09, 2007 at 03:52:31PM -0700, Bernard Aboba wrote:
> [BA] As outlined in RFC 3748 and the EAP Key Management Framework, channel binding matching is designed to be a mechanical process, which implies that they are communicated in the form of AAA attributes. 
>  
> For example, the following AAA attributes can be sent from the NAS to the AAA server for IEEE 802: 
>  
> Called-Station-Id:  Authenticator Port MAC address or AP BSSID (potentially with the SSID)
> Calling-Station-Id:  Supplcant MAC address
> NAS-Identifier:  Authenticator identifier (IEEE 802.11r R1KH-ID)
> 
> Lower layer specifications already define the source MAC addresses (e.g. IEEE 802), and in some cases, authenticator identities (IEEE 802.11r).   So no additional lower layer standards are required.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Apr 2007 15:52:31 -0700

---

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: 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: Nicolas Williams <[email-masked]>
Date: Thu, 12 Apr 2007 10:10:21 -0500

> comfortable with the guidance in Section 7.15 of 3748.

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.

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.

Nico
--

---

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

Hi Nico,

Please see inline:

> informative, and not at all intended to cause this doc to normatively

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

> perpetuate a perception that those two things are more different than

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

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: Sun, 15 Apr 2007 10:58:52 -0500

On Fri, Apr 13, 2007 at 07:52:17PM -0400, Charles Clancy wrote:
>   [...]
>   [...]

The problem you call the "lying NAS problem" sounds like nothing other
than an MITM attack on the peer: the MITM pretends to be the NAS to the
peer and the peer to the real NAS, passing through any other traffic
between the peer and the server, and when all is done the lying NAS has
had access to all the plaintext that the peer might have sent to or
received from the network it connected to.  This matches the generic
channel binding problem statement quite nicely.

The solution that's been described consists of: a) authentication of the
NAS to the peer at the lower layer, b) mutual authentication of the peer
and the EAP server, c) authentication of the NAS to the EAP server, d)
an authorization step where the peer sends the NAS' lower-layer ID to
the EAP server and where the EAP server decides whether the NAS that
authenticated to it is the same as that which authenticated to the
client and e) also decides whether the NAS is allowed to serve the peer.

This can be described as a use "end-point channel bindings" where the
application _knows_ that that's the type of channel binding provided by
the channel and where the end-point IDs are meaningful to the
application (the EAP server in this case).

More importantly: step (a) is difficult to arrange.  How does one
authenticate BSSIDs, MAC addresses, etc.?  It would be a lot simpler to
have an unauthenticated channel between the peer and the NAS and bind
that channel into the peer<->EAP server authentication.  Thus "unique
channel bindings" too could be used in EAP channel binding.

Unless I misunderstood something and the above text is incorrect then I
think Sam's text is sufficient.  A more detailed description of the EAP
channel binding problem and proposed solutions, and an analysis of how
that resembles the generic channel binding problem and solutions might
help.  I would place such text in a sub-section of the introduction.

Finally, to address Lakshminath's comments, I would insist that all
EAP-related text in this document is and should be informative, and it
should be clearly labelled as such.  If the EAP community finds this
document useful then it can choose to update RFC3748 to include this
document as a normative reference.

Nico
--

---

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

Sam Hartman wrote:
> used3)
	id 1Hbz0K-0000id-Kl; Thu, 12 Apr 2007 09:06:26 -0400
Content-Class: urn:content-classes:message
Date: Thu, 12 Apr 2007 06:04:36 -0700
From: Bernard Aboba <[email-masked]>
To: Lakshminath Dondeti <[email-masked]>, Sam Hartman
	<[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: [Emu] Last call comments:
	draft-williams-on-channel-binding-01.txt: EAP channel bindings
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: 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
--