I have no problemdocumenting why we do not do so as an example of privacy in sec cons
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu

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 <jsalowey <at> cisco.com> 发件人:  emu-bounces <at> ietf.org 2012-05-15 22:59

收件人 emu <at> ietf.org 抄送 Sam Hartman <hartmans-ietf <at> mit.edu> 主题 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 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu

Sam Hartman <hartmans-ietf <at> mit.edu> 写于 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu

Regards~~~

-Sujing Zhou

Sam Hartman <hartmans-ietf <at> mit.edu> 写于 2012-05-17 20:46:55:

> >>>>> "zhou" == zhou sujing <zhou.sujing <at> zte.com.cn> 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.
>
what if there is not such an internal key other than MSK and EMSK for a EAP method?

_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu