Subject: [Emu] Channel Binding attributes

From: Joe Salowey <[email-masked]>
Date: Tue, 9 Aug 2011 22:31:34 -0700

At the meeting in Quebec we discussed removing attributes specific to particular media types or lower layers and including recommendations for a small number of generally useful attributes in the draft.  

The attribute that seems to be most useful would be one that indicates what protocol is carrying the EAP conversation between the EAP peer and authenticator.  Its not clear to me if there is an existing attribute that meets this need.  It seems that there are the following contenders:

NAS-Port-Type (RFC-2865)  - this attribute contains  the physical type port that is carrying the EAP conversation.  It has values for things like ethernet, 802.11,802.16, various flavors of PPPoE, etc.  Since it represents a physical port It does not have values for higher layer protocols such as IKEv2 or PANA.

Tunnel-Type (RFC-2868) - this attribute is used for setting up compulsory tunnels and contains a value for IPSEC ESP tunnel.  It's not clear to me if this would be suitable to indicate IKEv2.

EAP-Lower-Layer (http://tools.ietf.org/html/draft-aboba-radext-wlan-13) -  this is an draft attribute designed to indicate the EAP lower layer.   It contains several values to cover many of the EAP lower layers.  IT does cover IKEv2 and PANA.  Its likely that list values need to be augmented and cleaned up.  

NAS-Port-Type and Tunnel-Type seem to have limitations. My initial suggestion is the following:

- Define the EAP-Lower-Layer attribute in the document

- If the lower layer protocol does not define a specific attribute indicate the lower layer type then EAP-Lower-Layer attributes MUST be included.  Would it also be useful to include NAS-Port-Type?

- If the lower layer protocol does define a specific attribute then that attribute MUST be included and EAP-Lower-Layer MAY be included.  Would it be easier just to always use EAP-Lower-Layer?  

Thoughts?

Joe

---

From: Glen Zorn <[email-masked]>
Date: Wed, 10 Aug 2011 15:41:33 +0700

> - Define the EAP-Lower-Layer attribute in the document

Since the draft you cite seems to be fairly evolved (at least it's been
around a long time ;-), is there any reason not to simply publish it?

...

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Aug 2011 10:56:02 -0400

>>>>> "Joe" == Joe Salowey <[email-masked]> writes:

    Joe> (http://tools.ietf.org/html/draft-aboba-radext-wlan-13) - this
    Joe> is an draft attribute designed to indicate the EAP lower layer.
    Joe> It contains several values to cover many of the EAP lower
    Joe> layers.  IT does cover IKEv2 and PANA.  Its likely that list
    Joe> values need to be augmented and cleaned up.

    Joe> NAS-Port-Type and Tunnel-Type seem to have limitations. My
    Joe> initial suggestion is the following:

    Joe> - Define the EAP-Lower-Layer attribute in the document

Since there are are already approved normative references waiting on
eap-chbind, I'd prefer to define the attribute here.
However if Bernard's draft is ready to last call I'd be fine with that.

    Joe> - If the lower layer protocol does not define a specific
    Joe> attribute indicate the lower layer type then EAP-Lower-Layer
    Joe> attributes MUST be included.  Would it also be useful to
    Joe> include NAS-Port-Type?

I think nas-port-type should be a SHOULD here.
For things like abfab it makes no sense at all.
for things like PANA it may or may not make sense.

    Joe> - If the lower layer protocol does define a specific attribute
    Joe> then that attribute MUST be included and EAP-Lower-Layer MAY be
    Joe> included.  Would it be easier just to always use
    Joe> EAP-Lower-Layer?

I'd have a hard time justifying such a MUST for something like abfab on
the grounds RFC 2119 gives for when a MUST is appropriate.  I think
SHOULD rather than MAY include eap-lower-layer better captures what's
going on.

    Joe> Thoughts?

I'd be happy to implement this within the next couple of weeks.
Obviously if Bernard's draft is ready and we can just send it on and use
eap-lower-layer that would be less work for me.

---

From: Joe Salowey <[email-masked]>
Date: Wed, 10 Aug 2011 21:25:13 -0700

> around a long time ;-), is there any reason not to simply publish it?
[Joe] I don't think its ready for publication yet.  I think its only partially current with 802.1X-2010. 

> <gwz.vcf>