Subject: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09

From: Joe Salowey <[email-masked]>
Date: Thu, 13 Oct 2011 14:15:37 -0700

THe working group last call for draft-ietf-emu-chbind-09 ends October 21, 2011.   So far we have received few comments on the list.   Please review  the document and post your comments to the list.  Comments indicating that you have read the document and not found any issues are also useful.  

Thanks,

Joe

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 Oct 2011 19:03:58 +0900

I have read emu-chbind-09.  I have no major issue on the document.
Especially I like the detailed background and general information
about channel binding in Sections 3 and 4, great work.

I have several comments.  I hope they are minor.

[1] As far as I understand, the method-based channel binding is not
applicable to ERP.  For completeness of the specification it may be
good to add some text to clarify this.

[2] While the document mentions transporting channel bindings within
the lower layer's secure association protocol for a future
alternative, it is also possible to extend EAP itself to transport
channel bindings for another future alternative as well.  I am just
wondering why the latter alternative is not mentioned in the document.

[3] Probably this was discussed in the WG, but I want to understand
the motivation for the namespace in Channel Binding Encoding because
it seems to be a hard requirement if the peer has to know what
namespace (or protocol) is being used between an EAP authenticator and
EAP server.  Also, in some case, the channel binding operation may be
performed with a standalone authenticator since, due to EAP's mode
independence property, the peer does not know whether the
authenticator it is talking to is a pass-through authenticator or a
stand-alone one.  What namespace should be used with a standalone
authenticator?

[4] The following comments are related to EAP Lower Layers Registry table:

- "PANA (no pre-authentication)" is mentioned but without a reference.
 I suggest adding a reference to RFC 5191 for this entry.

- Since there is also PANA pre-authentication (RFC 5873), I suggest
adding an entry "PANA (pre-authentication) [RFC 5873]".

- The entry for IEEE 802.11s does not make sense since
IEEE 802.11s does not support EAP authentication AFAIK.
Please check, and remove it if not needed.

- IEEE 802.16m supports EAP.  I suggest adding IEEE 802.16m.

- IEEE 802.21a (which is under Sponsor Ballot in IEEE SA and the work
is almost done) also supports EAP.  I suggest adding IEEE 802.21a.

(There may be some other EAP lower layers which I miss to mention.)

[5]  References [RFC4006] and [80211U-D4.01] are not used.

Best Regards,
Yoshihiro Ohba

(2011/10/14 6:15), Joe Salowey wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 10:02:54 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> [1] As far as I understand, the method-based channel
    Yoshihiro> binding is not applicable to ERP.  For completeness of
    Yoshihiro> the specification it may be good to add some text to
    Yoshihiro> clarify this.

I'd welcome suggestions.
I'm not really familiar with ERP.

    Yoshihiro> [3] Probably this was discussed in the WG, but I want to
    Yoshihiro> understand the motivation for the namespace in Channel
    Yoshihiro> Binding Encoding because it seems to be a hard
    Yoshihiro> requirement if the peer has to know what namespace (or
    Yoshihiro> protocol) is being used between an EAP authenticator and
    Yoshihiro> EAP server.  Also, in some case, the channel binding
    Yoshihiro> operation may be performed with a standalone
    Yoshihiro> authenticator since, due to EAP's mode independence
    Yoshihiro> property, the peer does not know whether the
    Yoshihiro> authenticator it is talking to is a pass-through
    Yoshihiro> authenticator or a stand-alone one.  What namespace
    Yoshihiro> should be used with a standalone authenticator?

The namespace ID simply names where the attribute comes from.  If you
are describing some value that is available in a RADIUS ID, then you
should use the RADIUS namespace. The EAP server (which as you point out
may be the authenticator) is responsible for matching up that
information in whatever form it has it.

For attributes available both in the diameter and RADIUS namespaces I'd
expect some lower layer document to describe which one to use regardless
of whether an AAA protocol is in use or which one is in use.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 15:59:42 -0400

