Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07

[Benjamin Kaduk <[e-mail]>]

Hi Valery,

Trimming as appropriate...

On Tue, Jan 11, 2022 at 05:55:45PM +0300, Valery Smyslov wrote:
> 
> > Section 3.3.2
> > 
> >    The requirement to support this behavior makes authentication
> >    challenging: it is not appropriate to add on-the-wire content of the
> >    IKE_INTERMEDIATE messages into the AUTH payload calculation, because
> >    peers generally are unaware in which form other side has received
> >    them.  Instead, a more complex scheme is used - authentication is
> >    performed by adding content of these messages before their encryption
> >    and possible fragmentation, so that data to be authenticated doesn't
> >    depend on the form the messages are delivered in.
> > 
> > The behavior of using the pre-encryption form of the messages in the
> > authentication seems to merit some closer inspection, as it opens up an
> > avenue for the attacker to modify what bits are authenticated as they
> > traverse the network.
> > 
> > On first look, since the encryption is done using keys negotiated in the
> > IKE_SA_INIT exchange, which is itself subject to IKE_AUTH
> > authentication, any tampering with the encrypted payloads would require
> > tampering with the IKE_SA_INIT exchange (so as to have access to the key
> > material needed), which would in turn be detected at time of IKE_AUTH.
> > But it would be reassuring to know that some more formal analysis has
> > been performed on this scenario.
> 
> I'm not aware of any formal analysis (nor did it myself). 
> Some analysis and vetting of the current construction was done by Scott Fluhrer and Daniel Van Geest:
> https://mailarchive.ietf.org/arch/msg/ipsec/n0QysCUXfgYUddrtWxtiEKvLqh4/

Thanks for the link!  Yoav, could you update the shepherd writeup to
mention this thread?

> > 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.

> 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.

> >    If any IKE_INTERMEDIATE exchange took place, the definition of the
> >    blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is
> >    modified as follows:
> > 
> >    InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth
> >    ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth
> > 
> > This sort of construction invites ambiguity if there is ever some other
> > future exchange that wants to go between IKE_SA_INIT and IKE_AUTH.  This
> > seems like a strong argument in support of the approach this draft
> > takes, i.e., make IKE_INTERMEDIATE fully generic, so as to minimize the
> > chance of needing such an additional future exchange.  That said, it
> > might be possible to slightly improve the future-proofing if we included
> > an indicator of what the "next content" after MACedIDFor[IR] is, such as
> > the one-octet encoding of the exchange type.  (I think it would have to
> > be part of IntAuth_N, not IntAuth itself.)  I don't have a great sense
> > for whether the value this adds would be worth the disruption to
> > existing implementations, though.
> 
> 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.

> And even if we decide to leave it out, some words should be added to 
> Security Considerations section anyway, I'll do it.

Sounds good.

> >    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.

Thanks,

Ben