Subject: [IPsec] IKE_AUX comments

From: Daniel Van Geest <[email-masked]>
Date: Tue, 3 Jul 2018 16:06:22 +0000

Hi Valery, I have some comments on https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-aux-00

AUX_EXCHANGE_SUPPORTED:

   This specification doesn't define any data this

   notification may contain, so the Notification Data is left empty.

   However, other specifications may override this.  Implementations

   MUST ignore the non-empty Notification Data if they don't understand

   its purpose.

If there are multiple future specifications which use AUX_EXCHANGE_SUPPORTED, is it expected that multiple AUX_EXCHANGE_SUPPORTED notifications would be sent in IKE_SA_INIT?  I don’t know of any other notifications where there might be multiple copies sent in one exchange, not that this is a reason to avoid it, but it might be simpler to not introduce this possibility.  Also, if the data is simple/only a few bytes there’s a chance of ambiguity as to whether the data is defined by one specification or another.  I think it would be simpler if the notification data is just left empty (or left for IKE_AUX-specific data, see below).  Other specifications will have to define how their own features are negotiated, so any related data could be sent in the notifications for those specifications and doesn’t need to be sent in IKE_AUX.

Authentication:

   ICV_INIT_1, ICV_INIT_2, ICV_INIT_3, etc. represent the content of the

   Integrity Checksum Data field from the Encrypted payloads (or

   Encrypted Fragment payloads) from all the IKE_AUX messages sent by

   the initiator in an order of increasing MessageIDs (and increasing

   Fragment Numbers for the same Message ID).

AEAD encryption transform IDs don’t use an Integrity Checksum Data field in their Encrypted payloads, so this method won’t work for authentication of IKE_AUX exchanges when AEAD is used.

Additionally, Scott pointed out to me that Integrity Check Values aren’t designed to be secure against someone who knows the key (which would be the case for a Quantum-enabled attacker) and that for algorithms like GMAC the attacker would be able to find a collision.  So then your statement later:

   THe forgery would become evident in the

   IKE_AUTH exchange (provided the attacker caanot break employed

   authentication mechanism)
wouldn’t hold; an attacker could find a forgery with the same ICV and IKE_AUTH exchange would succeed.

But regardless of that, AEAD is a good enough reason why ICVs shouldn’t be used here.  Presumably you don’t want to include the whole data for the entire set of IKE_AUX exchanges in the signed octets because that would mean persisting the data for all IKE_AUX exchanges until IKE_AUTH is processed, requiring a lot of extra buffer state and increasing the attack surface for buffer exhausting?

A second-preimage-resistant hash function is needed to use a digest of the IKE_AUX messages in the signed octets.  This algorithm could possibly be negotiated in the AUX_EXCHANGE_SUPPORTED notification data.

Thanks,
Daniel

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 4 Jul 2018 11:59:17 +0300

Hi Daniel,

thank you for your comments. See responses inline.

AUX_EXCHANGE_SUPPORTED:

The idea behind this text was that IKE_AUX specification itself might be

enhanced at some point in the future, so that new negotiation would be needed.

Instead of introducing new notify payloads, the content of the AUX_EXCHANGE_SUPPORTED

could be used. So, it is not the specifications that use IKE_AUX exchange (e.g. QSKE)

that would use data of AUX_EXCHANGE_SUPPORTED for their purposes, it is some future

enhancement (if any) of the IKE_AUX specification itself that this text meant.

It was never intended that multiple AUX_EXCHANGE_SUPPORTED are present.

I see some ambiguity here. How about the following:

   However, future enhancements of this specification may override this.  Implementations

   its purpose.

 

Authentication:

Well, I agree that from theoretical point of view AEAD algorithms might not have separate ICV value.

However, all the widely used AEAD algorithms I’m aware of (GCM, CCM, GCM-SIV etc.) computes a separate

Authentication Tag and RFC5282 uses this Tag as ICV while describing how to construct 

Encrypted Payload with AEAD algorithms.

So, in my opinion, this construction can be used with all currently defined AEAD algorithms (unless I missed something). 

If you think we should generalized it to be applicable to any future AEAD algorithm, including those that don’t produce

