Hi Ben, > Trimming as appropriate...
Further trimming... > > > In a similar vein, it would be good to see some more formal analysis > > > that confirms that this construction authenticates the number of > > > intermediate exchanges that have occurred. I am not sure that I could > > > sketch an attack that uses such a mismatch, but if we are using a threat > > > model where IKE_INTERMEDIATE is used to provide protection against a > > > quantum computer that could break the initial IKE_SA_INIT key exchange, > > > it seems like we need to be sure to protect against "truncation" attacks > > > that cut the quantum-resistant key-exchange out of the authenticated > > > transcript. > > > > I agree that formal analysis would be good to have for this situation. > > > > Informally, if we are talking about draft-ietf-ipsecme-ikev2-multiple-ke, > > then the SK_p* keys used for calculation of AUTH payload will depend > > not only on IKE_SA_INT, but on all subsequent (presumably quantum safe) > > key exchanges. And the peers always know how many IKE_INTERMEDIATE > > exchanges should take place (as a result of negotiation done in the > > IKE_SA_INIT). > > Of course, an attacker in the middle can play a downgrade attack by > > modifying IKE_SA_INT so, that no quantum safe key exchanges are proposed > > (or accepted), > > but in this case the peers will follow local policy - if it allows quantum > > unsafe > > key exchanges to take place, then it cannot be helped. > > Just to confirm: the peers negotiate how many additional KEs to run, which > is expected to also be the number of IKE_INTERMEDIATE exchanges, but could > be smaller if IKE_INTERMEDIATE is also used for some other > (as-yet-undefined) purpose in the same association. Yes, exactly. > > If we are talking about other applications of IKE_INTERMEDIATE (not > > concerned > > with quantum safe cryptography), then it is possible that an attacker > > equipped with quantum computer to break the authentication, but this is also > > true for the current IKEv2 specification, when IKE_INTERMEDIATE is not used. > > To reiterate on my reply to Tero, I'm thinking about the robustness of the > system overall -- e.g., if we assume a highly capable attacker that can do > many things we don't currently believe possible, like break DH and find > certain types of hash collision, do we have a mechanism in place to ensure > that the initiator and responder use transcripts of the same length? > The point is not that we expect an attacker with such capabilities to > appear, but rather to consider various aspects of the negotiation and > confirm that we have a specific mechanism in the AUTH construction that > protects that aspect of the negotiation. It is expected, that peers will negotiate new extensions which make use of IKE_INTERMEDIATE, so in general they will know how many the IKE_INTERMEDIATE exchanges would take place. However, I'd rather leave some flexibility here. See for example draft-smyslov-ipsecme-ikev2-qr-alt, where using IKE_INTERMEDIATE is optional on the Initiator's discretion. We can modify the calculation as you suggested in reply to Tero by appending MessageID of IKE_AUTH exchange at the IntAuth: IntAuth = IntAuth_1 [| IntAuth_2 [| IntAuth_3 ... ]] | MID_IKE_AUTH Do you think it is enough? > > If the WG thinks that it's worth to do this modification, then > > we may also consider addressing the following issue, > > raised past WGLC by Tobias Brunner: > > https://mailarchive.ietf.org/arch/msg/ipsec/8kM6GoPeJwjuoxSH4CL4B75ZJMk/ > > > > The WG reaction at that time was that the issue is minor and > > no modification is needed, but _if_ we decide to incorporate > > Ben's modification, then we can address this issue too. > > My instinct is to retain the current construction, but I don't remember > enough about previous times that this class of construction has come up to > be able to give a good reasoning for why. (I don't even remember if this > type of thing came up in TLS, or SAAG, or elsewhere.) Perhaps there was > some concern about some intermediate step being flawed or attacked so as to > bias the distribution of that intermediate value, thereby weakening the > authentication of the previous iterations, but I really don't remember for > sure. Should we ask cryptographers to review it? > > > is present if the Encrypted payload is not empty. It consists of the > > > > > > (editorial) I'd recommend including some keyword to provide a mnemonic > > > for the _A and _P suffixes for these intermediate values. > > > > The initial idea behind _A and _P was _A[AD] and _P[AYLOAD]. > > The _A chunk scope is equal to AAD for AEAD algorithms > > and the _P scope is just a content of Encrypted Payload > > before encryption. But then it was figured out that the lines > > with formulas become too long and don't fit into RFC text format > > limitations. So, the names were truncated in favor of formulas readability. > > If you have good suggestions how to make these values > > look more friendly, it'll be great. > > My suggestion would just be to add a new sentence (before "The > IntAuth_*_[I/R]_A chunk lasts from [...]"): "The IntAuth_*_[I/R]_A chunk > covers the data that is the AAD input to AEAD algorithms protecting the > Encrypted Payload, and the IntAuth_*_[I/R]_P chunk covers the plaintext > input to such algorithms. It's not great writing, but it will probably get > the job done. This is not accurate wording. First, although AEAD algorithms are in fashion now, the IntAuth_*_* construction doesn't rely on them, so it's not correct in my opinion to mention AAD here. Yes, IntAuth_*_[I/R]_A covers what AAD for AEAD is, but if non-AEAD algorithm is used, then AAD is undefined, but IntAuth_*_[I/R]_A still have the same scope. And second, IntAuth_*_[I/R]_P is not equal to the plaintext for AEAD, since the plaintext would also include Padding and Pad Length fields which are excluded from IntAuth_*_[I/R]_P. How about: The IntAuth_*_[I/R]_A chunk covers the data that would be the AAD input to AEAD algorithms should they be used for protecting the Encrypted Payload (regardless of whether they are actually used), and the IntAuth_*_[I/R]_P chunk covers the plaintext input to such algorithms stripped of the Padding and the Pad Length fields. Does this text helps or only adds confusion? Regards, Valery. > Thanks, > > Ben _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
