Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt
> "zhou" == zhou sujing writes: zhou> If there is another key available, it will be great, EMSK? It zhou> has been suggested for cryptographic binding. I'm expecting that most EAP methods will use a key internal to their heirarchy above both the MSK and EMSK. For example I'd expect that TLS-based tunnels would use the TLS integrity and confidentiality keys for channel binding. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt
Sam Hartman 写于 2012-05-16 20:26:40: > > The explicit structure of > that paragraph was called out for WG review prior to IETF last call; > also that structure was present in IETF last call. I do not wish to > wait to reach consensus on general comments about proes/cons of > implementing channel binding with tunnel methods prior to approval of > this document. Well，no matter what's the result, I don't like the logic in the current text, it is not clear and easy to confusing the two bindings. > Thus I prefer the current text. > > Channel binding can happen before or after the MSK is generated, but > effectively needs to happen after some key is generated. > > I would expect that the key used for channel binding integrity would be > cryptographically independent of the MSK. > I've not analyzed a method where the MSK is used for channel binding but > this is done prior to transport to the authenticator. > That's probably safe, but it seems like a bad design strategy because it > seems needlessly fragile. > So, I'd be nervous about that strategy and would recommend independent > keys for channel binding. If there is another key available, it will be great, EMSK? It has been suggested for cryptographic binding. > > I disagree. > I'd ask you to take a look at the slides I presented at IETF 83. I think > they are more clear than draft-hartman-emu-mutual-crypto-binding at the > moment, although obviously we will update that draft in the near future > to reflect your comments and those of others. If EMSK is used in channel binding, is cryptophic binding using EMSK still neccesary? > > That would be a change to existing EAP methods in some cases. > That sort of change is out of scope for draft-ietf-emu-chbind. > It's true that channel binding benefits from protected success > indications and the current draft-ietf-emu-chbind does discuss that. If EMSK is used, then no change to existing EAP methods will be made. That will be fine. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt
> "zhou" == zhou sujing writes: zhou> Hi all zhou> In section 9.1 One attractive implementation strategy for zhou> channel binding is to add channel binding support to a tunnel zhou> method which can tunnel an inner EAP authentication. was zhou> expected to introducing implementing channel binding on zhou> tunnel, but was sudden to turn to cryptographic binding by "" zhou> Tunnel methods sometimes use cryptographic binding," and began zhou> on weakness of tunnel method with cryptographic binding, zhou> especially on a specific (or typical) implementation with MSK. zhou> In my opinion, these are two different topic, better in zhou> separate paragraghs; and the first topic needs some zhou> explanation, pros and cons, why not adopt that implementation zhou> since it is attractive. I appreciate your desire to analyze the proes and cons of of tunnel methods. I'm nervous about expanding the scope of this document to do that because I believe it would add delay. Also, I'm confused about whether a general discussion of tunnel methods and channel bindings belongs in the security considerations section of this document. The explicit structure of that paragraph was called out for WG review prior to IETF last call; also that structure was present in IETF last call. I do not wish to wait to reach consensus on general comments about proes/cons of implementing channel binding with tunnel methods prior to approval of this document. Thus I prefer the current text. zhou> Also, on tunnel method with channel binding, I think there is zhou> some point unclear. zhou> According to zhou> section 4.2 "The channel bindings MUST be transported with zhou> integrity protection based on a key known only to the peer and zhou> EAP server. " section 6 "The channel binding protocol defined zhou> in this document must be transported after keying material has zhou> been derived between the EAP peer and server, and before the zhou> peer would suffer adverse affects from joining an adversarial zhou> network." zhou> To my understanding, channel binding exchange happens after a zhou> MSK is derived between EAP peer and EAP server, and before MSK zhou> is transported to authenticator. Channel binding can happen before or after the MSK is generated, but effectively needs to happen after some key is generated. zhou> If not, for example, after MSK is transported to zhou> authenticator, of course authenticator can control the channel zhou> binding exchange. I would expect that the key used for channel binding integrity would be cryptographically independent of the MSK. I've not analyzed a method where the MSK is used for channel binding but this is done prior to transport to the authenticator. That's probably safe, but it seems like a bad design strategy because it seems needlessly fragile. So, I'd be nervous about that strategy and would recommend independent keys for channel binding. zhou> I think that is why the EAP cryptograhic binding draft was put zhou> forward. If it is made clear and MUST that " MSK zhou> transportation to authenticator" happens after channel binding zhou> exchange finishes, I don't think an extra crypto binding is zhou> necessary. I disagree. I'd ask you to take a look at the slides I presented at IETF 83. I think they are more clear than draft-hartman-emu-mutual-crypto-binding at the moment, although obviously we will update that draft in the near future to reflect your comments and those of others. zhou> and to make it clear I suggest EAP server transport MSK after zhou> it has obtained explicit response from EAP peer to authorize zhou> the action. That would be a change to existing EAP methods in some cases. That sort of change is out of scope for draft-ietf-emu-chbind. It's true that channel binding benefits from protected success indications and the current draft-ietf-emu-chbind does discuss that. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt
Hi，all In section 9.1 ， “One attractive implementation strategy for channel binding is to add channel binding support to a tunnel method which can tunnel an inner EAP authentication.”was expected to introducing implementing channel binding on tunnel, but was sudden to turn to cryptographic binding by "" Tunnel methods sometimes use cryptographic binding," and began on weakness of tunnel method with cryptographic binding, especially on a specific (or typical) implementation with MSK. In my opinion, these are two different topic, better in separate paragraghs; and the first topic needs some explanation, pros and cons, why not adopt that implementation since it is attractive. Also, on tunnel method with channel binding, I think there is some point unclear. According to section 4.2 "The channel bindings MUST be transported with integrity protection based on a key known only to the peer and EAP server. " section 6 "The channel binding protocol defined in this document must be transported after keying material has been derived between the EAP peer and server, and before the peer would suffer adverse affects from joining an adversarial network." To my understanding, channel binding exchange happens after a MSK is derived between EAP peer and EAP server, and before MSK is transported to authenticator. If not, for example, after MSK is transported to authenticator, of course authenticator can control the channel binding exchange. I think that is why the EAP cryptograhic binding draft was put forward. If it is made clear and MUST that " MSK transportation to authenticator" happens after channel binding exchange finishes, I don't think an extra crypto binding is necessary. and to make it clear， I suggest EAP server transport MSK after it has obtained explicit response from EAP peer to authorize the action. Regards~~~ -Sophia, Sujing Zhou Joe Salowey 发件人: emu-boun...@ietf.org 2012-05-15 22:59 收件人 emu@ietf.org 抄送 Sam Hartman 主题 Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt Please respond on the list by May 25, 2012. Thanks, Joe On May 14, 2012, at 12:10 PM, Sam Hartman wrote: > > > This version includes a large number of changes mostly to respond to the > secdir review. > > I'm not entirely sure that Stephen Hanna will be happy with the changes > in section 9, but I'd like to start there and see where we are. I think > it's a good idea for WG members to review these changes. > ___ > 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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt
Please respond on the list by May 25, 2012. Thanks, Joe On May 14, 2012, at 12:10 PM, Sam Hartman wrote: > > > This version includes a large number of changes mostly to respond to the > secdir review. > > I'm not entirely sure that Stephen Hanna will be happy with the changes > in section 9, but I'd like to start there and see where we are. I think > it's a good idea for WG members to review these changes. > ___ > 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] I-D Action: draft-ietf-emu-chbind-15.txt
This version includes a large number of changes mostly to respond to the secdir review. I'm not entirely sure that Stephen Hanna will be happy with the changes in section 9, but I'd like to start there and see where we are. I think it's a good idea for WG members to review these changes. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
