Re: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind

[Sam Hartman]

 Jim == Jim Schaad jim...@augustcellars.com writes:

Jim Sam et al,
Jim 1. In section 1 after the Classic Tunnel Attack figure, I believe 
there are
Jim three methods listed as possible mitigation strategies, however I don't
Jim understand how the second one - a sufficiently strong inner method - 
could
Jim possibly be a mitigation by itself.  The three I see are 1) Policy 2) 
strong
Jim inner method 3) Cryptographic binding.

I actually was intending to describe cryptographic binding in two
sentences; I've re-punctuated the text to indicate that if the inner
method is strong enough you can do cryptographic binding.

I believe I've addressed your other comments in an upcoming draft.

--Sam
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind

[Sam Hartman]

 Jim == Jim Schaad i...@augustcellars.com writes:


Jim 3.  3.2.3 or 3.2.2 - If you had a non EAP method, and it
Jim derived a key (just like a good EAP method).  Is there any
Jim reason why you could not do the cryptographic binding?  Other
Jim than it is not currently defined in one of the current
Jim tunneling methods.  One could see that it could be defined as
Jim saying after you do this, then perform the same binding as any
Jim key deriving EAP method would do,.

I guess.  I don't know that key expert is really defined for the non-EAP
inners in a well-defined manner.  But yes, I think something like this
would be a good idea, although I'm not sure it is practical when
compared to just forcing EAP inner methods.

Jim 4.  Section 3.2.4 - Item #4 - did you mean that it MUST prevent
Jim an attacker from downgrading the binding from mutual to just
Jim MSK-based?  Also if the down grade occurs, do you still want to
Jim claim that it is still mutual if step 4 is downgraded?  The
Jim current text implies this to me and that seems wrong.

I'd love to discuss this with you in person if you're available.

Jim 5.  Section 3.2.4 - last paragraph - the last sentence confuses
Jim the heck out of me.

And everyone else; it's wrong:-)
Will propose fixes to this and other comments.

Jim 6. Section 4.2 - I don't understand why things like doing
Jim channel binding require that a mutual authentication be
Jim present.  I can understand a statement that the peer MUST have
Jim doing an adequate job of authenticating the server, but I am
Jim less clear why the server needs to have authenticated the
Jim client.  Thus for example I think that cryptographic binding
Jim should be sufficient to deal with these cases.  (i.e. Tunnel is
Jim authenticated to certificate and mutual auth is tied to the
Jim tunnel).

I think there's an assumption that EAP always provides peer
authentication (although sometimes to an anonymous identity, isn't
semantics fun?) so mutual auth and server auth are synonyms.

And draft-ietf-emu-chbind has required mutual auth since well before I
started working on it. I didn't re-evaluate that requirement.

Jim Jim


Jim ___ Emu mailing
Jim list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu