Paul Wouters writes: > What I take from this: > > - Maybe look at a new EAP method to prevent AUTH payload from the > server to be send before client is authenticated.
When we were designing IKEv2 we had long discussion about who should authenticate first. If the initiator authenticates first, that allows attackers to find out identity of the client / remote users, which might be more valuable than the identity of the server. The identity of the server is quiet often already known based on the IP-address. Making resopnder to authenticate first will allow attackers to do scanning of identities on the network, i.e., they can connect to hosts and do active connection and get the authenticated identity of the server. > - Implementations MUST reject weak PSKs that are easy to detect. To that to be MUST, it would require some specific methods to tell how you can detect weak PSKs. We already have: Note that it is a common but typically insecure practice to have a shared key derived solely from a user-chosen password without incorporating another source of randomness. This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. On the other perhaps we should think of moving Secure Password Framework for IKev2 (RFC6467) and ONE of the associated password authentication methods to standard track, and try to get people to implement them. If I remember right CFRG has now selected one augmented and one non-augmented PAKE, so perhaps we could simply say use them, but I have not checked whether we have either one of them defined for Secure Password Framwork (RFC6567) uses. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
