Re: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind
> "Jim" == Jim Schaad 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
> "Jim" == Jim Schaad 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
[Emu] Comments on draft-hartman-emu-mutual-crypto-bind
Sam et al, 1. In section 1 after the Classic Tunnel Attack figure, I believe there are three methods listed as possible mitigation strategies, however I don't understand how the second one - a sufficiently strong inner method - could possibly be a mitigation by itself. The three I see are 1) Policy 2) strong inner method 3) Cryptographic binding. 2. In section 3.2.2 - For the more traditional MITM attack. There is a requirement for this defense that the internal authentication methods are going to be able to support the cryptographic binding that you are postulating. If this is not true then this would not be a detectible attack. I think this should go into the paragraph before the diagram rather than being (kind of) implicit in the paragraph after the figure. 3. 3.2.3 or 3.2.2 - If you had a non EAP method, and it derived a key (just like a good EAP method). Is there any reason why you could not do the cryptographic binding? Other than it is not currently defined in one of the current tunneling methods. One could see that it could be defined as saying after you do this, then perform the same binding as any key deriving EAP method would do,. 4. Section 3.2.4 - Item #4 - did you mean that it MUST prevent an attacker from downgrading the binding from mutual to just MSK-based? Also if the down grade occurs, do you still want to claim that it is still mutual if step 4 is downgraded? The current text implies this to me and that seems wrong. 5. Section 3.2.4 - last paragraph - the last sentence confuses the heck out of me. 6. Section 4.2 - I don't understand why things like doing channel binding require that a mutual authentication be present. I can understand a statement that the peer MUST have doing an adequate job of authenticating the server, but I am less clear why the server needs to have authenticated the client. Thus for example I think that cryptographic binding should be sufficient to deal with these cases. (i.e. Tunnel is authenticated to certificate and mutual auth is tied to the tunnel). Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
