>>>>> "zhou" == zhou sujing <zhou.suj...@zte.com.cn> 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