Hi. I've added PANA (pre-authentication).

I wonder about the whole lower layer table.
Why is it important to distinguish PANA with pre-auth from pana without
pre-auth?

Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with
pre-auth?

I'd appreciate it if someone who cared about network access told me what
to do here:-)

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 19 Oct 2011 15:52:49 -0700 (PDT)

Hi Sam,

> I'd appreciate it if someone who cared about network access told me what

  You can collapse wpa, wpa2 and wpa2 with preauth. wpa and wpa2 are both
actually trademarked terms of the Wi-Fi Alliance so they should probably
not be in an IANA registry anyway. Regardless, though, they all do the
same thing by conveying the same type of information in the same way.

  802.11s specifies a password-based authentication scheme that does not
use EAP so there doesn't seem to be a reason to define an "EAP lower
layer" for 802.11s.

  802.11r does things a little differently-- a key hierarchy is built up
and keys are distributed hither and yon-- so it might be good to channel
bind that stuff but 802.11r has been rolled into the 802.11 standard
(there is no stand-alone reference for 802.11r, by the way) and can be
dealt with as just 802.11. All the "information elements" that specify
that 11r-specific stuff is being communicated are defined by 802.11's
Assigned Number Authority and their communication is done in the same
fashion as plain-jane 802.11 (aka wpa and wpa2). If "information
elements" for 802.11r are included in the 802.11 channel binding data
then it means the session is going to be used for 802.11r-type stuff.

  Values 4-8 in the table in section 11.1 can all be combined into a
single value named "802.11" with a reference to IEEE 802.11-2007.

  regards,

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Oct 2011 08:32:41 +0900

Hi Sam,

Please see my comments below.

(2011/10/18 23:02), Sam Hartman wrote:
>>>>>> "Yoshihiro" == Yoshihiro Ohba<[email-masked]>  writes:
> 

OK.  My suggestion is to modify the following text in Section 4.2:

"
For many deployments, changing all the NASes is expensive and adding
channel binding support to enough EAP methods to meet the goals of
the deployment will be cheaper.  However for deployment of new
equipment, or especially deployment of a new lower layer technology,
changing the NASes may be cheaper than changing EAP methods.
Especially if such a deployment needed to support a large number of
EAP methods, sending channel bindings in the secure association
protocol might make sense.
"

to:

"
For many deployments, changing all the NASes is expensive and adding
channel binding support to enough EAP methods to meet the goals of
the deployment will be cheaper.  However for deployment of new
equipment, or especially deployment of a new lower layer technology,
changing the NASes may be cheaper than changing EAP methods.
Especially if such a deployment needed to support a large number of
EAP methods, sending channel bindings in the secure association
protocol might make sense.  Sending channel bindings in the secure
association protocol can work even with ERP [RFC5296] in which
previously established EAP key material is used for the secure
association protocol without carrying out any EAP method during
re-authentication.
"

> of whether an AAA protocol is in use or which one is in use.

So it seems there is a requirement for lower-layer protocols or
profiles to describe about the channel binding namespace.  Shouldn't
such a requirement be explicitly mentioned in this document?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Oct 2011 09:05:39 +0900

Hi Sam,

Since authorization and accounting with the use of the
pre-authentication may be different from those with the use of normal
authentication, it would be good to differentiate pre-auth and without
pre-auth for network access authentication protocols that support
pre-authentication, PANA and 802.11 are such protocols as far as I know.

BTW, I also commented about adding IEEE 802.16m and IEEE 802.21a for
EAP lower-layers.  Here is the references for them:

IEEE 802.16m: "Standard for Local and Metropolitan Area Networks -
Part 16: Air Interface for Broadband Wireless Access Systems -
Advanced Air Interface", IEEE 802.16m-2011, 2011.

