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
expected to introducing implementing channel binding on tunnel,
but was sudden to turn to cryptographic
binding by "" Tunnel methods sometimes use
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.
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
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
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.
-Sophia, Sujing Zhou
|Joe Salowey <jsalowey <at> cisco.com>
发件人: emu-bounces <at> ietf.org
|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.
On May 14, 2012, at 12:10 PM, Sam Hartman wrote:
> This version includes a large number of changes mostly to respond
> 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
> it's a good idea for WG members to review these changes.
> Emu mailing list
> Emu <at> ietf.org
Emu mailing list
Emu <at> ietf.org