On Wed, 5 Apr 2017, Tero Kivinen wrote:
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.
Nope. Like normally you are not using the data in the file unless it
is properly authenticated. I.e. even if the attacker can say use PPK
from offset 0x123123, the other end will not update the offset
0x123123 to be used unless the other end also proofs it knows the PPK
at that offset.
That opens up an attack where an attacker can trick you into re-using
the same PPK many times. I was assuming that could be dangerous in
itself? If it is not, then we should clearly explain that in the
document.
And the real user will most likely be locked out earlier because when
the attacker starts to do several tens of million IKE connections to
the server the server will most likely lock the user out or add
delays to connections long before the attacker is able to deplate the
one time pad...
If the attacker can lock out the real user, that is also a DOS attack :)
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 :)
Good. I was scared you might say, that of course we need to be able to
use NULL authentication with quantum protection...
My intention is to create so much AUTH_NULL IKE that I really hope the
TLA's cannot store all that ESP traffic to decrypt it with their fancy
new quantum computer in five years :)
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