IEEE 802.21a: "Draft Standard for Local and metropolitan area
networks-Part 21: Media Independent Handover Services Amendment 2:
Security Extensions to Media Independent Handover Services and
Protocol", IEEE P802.21a/D04, 2011.

Regards,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 08:48:17 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Hi Sam, Since authorization and accounting with the use
    Yoshihiro> of the pre-authentication may be different from those
    Yoshihiro> with the use of normal authentication, it would be good
    Yoshihiro> to differentiate pre-auth and without pre-auth for
    Yoshihiro> network access authentication protocols that support
    Yoshihiro> pre-authentication, PANA and 802.11 are such protocols as
    Yoshihiro> far as I know.
OK, but Dan is arguing to remove them.

    Yoshihiro> BTW, I also commented about adding IEEE 802.16m and IEEE
    Yoshihiro> 802.21a for EAP lower-layers.  Here is the references for
    Yoshihiro> them:

Right. I didn't feel qualified to evaluate these.

Ultimately the chairs are going to have to decide what the table entries
are; I think that's beyond what I can do as an editor.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Oct 2011 22:11:31 +0900

Hi Sam,

> OK, but Dan is arguing to remove them.

I see.  As long as all lower-layers are treated in a consistent
manner, I am ok.  Maybe it is cleaner to define pre-auth information
as separate channel binding data.

> are; I think that's beyond what I can do as an editor.

OK.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 09:35:14 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Hi Sam,
    >> OK, but Dan is arguing to remove them.

    Yoshihiro> I see.  As long as all lower-layers are treated in a
    Yoshihiro> consistent manner, I am ok.  Maybe it is cleaner to
    Yoshihiro> define pre-auth information as separate channel binding
    Yoshihiro> data.

You might not want to do it that way.  It seems that learning the
eap-lower-layer from the NAS may influence your accounting handling
(especially for pre-auth) even if the client does not specify channel
binding.
That's something for the WG to consider and possibly something where we
need to circle back with radext.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 09:58:35 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Hi Sam, Please see my comments below.
    Yoshihiro> sense.  Sending channel bindings in the secure
    Yoshihiro> association protocol can work even with ERP [RFC5296] in
    Yoshihiro> which previously established EAP key material is used for
    Yoshihiro> the secure association protocol without carrying out any
    Yoshihiro> EAP method during re-authentication.  "

I like this text.
Objections to including it?

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 21 Oct 2011 12:55:19 -0700 (PDT)

> are; I think that's beyond what I can do as an editor.

  Why the chairs? I know for a fact that there is at least one person
that is active in EMU that also regularly attends 802.11 meetings (and
neither of the chairs are that person). Maybe we could listen that
person's opinion, at least on the 802.11 entries in the table.

  regards,

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Oct 2011 16:21:48 -0400

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:

    Dan> On Thu, October 20, 2011 5:48 am, Sam Hartman wrote:
    >> Ultimately the chairs are going to have to decide what the table
    >> entries are; I think that's beyond what I can do as an editor.

    Dan>   Why the chairs? 

Sorry.  what I meant here is that the chairs should tell me what to put
in the doc.  Why the chairs? It's their job to judge consensus.
Obviously, they should do that by reading the messages here and telling
me what the consensus is.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 23 Oct 2011 15:54:14 -0700

* In section 5.1 (para 3) - The following sentence does not make sense to
me.
   Message i2 is the information the AAA server receives from the last hop
in the AAA  proxy chain which is not necessarily the authenticator.

  Specifically I do not follow the last clause and what it is referring to.
Are you stating that the element in the AAA proxy chain may not be the
authenticator?  If so, I would omit the clause as it seems obvious to me
since you are talking about a chain.

* How does authenticated vs non-authenticated information get denoted in a
AAA message?  Given that some information can be authenticated at an early
point in the chain and some must be deferred until the last node this would
need to be denoted as authenticated vs non-authenticated information.  And
who validated it? <WARNING: may be stupid question by somebody who does not
know Radius/Diameter>

