| Main Archive Page > Month Archives > ipsec archives |
Re: [IPsec] CHILD_SA and PFS
From: Yoav Nir <ynir_at_nospam>Date: Tue Nov 20 2007 - 10:16:06 GMT
To: Chinh Nguyen <cnguyen@certicom.com>, ipsec@ietf.org
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:
- 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.
- 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.
>
> 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
IPsec mailing list
IPsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec