Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
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: > 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 > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
> "Yoshihiro" == Yoshihiro Ohba 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
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:-) ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Sam, On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote: > 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:-) 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Sam, Please see my comments below. (2011/10/18 23:02), Sam Hartman wrote: >> "Yoshihiro" == Yoshihiro Ohba 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. 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. " > > 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. > 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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
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 (2011/10/20 4:59), Sam Hartman wrote: > 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:-) > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
> "Yoshihiro" == Yoshihiro Ohba 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Sam, (2011/10/20 21:48), Sam Hartman wrote: >> "Yoshihiro" == Yoshihiro Ohba 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. 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. > > 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. > OK. Yoshihiro Ohba ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Hi Sam, Yoshihiro> (2011/10/20 21:48), Sam Hartman wrote: >>> "Yoshihiro" == Yoshihiro Ohba >>> 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> 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
> "Yoshihiro" == Yoshihiro Ohba 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? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
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. 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
> "Dan" == Dan Harkins 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
* 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? * 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? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
> "Jim" == Jim Schaad 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
On Oct 19, 2011, at 3:52 PM, Dan Harkins wrote: > > Hi Sam, > > On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote: >> 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:-) > > 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. > [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. > 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. > [Joe] Agree > 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. > [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. > 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. > [Joe] I'm leaning to towards 802.11 and 802.1-pre-auth. > regards, > > Dan. > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Joe, On Sun, October 23, 2011 9:20 pm, Joe Salowey wrote: > > On Oct 19, 2011, at 3:52 PM, Dan Harkins wrote: > >> >> Hi Sam, >> >> On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote: >>> 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:-) >> >> 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. >> > > [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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
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? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
On Oct 19, 2011, at 5:05 PM, Yoshihiro Ohba wrote: > 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. > [Joe] How does 802.16m differ from 802.16e? > 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. > [Joe] I'd rather not include draft specifications in this document. > Regards, > Yoshihiro Ohba > > > (2011/10/20 4:59), Sam Hartman wrote: >> 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:-) >> > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
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 On Oct 25, 2011, at 3:49 AM, Sam Hartman wrote: > 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? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi Joe, (2011/10/29 0:19), Joe Salowey wrote: >> >> 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. >> > > > [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. > >> 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. >> > > [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 >> Regards, >> Yoshihiro Ohba >> >> >> (2011/10/20 4:59), Sam Hartman wrote: >>> 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:-) >>> >> >> ___ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
