Subject: [IPsec] interoperability issue with modp transform mismatch for child sa

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Jul 2014 15:12:44 -0400 (EDT)

Hi,

RFC 5996 states:

  	Although ESP and AH do not directly include a Diffie-Hellman
  	exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
  	This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
  	exchange, providing perfect forward secrecy for the generated Child
  	SA keys.

software tends to configure the modp group as part of the phase2alg=
or esp= option, inherited from IKEv1's strict separation. With IKEv2,
we have a child sa negotiation in the initial exchange and one in the
create_child_sa. For the initial exchange, you would never do a new
DiffieHellman.

But a configuration does not know whether it will be initiated via
the initial exchange or via the create_child_sa. It can depend on
which happens to be the first tunnel with the peer.

I see an interop issue where a transform for a child sa is rejected in
the initial exchange because of a mismatch in the modp transform.

My questions:

Should we accept an initial exchange child transform that does not specify
a modp transform if we are configured to need one for the child sa?

Should we leave out the modp group transform for the child sa in the initial
exchange, if we are configured to need one for the child sa?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 9 Jul 2014 15:14:43 +0400

Hi Paul,

> the initial exchange because of a mismatch in the modp transform.

Our implementation requires that the list of DH groups for
IKE and IPsec be the same in case of IKEv2.

> a modp transform if we are configured to need one for the child sa?

I think we should as it is a special case. But we must ensure that the 
group,
negotiated in IKE_SA_INIT is also acceptable for the Child SA.

> exchange, if we are configured to need one for the child sa?

Not only we should, we must leave it out. RFC5996, page 12:

   Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
   Thus, the SA payloads in the IKE_AUTH exchange cannot contain
   Transform Type 4 (Diffie-Hellman group) with any value other than
   NONE.  Implementations SHOULD omit the whole transform substructure
   instead of sending value NONE.

Again, it is a special case. And while proposing DH group
for the IKE SA we must ensure that it is also acceptable
for the child SA.

Regards,
Valery.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Jul 2014 14:52:54 +0300

> IKE and IPsec be the same in case of IKEv2.

Or you could remove rules set for the obsoleted IKEv1 protocol, and
move the configuration to work on the IKEv2 terms. In that case you
could define Diffie-Hellman groups for IKEv2 SA and another
Diffie-Hellman groups for PFS (i.e. for later create child sa
exchanges).

> I think we should as it is a special case. But we must ensure that
> the group, negotiated in IKE_SA_INIT is also acceptable for the
> Child SA.

In the IKE_SA_INIT we have SA payloads specifying the policy for the
IKE SA and that include mandatory Diffie-Hellman group. This group
protects the whole authentication and the IKE SA and also provides the
upper bound for security of the Child SAs created using that IKE SA.
If this group is too weak, then the attacker can break the IKE SA
protection, thus it can modify the later CREATE_CHILD_SA exchanges at
will, and act as man in the middle for them too, thus breaking
whatever Diffie-Hellman is used later. Thus there is no point of
having more secure Diffie-Hellman group in the CREATE_CHILD_SAs for
PFS than what was used in the IKE SA creation.

So if you want to check policy for the initial group and PFS group,
just check the policy at the load time, and make sure the groups
allowed in the IKE SA creation are stronger than the one used in the
PFS.

So in IKE_SA_INIT and IKE_AUTH there is exactly one group that is
specified in the IKE_SA_INIT SA payload and that protects the whole
IKE SA and the first Child SA. That group is by definition good enough
for the first Child SA, as security of all future Child SAs are also
limited to that one group. 

> > Should we leave out the modp group transform for the child sa in
> > the initial exchange, if we are configured to need one for the
> > child sa?
> 

Yes.

> for the IKE SA we must ensure that it is also acceptable

Not really, as the DH group used in the IKE SA is by definition the
upper bound of the security for all Child SAs created inside it. Doing
another PFS later does not add anything if the original Diffie-Hellman
is already broken at that time and there is active attacker there.

I.e if you use weak Diffie-Hellman group in the IKE SA and there is
passive attacker who records the whole IKE SA exchange and starts
breaking the Diffie-Hellman you did. After the attacker manages to
break the Diffie-Hellman for the IKE SA it can now calculate the
SKEYSEED, an from there it can calculate the SK_d, SK_a* etc. 

It can use the SK_a* and SK_e* and get in the middle of the IKE SA,
thus it can take exchange from the IKE SA decrypt them, modify them,
reencrypt and reauthenticate them and send them forward. This means
that if you do CREATE_CHILD_SA with much stronger PFS group after
attacker can act as man-in-the-middle, the attacker can get that
CREATE_CHILD_SA request, replace the KE payload in there, send it
forward and do the same in the CREATE_CHILD_SA response. Now you have
new Child SA between the peers, but there is attacker in the middle of
that SA too, even when you used so strong Diffie-Hellman that attacker
could not break it.

I.e the security of the IKE SA lies in the IKE SA Diffie-Hellman
exchange. If that is broken everything is lost.

