Subject: [IPsec] CHILD_SA and PFS

From: Chinh Nguyen <[email-masked]>
Date: Fri, 16 Nov 2007 11:14:12 -0500

As stated in RFC4718, we do not include a DH group in the first 
CHILD_SA's proposals, due to the fact that no KE payloads are exchanged. 
This leaves the situation that any mismatch in the "PFS" mode of the 
peers (on/off) or DH group will not be known until the ipsec SA rekeys. 
At which time, presumably a NO PROPOSAL CHOSEN will be sent back.

However, from a VPN user's perspective, it's not clear which is the more 
palatable scenario: failure to login (assuming we send the DH group in 
SAi2) or failure to maintain a VPN session (ipsec rekey fails).

Chinh
--
http://www.certicom.com

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

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 09:52:18 +0200

If the initial handshakes have completed, the peers have at least 
one Diffie-Hellman group they both support and consider acceptable.
Although in theory you could consider group X acceptable only
for "phase 1", but not "phase 2", this sounds like a somewhat
weird policy to me.

About the "PFS mode": if the exchange initiator proposes a DH
group in CREATE_CHILD_SA exchange, I'd usually expect the 
responder to accept it (if the group is generally acceptable), 
even if the responder doesn't care about PFS. If the initiator 
doesn't propose a DH group, and the responder cares about PFS, 
the responder can always initiate rekeying itself.

Best regards,
Pasi

> -----Original Message-----
> From: ext Chinh Nguyen [mailto:[email-masked]] 
> Sent: 16 November, 2007 18:14
> To: [email-masked]
> Subject: [IPsec] CHILD_SA and PFS
> 
> CHILD_SA's proposals, due to the fact that no KE payloads are
> exchanged.  This leaves the situation that any mismatch in the "PFS"
> mode of the peers (on/off) or DH group will not be known until the
> ipsec SA rekeys.  At which time, presumably a NO PROPOSAL CHOSEN
> will be sent back.
> 
> However, from a VPN user's perspective, it's not clear which is the
> more palatable scenario: failure to login (assuming we send the DH
> group in SAi2) or failure to maintain a VPN session (ipsec rekey
> fails).

---

From: Chinh Nguyen <[email-masked]>
Date: Mon, 19 Nov 2007 10:49:40 -0500

> for "phase 1", but not "phase 2", this sounds like a somewhat

Users of Certicom's IPSec can specify different DH groups for IKE and 
IPsec. Of couse, this is our implementation choice and I don't want to 
generalize to other implementation.

> even if the responder doesn't care about PFS. If the initiator 

Unfortunately, since we do not associate/share any phase 1 settings with 
phase 2 settings, if the configured ipsec proposals contain no DH group, 
there's just no way to accept the ipsec rekey.

> the responder can always initiate rekeying itself.

I would suspect that the peer, unable to rekey itself, has torn down the 
connection by the time the responder decides to rekey.

The logic that "if peer rekeys without PFS and PFS is needed then we 
rekey right away" is currently too specialized for us to consider adding 
at this time.

So my query is this. There is a statement in the RFC that since there is 
no KE payload (and nonces) in the IKE_AUTH, this implies that the DH 
group should be NONE or omitted. I don't understand logically why the 
latter follows from the former.

I thought an SA proposal is to enumerate supported/acceptable transforms 
(and one possible usage is the inclusion of a DH group in the CHILD_SA 
SA proposals to signal PFS in rekey).

Chinh
--
http://www.certicom.com

---

From: "Ricky Charlet" <[email-masked]>
Date: Mon, 19 Nov 2007 12:03:16 -0600

Hi Pasi,
 
  Does this still leave a true IKEv2 protocol problem for environments
which wish to configure separate DH groups for IKE and IPsec SAs and
also have reasons (NAT / remote-access) to configure the peers as
initiator/responder only?

   If the answer is "if you need to configure initiator/responder only
then you have to adminstrativly ensure that your PFS policy uses the
same DH group for both IKE and 
IPsec" that would be fine (with me). I'm just not yet clear if that is
what you are saying.

   My basic question is... Do I have to write documentation guidance to
adminstrators of my systems for this?

Ricky Charlet
[email-masked]

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, November 18, 2007 11:52 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [IPsec] CHILD_SA and PFS
> 
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Nov 2007 12:16:06 +0200

I believe that your suggestion in the last line is a very good one.  
However, RFC 4306 says this:

    In the CHILD_SA created as part of the initial exchange, a second KE
    payload and nonce MUST NOT be sent.  The nonces from the initial
    exchange are used in computing the keys for the CHILD_SA.

and also this

                                                 If the SA offers  
include
    different Diffie-Hellman groups, KEi MUST be an element of the group
    the initiator expects the responder to accept.  If it guesses wrong,

Taken together, this says that if you include a D-H transform, you  
also need to include a KE payload, and in AUTH that's not allowed, so  
the D-H transform is not allowed either.

I agree that this is a real problem not just because a peer may be  
configured to do group #5 for IKE and group #2 for IPsec, but because  
some IKE peers may prohibit D-H for IPsec (for example RA  
concentrators) while others may require it. This is clearly a  
mismatched configuration, yet it will only be discovered when the  
IPsec SA needs to be rekeyed.

