Subject: RE: [Ipsec] PFS

From: "Stephane Beaulieu \(stephane\)" <[email-masked]>
Date: Fri, 11 Nov 2005 11:46:06 -0500

Hi Alejandro,

You should include the DH transform in both, and set them to identical
values.

Stephane. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Alejandro Perez Mendez
> Sent: Friday, November 11, 2005 6:52 AM
> To: [email-masked]
> Subject: [Ipsec] PFS
> 
> Hi. I have some troubles understanding how PFS is performed 
> when proposal has more than one protocol.
> 
> What is the desired way to indicate we want to use AH + ESP 
> protocol and we also want to refresh DH material?
> Where we must include the DH_ID transform, in the ESP 
> protocol, in the AH protocol, in both...?
> 
> If a proposal like the following is valid (I suppouse it is), 
> must we include two KE payloads in the CREATE_CHILD_SA 
> exchange? It is possible?
> I suppouse that not but I don't know how perform this funcionability.
> 
> PROPOSAL #1---------> PROTOCOL ESP |---------> TRANSFORM ENCR 3DES
>           |                        |---------> TRANSFORM ENCR AES256
>           |                        |---------> TRANSFORM INTEG SHA1
>           |                        |---------> TRANSFORM DH 2
>           |                        |       ....
>           |            
>           |---------> PROTOCOL AH  |---------> TRANSFORM INTEG MD5
>           |                        |---------> TRANSFORM DH 1
>           |                        |       ....
> 
> 
> --
> Alejandro Perez Mendez <[email-masked]> Pedro 
> Javier Fernandez Ruiz <[email-masked]>
> 
> 
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
> 

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 11 Nov 2005 21:18:53 +0200

I assume you are talking about IKEv2 here.

> You should include the DH transform in both, and set them to identical

Yes, if you want to support that kind of extension to RFC2401bis you
probably should do it that way (and only include one KE payload).

> > protocol and we also want to refresh DH material?

Note, that in the RFC2401bis you do not create AH + ESP with that kind
of exchang. Instead you create AH as a separate exchange and put
traffic selectors to be ESP, and then create the ESP SA separately
with real traffic selectors.

> > exchange? It is possible?

I do not think it is valid to have to different diffie hellman groups,
and two KE payloads. On the other hand when using RFC2401bis
architecture this issue does not come up, as there is no ESP and AH
protocol in one proposal there, as the two SAs are set up separately.
-- 
[email-masked]

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 11 Nov 2005 20:25:41 +0100

> I assume you are talking about IKEv2 here.

Yes, I am.

> probably should do it that way (and only include one KE payload).

I also think this is the best way to do that.

> with real traffic selectors.

I know it, but IKEv2 support this feature and I'm interesting in a IKEv2
over RFC 2401 implementation.

> protocol in one proposal there, as the two SAs are set up separately.

Thank you all for the clarifications.
Best Regards!
-- 
Alejandro Perez Mendez <[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Nov 2005 10:56:00 +0200

> over RFC 2401 implementation.

IKEv2 does not really specify that feature, but it does not forbid the
feature either.  As you can see from your questions it is not
specified in the IKEv2 document (and should not be specified, as IKEv2
do require RFC2401bis architecture).

Using IKEv2 and old RFC2401 architecture have other problems also, so
I would not recommend that combination. 
-- 
[email-masked]

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 14 Nov 2005 10:04:57 +0100

El lun, 14-11-2005 a las 10:56 +0200, Tero Kivinen escribió:
> specified in the IKEv2 document 

But a AH + ESP combination it is allowed in the specification since
PROPOSAL structure can contain more than one protocol substructure. Why
is this allowed if the correspondent behaviour is not specified?

> (and should not be specified, as IKEv2

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Nov 2005 14:56:17 +0200

> is this allowed if the correspondent behaviour is not specified?

Mostly because it was copied from the old IKEv1 structure. Another
reason was to keep that open for to allow negotiation of multiple
protocols. RFC2401bis finished after IKEv2 and it decided that we do
not need that feature, thus IKEv2 implementations need not to
implement it as it is not needed in the RFC2401bis architecture.

Even if you would want to use it, you need to notice, that as it is
not part of the RFC2401bis architecture, that will mean that other
implementations will NOT implement it, thus your extension will be
non-standard extension which will not interoperate with implementation
following the RFC2401bis standard.

Why do you want to do that in non-standard way? Wouldn't it be better
to implement it as specified in the RFC2401bis standard?
-- 
[email-masked]