Subject: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Aug 2017 22:16:08 -0400 (EDT)

Hi,

Vukasin Karadzic is working on implementing draft-fluhrer-qr-ikev2
for libreswan and stumbled upon a problem. The relevant text:

    When the initiator receives this reply, it checks whether the
    responder included the PPK_SUPPORT notify.  If the responder did not,
    then the initiator MUST either proceed with the standard IKE
    negotiation (without using a PPK), or abort the exchange (for
    example, because the initiator has the PPK marked as mandatory).  If
    the responder did include the PPK_SUPPORT notify, then it selects a
    PPK, along with its identifier PPK_id.  Then, it computes this
    modification of the standard IKE key derivation:

A responder answering an IKE_INIT containing PPK_SUPPORT needs to
reply without knowing for which connection this IKE_INIT will be.

The responder has not yet received the initiator's ID. If the responder
has some connections that require a PPK and some connections that
require NO PPK, then it has to flip a coin on whether or not to send
the PPK_SUPPORT notify and if it guessed wrong, the AUTH payload on
the initiator will be wrong. Sending the notify commits to using a PPK
because the initiator uses it as input to the AUTH payload.

So this table from the RFC is incomplete:

    This table summarizes the above logic by the responder

  Received PPK_SUPPORT  Have PPK   PPK Mandatory    Action
  ------------------------------------------------------------------
       No                  No          *            Standard IKE protocol
       No                 Yes         No            Standard IKE protocol
       No                 Yes        Yes            Abort negotiation
      Yes                  No          *            Standard IKE protocol
      Yes                 Yes          *            Include PPK_SUPPORT

Basically, we are in the case where "Have PPK" is not yet known.

One way of solving this could be to allow PPK_SUPPORT to have some
notify data, which could for instance be a hash of the connection/group
name used by the responder. Another option is to use the PPK as one
of the inputs to some hash algorithm as PPK_SUPPORT data, so the
responder can go through its list of PPKs to match it back to a
connection/group. But we would need to be sure that this does not
open up the PPK to attacks (classic and quantum)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Aug 2017 16:48:55 +0300

>   Received PPK_SUPPORT  Have PPK   PPK Mandatory    Action

I think the discussion earlier was that we solve this by policy, where
responder is configured BEFORE initiator. I.e., if responder sees
initiator that says PPK is supported (meaning initiator has PPK) then
responder is safe to assume that it has also been configured PPK for
that ID. Anyways if this guess turns out to be wrong, it can then
fail the exchange later, and mark that peer as not having PPK when it
reconnects, i.e., add peer IP-address to temporary list saying that if
connection comes from this IP-address, and says it has supports PPK,
we do not have PPK for it, so fall back to standard IKE.

Anyways this kind of text needs to be added to the protocol draft.

I do not like to make this document any more complicated than what is
required, as I like to get this document out so it can be implemented,
even when we know there are some corner cases which require manual
configuration.
-- 
[email-masked]

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 17 Aug 2017 14:19:11 +0000

> -----Original Message-----
> From: Paul Wouters [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2017 10:16 PM
> To: [email-masked] WG
> Cc: Scott Fluhrer (sfluhrer); Vukasin Karadzic
> Subject: draft-fluhrer-qr-ikev2 AUTH issue
> 
> 
> Hi,
> 
> Vukasin Karadzic is working on implementing draft-fluhrer-qr-ikev2 for
> libreswan and stumbled upon a problem. The relevant text:
> 
> A responder answering an IKE_INIT containing PPK_SUPPORT needs to reply
> without knowing for which connection this IKE_INIT will be.
> 
> The responder has not yet received the initiator's ID. If the responder has
> some connections that require a PPK and some connections that require NO
> PPK,

We never envisioned a situation where you would deliberately chose not to use a PPK.  Can we replace this with a situation where you don't know whether you share a PPK with the initiator?

> then it has to flip a coin on whether or not to send the PPK_SUPPORT
> notify and if it guessed wrong, the AUTH payload on the initiator will be
> wrong. Sending the notify commits to using a PPK because the initiator uses
> it as input to the AUTH payload.
> 
> One way of solving this could be to allow PPK_SUPPORT to have some notify
> data, which could for instance be a hash of the connection/group name used
> by the responder.
> Another option is to use the PPK as one of the inputs to
> some hash algorithm as PPK_SUPPORT data, so the responder can go
> through its list of PPKs to match it back to a connection/group. But we would
> need to be sure that this does not open up the PPK to attacks (classic and
> quantum)

That's what we did in our original proposal (actually, it was a function of the PPK itself).  The problems with that were:

- If we made it a nondeterministic function (that is, include a randomizer), then the server had to do a linear scan over all their known PPKs to find the matching one.

- If we made it a deterministic function, then someone listening in can trivially determine when we're reusing the same PPK

(There's also a minor issue of "which hash function to use"; we haven't negotiated any at this time).

A linear scan over possibly 10,000 PPKs was considered unacceptable.  One of our proposals even allowed the server to specify the trade-off between the above two; that was considered too complex.

I'm not thrilled with Tero's answer of "lets be careful about the order we upgrade things in complex networks", but I don't know how to better solve it without adding lots of complexity to the protocol, potential anonymity leaks or requiring significant computation on the server side.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 17 Aug 2017 22:44:22 +0000

Good point Paul. The issue will also hold for an initiator. The initiator might have PPK enabled with other peers but not have a PPK_id configured for a responder after he gets her IKE_INIT response with N(PPK_SUPPORT) included. Practically the N(PPK_SUPPORT) is dictated by a global PPK support configuration on the initiator and responder, but that does not mean a PPK is configured for all their peers.

As Tero and Scott suggested, for the shake of simplicity it makes sense to tighten the text with normative language to make it clear to an implementer. For an initiator with PPK enabled but no PPK_id, regular IKE should be included in the initiators IKE_AUTH message. For the responder, imo a failure should occur after the initiator's IKE_AUTH if a PPK_id doesn't exist and PPK is enabled in the responder. And optionally the responder could add the initiator in a no_PPK_supported local cache.  

Rgs,
Panos

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Paul Wouters
Sent: Wednesday, August 16, 2017 10:16 PM
To: [email-masked] WG <[email-masked]>
Cc: Vukasin Karadzic <[email-masked]>; Scott Fluhrer (sfluhrer) <[email-masked]>
Subject: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

Hi,

Vukasin Karadzic is working on implementing draft-fluhrer-qr-ikev2 for libreswan and stumbled upon a problem. The relevant text:

A responder answering an IKE_INIT containing PPK_SUPPORT needs to reply without knowing for which connection this IKE_INIT will be.

The responder has not yet received the initiator's ID. If the responder has some connections that require a PPK and some connections that require NO PPK, then it has to flip a coin on whether or not to send the PPK_SUPPORT notify and if it guessed wrong, the AUTH payload on the initiator will be wrong. Sending the notify commits to using a PPK because the initiator uses it as input to the AUTH payload.

One way of solving this could be to allow PPK_SUPPORT to have some notify data, which could for instance be a hash of the connection/group name used by the responder. Another option is to use the PPK as one of the inputs to some hash algorithm as PPK_SUPPORT data, so the responder can go through its list of PPKs to match it back to a connection/group. But we would need to be sure that this does not open up the PPK to attacks (classic and quantum)

Paul

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Aug 2017 11:26:55 -0400 (EDT)

On Thu, 17 Aug 2017, Tero Kivinen wrote:

> responder is configured BEFORE initiator.

I thought about this a few times, and after some discussions with
myself, I agree that you are right.

> I.e., if responder sees

That is a terrible hack. It will likely not work well with NAT, when
the client mind end up with a new exchange on a different NAT port,
so you cannot tell whether this is 1 client behind NAT or 2 clients
behind NAT. But I see how we can just call this a "misconfiguration"
and I don't mind it not working.

> Anyways this kind of text needs to be added to the protocol draft.

Yes.

So I agree with Tero. And I guess our code is already doing this.

Paul

---

From: Derrell Piper <[email-masked]>
Date: Fri, 18 Aug 2017 13:56:27 -0700

Notes on draft-fluhrer-qr-ikev2-04, mostly nits:

pp. 1
"...pose a serious challenge to cryptography algorithms [deployed?] widely today."

pp. 2
"when might one be implemented" -> "when one might be implemented"

pp. 3
The Changes section wording confuses me.  Does that mean, relative to the last draft?  Or 
does it mean those were the change in -03?

pp. 4
"...then it must check if has a..." -> "...if it has a..."

pp. 8

"Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin"

RE: rfc6030, any chance we can not refer to an RFC with XML in it?  I strongly
object to XML.  Does IKEv2 reference any XML?  (sticks fingers in ears...)

pp. 9

RE: rfc6023 text

I would prefer text here that suggests exactly how to achieve post-quantum ID
confidentiality.  This is vague and that means people will implement it all
over the map.  I also don't think Child SAs should ever have been made
mandatory, so refering to rfc6023 is fine.

Overall, I think this document should advance.  This is nice and simple, more
or less.

Derrell

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Mon, 21 Aug 2017 09:46:02 +0000

Hi Paul

I’m a bit late to the party, but thought I’d chip in if it helps..

With regards to ‘If the responder has some connections that require a PPK and some connections that require NO PPK, then it has to flip a coin on whether or not to send
the PPK_SUPPORT notify and if it guessed wrong’

If you follow the logic below (I sent the following to Scott back in the day) with the GW (or responder) being configured with the PPK’s for the initiators first, then the initiators being configured and ONLY sending the PPK supported when it has a key for the peer you should be ok.

cheers

I would like to propose the following;
- Step 0 is "never use PPKs" (this is the existing IKE standard)

- Logic 1 is “if we are initiator only advertise PPK notify if we have a PPK for the peer”

- Step 1 is "if we're the initiator, then use PPKs if the responder signaled support for it"

    - Step 2 is "insist on PPKs if the peer support it (in both the initiator and the responder roles)"

So for a remote access VPN GW, you would configure the GW first and then each client. The GW will only respond with the PPK notify if the client had included the PPK notify. Once the client has the PPK it will include the PPK notify and pass authentication.

Likewise for Hub and Spoke, the same principle.

The issue I would foresee is something like DMVPN or a partial/full mesh, but my logic mitigates any issues.. the Hub has the PPK and Spoke 1 has the PPK.. The Spoke1 – Hub SA is protected by the PPK. If Spoke2 did not have a PPK and connected to the Hub, the Spoke2 – Hub is not PPK protected, then Spoke1 connected to Spoke2, because of the logic (“if we are initiator only advertise PPK notify if we have a PPK for the peer”) Spoke1 would not advertise the PPK notify and hence we get over this limitation.

Now where this falls down is if there’s a shared key, so in the example above is all spokes used a shared key and one of the spokes didn’t have it – then the logic would fail.

On 17/08/2017, 03:16, "IPsec on behalf of Paul Wouters" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    

    

    
    Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 21 Aug 2017 17:24:45 +0300

Hi Scott, 

> > it as input to the AUTH payload.

[...]

> - If we made it a nondeterministic function (that is, include a randomizer), then the server had to do a linear
> scan over all their known PPKs to find the matching one.
> 
> A linear scan over possibly 10,000 PPKs was considered unacceptable.  One of our proposals even allowed the
> server to specify the trade-off between the above two; that was considered too complex.
> 
> I'm not thrilled with Tero's answer of "lets be careful about the order we upgrade things in complex
> networks", but I don't know how to better solve it without adding lots of complexity to the protocol, potential
> anonymity leaks or requiring significant computation on the server side.

One (relatively) simple solution would be the following.

If initiator is configured with PPK, but at the same time its policy marks using PPK as optional,
then the initiator can send two authenticators - one using SK_pi' and the other using SK_pi
(where SK_pi = prf(PPK, SK_pi')). The one, computed using SK_pi (where PPK is involved) is placed in
AUTH payload, and the other, computed using SK_pi' (without PPK) is placed in 
a new optional status notification NO_PPK_AUTH.

   Initiator                       Responder
   ------------------------------------------------------------------
   HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2, TSi, TSr, 
       N(PPK_IDENTITY)(PPK_id), 
      [N(NO_PPK_AUTH)(auth_data)] }  --->

When responder receives this message and cannot find the corresponding PPK based on PPK_id and is configured
to allow PPK-less SA, it can still authenticate initiator by using the content of NO_PPK_AUTH. 
In this case the Responder replies with the IKE_AUTH response lacking PPK_IDENTITY to let the initiator
know that AUTH payload is computed as per RFC7296 (using SK_pr', i.e. without using PPK).

<---   HDR, SK {IDr, [CERT,]
       AUTH, SAr2, TSi, TSr} 

If the responder has the corresponding PPK, then it computes its AUTH payload using 
SK_pr and includes PPK_IDENTITY notification:

<---   HDR, SK {IDr, [CERT,] 
       AUTH, SAr2, TSi, TSr, 
       N(PPK_IDENTITY)(PPK_id)} 

This solution allows peers to communicate in different settings and to enforce their own policy.
For instance, if the initiator is configured to always use PPK, it won't include 
NO_PPK_AUTH at all. If responder is configured to always use PPK, it will just ignore
NO_PPK_AUTH and return AUTHENTICATION_FAILED in case the proper PPK is not found.

Regards,
Valery.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 22 Aug 2017 16:58:51 +0000

Valery,
It is a good idea. A new optional notification that includes the auth_data as it would be calculated without the PPK would work. With that, the corner case of ' PPK_id configured on initiator but missing on the responder' is addressed. There is an additional cost of the extra notification message for every initiator that has no-mandatory ppk configured for the responder. In the worst case scenario the responder would need to go through looking up the PPK_id and if that fails then authenticate the auth_data. Even though it is slightly more work for the responder, I don't consider that heavy processing that would introduce attack concerns. 

My concerns is that we might be making it too complicated by potentially introducing two separate SK_p's. From an ops perspective, if we stated the rule that when we want to go postquantum a PPK should be populated on the responder first as Graham and others suggested, then the extra complication of a new notification can be avoided. Violation of that rule would lead to IKE_AUTH failure for that initiator only.

Vukasin,
Any thoughts from an implementer's standpoint? 

Panos

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Monday, August 21, 2017 10:25 AM
To: Scott Fluhrer (sfluhrer) <[email-masked]>; 'Paul Wouters' <[email-masked]>; [email-masked]
Cc: 'Vukasin Karadzic' <[email-masked]>
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

Hi Scott, 

> > notify and if it guessed wrong, the AUTH payload on the initiator 
> > will be wrong. Sending the notify commits to using a PPK because the 
> > initiator uses it as input to the AUTH payload.

[...]

> > notify data, which could for instance be a hash of the 
> > connection/group name used by the responder.
> > Another option is to use the PPK as one of the inputs to some hash 
> > algorithm as PPK_SUPPORT data, so the responder can go through its 
> > list of PPKs to match it back to a connection/group. But we would 
> That's what we did in our original proposal (actually, it was a 
> function of the PPK itself).  The problems with that were:
> 
> - If we made it a nondeterministic function (that is, include a 
> randomizer), then the server had to do a linear scan over all their known PPKs to find the matching one.
> 
> - If we made it a deterministic function, then someone listening in 
> can trivially determine when we're reusing the same PPK
> 
> A linear scan over possibly 10,000 PPKs was considered unacceptable.  
> One of our proposals even allowed the server to specify the trade-off between the above two; that was considered too complex.
> 
> I'm not thrilled with Tero's answer of "lets be careful about the 
> order we upgrade things in complex networks", but I don't know how to 
> better solve it without adding lots of complexity to the protocol, potential anonymity leaks or requiring significant computation on the server side.

If initiator is configured with PPK, but at the same time its policy marks using PPK as optional, then the initiator can send two authenticators - one using SK_pi' and the other using SK_pi (where SK_pi = prf(PPK, SK_pi')). The one, computed using SK_pi (where PPK is involved) is placed in AUTH payload, and the other, computed using SK_pi' (without PPK) is placed in a new optional status notification NO_PPK_AUTH.

   Initiator                       Responder