* s/thatwere/that were/

* section 5.2
s/have gone lost/have got lost/

* It  is not clear to me if the EAP server is to reflect the values from the
EAP client in the response message or if it should reflect values from the
NAS/AAA path.  

* Is it reasonable/possible that a policy would pull some attribute from the
AAA path that is not supplied by the EAP client and therefore need to
reflect it to the EAP client as part of the response?  Or is the set of
values to be reflected back to the EAP client restricted by the set of
values that it supplies?

* Section 7.2 - I am afraid I don't understand what this new RADIUS
attribute is supposed to be carrying.   I am doubly confused since the
introductory text in sections 7 and 7.1 talk about the values of i1, but my
understanding is that i1 is sent from the NAS to the peer, using some
unknown protocol and then from the peer to the EAP server using an EAP
method and thus the reason for the RADIUS attribute is confusing.  I would
understand it better if we are talking about sending i2 data for things
which are not already RADIUS attributes, but that does not seem to be how
the text is designed. 

This might just be talking about the EAP method to be used, but this is also
confusing since that is not something I would expect the NAS to be involved
in.

I might have gotten a better grasp on this, and I think that part of my
problem is that I think that this could be a mis-named attribute.  I now
understand that this is dealing with what is the method that is being used
to talk between the EAP peer and the NAS.   I think it is partly misleading
because this is only part of what is carrying the EAP data layer (along with
a AAA layer currently) and thus is not completely true.  It might be better
to call it the Peer-NAS transport layer or something similar.

* Section 8 - You are talking about this information as being validated by
the AAA server as oppose to being validated for consistency against the i1
data by the EAP server.  Is this what you are really intended?

---

From: Sam Hartman <[email-masked]>
Date: Sun, 23 Oct 2011 19:13:32 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:
Responding only to things I can respond to without reading the
document. I''m in the middle of another document.
I'll get to the rest sometime next week.

    Jim> * In section 5.1 (para 3) - The following sentence does not
    Jim> make sense to me.  Message i2 is the information the AAA server
    Jim> receives from the last hop in the AAA proxy chain which is not
    Jim> necessarily the authenticator.

    Jim>   Specifically I do not follow the last clause and what it is
    Jim> referring to.  Are you stating that the element in the AAA
    Jim> proxy chain may not be the authenticator?  

Yes.

    Jim> If so, I would omit
    Jim> the clause as it seems obvious to me since you are talking
    Jim> about a chain.

I'd appreciate comments from others.

    Jim> * How does authenticated vs non-authenticated information get
    Jim> denoted in a AAA message?  

It doesn't.  All information in an AAA message is integrity-protected
hop-by-hop.
How much you trust it is up to your local policy.

    Jim> * It is not clear to me if the EAP server is to reflect the
    Jim> values from the EAP client in the response message or if it
    Jim> should reflect values from the NAS/AAA path.

EAP client.

    Jim> * Is it reasonable/possible that a policy would pull some
    Jim> attribute from the AAA path that is not supplied by the EAP
    Jim> client and therefore need to reflect it to the EAP client as
    Jim> part of the response?  Or is the set of values to be reflected
    Jim> back to the EAP client restricted by the set of values that it
    Jim> supplies?

In this version of the spec it's restricted to thes included by the EAP
peer.
I think we may need to relax that in the future, but there is
significant complexity surrounding some issues there.
So, clients MUST ignore unknown attributes
but right now we don't send them.

    Jim> * Section 7.2 - I am afraid I don't understand what this new
    Jim> RADIUS attribute is supposed to be carrying.  

It describes the protocol between the peer and the NAS.
It's sent in the channel binding and potentially over the AAA path.

I think the name is correct: RFC 3748 (EAP) does call that a lower
layer.

    Jim> * Section 8 - You are talking about this information as being
    Jim> validated by the AAA server as oppose to being validated for
    Jim> consistency against the i1 data by the EAP server.  Is this
    Jim> what you are really intended?

