Hi Scott, > > Would it be reasonable to create some token/nonce from something before > > the PPK is mixed in such that we could recognize the different AUTH > > FAILUREs, or does that create too much of an oracle for testing PPKs? > > I believe that would be reasonable. We already exchange notifies between the > two sides (to allow both > sides to know whether or not we're using a PPK); the obvious mention would be > if the notifies included > PRF( PPK, "fixed value" ).
That's similar to what I suggested in https://www.ietf.org/mail-archive/web/ipsec/current/msg11058.html (my proposal only used nonces instead of "fixed value" to decrease traceability of PPK, if it is ever important). > As for an Oracle, I don't believe that would present a problem; the general > assumption is that PPKs have > enough entropy to be completely unguessable (and if that's assumption is > wrong, this doesn’t make it any > worse). In any case: > - With the current protocol, an active attacker can already determine > whether a guess of the PPK is > correct (assuming they're the side that first receives an encrypted message > after we stir in the PPK, it can > obviously try different PPKs to see which one allows a plausible decryption). > - With this protocol extension, a passive attacker could plausibly > determine whether the connection > failed due to a PPK mismatch or something else (presumably, the > implementation will react differently due > to the two error modes). It's not at clear whether that leaks any > interesting information; the only way that > an attacker could induce a PPK mismatch on properly configured systems is by > messing with the ID > payloads (PPKs are selected based on the ID payloads), and one would hope > such a modification would > cause a failure earlier. > > So, what does the WG think? Would doing something like this (to allow both > sides to determine a PPK > mismatch vs. some other failure) be important? Would the informational > leakage be a concern? Yes, it is important. Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