When responder receives this message and cannot find the corresponding PPK based on PPK_id and is configured to allow PPK-less SA, it can still authenticate initiator by using the content of NO_PPK_AUTH. 
In this case the Responder replies with the IKE_AUTH response lacking PPK_IDENTITY to let the initiator know that AUTH payload is computed as per RFC7296 (using SK_pr', i.e. without using PPK).

If the responder has the corresponding PPK, then it computes its AUTH payload using SK_pr and includes PPK_IDENTITY notification:

This solution allows peers to communicate in different settings and to enforce their own policy.
For instance, if the initiator is configured to always use PPK, it won't include NO_PPK_AUTH at all. If responder is configured to always use PPK, it will just ignore NO_PPK_AUTH and return AUTHENTICATION_FAILED in case the proper PPK is not found.

Regards,
Valery.

---

From: Vukasin Karadzic <[email-masked]>
Date: Wed, 23 Aug 2017 00:49:17 +0200

Vukasin,
> Any thoughts from an implementer's standpoint?

Unfortunately no, no special thoughts. All proposed solution seem to be
more or less simple to implement/add to existing implementation.

In my humble opinion (I'm a GSoC student), the Valery Smyslov proposal is
very clever. But I don't know whether it is "worth the trouble"
doing that because of the one corner case we found.

I would also point out that currently libreswan aborts the negotiation if
it comes to this situation.

Regards,
Vukasin Karadzic

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 23 Aug 2017 16:34:35 +0300

Hi Panos,

> Valery,
> It is a good idea. A new optional notification that includes the auth_data as it would be calculated without the
> PPK would work. With that, the corner case of ' PPK_id configured on initiator but missing on the responder' is
> addressed. There is an additional cost of the extra notification message for every initiator that has no-
> mandatory ppk configured for the responder. 

Yes, and there is also an extra cost for initiator of performing AUTH calculation (e.g. digital signature)
twice - one with SK_p' and the other with SK_p. Good news are is that it is 
a) is performed by initiator only, so there is no risk of DoS attack on responder 
b) is needed only if initiator is configured in "permissive" mode - when its policy allows both PPK and non-PPK 
    SAs with the particular responder