I'm not intending to make that distinction in section 8.
No, we're talking about the same validation as in section 5.
I think this may be terminology rot; will check when I reconcile your
comments against the document.

---

From: Joe Salowey <[email-masked]>
Date: Sun, 23 Oct 2011 21:20:39 -0700

> same thing by conveying the same type of information in the same way.

[Joe] I agree with  removing WPA references.  This really about the l2 ciphering, not EAP.  It may be useful to have this in an attribute, but I don't think it belongs in this one.  

I'm lean towards including the pre-auth case since I believe it is different enough from the non-pre-auth case.  It seems that different parties may be involved in the conversation.  

> use EAP so there doesn't seem to be a reason to define an "EAP lower

[Joe] Agree

> then it means the session is going to be used for 802.11r-type stuff.

[Joe]  I think the authentication procedures are the same whether you use 11r  or not.    The differences are after authentication so I agree this does not belong in this attribute.  

> single value named "802.11" with a reference to IEEE 802.11-2007.

[Joe]  I'm leaning to towards 802.11 and 802.1-pre-auth.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 24 Oct 2011 11:57:50 -0700 (PDT)

Hi Joe,

On Sun, October 23, 2011 9:20 pm, Joe Salowey wrote:
> [Joe] I agree with  removing WPA references.  This really about the l2
> ciphering, not EAP.  It may be useful to have this in an attribute, but I
> don't think it belongs in this one.

  The AP will be putting that attribute (possibly a list of them if it
supports more than 1 cipher) in its beacons and probe responses and the
client will be putting that attribute (the one it selects from the list)
in its associate request. These attributes are already defined by 802.11's
number authority, ANA, so it might be a good idea to just use the
ANA-defined attribute in the 802.11 channel binding data.

> I'm lean towards including the pre-auth case since I believe it is
> different enough from the non-pre-auth case.  It seems that different
> parties may be involved in the conversation.

  Yes, you're right. Pre-auth and non-pre-auth use different ether-types
to transmit their EAPoL-encapsulated EAP messages so the "eap lower layer"
really is different. It's probably a good idea to retain this difference.

  regards,

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Oct 2011 06:49:25 -0400

So, chairs, can I go forward with Joe's suggestions, include the ERP
text and attempt to resolve Jim's comments if I can manage to find time
before the cutoff?

---

From: Joe Salowey <[email-masked]>
Date: Fri, 28 Oct 2011 08:19:29 -0700

> Advanced Air Interface", IEEE 802.16m-2011, 2011.

[Joe] How does 802.16m differ from 802.16e?

> Protocol", IEEE P802.21a/D04, 2011.

[Joe] I'd rather not include draft specifications in this document.

---

From: Joe Salowey <[email-masked]>
Date: Fri, 28 Oct 2011 09:50:26 -0700

There have not been any more comments on the list so please prepare a new draft if you have time before the cutoff.  I would also like to have a discussion of this draft and last call changes in the EMU meeting in Taiwan.  

One additional issue I found was in section 9 the NAS-Identifier text references Calling-Station-Id which is no longer referenced in the document, in addition I don't think the rest of the text is accurate.  Here is a suggested revision:

NAS-Identifier:  This is an identifier populated by the NAS to identify the NAS to the AAA server.  It SHOULD be validated for consistency with the local database in an enterprise deployment. 

Joe

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 31 Oct 2011 10:09:08 +0900

Hi Joe,

> [Joe] How does 802.16m differ from 802.16e?

As far as I understand, PHY and frame encodings are different.  I am
not sure if those differences are significant from EAP channel binding
perspective.

> [Joe] I'd rather not include draft specifications in this document.

Fair enough.  As soon as 802.21a specification is published,  I will
let you know.

Thanks,
Yoshihiro Ohba