Hi Rebecca, We ended up going with IKE_SA_INIT_FULL_TRANSCRIPT_AUTH: https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-01.html#section-6-1
I do have a concern with the “IKE_SA_INIT” portion of the Notify Payload > name. In the case where peers use IKE_INTERMEDIATE to perform an additional > key establishment, I find it confusing that the Notify Payload name refers > only to the IKE_SA_INIT exchange and not IKE_INTERMEDIATE, though both > exchanges would be included in the transcript. > > > Is there a way to make it clear that all pre-IKE_AUTH messages are > included in the transcript, and not just IKE_SA_INIT? Something like > PRE_IKE_AUTH_FULL_TRANSCRIPT_AUTH? Or AUTH_WITH_PRE_IKE_AUTH_TRANSCRIPT? > I believe that's correct: if RFC 9242 authenticates the entire transcript for intermediate exchanges, then draft-ietf-ipsecme-ikev2-downgrade-prevention would fill the gaps in the initial exchange, and you would have coverage all exchanges prior to IKE_AUTH. However, given how extensible IKEv2 is, it may be wise to avoid setting the expectation that implementing this draft is sufficient to have full transcript authentication. Imagine a new extension is defined that specifies a new exchange. Hopefully the extension's designers would decide to authenticate those messages, but this can't be enforced by this draft or the core IKEv2 protocol. The extension itself would have to specify this. Given this possibility, my preference would be to name the extension in a way that is specific to the problem being solved: we're patching an authentication issue in the initial exchange. Chris P.
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