a separate Authentication Tag, but spread authentication information across the ciphertext,

then I agree that a different construction is needed (e.g. see below).

OK I agree that for the current definition of how IKE_AUX is authenticated this statement is not accurate.

Exactly.

I’d rather to avoid using an additional algorithm. I think the negotiated PRF can be used for this purpose, can’t it?

InitiatorSignedOctets = RealMessage1 | AUX_I | NonceRData | MACedIDForI

AUX_I = PRF(SK_pi, AUX_INIT_MSG_1) | PRF(SK_pi, AUX_INIT_MSG_2)| PRF(SK_pi, AUX_INIT_MSG_3) ...

ResponderSignedOctets = RealMessage2 | AUX_R | NonceIData | MACedIDForR

AUX_R = PRF(SK_pr, AUX_RESP_MSG_1) | PRF(SK_pr, AUX_RESP_MSG_2)| PRF(SK_pr, AUX_RESP_MSG_3) ...

I used SK_pi/r instead of SK_ai/r here because their size fits the preferred key length

for PRF (that is not generally the case for SK_ai/r).

So, what do you think? Is this construction secure? 

Regards,

Valery.

Thanks,

Daniel

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 5 Jul 2018 04:00:22 +0000

From: Valery Smyslov <[email-masked]>
Sent: Wednesday, July 04, 2018 4:59 AM
To: 'Daniel Van Geest' <[email-masked]>; [email-masked]
Cc: Scott Fluhrer (sfluhrer) <[email-masked]>
Subject: RE: IKE_AUX comments

Hi Daniel,

Exactly.

My comment assumed that we were using IKE_AUX this way; we perform an initial key exchange during the IKE_INIT; this will generate keying material which we will use to protect the initial IKE_AUX message; then, we will perform a second key exchange during the IKE_AUX, which would be used to generate a second set of keying material; this will be used to protect the next IKE messages (which might be another IKE_AUX, or it might be the IKE_AUTH)..

If we assume an adversary that can break the initial key exchange while the protocol is running (e.g. it’s an (EC)DH exchange, and he has a fairly advanced quantum computer), then he can learn the SK_pi, SK_pr values.

The problem is that, with some PRF’s, if you know the key, you can find a second message with the same PRF value as a given message; hence our MITM would be able to introduce his own key shares, and leave the PRF value unmodified.  From the IANA PRF registry, all the HMAC-based PRFs would be safe (that is, make this attack infeasible, at least in real time), while PRF_AES128_XCBC and PRF_AES128_CMAC are not; given a 128 bit block within the message that the attacker can set arbitrarily, it is easy to find the setting to make the PRF value be whatever the attacker chooses (including the PRF of another message).  And, yes, this is a situation where MD5 is actually stronger than AES…

What could an attacker do with this capability?  Well, depending on the later key exchange, an attacker may be able to insert his own key shares in such a way that both sides obtain the same shared secret (that the attacker would know); this means that the attacker would have succeeded in listening in (as everything used to compute InitiatorSignedOctets and ResponderSignedOctets are exactly the same as in the non-MITM case)

There are some details that I’m omitting that may make this attack more difficult than I outlined; however I don’t believe we should depend on those details.

One thing we might consider to address this is limiting the PRF’s to those which disallow preimage attacks (even if the attacker knows the key); those would be HMAC-based (and KMAC-based if the WG actually defines such a PRF).

Regards,
Valery.

Thanks,
Daniel

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Jul 2018 15:43:40 +0300

Hi Scott,

thank you for clarification. Please, see inline.

Exactly.

 

Yes, that’s how I think it should work.

OK, I see the problem. My (false) premise was that PRF in general has stronger cryptographic properties than MAC,

but now I see that in situation when attacker knows key some PRFs behave badly regarding second-preimage resistance.

So, using PRF won’t really help here (if we’re talking about arbitrary PRF).

So, our options are:

1. Using IKE_AUX messages themselves:

InitiatorSignedOctets = RealMessage1 | AUX_INIT_MSG_1 | AUX_INIT_MSG_2 | AUX_INIT_MSG_3 ... | NonceRData | MACedIDForI

