Hi Daniel,
On the other hand, if later some new QSKE method appear, that
will have small enough public keys, so that it can be used in IKE_SA_INIT,
and IKE_AUX would be used for some purposes other then QSKE,
then again the key would not be known to attacker and there would be
no reason to restrict the choice of PRFs.
In this example, assuming that one is using a QSKE because they want quantum
safety, the PRFs will still have to be restricted simply because
PRF_AES128_XCBC and PRF_AES128_CMAC only provide 64 bits of protection against
a quantum computer.
Sorry, I should have been more clear. I meant that if tomorrow a new PRF
appears
that will provide 128 (or more) bits of security against quantum computers, but
will not be second preimage resistant in case of known key, then this PRF
can be used if IKE_SA_INIT key exchange uses quantum safe methods
and we change all-zero key to SK_pi/SK_pr. I didn’t mean PRF_AES128_XCBC/CMAC,
just some imaginary PRF with the same properties, but quantum safe.
So, my suggestions:
1. use SK_pi/SK_pr as keys for PRF that authenticate IKE_AUX messages
If using IKE_AUX in a non-QSKE use-case then any encrypted payload is already
protected by the encryption algorithm + integrity algorithm (or AEAD
encryption), but any unencrypted payloads + the IKE header wouldn’t be
protected using a 0 key, so your proposal sounds reasonable.
Good.
2. don't impose any restrictions on the choice of PRF in the IKE_AUX draft
(but probably write some words in the Security Considerations)
3. in QSKE document add a restriction on PRF choice, excluding those,
that a) are not secure in PQ world and b) are not secure against
preimage attack in case of known key.
Sounds reasonable, since in order to establish a QS SA there will have to be
restrictions on encryption/integrity algorithms anyways, with the caveat that
for encryption/integrity we only have to say “use something with 256 bits of
security”, whereas for PRF that wouldn’t be sufficient if for example
PRF_AES256_CMAC became a thing.
OK, if nobody disagrees, I’ll update IKE_AUX draft accordingly.
Regards,
Valery.
Any opinions? Scott, Daniel, what do you think about this?
Regards,
Valery.
All three work (that is, they prevent any undetected modifications to the
IKE_AUX payloads); I quite understand if (1) would be considered an
undesirable option. As for (2) and (3), they are largely the same; (3) limits
the PRF’s to the ones which include second-preimage-resistant hash functions.
I can see the attraction of not requiring a separate negotiation; I’m just
worried about someone ignoring our ‘don’t use XCBC/CMAC’ mandate…
Also, for (3), you have to be careful to specify which SK_p[ir] to use; in our
draft, the IKE_AUX message updates them; the obvious thing to do is specify
that you’ll use the SK_p[ir] values that were in effect at the beginning of the
IKE_AUX message in question. Actually, for security, we don’t need a secret
key, having both sides use, say, an all zero key, would achieve the same
security goal, however that does feel weird…
Using an all zero key does feel weird, however it could help avoid potential
incompatible implementation errors. There are two sets of SK_p[ir] available
to use in the case where an IKE_AUX includes a key exchange, the values in
effect at the beginning of the IKE_AUX exchange, and the updated values
resulting from the IKE_AUX exchange. Depending on the order in which
implementations recalculate the SKEYSEED and SK_* keys, vs when they perform
the PRF on the IXE_AUX data, the “current” SK_p[ir] values could be the old or
new values and so some implementations may have to maintain both the old and
new keys until the IKE_AUX digest is calculated. All this is to say, if it
doesn’t affect the security it may just be simpler and easier for compatibility
to use an all zero key.
Regards,
Valery.
Thanks,
Daniel
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
