On Sep 8, 2014, at 2:17 PM, Paul Wouters <[email protected]> wrote: > On Mon, 8 Sep 2014, [email protected] wrote: > >> Maybe. >> >> I understand and support the rationale for this draft. >> >> The Security Considerations seems to be inadequate. Whenever possible, real >> authentication should be used. So the Security Considerations should >> explicitly and strongly emphasize that, and recommend that products that >> incorporate Null authentication should strive to avoid its use whenever >> possible, and steer users away from its use when they can. > > I think that is better formulated as "use null authentication only if the > alternative is to send plaintext”.
That is a very good way to state it. Thanks. >> A related question: does the use of Null authentication open up the Bellovin >> attack? It seems that it would. If so, my answer changes to “NO”. > > I find multiple references to a "Bellovin attack", but all seem to be active > attacks. Unauthenticated connections are not protected from active attacks. > However, with IKE one peer can authenticate the other without letting itself > be authenticated - like TLS clients. That _is_ a protection against > active attacks while still using null auth in one direction. I was referring to https://www.cs.columbia.edu/~smb/papers/badesp.pdf . The existing security considerations section refers to a man in the middle attack. Bellovin’s attack is not a man in the middle attack. It does not require being able to modify the data stream under attack at all. For that reason, it is likely to be easier to execute and harder to detect. In any event, if we’re going to have a new IPSec mode that weakens the normal properties of IPSec, we need to be very explicit and very detailed about what precisely you lose by using this mode. I would expect a security considerations section that takes up at least half the total page count of the document, as opposed to just a third of a page as it is right now. For example, right now the security considerations section does NOT say that “Unauthenticated connections are not protected from active attacks”. It only says that they are not protected from man in the middle attacks. paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