You might even go so far that limit the security of the
CREATE_CHILD_SA Diffie-Hellman groups to the security of the IKE SA DH
Group. I.e. if the IKE SA used 1024-bit MODP group, there is no point
of proposing 2048-bit MODP group for PFS. You might simply propose the
same group you used in the IKE SA, as that is the security limit
anyways.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 11 Jul 2014 10:21:43 +0400

Hi Yoav,

did you consider the following initial exchange:

     Initiator                         Responder
     -------------------------------------------------------------------
     HDR(A,0), SAi1, KEi, Ni  -->
                                  <--  HDR(A,0), N(COOKIE), N(PUZZLE)

    (supported initiator)
     HDR(A,0), N(SOLVED_PUZZLE), SAi1,
         KEi, Ni  -->

-- or --

    (unsupported or unwilling initiator)
     HDR(A,0), N(COOKIE), SAi1,
         KEi, Ni  -->

The idea is that responder sends both the COOKIE and the PUZZLE 
notifications (of course, the cookie for PUZZLE must be generated
differently from the cookie for COOKIE, probably using different secret
or different algorithm).

In this case if the initiator doesn't support puzzles, it would
ignore the PUZZLE notification as unknown status notification
and return the COOKIE. On the other hand, if initiator supports
puzzles, then it have a choice - whether to return COOKIE
and have lower chance to establish SA or make some work
and return SOLVED_PUZZLE (that is identical to COOKIE 
apart from the type of notification) and have a better chance.
The responder in this case would give more priority to 
the SOLVED_PUZZLE requests and leave the remaining resources
to the COOKIE and initial IKE_SA_INIT requests.

I think this approach would:
    1) increase interoperability
    2) give more flexibility to initiator depending on
        the CPU resources it has
    3) allows responder to separate solved puzzles 
        from COOKIEs and to give them more priority

Regards,
Valery Smyslov.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Jul 2014 11:13:51 +0300

I think doing this would cause clients to calculate the puzzle solution, when in fact they don’t have to, and sending back the COOKIE would be enough.

What I envision is for the IKE gateway to measure its load (probably based on amount of half-open IKE SAs). As long as the load level is low, the gateway sends neither COOKIE nor PUZZLE. If the load gets higher, the gateway begins sending COOKIEs, and every implementation of RFC 5996 works. If the load gets even higher (to the extent that it jeopardizes the gateway’s ability to provide its services), then it sends PUZZLEs instead of COOKIEs, and initiators that don’t support this specification are left out.

Yoav

On Jul 11, 2014, at 9:21 AM, Valery Smyslov <[email-masked]> wrote:

> The idea is that responder sends both the COOKIE and the PUZZLE notifications (of course, the cookie for PUZZLE must be generated
> and return SOLVED_PUZZLE (that is identical to COOKIE apart from the type of notification) and have a better chance.
> The responder in this case would give more priority to the SOLVED_PUZZLE requests and leave the remaining resources
>   3) allows responder to separate solved puzzles        from COOKIEs and to give them more priority
> 
> Regards,
> Valery Smyslov.
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 15 Jul 2014 16:06:27 +0400

> I think doing this would cause clients to calculate the puzzle solution,
> when in fact they don’t have to, and sending back the COOKIE would be 
> enough.
>
> What I envision is for the IKE gateway to measure its load (probably based
> on amount of half-open IKE SAs). As long as the load level is low, the 
> gateway
> sends neither COOKIE nor PUZZLE. If the load gets higher, the gateway
> begins sending COOKIEs, and every implementation of RFC 5996 works.
> If the load gets even higher (to the extent that it jeopardizes the 
> gateway’s
> ability to provide its services), then it sends PUZZLEs instead of 
> COOKIEs,
> and initiators that don’t support this specification are left out.

I understand the idea. I only suggest a small modification,
that would make the overall process more flexible and interoperable.
The modification is: instead of sending only PUZZLE in case of high load,
the SG would send both COOKIE and PUZZLE, calculated with
different secrets. Those initiators, that don't support puzzles, would
ignore it and return COOKIE. The others would have a choice -
whether to spend some CPU power, solve the puzzle and return it
or just ignore puzzle and send COOKIE (as unsupported initiators).
The SG would give more priority to requests containing SOLVED_PUZZLE
than to requests containing COOKIE or initial IKE_SA_INIT.

I can see the following benefits with this modification:
1. Old initiators that don't support puzzles would still have a chance
    to establish SA (although their chances will be lower comparing
    to initiators, supported puzzles)
2. Every single initiator supported puzzles will have a choice - try to 
solve
    puzzle or try to continue with COOKIE. This is important,
    as SG sets an equal level of difficulty for all initiators,
    but, as you have mentioned in the draft, CPU power
    may differ drastically between small mobile devices and high-end 
desktops.
    For the former it is sometimes easier to ignore puzzles
    and hope that resending COOKIE would eventually work.
3. SG would be able to separate requests with solved puzzles from
    those with just returned cookies and would give the former
    higher priority.

I don't see any drawback with this modification, do you?

Regards,
Valery.

> > and return SOLVED_PUZZLE (that is identical to COOKIE apart from the 
> > type of notification) and have a better chance.
> > The responder in this case would give more priority to the SOLVED_PUZZLE 
> > requests and leave the remaining resources