Re: [Emu] Channel Binding Consensus Call
The consensus for the first topic affirms the current direction of the document. The consensus for the second question is a bit rougher, but indicates a preference for option 1. The document needs to be revised to reflect any changes as a result of this call. On Apr 18, 2011, at 11:11 AM, Joe Salowey wrote: This is a consensus call to validate the direction the draft-ietf-emu-chbind-07 and confirm the consensus around the encoding of the channel binding TLV. Please respond to the following questions by May 2, 2011. 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indicates to the client what attributes were validated. 2. Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf. Do you prefer encoding option 1, where attributes are encoded individually or option 2 where attributes in the same namespace are grouped together. Cheers, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
Alan == Alan DeKok al...@deployingradius.com writes: Alan Stefan Winter wrote: Attribute parsing should be easier with this option 1 - Length can always serve as a pointer to the next attribute, with explicit namespace ID. With option 2, attribute delimiters are only within NS-Specific, and Length points to the Namespace, if any. That makes two code paths, one for parsing NSID delimiters, and one for parsing attributes. Alan My $0.02 is that it's easier to do: Alan Parse NS stuff NS1 - parse protocol-specific 1 NS2 - parse Alan protocol-specific 2 I think this is true on the server. However, I'd really appreciate your thoughts on what will happen inside the EAP peer itself? My assumption is that outside of the guts of a TTLS implementation, EAP peers today don't have knowledge either of RADIUS or DIAMETER. So, a format that minimizes how much they need to understand either of these protocols would be valuable. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
Sam Hartman wrote: I think this is true on the server. Yes. However, I'd really appreciate your thoughts on what will happen inside the EAP peer itself? Ideally, code re-use. My assumption is that outside of the guts of a TTLS implementation, EAP peers today don't have knowledge either of RADIUS or DIAMETER. Largely, yes. So, a format that minimizes how much they need to understand either of these protocols would be valuable. Valuable, yes. High value, perhaps not. There is plenty of BSD-licensed code available for packing and unpacking RADIUS attributes. There should be little cost to re-using that, and a larger cost in writing a new attribute packer. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
Alan == Alan DeKok al...@deployingradius.com writes: Alan There is plenty of BSD-licensed code available for packing Alan and unpacking RADIUS attributes. There should be little cost Alan to re-using that, and a larger cost in writing a new attribute Alan packer. Assuming RADIUS is basically the only namespace we end up needing this probably is true. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
Dear all, 1) Agree 2) Option 1 Kind regards Stephen McCann Research in Motion Southampton, UK On 18 April 2011 19:11, Joe Salowey jsalo...@cisco.com wrote: This is a consensus call to validate the direction the draft-ietf-emu-chbind-07 and confirm the consensus around the encoding of the channel binding TLV. Please respond to the following questions by May 2, 2011. 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indicates to the client what attributes were validated. 2. Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf. Do you prefer encoding option 1, where attributes are encoded individually or option 2 where attributes in the same namespace are grouped together. Cheers, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/18/11 8:11 PM, Joe Salowey wrote: Hi, 1. yes 2. option 1 I have no strong preference for either, but option 1 seems cleaner to me (no further parsing neccesary, and I think the waste of bytes is not that big that we need to be too worried about that). For the record, I have indicated the same in the WG meeting. Klaas This is a consensus call to validate the direction the draft-ietf-emu-chbind-07 and confirm the consensus around the encoding of the channel binding TLV. Please respond to the following questions by May 2, 2011. 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indicates to the client what attributes were validated. 2. Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf. Do you prefer encoding option 1, where attributes are encoded individually or option 2 where attributes in the same namespace are grouped together. Cheers, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk227F4ACgkQH2Wy/p4XeFIJggCcCYClU2I9ju2tRkrb5kn9TiZ2 EE4AnRlidd17x1i1F1K8yYXd4ZwUfxnK =zwx5 -END PGP SIGNATURE- ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Channel Binding Consensus Call
This is a consensus call to validate the direction the draft-ietf-emu-chbind-07 and confirm the consensus around the encoding of the channel binding TLV. Please respond to the following questions by May 2, 2011. 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indicates to the client what attributes were validated. 2. Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf. Do you prefer encoding option 1, where attributes are encoded individually or option 2 where attributes in the same namespace are grouped together. Cheers, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
1. agree 2. option 1 because it appears cleaner but no strong preference Katrin -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Joe Salowey Sent: Monday, April 18, 2011 1:12 PM To: emu@ietf.org Subject: [Emu] Channel Binding Consensus Call This is a consensus call to validate the direction the draft-ietf-emu- chbind-07 and confirm the consensus around the encoding of the channel binding TLV. Please respond to the following questions by May 2, 2011. 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indicates to the client what attributes were validated. 2. Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf. Do you prefer encoding option 1, where attributes are encoded individually or option 2 where attributes in the same namespace are grouped together. Cheers, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
