On Tue, 4 Apr 2017, Tero Kivinen wrote:
N(PPK_SUPPORTED) -->
For example if the PPKs are taken from the 1GB one-time-pad file
shared by the peers (one file per user), then the ppk_id could simply
be 32-bit offset to the file, and the external PPK management module
would keep track which of the offsets are used and which are not.
This is vulnerable to a DOS attack though. The attacker once inserts
themselves to get IDi. Then they connect to the server often enough
with increased offsets to fail authentication, depleting the
one-time-pad file for the real user, who presumbly then is locked out.
Not announcing PPK support would not help much, as sending obvious
offsets would still be detectable.
Is there a way to securely use the same OTP ofset until AUTH is
successful?
The NULL authentication (RFC7619) is logically incompatible with this
(it being opportunistic and this requiring configuration), so I think
we can say this will not be used with it. Or we can just say that can
be used, and SK_pi are used as specified here and in the RFC7619...
I would just say don't use both :)
That would be one option too. I.e., only modify SK_pr. I think it
actually would be enough, as we do trust the other end to do correct
things, and this would be enough to know whether peers share the same
PPK. On the other hand we will end up annoying case where the
initiator will know that PPK is wrong after the IKE_SA has already
been properly installed on the responder, thus initiator needs to
signal this with separate INFORMATIONAL exchange to the responder, and
thne delete IKE SA. I think the option I explained above is better.
Not a fan of this :)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
