Hi, > > - Maybe look at a new EAP method to prevent AUTH payload from the > > server to be send before client is authenticated.
If EAP is employed the server sends AUTH twice - first time before any EAP method starts and second time - at the end of EAP protocol. Are you suggesting not to send the first AUTH, so not pre-authenticate server to client before EAP starts? > 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, Strongly support. > and try to get people to implement We implemented 6467. > 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. These methods are CPace (balanced) and OPAQUE (augmented). None are defined for 6467 yet. Moreover, both are not yet published as RFC. Regards, Valery. > -- > [email protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