So I think your idea is a good one, but it is in conflict with RFC 4306.

I can think of two ways to fix this:

1. Add a notification to IKEv2 with a name like WILL_DO_PFS_ON_REKEY  
that can be added to the AUTH exchange. It will specify the groups  
supported (maybe only zero for no PFS). A peer that recognizes this  
notification may fail the exchange if the next CHILD_SA is doomed to  
fail.

2. Implement your suggestions, but this is a bits-on-the-wire change,  
and will probably force us to call this IKEv2.1.  If you want to go  
that path, there's probably lots of others who would like to get  
things into v2.1, so that would be a long haul indeed.

Yoav

On Nov 19, 2007, at 5:49 PM, Chinh Nguyen wrote:
>
>> doesn't propose a DH group, and the responder cares about PFS, the  
>> responder can always initiate rekeying itself.
>
> I would suspect that the peer, unable to rekey itself, has torn down  
> the connection by the time the responder decides to rekey.
>
> rekey right away" is currently too specialized for us to consider  
> adding at this time.
>
> So my query is this. There is a statement in the RFC that since  
> there is no KE payload (and nonces) in the IKE_AUTH, this implies  
> that the DH group should be NONE or omitted. I don't understand  
> logically why the latter follows from the former.
>
> I thought an SA proposal is to enumerate supported/acceptable  
> transforms (and one possible usage is the inclusion of a DH group in  
> the CHILD_SA SA proposals to signal PFS in rekey).
>
> Chinh
> --
> http://www.certicom.com

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 13:07:39 +0200

Ricky Charlet wrote:

>    If the answer is "if you need to configure initiator/responder
> only then you have to adminstrativly ensure that your PFS policy
> uses the same DH group for both IKE and IPsec" that would be fine
> (with me). I'm just not yet clear if that is what you are saying.

Well, the answer is that "if you want to do PFS, you need to 
configure the initiator and the responder so that they have at 
least one acceptable DH group in common".

This is the case even with the protocol changes Chinh is
proposing. The difference is only at what time the policy
mismatch is detected and the connection is torn down (until
the administrator changes the configuration).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 13:07:39 +0200

Chinh Nguyen wrote:

> transforms (and one possible usage is the inclusion of a DH group
> in the CHILD_SA SA proposals to signal PFS in rekey).

The SA proposal here enumerates the transforms to be used for
*this* CHILD_SA creation (not future CHILD_SAs; those exchanges
have their own SA payloads, which may contain different things).
Since no Diffie-Hellman calculation is done when this CHILD_SA is
created, you can't get negotiate the Diffie-Hellman transform here.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 13:12:30 +0200

Yoav Nir wrote:

