Paul Wouters writes: > 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.
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. It is same as we do not update the ESP replay counter unless the packet actually has valid authentication token. And this was the exact issue the 802.15.4 had with encrypt only mode, i.e., with encrypt only mode there was no authentication tag, so the responder was always required to assume packet is valid, and then it updated the global frame counter of the sending device, and if attacker sent frame counter of 0xfffffffe, that effectively locked the sending device out permanently. This is the reason encrypted only mode was removed in the 802.15.4-2015.... 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... > Not announcing PPK support would not help much, as sending obvious > offsets would still be detectable. Yep. > Is there a way to securely use the same OTP ofset until AUTH is > successful? Yes. This is what all OTP methods do. If you give wrong value for OTP token, they will ask the same value over and over again until you get it right. In addition to that they usually add longer and longer delays if you get it wrong several times in the row and finally lock you out. They might even give you information saying that you typed OTP response for number 15, but current response number required is 16. For example the bank in Finland which uses OTP tokens does that, but only if you give correct response to the number that was already used. They also say that if you have completely lost the number where you are, type in the last number in the list, and they will then tell you what number is the next number on the list (I assume they will then mark the last number used, and next time ask for second last number etc). > > 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... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
