Re: [Emu] Comments on the eap-tunnel-method-00 draft
Jim: Please see inline. -Original Message- From: Jim Schaad [mailto:i...@augustcellars.com] Sent: Wed 10/19/2011 7:54 PM To: Hao Zhou (hzhou); draft-ietf-emu-eap-tunnel-met...@tools.ietf.org; Sam Hartman Cc: emu@ietf.org Subject: 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? [HZ] Yes, a NAK with other proposed EAP method if available. Will clarify in 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. Ok - this would be in violation of the last paragraph in section 3.1 which says that the version numbers MUST be done. [HZ] Good point. Seems like we need to crypto-binding every time if we want to protect the version number, EAP type, and outer TLVs. Will discuss and fix in next rev. > > >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. [HZ] It is described in Section 4.2.8, "The Crypto-Binding TLV MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods. The Crypto-Binding TLV can be issued at other times as well." We will clarify to make it clear that it MUST be done after each successful EAP method even if it's only one in the sequence. > > '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 seri
Re: [Emu] Comments on the eap-tunnel-method-00 draft
> "Hao" == Hao Zhou writes: Hao> Rereading the updated chbind draft, it has already defined the Hao> mechanism for two way communication and tunnel EAP draft just Hao> defined a TLV container to carry the Channel binding data Hao> defined in Section 5.3, so we should be ok. No change is Hao> needed on the tunnel EAP draft on this, other maybe called out Hao> Section 5.3. And to indicate it's two-way. ___ 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] 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 > &
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] 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
[Emu] Comments on the eap-tunnel-method-00 draft
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? 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? If no embedded EAP methods run, then no crypto check and thus no version # checking is 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 'serially in a sequence' is redundant - section 3.3.1 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 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? 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 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? 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? 2. What if multiple inner EAP methods are run - which Peer-Id is used then? 3. What if client and machine EAP methods are run - which one to use then? (Internal what are the ids used for?) 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 Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV itself need to be acknowledged? Section 3.7 - Can I assume that the identifier value is monotonically increasing and does not wrap? Section 3.7 - it might be useful to tell me how to error for a message too big or response time too long in dealing with fragmentation - are both just final errors? Or should it potentially be treated as a TLS error? Section 3.2 - possible clarification. If all TLVs in a message are marked optional and none are understood by the peer, then an EMPTY response message must still be sent to the server. Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV - not what it says in section 3.3 Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not sure I understand why. If I send an EAP plus a vendor w/ mandatory set, should not I get back a NAK on the vendor plus a result for the EAP? I might be happy to not do the vendor, but want to distinguish between you cannot do this vs you choose not to do this. 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. Section 4.2.8 - Currently says that version should be 1 while the version defined in the intro sections is 2 - would be correct if we change the EAP method. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