ResponderSignedOctets = RealMessage2 | AUX_RESP_MSG_1 | AUX_RESP_MSG_2 | AUX_RESP_MSG_3 ... | NonceIData | MACedIDForR

This approach has a disadvantage that implementation needs to keep all IKE_AUX messages 

(which might be quite large) until it receives IKE_AUTH, that increases vulnerability to DoS attack.

2. Using hashes of IKE_AUX messages (as Daniel proposed):

InitiatorSignedOctets = RealMessage1 | H(AUX_INIT_MSG_1) | H(AUX_INIT_MSG_2) | H(AUX_INIT_MSG_3) ... | NonceRData | MACedIDForI

ResponderSignedOctets = RealMessage2 | H(AUX_RESP_MSG_1) | H(AUX_RESP_MSG_2) | H(AUX_RESP_MSG_3) ... | NonceIData | MACedIDForR

where H is a collision-resistant hash function.

The problem with this approach is that it would require to add a new crypto primitive (hash),

that is not currently present in a set of negotiated parameters. So a new negotiation mechanism

would be needed (or a new Transform Type) and a new IANA registry. And all this would 

increase the IKE_SA_INIT messages size.

3. Using the PRFs as outlined above, but limiting PRFs to only those, which are preimage 

resistant even if key is known (as you proposed). From the current set of PRFs 

registered for IKEv2 in IANA this would leave out PRF_AES128_XCBC and PRF_AES128_CMAC, that 

don’t provide enough security in post-quantum world anyway (due to their 128 bit internal key).

Any other options? Any thoughts?

Regards,

Valery.

Thanks,

Daniel

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 5 Jul 2018 13:09:57 +0000

From: Valery Smyslov <[email-masked]>
Sent: Thursday, July 05, 2018 8:44 AM
To: Scott Fluhrer (sfluhrer) <[email-masked]>; 'Daniel Van Geest' <[email-masked]>; [email-masked]
Subject: RE: IKE_AUX comments

Hi Scott,

So, our options are:

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…

Regards,
Valery.

Thanks,
Daniel

---

From: Daniel Van Geest <[email-masked]>
Date: Thu, 5 Jul 2018 15:19:30 +0000

On 2018-07-05, 3:10 PM, "Scott Fluhrer (sfluhrer)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Scott,

So, our options are:

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 6 Jul 2018 16:21:23 +0300

So, our options are:

That’s a valid concern. But if somebody use XCBC/CMAC, then he/she won’t get enough QC protection anyway – 

with or without this attack. 

PRF(SK_p*, AUX_*_MSG) aren’t sent on the wire and are calculated only in IKE_AUTH.

It is possible to use SK_pi/r from the latest recalculation (when final SKEYSEED is available)

for authentication of alll previous IKE_AUX messages. So there is no such a problem. However, 

if security doesn’t depend on the key here, it’s probably easier to use all-zero key.

Note, that SK_ei/r and SK_ai/r are recalculated after each IKE_AUX exchange 

(more precisely – after each new key exchange performed in IKE_AUX). 

Regards,

Valery.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 6 Jul 2018 13:52:20 +0000

From: Valery Smyslov <[email-masked]>
Sent: Friday, July 06, 2018 9:21 AM
To: 'Daniel Van Geest' <[email-masked]>; Scott Fluhrer (sfluhrer) <[email-masked]>; [email-masked]
Subject: RE: IKE_AUX comments

PRF(SK_p*, AUX_*_MSG) aren’t sent on the wire and are calculated only in IKE_AUTH.
It is possible to use SK_pi/r from the latest recalculation (when final SKEYSEED is available)
for authentication of alll previous IKE_AUX messages.

Are you sure about that?  The reason we’re including a summary of the aux message in the Initiator/Responder Signed Octets (rather than including the entire aux) message was to avoid having to store the entire aux message until the IKE_AUTH is processed.  PRF(SK_p*, AUX) can’t be computed until we know the SK_p* key.  If we make that key the final SK_p key, we don’t know that until the final IKE_AUX is exchanged, that means that we’ll need to store the AUX messages (which is what we were trying to avoid).

