Re: [Emu] Submitted 10
On 10/20/2011 3:09 AM, Sam Hartman wrote: > > > I believe I've addressed all of Alan's comments with the exception of > removing the RADIUS diagram from 5.3. Great, so what are we supposed to do now? WGLC was issued on draft-ietf-emu-chbind-09. The last call is not complete. Shall we just start over? This creation of a moving target wouldn't be so annoying if you were a newbie but you are anything but that... > Thanks Alan for the comments! > > --Sam > ___ > 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] Comments on the eap-tunnel-method-00 draft
Rereading the updated chbind draft, it has already defined the mechanism for two way communication and tunnel EAP draft just defined a TLV container to carry the Channel binding data defined in Section 5.3, so we should be ok. No change is needed on the tunnel EAP draft on this, other maybe called out Section 5.3. On 10/19/11 8:22 PM, "Sam Hartman" wrote: >> "Jim" == Jim Schaad writes: Section 4.2.10 - How can I know if the server does or does not >>> process > the channel binding TLV? This may be part of my policy >>> as a peer > depending on circumstances. >>> [HZ] Currently, the Channel-binding TLV is an optional TLV, >>> doesn't > require >>> acknowledgement, and is designed to be only one way, for client >>> to send some channel binding data to the server for verification >>> purpose. There is >> no >>> feedback provided. The indication of whether the server supports >>> channel- binding and/or validated the channel-binding could be >>> conveyed in other TLVs to be added, if the WG agrees to be >>> valuable. >>> > > Jim>Sam - do you see this as being an issue for abfab? > > > It's an issue for EMU actually. > See Section 5.3 of draft-ietf-emu-chbind. > Channel binding must be two-way and must follow the semantics of that > section. > > And yes, draft-ietf-abfab-gss-eap depends on those semantics. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on the eap-tunnel-method-00 draft
> "Jim" == Jim Schaad writes: >> > Section 4.2.10 - How can I know if the server does or does not >> process > the channel binding TLV? This may be part of my policy >> as a peer > depending on circumstances. >> > >> [HZ] Currently, the Channel-binding TLV is an optional TLV, >> doesn't require >> acknowledgement, and is designed to be only one way, for client >> to send some channel binding data to the server for verification >> purpose. There is > no >> feedback provided. The indication of whether the server supports >> channel- binding and/or validated the channel-binding could be >> conveyed in other TLVs to be added, if the WG agrees to be >> valuable. >> Jim>Sam - do you see this as being an issue for abfab? It's an issue for EMU actually. See Section 5.3 of draft-ietf-emu-chbind. Channel binding must be two-way and must follow the semantics of that section. And yes, draft-ietf-abfab-gss-eap depends on those semantics. ___ 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] Comments on the eap-tunnel-method-00 draft
> -Original Message- > From: Hao Zhou [mailto:hz...@cisco.com] > Sent: Wednesday, October 19, 2011 12:31 PM > To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org > Cc: emu@ietf.org > Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft > > Jim: > > Thanks for reviewing the draft in detail and comments provided. Please see > my response inline below. > > > On 10/17/11 6:08 PM, "Jim Schaad" wrote: > > > I have gathered these comments over time and therefore some of them > > are not fully fleshed out. If you have any questions I will try and > > reconstruct my ideas at the time. > > > > Jim > > > > > > > > Version Negotiation - terminate the conversation - w or w/o a fail? > > Edge case - what if peer only supports a higher version than the > > server supports? NAK? > > > [HZ] It depends. Server might want to proceed with other EAP type > negotiation by proposing a different EAP type, or terminate the conversation > with an EAP-Failure. I will clarify that in the next rev. Yes - but in this case I would expect a NAK from the client - possibly proposing other methods. Is this correct? > > > EAP Server Name Checking - On what basis does the client accept or not > > accept the EAP server name?You are suggesting that it is signed by a CA > > controlling the intended domain, but what does this mean? Are you > > suggesting that the CA should have a DNS subject alt name in it for > > the domain in question? > > > [HZ] It's up to client's policy, especially if the server cert is issued by a public > CA. Client needs not only verify that the server cert presented is a valid cert > signed by the trusted CA, but also the server name presented in the cert is > matching the domain it tried to authenticate with. A FQDN in the CN or SAN > would be a way to do it. > > > If no embedded EAP methods run, then no crypto check and thus no > > version # checking is done. > [HZ] That's true. Ok - this would be in violation of the last paragraph in section 3.1 which says that the version numbers MUST be done. > > >Also no checking done if only one inner EAP method is used as this > >only sends the Result TLV and not the Crypto-Binding TLV > > > [HZ] That's not true. Crypto-binding would still be exchanged with Result TLV. > Actually using of the Result TLV in lieu of IM-Result TLV is for legacy reason in > EAP-FAST, which could be removed in next rev since we are designing a new > EAP method. Please tell me where it says this is done. All I can see is that one CAN send intermediate-result, result and crypto-binding TLVs in the same message. (Unless of course only one is sent in which case the Intermediate-Reuslt TLV MUST NOT be sent). However these is nothing that says that the Crypto-binding TLV would be sent after the first and only EAP method - or indeed after a sequence of EAP methods. > > 'serially in a sequence' is redundant - section 3.3.1 > > > [HZ] Ok. The text is trying to distinguish from running multiple EAP methods > in parallel. > > > Not only does it not allow initiating multiple EAP methods in > > parallel, it requires that they not be running in parallel. This is a > > more strict condition > > > [HZ] For simplicity, otherwise implementation would need to trace when the > 1st method finishes and applies the key from the authentication to the > crypto-binding. Supporting them in complete sequence makes it simpler and > securer, as 2nd method might not be safe to run if the crypto-binging after > 1st method fails. Do you ever expect a version to allow multiple EAP sequences to be run at the same time? If not then just the statement that they MUST be executed serially is probably sufficient. > > > Para #3 - can the peer return an error and treat the failure of a > > specific EAP method as a total failure for the overall process - or at > > least recommend that it should be an overall failure? > > > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send up some > Fatal Error TLV and Result TLV to indicate the end. Ok - either I don't see the text or my comment is not sufficiently clear. Consider: Client is running EAP-BLAH and returns inside of the EAP-BLAH method a failure. If the client wants an overall failure rather than leaving it up to the server, does it send both the Result TLV failure and the EAP-Message w/ the failure - or just the result TLV failure or is this not reasonable for the client? > > > Confused messages in 3.3.1 and 3.3.3 about sending intermediate > > results and final results at the same time. Specifically 3.3.1 says > > MUST NOT for one inner EAP method, but text is not reflected in > > section 3.3.3 > > > [HZ] I think we can change to always send IM result after each inner EAP > method, if only one inner method, then Result TLV could be sent as well. See > explanation above. > > Conflict between 3.3.3 and security considerations (7.5) about sending > > a different value in the Result TLV and the clear
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, 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
[Emu] Submitted 10
I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Thanks Alan for the comments! --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-chbind-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename: draft-ietf-emu-chbind-10.txt Pages : 30 Date: 2011-10-19 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-10.txt ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on the eap-tunnel-method-00 draft
Dan: Thanks for the review comments. Sorry for not responding right away. The current plan is that we will publish a new revision today with the name change and etc, and Joe will start an issue list including the comments you made, as it will require some WG discussion, and then we will make another revision once we have consensus on them. On 10/19/11 3:55 PM, "Dan Harkins" wrote: > > Hi Hao, > > About 6 weeks ago I sent in some detailed comments, notably > the request for a new TLV to pass a PKCS#10 to the server to go > along with the existing TLV that sends a PKCS#7 to the peer, and > for a server unauthenticated provisioning mode, and never heard > from the editors of the tunnel method draft. > > Do you have any response to those comments? > > regards, > > Dan. > > On Wed, October 19, 2011 12:31 pm, Hao Zhou wrote: >> Jim: >> >> Thanks for reviewing the draft in detail and comments provided. Please see >> my response inline below. >> >> >> On 10/17/11 6:08 PM, "Jim Schaad" wrote: >> >>> I have gathered these comments over time and therefore some of them are >>> not >>> fully fleshed out. If you have any questions I will try and reconstruct >>> my >>> ideas at the time. >>> >>> Jim >>> >>> >>> >>> Version Negotiation - terminate the conversation - w or w/o a fail? >>> Edge case - what if peer only supports a higher version than the >>> server supports? NAK? >>> >> [HZ] It depends. Server might want to proceed with other EAP type >> negotiation by proposing a different EAP type, or terminate the >> conversation >> with an EAP-Failure. I will clarify that in the next rev. >> >>> EAP Server Name Checking - On what basis does the client accept or not >>> accept the EAP server name?You are suggesting that it is signed by a >>> CA >>> controlling the intended domain, but what does this mean? Are you >>> suggesting that the CA should have a DNS subject alt name in it for the >>> domain in question? >>> >> [HZ] It's up to client's policy, especially if the server cert is issued >> by >> a public CA. Client needs not only verify that the server cert presented >> is >> a valid cert signed by the trusted CA, but also the server name presented >> in >> the cert is matching the domain it tried to authenticate with. A FQDN in >> the >> CN or SAN would be a way to do it. >> >>> If no embedded EAP methods run, then no crypto check and thus no version >>> # >>> checking is done. >> [HZ] That's true. >> >>> Also no checking done if only one inner EAP method is >>> used as this only sends the Result TLV and not the Crypto-Binding TLV >>> >> [HZ] That's not true. Crypto-binding would still be exchanged with Result >> TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for >> legacy >> reason in EAP-FAST, which could be removed in next rev since we are >> designing a new EAP method. >>> 'serially in a sequence' is redundant - section 3.3.1 >>> >> [HZ] Ok. The text is trying to distinguish from running multiple EAP >> methods >> in parallel. >> >>> Not only does it not allow initiating multiple EAP methods in parallel, >>> it >>> requires that they not be running in parallel. This is a more strict >>> condition >>> >> [HZ] For simplicity, otherwise implementation would need to trace when the >> 1st method finishes and applies the key from the authentication to the >> crypto-binding. Supporting them in complete sequence makes it simpler and >> securer, as 2nd method might not be safe to run if the crypto-binging >> after >> 1st method fails. >> >>> Para #3 - can the peer return an error and treat the failure of a >>> specific >>> EAP method as a total failure for the overall process - or at least >>> recommend that it should be an overall failure? >>> >> [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send >> up >> some Fatal Error TLV and Result TLV to indicate the end. >> >>> Confused messages in 3.3.1 and 3.3.3 about sending intermediate results >>> and >>> final results at the same time. Specifically 3.3.1 says MUST NOT for >>> one >>> inner EAP method, but text is not reflected in section 3.3.3 >>> >> [HZ] I think we can change to always send IM result after each inner EAP >> method, if only one inner method, then Result TLV could be sent as well. >> See >> explanation above. >>> Conflict between 3.3.3 and security considerations (7.5) about sending a >>> different value in the Result TLV and the clear result in the event of >>> not >>> doing a Request-Action TLV from the client. Is the server required to >>> use >>> the client suggested result in the event it does not perform the request >>> action - could it use a different failure message or a success message? >>> Does it matter? >>> >> [HZ] Server is supposed to send the suggested Result code in >> Request-Action >> TLV if it refuse to do the action, this way peer will get notify about the >> final result and in-sync with the clear text EAP-Success/Failure packet. >> Probably d
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] Comments on the eap-tunnel-method-00 draft
Hi Hao, About 6 weeks ago I sent in some detailed comments, notably the request for a new TLV to pass a PKCS#10 to the server to go along with the existing TLV that sends a PKCS#7 to the peer, and for a server unauthenticated provisioning mode, and never heard from the editors of the tunnel method draft. Do you have any response to those comments? regards, Dan. On Wed, October 19, 2011 12:31 pm, Hao Zhou wrote: > Jim: > > Thanks for reviewing the draft in detail and comments provided. Please see > my response inline below. > > > On 10/17/11 6:08 PM, "Jim Schaad" wrote: > >> I have gathered these comments over time and therefore some of them are >> not >> fully fleshed out. If you have any questions I will try and reconstruct >> my >> ideas at the time. >> >> Jim >> >> >> >> Version Negotiation - terminate the conversation - w or w/o a fail? >> Edge case - what if peer only supports a higher version than the >> server supports? NAK? >> > [HZ] It depends. Server might want to proceed with other EAP type > negotiation by proposing a different EAP type, or terminate the > conversation > with an EAP-Failure. I will clarify that in the next rev. > >> EAP Server Name Checking - On what basis does the client accept or not >> accept the EAP server name?You are suggesting that it is signed by a >> CA >> controlling the intended domain, but what does this mean? Are you >> suggesting that the CA should have a DNS subject alt name in it for the >> domain in question? >> > [HZ] It's up to client's policy, especially if the server cert is issued > by > a public CA. Client needs not only verify that the server cert presented > is > a valid cert signed by the trusted CA, but also the server name presented > in > the cert is matching the domain it tried to authenticate with. A FQDN in > the > CN or SAN would be a way to do it. > >> If no embedded EAP methods run, then no crypto check and thus no version >> # >> checking is done. > [HZ] That's true. > >>Also no checking done if only one inner EAP method is >> used as this only sends the Result TLV and not the Crypto-Binding TLV >> > [HZ] That's not true. Crypto-binding would still be exchanged with Result > TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for > legacy > reason in EAP-FAST, which could be removed in next rev since we are > designing a new EAP method. >> 'serially in a sequence' is redundant - section 3.3.1 >> > [HZ] Ok. The text is trying to distinguish from running multiple EAP > methods > in parallel. > >> Not only does it not allow initiating multiple EAP methods in parallel, >> it >> requires that they not be running in parallel. This is a more strict >> condition >> > [HZ] For simplicity, otherwise implementation would need to trace when the > 1st method finishes and applies the key from the authentication to the > crypto-binding. Supporting them in complete sequence makes it simpler and > securer, as 2nd method might not be safe to run if the crypto-binging > after > 1st method fails. > >> Para #3 - can the peer return an error and treat the failure of a >> specific >> EAP method as a total failure for the overall process - or at least >> recommend that it should be an overall failure? >> > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send > up > some Fatal Error TLV and Result TLV to indicate the end. > >> Confused messages in 3.3.1 and 3.3.3 about sending intermediate results >> and >> final results at the same time. Specifically 3.3.1 says MUST NOT for >> one >> inner EAP method, but text is not reflected in section 3.3.3 >> > [HZ] I think we can change to always send IM result after each inner EAP > method, if only one inner method, then Result TLV could be sent as well. > See > explanation above. >> Conflict between 3.3.3 and security considerations (7.5) about sending a >> different value in the Result TLV and the clear result in the event of >> not >> doing a Request-Action TLV from the client. Is the server required to >> use >> the client suggested result in the event it does not perform the request >> action - could it use a different failure message or a success message? >> Does it matter? >> > [HZ] Server is supposed to send the suggested Result code in > Request-Action > TLV if it refuse to do the action, this way peer will get notify about the > final result and in-sync with the clear text EAP-Success/Failure packet. > Probably doesn't matter what the server sends, client would set the final > result base on its policy. > >> Section 3.4 - Need to address the following issues: >> 1. what if both certificates and an inner EAP method are run - what is >> the >> Peer-Id then? > [HZ] Good question. There were some discussions on this. The new draft rev > will propose to use the first authenticated peer identity. The WG can > discuss more on this. >> 2. What if multiple inner EAP methods are run - which Peer-Id is used >> then? > [HZ] Same as above. >> 3. What if client and
Re: [Emu] Comments on the eap-tunnel-method-00 draft
Jim: Thanks for reviewing the draft in detail and comments provided. Please see my response inline below. On 10/17/11 6:08 PM, "Jim Schaad" wrote: > I have gathered these comments over time and therefore some of them are not > fully fleshed out. If you have any questions I will try and reconstruct my > ideas at the time. > > Jim > > > > Version Negotiation - terminate the conversation - w or w/o a fail? > Edge case - what if peer only supports a higher version than the > server supports? NAK? > [HZ] It depends. Server might want to proceed with other EAP type negotiation by proposing a different EAP type, or terminate the conversation with an EAP-Failure. I will clarify that in the next rev. > EAP Server Name Checking - On what basis does the client accept or not > accept the EAP server name?You are suggesting that it is signed by a CA > controlling the intended domain, but what does this mean? Are you > suggesting that the CA should have a DNS subject alt name in it for the > domain in question? > [HZ] It's up to client's policy, especially if the server cert is issued by a public CA. Client needs not only verify that the server cert presented is a valid cert signed by the trusted CA, but also the server name presented in the cert is matching the domain it tried to authenticate with. A FQDN in the CN or SAN would be a way to do it. > If no embedded EAP methods run, then no crypto check and thus no version # > checking is done. [HZ] That's true. >Also no checking done if only one inner EAP method is > used as this only sends the Result TLV and not the Crypto-Binding TLV > [HZ] That's not true. Crypto-binding would still be exchanged with Result TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for legacy reason in EAP-FAST, which could be removed in next rev since we are designing a new EAP method. > 'serially in a sequence' is redundant - section 3.3.1 > [HZ] Ok. The text is trying to distinguish from running multiple EAP methods in parallel. > Not only does it not allow initiating multiple EAP methods in parallel, it > requires that they not be running in parallel. This is a more strict > condition > [HZ] For simplicity, otherwise implementation would need to trace when the 1st method finishes and applies the key from the authentication to the crypto-binding. Supporting them in complete sequence makes it simpler and securer, as 2nd method might not be safe to run if the crypto-binging after 1st method fails. > Para #3 - can the peer return an error and treat the failure of a specific > EAP method as a total failure for the overall process - or at least > recommend that it should be an overall failure? > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send up some Fatal Error TLV and Result TLV to indicate the end. > Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and > final results at the same time. Specifically 3.3.1 says MUST NOT for one > inner EAP method, but text is not reflected in section 3.3.3 > [HZ] I think we can change to always send IM result after each inner EAP method, if only one inner method, then Result TLV could be sent as well. See explanation above. > Conflict between 3.3.3 and security considerations (7.5) about sending a > different value in the Result TLV and the clear result in the event of not > doing a Request-Action TLV from the client. Is the server required to use > the client suggested result in the event it does not perform the request > action - could it use a different failure message or a success message? > Does it matter? > [HZ] Server is supposed to send the suggested Result code in Request-Action TLV if it refuse to do the action, this way peer will get notify about the final result and in-sync with the clear text EAP-Success/Failure packet. Probably doesn't matter what the server sends, client would set the final result base on its policy. > Section 3.4 - Need to address the following issues: > 1. what if both certificates and an inner EAP method are run - what is the > Peer-Id then? [HZ] Good question. There were some discussions on this. The new draft rev will propose to use the first authenticated peer identity. The WG can discuss more on this. > 2. What if multiple inner EAP methods are run - which Peer-Id is used then? [HZ] Same as above. > 3. What if client and machine EAP methods are run - which one to use then? > (Internal what are the ids used for?) > [HZ] Again, good question. Same as above. > Section 3.6 - item #2 - it should be noted that not all failure indications > would be transmitted. The failure/success of the last EAP method may not be > sent as it gets wrapped into the Result TLV message > [HZ] Should be fixed with the change on IM result TLV. > Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV > itself need to be acknowledged? > [HZ] Probably no need to, as it is fatal and other side probably already terminated the tun
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Also, this is probably neither here nor there, but NegoEx provides for server-initiated context establishment (i.e. the first token is emitted by the acceptor). I seem to have lost the reference to this, although NegoEx is otherwise specified in draft-zhu-negoex-04. -- Luke ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
> With a standard EAP library that is lock-step in the manner you > describe, it's far easier to produce a synthetic identity request in the > initiator than to hack the state machine or do anything else. Think of Right, I actually tried to hack the state machine as described in a very early iteration and, with the library we used, it just didn't work. -- Luke ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: >>> "Rafa" == Rafa Marin Lopez writes: >> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: >> I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). >> Rafa> Sending its identity does not mean that it must be carried in Rafa> the EAP response/identity. In fact what I suggested is to Rafa> carry the identity in the first message but not contained in Rafa> the EAP response/identity. >> >> OK. Why not carry it in the EAP response/identity? It seems >> easier than developing new encoding. Rafa> Basically EAP is a lock-step protocol where it is required to Rafa> get a request to obtain a response (in the peer side)). So the Rafa> EAP peer state machine implementing the EAP standard protocol Rafa> will react after receiving an EAP request. So I see two Rafa> options: either you hack the EAP peer state machine to return Rafa> an EAP response/identity without receiving any EAP Rafa> request/identity (this "violates" the standard and so we need Rafa> to hack the EAP peer state machine) Or the initiator synthesizes a request and feeds it to the peer's state machine. IN our implementation, even if the IETF decides on an an alternate encoding for the identity, we'll end up synthesizing an identity request and doing something with the identity response. With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. Think of it this way. In GSS-EAP, the identity request is generated by a party very close to the initiator. EAP already supports the identity request being generated by a different party than the actual EAP messages. Why does it matter whether the request comes from inside the peer or from a NAS? Rafa> or directly at GSS-API Rafa> level you create a EAP response/identity and include the Rafa> identity (which seems weird taking into account that we have Rafa> an EAP stack in charge of creating EAP messages) But if you don't create an EAP response/identity on the initiator you probably do have to do it on the acceptor to trigger AAA to use EAP. Rafa> Personally, I do not like either (considering the standard RFC Rafa> 3748). So, I would prefer to define a subtoken for this. We can do that. It means faking up an identity response on the acceptor. But that is certainly not a big deal. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Hi again: I have been thinking again about the situation created with sending an EAP response/id without the authenticator sending EAP request/id and I realized that it may be even worse in the authenticator side. Basically, the authenticator will see an EAP response message which does not answer to any EAP request sent. Best regards. El 19/10/2011, a las 11:45, Rafa Marin Lopez escribió: > Please replace RADIUS Access-Challenge by RADIUS Access-Request in the > sentence of my previous e-mail > > "In other words, once the acceptor knows the peer's identity can send that > EAP-start message in a RADIUS Access-Challenge..." > > Best regards. > > El 19/10/2011, a las 11:28, Rafa Marin Lopez escribió: > >> Hi Sam: >> >> El 19/10/2011, a las 00:23, Sam Hartman escribió: >> "Rafa" == Rafa Marin Lopez writes: >>> >>> Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: >>> >> "Rafa" == Rafa Marin Lopez writes: > >>> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: > >>> I think I may have been unclear in what I was proposing. I'm >>> proposing that the peer send its identity in the first message >>> (*) and that the server gets to respond with type 4 or greater >>> (a specific EAP method). > >>> Rafa> Sending its identity does not mean that it must be carried in >>> Rafa> the EAP response/identity. In fact what I suggested is to >>> Rafa> carry the identity in the first message but not contained in >>> Rafa> the EAP response/identity. > > OK. Why not carry it in the EAP response/identity? It seems > easier than developing new encoding. >>> >>> Rafa> Basically EAP is a lock-step protocol where it is required to >>> Rafa> get a request to obtain a response (in the peer side)). So the >>> Rafa> EAP peer state machine implementing the EAP standard protocol >>> Rafa> will react after receiving an EAP request. So I see two >>> Rafa> options: either you hack the EAP peer state machine to return >>> Rafa> an EAP response/identity without receiving any EAP >>> Rafa> request/identity (this "violates" the standard and so we need >>> Rafa> to hack the EAP peer state machine) >>> >>> Or the initiator synthesizes a request and feeds it to the peer's state >>> machine. >> >> Yes, this is another option, though I don't like either. The reason is >> simple. AFAIK, the standard EAP does not say anything about a EAP >> lower-layer synthesizing a request (which sounds like another type of hack). >> EAP requests are sent by the authenticator. This is what the standard says. >> >>> >>> IN our implementation, even if the IETF decides on an an alternate >>> encoding for the identity, we'll end up synthesizing an identity request >>> and doing something with the identity response. >>> >>> With a standard EAP library that is lock-step in the manner you >>> describe, it's far easier to produce a synthetic identity request in the >>> initiator than to hack the state machine or do anything else. >> >> As I said synthesizing an EAP request is another type of hack, because the >> EAP protocol does not work like that. We have a RFC 3748 and RFC 5247 where >> the EAP protocol is defined. I believe it would be good if we follow the >> standards. >> >>> Think of >>> it this way. In GSS-EAP, the identity request is generated by a party >>> very close to the initiator. EAP already supports the identity request >>> being generated by a different party than the actual EAP messages. Why >>> does it matter whether the request comes from inside the peer or from a >>> NAS? >> >> >> Regarding this, you need to think about the mode independence property of >> EAP where: >> >> "As far as the EAP peer is concerned, its conversation with the EAP >> authenticator, and all >> consequences of that conversation, are identical, regardless of the >> authenticator mode of operation." >> >> In other words, under peer standpoint, all EAP requests are coming from the >> EAP authenticator (the peer does not know and do not care if there is a >> backend EAP server or it is integrated with the authenticator). >> >> >>> >>> >>> Rafa> or directly at GSS-API >>> Rafa> level you create a EAP response/identity and include the >>> Rafa> identity (which seems weird taking into account that we have >>> Rafa> an EAP stack in charge of creating EAP messages) >>> >>> But if you don't create an EAP response/identity on the initiator you >>> probably do have to do it on the acceptor to trigger AAA to use EAP. >> >> I don't think you need to do that. As I explained in the previous e-mail, in >> RADIUS EAP (RFC 3579) you can find this text: >> >> "Rather than sending an initial EAP-Request packet to the >> authenticating peer, on detecting the presence of the peer, the NAS >> MAY send an Access-Request packet to the RADIUS server containing an >> EAP-Message attribute signifying EAP-Start. The RADIUS server will >> typic
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Please replace RADIUS Access-Challenge by RADIUS Access-Request in the sentence of my previous e-mail "In other words, once the acceptor knows the peer's identity can send that EAP-start message in a RADIUS Access-Challenge..." Best regards. El 19/10/2011, a las 11:28, Rafa Marin Lopez escribió: > Hi Sam: > > El 19/10/2011, a las 00:23, Sam Hartman escribió: > >>> "Rafa" == Rafa Marin Lopez writes: >> >> Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: >> > "Rafa" == Rafa Marin Lopez writes: >> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: >> I think I may have been unclear in what I was proposing. I'm >> proposing that the peer send its identity in the first message >> (*) and that the server gets to respond with type 4 or greater >> (a specific EAP method). >> Rafa> Sending its identity does not mean that it must be carried in >> Rafa> the EAP response/identity. In fact what I suggested is to >> Rafa> carry the identity in the first message but not contained in >> Rafa> the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. >> >> Rafa> Basically EAP is a lock-step protocol where it is required to >> Rafa> get a request to obtain a response (in the peer side)). So the >> Rafa> EAP peer state machine implementing the EAP standard protocol >> Rafa> will react after receiving an EAP request. So I see two >> Rafa> options: either you hack the EAP peer state machine to return >> Rafa> an EAP response/identity without receiving any EAP >> Rafa> request/identity (this "violates" the standard and so we need >> Rafa> to hack the EAP peer state machine) >> >> Or the initiator synthesizes a request and feeds it to the peer's state >> machine. > > Yes, this is another option, though I don't like either. The reason is > simple. AFAIK, the standard EAP does not say anything about a EAP lower-layer > synthesizing a request (which sounds like another type of hack). EAP requests > are sent by the authenticator. This is what the standard says. > >> >> IN our implementation, even if the IETF decides on an an alternate >> encoding for the identity, we'll end up synthesizing an identity request >> and doing something with the identity response. >> >> With a standard EAP library that is lock-step in the manner you >> describe, it's far easier to produce a synthetic identity request in the >> initiator than to hack the state machine or do anything else. > > As I said synthesizing an EAP request is another type of hack, because the > EAP protocol does not work like that. We have a RFC 3748 and RFC 5247 where > the EAP protocol is defined. I believe it would be good if we follow the > standards. > >> Think of >> it this way. In GSS-EAP, the identity request is generated by a party >> very close to the initiator. EAP already supports the identity request >> being generated by a different party than the actual EAP messages. Why >> does it matter whether the request comes from inside the peer or from a >> NAS? > > > Regarding this, you need to think about the mode independence property of EAP > where: > > "As far as the EAP peer is concerned, its conversation with the EAP > authenticator, and all > consequences of that conversation, are identical, regardless of the > authenticator mode of operation." > > In other words, under peer standpoint, all EAP requests are coming from the > EAP authenticator (the peer does not know and do not care if there is a > backend EAP server or it is integrated with the authenticator). > > >> >> >> Rafa> or directly at GSS-API >> Rafa> level you create a EAP response/identity and include the >> Rafa> identity (which seems weird taking into account that we have >> Rafa> an EAP stack in charge of creating EAP messages) >> >> But if you don't create an EAP response/identity on the initiator you >> probably do have to do it on the acceptor to trigger AAA to use EAP. > > I don't think you need to do that. As I explained in the previous e-mail, in > RADIUS EAP (RFC 3579) you can find this text: > > "Rather than sending an initial EAP-Request packet to the > authenticating peer, on detecting the presence of the peer, the NAS > MAY send an Access-Request packet to the RADIUS server containing an > EAP-Message attribute signifying EAP-Start. The RADIUS server will > typically respond with an Access-Challenge containing EAP-Message > attribute(s) encapsulating an EAP-Request/Identity (Type 1). > However, an EAP-Request for an authentication method (Type 4 or > greater) can also be sent by the server. > > EAP-Start is indicated by sending an EAP-Message attribute with a > length of 2 (no data)." > > > In other words, once the acceptor knows the peer's identity can send that > EAP-start message in a RADIUS Access-Challenge. Moreover it should in
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Hi Sam: El 19/10/2011, a las 00:23, Sam Hartman escribió: >> "Rafa" == Rafa Marin Lopez writes: > >Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: > "Rafa" == Rafa Marin Lopez writes: >>> >Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: >>> > I think I may have been unclear in what I was proposing. I'm > proposing that the peer send its identity in the first message > (*) and that the server gets to respond with type 4 or greater > (a specific EAP method). >>> >Rafa> Sending its identity does not mean that it must be carried in >Rafa> the EAP response/identity. In fact what I suggested is to >Rafa> carry the identity in the first message but not contained in >Rafa> the EAP response/identity. >>> >>> OK. Why not carry it in the EAP response/identity? It seems >>> easier than developing new encoding. > >Rafa> Basically EAP is a lock-step protocol where it is required to >Rafa> get a request to obtain a response (in the peer side)). So the >Rafa> EAP peer state machine implementing the EAP standard protocol >Rafa> will react after receiving an EAP request. So I see two >Rafa> options: either you hack the EAP peer state machine to return >Rafa> an EAP response/identity without receiving any EAP >Rafa> request/identity (this "violates" the standard and so we need >Rafa> to hack the EAP peer state machine) > > Or the initiator synthesizes a request and feeds it to the peer's state > machine. Yes, this is another option, though I don't like either. The reason is simple. AFAIK, the standard EAP does not say anything about a EAP lower-layer synthesizing a request (which sounds like another type of hack). EAP requests are sent by the authenticator. This is what the standard says. > > IN our implementation, even if the IETF decides on an an alternate > encoding for the identity, we'll end up synthesizing an identity request > and doing something with the identity response. > > With a standard EAP library that is lock-step in the manner you > describe, it's far easier to produce a synthetic identity request in the > initiator than to hack the state machine or do anything else. As I said synthesizing an EAP request is another type of hack, because the EAP protocol does not work like that. We have a RFC 3748 and RFC 5247 where the EAP protocol is defined. I believe it would be good if we follow the standards. > Think of > it this way. In GSS-EAP, the identity request is generated by a party > very close to the initiator. EAP already supports the identity request > being generated by a different party than the actual EAP messages. Why > does it matter whether the request comes from inside the peer or from a > NAS? Regarding this, you need to think about the mode independence property of EAP where: "As far as the EAP peer is concerned, its conversation with the EAP authenticator, and all consequences of that conversation, are identical, regardless of the authenticator mode of operation." In other words, under peer standpoint, all EAP requests are coming from the EAP authenticator (the peer does not know and do not care if there is a backend EAP server or it is integrated with the authenticator). > > >Rafa> or directly at GSS-API >Rafa> level you create a EAP response/identity and include the >Rafa> identity (which seems weird taking into account that we have >Rafa> an EAP stack in charge of creating EAP messages) > > But if you don't create an EAP response/identity on the initiator you > probably do have to do it on the acceptor to trigger AAA to use EAP. I don't think you need to do that. As I explained in the previous e-mail, in RADIUS EAP (RFC 3579) you can find this text: "Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data)." In other words, once the acceptor knows the peer's identity can send that EAP-start message in a RADIUS Access-Challenge. Moreover it should include the user-name in the request. With that, the RADIUS EAP server should start the EAP method selected for that peer. > >Rafa> Personally, I do not like either (considering the standard RFC >Rafa> 3748). So, I would prefer to define a subtoken for this. > > We can do that. It means faking up an identity response on the > acceptor. But that is certainly not a big deal. As explained, you do not need to fake up an
