Hi all,
The core mechanisms here seem in good shape. My main area of
uncertainty relates to how much analysis, and with what degree of
formalism, has been applied to the updated IKE_AUTH procedures that are
supposed to authenticate the intermediate exchange(s). My comments on
§3.3.2 have more details, but key questions include how we authenticate
how many rounds of IKE_INTERMEDIATE were performed, whether using the
plaintext of the Encrypted payload gives an attacker too much
flexibility, and whether we want to make any tweaks to "future-proof"
the construction in case we need some other exchange that occurs prior
to IKE_AUTH.
I'd also like to confirm that the current (lack of) Updates:
relationship between this document and RFC 7296 is correct. In §3.2, we
reaffirm that the normal IKE rules for assigning Message IDs apply, so
"it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next
(if any) and so on". But in §2.2 of RFC 7296 it is claimed that "the
first pair of IKE_AUTH messages will have an ID of 1, the second (when
EAP is used) will be 2, and so on", where we now have competing claims
about what exchange will get Message ID 1. I can see a case to be made
that neither of these statements is intended to be normative, and thus
that there is no conflict, but wanted to confirm that the WG had
considered this topic.
I see the shepherd writeup mentioned some missing articles ('a', 'the',
etc.). I took the liberty of making some edits in that space to a local
copy of the draft, which I will send to the author directly for him to
incorporate or ignore.
Section 3.2
If the presence of NAT is detected in the IKE_SA_INIT exchange via
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
notifications, then the peers MUST switch to port 4500 and send all
IKE_INTERMEDIATE exchanges using port 4500.
I think I see an equivalent requirement in §2.23 of RFC 7296 ("The IKE
initiator MUST check the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP payloads if present, and if they do not
match the addresses in the outer packet, MUST tunnel all future IKE and
ESP packets associated with this IKE SA over UDP port 4500."), since the
IKE_INTERMEDIATE exchanges would fall under "all future IKE packets".
So, does this need to be written in this was with normative MUST as if
it is a new requirement? Or should we rephrase slightly to reaffirm
that the existing requirement applies in this case?
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.
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.
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.
IKE_INTERMEDIATE exchanges took place). The prf is applied to the
the concatenation of two chunks of data: mandatory IntAuth_*_[I/R]_A
optionally followed by IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A
chunk lasts from the first octet of the IKE Header (not including
prepended four octets of zeros, if port 4500 is used) to the last
octet of the Encrypted payload header. The IntAuth_*_[I/R]_P chunk
I think this would be more precise as "the last octet of the generic
payload header of the Encrypted payload". We do go on to say that the
IV/etc. are not included, but that seems to be in the context of
computing the _P chunk, and may or may not be saying anything about
excluding it from the _A calculation.
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.
Section 3.4
DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe how
errors are handled in initial IKEv2 exchanges, these considerations
are also applied to the IKE_INTERMEDIATE exchange.
While the translation of the IKE_SA_INIT error handling to
IKE_INTERMEDIATE seems pretty straightforward, I wonder if we want to
say a little more about how the IKE_AUTH error handling applies. In
particular, I'm not sure if the portions about sending an
AUTHENTICATION_FAILED notification will ever apply. (The handling of
messages that contain an unsupported critical payload, on the other
hand, does seem like it would apply in a fairly straightforward manner.)
Section 5
Do we think there's a risk of IKE_INTERMEDIATE being used as a DoS
vector by way of causing a peer to retain a lot of state prior to
authentication? Perhaps that is more appropriate for the other
specifications that consume IKE_INTERMEDIATE.
attacker to mount Denial-of-Service attack. Moreover, if in this
situation the negotiated prf was not secure against preimage attack
with known key, then the attacker could forge the IKE_INTERMEDIATE
I think this would need to be a second-preimage attack, right? It's
probably worth clarifying.
Thanks,
Ben
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
