Re: [Emu] Submitted 10
> "Jim" == Jim Schaad writes: Jim> I want to make sure that we have distinguished between the two Jim> statements 1. The server says that I don't support these Jim> specific attributes Jim> and 2. The server does not tell me that it Jim> did or did not do matching of some attributes. Jim> The first I think is totally optional, but the second is Jim> necessary for the tunnel draft and should be made explicit in Jim> this draft as something that needs to be done. I think section 5.3 clearly requires that a peer learn whether the server did do matching and if so, what attributes it successfully matched. We don't currently have a way for the server to say "these attributes didn't match." That's kind of tricky and I'd prefer that to be a future work item. I've left extensibility for it. Also, the client's request to the server is integrity protected. I believe we should require and would appreciate you checking that we do require: 1) A client supporting channel binding to a server supporting channel binding will get channel binding. An attacker cannot downgrade to no channel binding. I believe that by doing channel binding over an integrity-protected channel we get that. 2) If you do channel binding the client will learn the result and will learn which attributes it sent were considered and met whatever consistency check the server did. This is a little vaguely worded because there's a lot of latitude for server policy. ___ 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] Submitted 10
Jim: The chbind draft already has that covered by the use of the code. Tunnel method defines the channel-binding TLV that wraps the channel data defined in chbind draft, so I think we are ok. On 10/21/11 4:13 PM, "Jim Schaad" wrote: > I want to make sure that we have distinguished between the two statements > > 1. The server says that I don't support these specific attributes and > 2. The server does not tell me that it did or did not do matching of some > attributes. > > The first I think is totally optional, but the second is necessary for the > tunnel draft and should be made explicit in this draft as something that > needs to be done. I will be reading this document with this in mind. > > Jim > > >> -Original Message- >> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of >> Sam Hartman >> Sent: Friday, October 21, 2011 12:34 PM >> To: Hao Zhou >> Cc: Sam Hartman; emu@ietf.org >> Subject: Re: [Emu] Submitted 10 >> >> I'll respond to the question of channel binding support now. I think the >> current text permits an EAP method to not send channel binding if it knows >> the server fails to support it. If your method can discover that and >> optimistically avoid sending channel binding that's fine. >> >> I think we discussed the flow in a fair bit of detail and I think we have >> consensus on the current flow including the lack of server telling the > peer >> which channel binding attributes it supports. As an individual, I do not >> support opening that up again, although if there is WG consensus to make a >> change we should do so. >> ___ >> 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] Submitted 10
I want to make sure that we have distinguished between the two statements 1. The server says that I don't support these specific attributes and 2. The server does not tell me that it did or did not do matching of some attributes. The first I think is totally optional, but the second is necessary for the tunnel draft and should be made explicit in this draft as something that needs to be done. I will be reading this document with this in mind. Jim > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Sam Hartman > Sent: Friday, October 21, 2011 12:34 PM > To: Hao Zhou > Cc: Sam Hartman; emu@ietf.org > Subject: Re: [Emu] Submitted 10 > > I'll respond to the question of channel binding support now. I think the > current text permits an EAP method to not send channel binding if it knows > the server fails to support it. If your method can discover that and > optimistically avoid sending channel binding that's fine. > > I think we discussed the flow in a fair bit of detail and I think we have > consensus on the current flow including the lack of server telling the peer > which channel binding attributes it supports. As an individual, I do not > support opening that up again, although if there is WG consensus to make a > change we should do so. > ___ > 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] Submitted 10
I wasn't aware of previous discussion and decision on this already. Sorry for bringing this up. Proceed with the current draft. On 10/21/11 3:36 PM, "Alan DeKok" wrote: > Sam Hartman wrote: >> I think we discussed the flow in a fair bit of detail and I think we >> have consensus on the current flow including the lack of server telling >> the peer which channel binding attributes it supports. As an >> individual, I do not support opening that up again, although if there is >> WG consensus to make a change we should do so. > > I think there's been a lot of discussion on the document. We need to > get closure quickly. This means not re-opening issues which were > previously discussed and decided. > > Alan DeKok. ___ 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] Submitted 10
Sam Hartman wrote: > I think we discussed the flow in a fair bit of detail and I think we > have consensus on the current flow including the lack of server telling > the peer which channel binding attributes it supports. As an > individual, I do not support opening that up again, although if there is > WG consensus to make a change we should do so. I think there's been a lot of discussion on the document. We need to get closure quickly. This means not re-opening issues which were previously discussed and decided. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
I'll respond to the question of channel binding support now. I think the current text permits an EAP method to not send channel binding if it knows the server fails to support it. If your method can discover that and optimistically avoid sending channel binding that's fine. I think we discussed the flow in a fair bit of detail and I think we have consensus on the current flow including the lack of server telling the peer which channel binding attributes it supports. As an individual, I do not support opening that up again, although if there is WG consensus to make a change we should do so. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Sam: My review comments: 1. Section 3, paragraph 1, should " far removed" be "far remoted"? 2. Section 3, bottom of Page 6, should "virtual Lads (VLANs)" be "virtual LANs (VLANs)"? 3. Section 5.1, page 14, paragraph 2, should "I2" be "i2"? 4. So, client sends channel-binding data automatically or by its configuration, not per server request? It seems inefficient for peer send a big chunk of i1 without knowing whether the server supports channel binding or what information is needs. Might be better if server can request it and specific information before the peer sends it. 5. Section 7, should the title be Channel-binding AVP instead, as it talks all about AVP, not TLV? On 10/19/11 4:09 PM, "Sam Hartman" wrote: > > > 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 mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Glen Zorn wrote: > Thank you for your authoritative reading of WG consensus. If the > problems (and their solutions were so obvious, why were they present in > the draft at all? No draft is perfect on first writing. Even the IESG may offer feedback to improve a document. > I could have sworn that the process WRT a WG Draft was that it was > changed only by direction of the Chair(s) as a result of the > determination of WG consensus, rather than at the whim of the editor. > Maybe a different process? I have no problem with a document being updated in WGLC due to feedback on the list. This has happened with other WG's, too. > Apparently I was unclear: the specific text to which I am objecting is > -10. All of it. Curious. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
On Fri, Oct 21, 2011 at 4:57 AM, Glen Zorn wrote: > > Apparently I was unclear: the specific text to which I am objecting is > -10. All of it. > Ooo. Someone woke up exceptionally grumpy this morning. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
On 10/20/2011 8:55 PM, Sam Hartman wrote: >> "Glen" == Glen Zorn writes: > > Glen> 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. > > Glen> Great, so what are we supposed to do now? WGLC was issued on > Glen> draft-ietf-emu-chbind-09. The last call is not complete. > Glen> Shall we just start over? > > Documents are updated to reflect feedback during last calls all the > time. It happens in WGs I chair; it happened with documents for which I > was the AD; I've been asked to do it by ADs and other chairs. Drivers run red lights all the time, too. > Obviously, sometimes it is done wrong. > > My thinking is that Alan's comments had been outstanding for a while, > seemed fairly obvious and with the exception of the question about > encoding of responses were non-contraversial. Thank you for your authoritative reading of WG consensus. If the problems (and their solutions were so obvious, why were they present in the draft at all? In fact, they become "non-controversial" at the end of last call, not in the middle. > > None of them seemed to require a second last call. > By submitting 10 I've made a version with the changes folded in > available for review. > > What I did is clearly permitted by the process. I could have sworn that the process WRT a WG Draft was that it was changed only by direction of the Chair(s) as a result of the determination of WG consensus, rather than at the whim of the editor. Maybe a different process? > The chairs may of > course decide I made an error and that one of Alan's comments didn't > have sufficient consus. They can ask me to (or do it themselves) > resubmit 09 as 11, ask me to remove some text, or give more specific > guidance. We may also discover that I incorrectly applied Alan's > comment. > > You still had the options you had before. You can review 09 if you like > and send comments on 09. You can reply to Alan's comments and respond to > them. > > You have some additional options now. If you haven't started reviewing > yet you can start with 10. If you'd like you can review the diff > between 10 and 9. You can review 9 and 10 separately if you have a lot > of free time on your hands. You can ignore the whole thing. You get a > chance to see Alan's context in the text. You can better appreciate them > and if you find a problem bring it up. > > If you have trouble finding 09 or a diff between 09 and 10 let me know; > I bet we can find one if we work together. > > > If you have an objection to text in 9, text in 10, changes between the > two bring it up. Objections of this form without an objection to actual > text are not constructive. Apparently I was unclear: the specific text to which I am objecting is -10. All of it. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