> In the worst case scenario the responder would need to go
> through looking up the PPK_id and if that fails then authenticate the auth_data. Even though it is slightly
> more work for the responder, I don't consider that heavy processing that would introduce attack concerns.

Exactly.

> My concerns is that we might be making it too complicated by potentially introducing two separate SK_p's.
> From an ops perspective, if we stated the rule that when we want to go postquantum a PPK should be
> populated on the responder first as Graham and others suggested, then the extra complication of a new
> notification can be avoided. Violation of that rule would lead to IKE_AUTH failure for that initiator only.

In general I think that if protocol allows more flexible operational conditions, then it is a good thing.
If we add this feature, then it will be completely optional for both initiator and responder
(neither initiator is required to send NO_PPK_AUTH, nor responder is required to understand it).
So, if people strictly follow transition plan, then there is no much need in this feature.
However, I suspect that in fields some folks may find these rules too restrictive under some circumstances.
So we can add a bit more flexibility in the protocol for those folks for a relatively low cost. 

Regards,
Valery.

> > better solve it without adding lots of complexity to the protocol, potential anonymity leaks or requiring
> significant computation on the server side.
> 
> If initiator is configured with PPK, but at the same time its policy marks using PPK as optional, then the
> initiator can send two authenticators - one using SK_pi' and the other using SK_pi (where SK_pi = prf(PPK,
> SK_pi')). The one, computed using SK_pi (where PPK is involved) is placed in AUTH payload, and the other,
> computed using SK_pi' (without PPK) is placed in a new optional status notification NO_PPK_AUTH.
> 
>    Initiator                       Responder
> When responder receives this message and cannot find the corresponding PPK based on PPK_id and is
> configured to allow PPK-less SA, it can still authenticate initiator by using the content of NO_PPK_AUTH.
> In this case the Responder replies with the IKE_AUTH response lacking PPK_IDENTITY to let the initiator know
> that AUTH payload is computed as per RFC7296 (using SK_pr', i.e. without using PPK).
> 
> For instance, if the initiator is configured to always use PPK, it won't include NO_PPK_AUTH at all. If responder
> is configured to always use PPK, it will just ignore NO_PPK_AUTH and return AUTHENTICATION_FAILED in case
> the proper PPK is not found.
> 
> Regards,
> Valery.
> 
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Aug 2017 14:42:17 -0400 (EDT)

>> more work for the responder, I don't consider that heavy processing that would introduce attack concerns.

This is a good idea. It solves our issue when both ends are configured
to initiate and/or respond, and one end is updated and the other isn't,
yet we don't know which endpoint will become initiator or responder.

The only thing I think we should double check with some cryptogrpahers,
is if this opens up any kind of quantum or classic attack. I don't think
it does, but it would be good to get confirmed.

> So we can add a bit more flexibility in the protocol for those folks for a relatively low cost.

Yes, one of the scenarios is the one where both endpoints are configured
to bring up the connection and you cannot predict which end will become
initiator or responder.

Paul