>>>>> "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