> I agree that this is a real problem not just because a peer may
> be configured to do group #5 for IKE and group #2 for IPsec, but
> because some IKE peers may prohibit D-H for IPsec (for example RA
> 1. Add a notification to IKEv2 with a name like
> WILL_DO_PFS_ON_REKEY that can be added to the AUTH exchange. It
> will specify the groups supported (maybe only zero for no PFS). A
> peer that recognizes this notification may fail the exchange if
> the next CHILD_SA is doomed to fail.

In general, there's no way to know whether a CREATE_CHILD_SA
exchange will succeed without trying it. The DH group seems to be
rather small part of this: one peer could require using AES-256 for
some traffic, but the other one could require something else. 

If the policies are fundamentally incompatible (and changing them
requires administrative action), I'm not sure if it's important to
discover *this* particular incompatibility during IKE_SA creation
(since most of the incompatibilities can't be discovered anyway
at this time).

BTW, the chances of having mismatched policy probably depend on the
user interface. If the UI offers exclusive options "(A) No PFS, (B)
Group 2, (C) Group 5", it's easy to configure mismatched policies.

If the interface offered options "(1) Propose PFS with
groups 2,5,X,Y (2) Require PFS with groups 2,5,X,Y -- fail
connection if not supported by peer, (3) Don't propose PFS but
accept if required by peer, (4) Prohibit PFS -- fail connection 
if required by peer", probably fewer people would choose "4"
than would choose "A". (This is of course only a hypothesis,
not confirmed by testing.)

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Nov 2007 15:20:46 +0200

> I can think of two ways to fix this:

I think the easiest is to fix the configuration. Note that this does
not cause any big problem even if nothing is done. The IPsec SA rekey
will fail, which means the IPsec SA will expire, and when creating new
IPsec SA fails too, the initiator will tear down the IKE SA, and
recreate it, which will again generate new IKE SA and IPsec SA and
traffic works again. I.e every few hours there is few seconds when
traffic does not work because of configuration error. If the user
wants to get rid of it he should fix the confuration. 
-- 
[email-masked]

---

From: Chinh Nguyen <[email-masked]>
Date: Tue, 20 Nov 2007 08:52:45 -0500

> created, you can't get negotiate the Diffie-Hellman transform here.

Yes, of course. This is the clearest, most succinct reason why DH group 
cannot be included. Thanks, Pasi.

Although practically speaking, I don't think I've seen a 
configuration/implementation that changes its SA proposal (DH group for 
PFS excepted) upon rekey.

Regards,

Chinh
--
http://www.certicom.com

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Nov 2007 15:53:27 +0200

This assumes that generating a new IKE SA is a painless procedure. For  
clients, this could mean keying in a passcode from a token, or  
entering a password or pushing some button on a phone.

Even if generating an IKE SA is painless, it's also bad if you need  
multiple SAs. Only the first SA (the one that happened to trigger IKE)  
will succeed. All the others will fail (assuming all require PFS). So  
we have a badly mismatched configuration that occasionally works.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Nov 2007 17:56:04 +0200

> entering a password or pushing some button on a phone.

Which will cause the client to fix the problem sooner than later,
which is even better. 

> we have a badly mismatched configuration that occasionally works.

If the policies are different, any of the later SAs can fail too,
regardless of PFS. I do not really see that big difference in PFS. In
normal case the client should not really care what is configured for
the PFS group, it should be configured to: suggest without PFS, allow
also any group supported. Then the server can request what kind of
policy it wants.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Nov 2007 11:31:35 +0200

PFS is different.  For other attributes, if the SPD entry says you  
need, say, 3DES, and the other side's SPD entry says AES-128-GCM, then  
you'll fail every time.  If you succeed, then your policies are matched.

With PFS is different.  One side can have an SPD entry saying PFS is a  
must. The other SPD entry says PFS is must not. At any time except  
during the initial exchange, this will fail, and rightly so - so the  
users fix the problem.  But if it's in the initial exchange, it  
suddenly succeeds. This practically guarantees usability problems for  
any implementation.

On Nov 21, 2007, at 5:56 PM, Tero Kivinen wrote:

> Scanned by Check Point Total Security Gateway.
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Nov 2007 16:44:13 +0200

> you'll fail every time.  If you succeed, then your policies are matched.

Not really.

If your clients SPD says:

Local		Remote		Action
-----		------		------
192.168.2.1	10.0.0.0/8	PROTECT(ESP,AES)

and the servers SPD says:

Local		Remote		Action
-----		------		------
10.0.0.2	192.168.2.1	PROTECT(ESP,3DES)
10.0.0.0/8	192.168.2.1	PROTECT(ESP,AES)

Then if you happen to send first packet from client to 10.0.0.5
addres, the client will negotiate ESP IPsec SA with AES, and with
traffic selectors TSi = (192.168.2.1-192.168.2.1), TSr =
(10.0.0.0-10.0.0.1, 10.0.0.3-10.0.0.255), as the server will narrow it
down to that when proposed clients traffic selectors.

Now if the either end tries to negotiate SA between 192.168.2.1 and
10.0.0.2 that will fail. 

> suddenly succeeds. This practically guarantees usability problems for  

PFS is no different there. It is just like any similar policy mismatch
error. In the case above the user thinks he has ok policy as he can
use most of the services from the office network, but for some reason
he cannot connect to the 10.0.0.2 server, even when everything else
works. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Nov 2007 17:29:31 -0500

Yoav Nir wrote:
> notification may fail the exchange if the next CHILD_SA is doomed to fail.

This is the best solution.
It can be done unilaterally by the responder.

An initiator that doesn't recognize it falls into the situation that Kivinen 
mentioned. (which is the same situation as we have now)

An initiator that understands this notification can realize that it is 
misconfigured, and either fix itself (if it had a "MAY DO PFS" option), or 
let the user know immediately and fail the communications.

No IKE2.1 necessary.

If there in fact so many things that are waiting that need a 2.1 to do
perhaps someone could list them.  Minor version changes should not be
a big deal.  We tried to make sure of that.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 25 Nov 2007 11:14:26 +0200

That's my point. The client can never connect to 10.0.0.2. It always  
fails, so the user tells the administrator that something is wrong,  
and (hopefully) it gets fixed.

With PFS, the connection succeeds and everything works. Then suddenly,  
it stops.

If I can get to the file server at 10.0.0.5 but not to the mail server  
at 10.0.0.2, I'm going to call the administrator.  If the connection  
just stops after 30 minutes, I'm going to blame the ISP or the client  
vendor. I wouldn't associate a misconfiguration with this.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Nov 2007 17:30:46 +0200

> and (hopefully) it gets fixed.

But from the users point of view, he has working connection to the
office network, as the everything works, but then suddenly when he
wants do something else that does not work. 

> With PFS, the connection succeeds and everything works. Then suddenly,  

It does not stop, it pauses for sometime and fixes the situation after
a while. 

> vendor. I wouldn't associate a misconfiguration with this.

But if you are connecting to the smtp.company.local and half of the
time it works and half of the time it does not, as your dns resolver
is using round robin and both 10.0.0.2 and 10.0.0.5 are used for that
name, then you blame ISP or the client vendor again.

Anyways, blaming the client vendor is quite valid thing to do, as he
allowed misconfiguring the client in the way where it allows such
policies. If you use the better GUI example given by Pasi, I do not
think you will have that many problems. If you just have the "enable
PFS" checkbox, then I think the client vendor needs to be blamed.
-- 
[email-masked]