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