So there is no such a problem. However,
if security doesn’t depend on the key here, it’s probably easier to use all-zero key.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 6 Jul 2018 17:04:42 +0300

You are right, it was my mistake.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 19 Jul 2018 10:14:51 -0400

Hi,

as it often happens, good thoughts come a bit late...

While I agreed before on using all-zero key for PRF and even 

put this into my yesterday's presentation, while keeping thinking

about the issue I came across a good reason to use SK_pi/SK_pr

instead of all-zero keys.

My reasoning is as follows. We define IKE_AUX as a more generic mechanism

for transporting large amount of data in initial IKE exchanges. 

While currently QSKE looks like primary application for this mechanism,

I can imagine that it can be applicable for other use cases too.

Then, while we all are waiting for appearing Quantum Computers

and are trying to be prepared to this, we really don't know when

it happens and whether it happens at all (the story of TOKAMAK

https://en.wikipedia.org/wiki/Tokamak is a good example of situation,

when engineering issues keep unresolved for decades).

So we can expect that at least for some period of time there 

will be applications that would not be concerned with Quantum Computers,

but they would probably use IKE_AUX. For such use cases we can assume that

initial shared keys computed as a result of IKE_SA_INIT are not known

to attacker, and if we use SK_pi/SK_pr as a keys for PRF, then there is no

reason to restrict choice of PRFs by excluding XCBC and CMAC.

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.

So, my suggestions: 

1. use SK_pi/SK_pr as keys for PRF that authenticate IKE_AUX messages

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.

Any opinions? Scott, Daniel, what do you think about this?

Regards,

Valery.

 

 

Regards,

Valery.

Thanks,

Daniel

---

From: Daniel Van Geest <[email-masked]>
Date: Thu, 19 Jul 2018 16:11:22 +0000

Hi Valery, opinions inline

On 2018-07-19, 10:14 AM, "Valery Smyslov" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

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.

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

Regards,
Valery.

Regards,
Valery.

Thanks,
Daniel

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 25 Jul 2018 16:03:13 +0300

Hi Daniel,

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: 

Good.

OK, if nobody disagrees, I’ll update IKE_AUX draft accordingly.

Regards,

Valery.

Regards,

Valery.

 

 

Regards,

Valery.

Thanks,

Daniel

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 25 Jul 2018 15:26:59 +0000

From: IPsec <[email-masked]> On Behalf Of Valery Smyslov
Sent: Wednesday, July 25, 2018 9:03 AM
To: 'Daniel Van Geest' <[email-masked]>; Scott Fluhrer (sfluhrer) <[email-masked]>; [email-masked]
Subject: Re: [IPsec] IKE_AUX comments

Hi Daniel,

So, my suggestions:

Good.

The reason that the ‘all-0-bits’ suggestion was put out there was an attempt to avoid confusion as to which SK_pi/pr keys to use (as they get updated in our draft after each QSKE IKE_AUX message).  If we expect that implementations will be able to handle it, then I see no reason not to use the current key values.

No disagreement here.

I do have one issue I’ve been pondering, though; we do an IKE_AUX exchange, and then follow it up with an IKE_AUTH exchange.  At least with my accent, those are phonetically quite close.  It would be nice if we could come up with an alternative name to IKE_AUX that was just as descriptive, but wasn’t such a near collision (and no, I don’t have any immediate suggestions).

Regards,
Valery.

Regards,
Valery.

Regards,
Valery.

Thanks,
Daniel

---

From: Daniel Van Geest <[email-masked]>
Date: Thu, 26 Jul 2018 01:39:33 +0000

On 2018-07-25, 5:27 PM, "Scott Fluhrer (sfluhrer)" <[email-masked]<mailto:[email-masked]>> wrote:

I have the same issue when discussing the draft.  Off the top of my head, IKE_PRE_AUTH could work.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 26 Jul 2018 10:17:58 +0300

Probably IKE_INT (intermediate)? Actually I was thinking of this name when started writing the draft...

IKE_PRE_AUTH sounds to me like it is somehow bound to authentication, while in fact it is multi-purpose

and can be used for transferring any additional data before IKE_AUTH...