On Wed, 15 Nov 2023, Valery Smyslov wrote:
- 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?
I don't know. As Tero said:
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.
But if the EAP method could run in a way that the initiator can detect a
wrong EAP server before revealing itself in a way that wouldn't return
a signed AUTH message from the server, there might be value in that.
Although it might just move the problem to the AAA server that might
suffer the same faulty signature bug ?
- 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.
We also talked about that before. A truly strong random PSK is much
stronger than a PAKE. Pushing people to use PAKE might in many cases
decrease the security strength as well. So we cannot get rid of PSK,
so it seems advise to "use PAKE not PSK" will have the same effect
as "don't use weak PSKs" which clearly is not working. Which is why
I feel perhaps at loading time of PSKs, my implementation should reject
certain obviously weak PSKs. On systems using PSKs, we don't tend to
have 1000s of these, just a few. We can spend some CPU cycles on these.
and try to get people to implement
We implemented 6467.
For users to authenticate with a password, I think EAP methods are far
more common. eg EAP-mschapv2, which you can ask the RADEXT group has
its own set of horrible security features (eg if the EAP messages are
not themselves encrypted to the AAA server).
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.
We can work on adding these, but I feel that IKE implementations kind of
need to force that a minimum length PSK cannot be used without a PAKE.
Otherwise we just add another unused feature without solving anything.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
