Subject: [IPsec] #30: Conflicts in DH proposals

From: Yaron Sheffer <[email-masked]>
Date: Sun, 7 Dec 2008 17:09:23 +0200

Tero: One of the questions that have been out long time, is that do all of
the offered proposals must have identical Diffie-Hellman group lists. What
does it mean if one of the proposals have different list than some other
proposal. Can the KE payload include then be from such group that only
exists in one of the lists. Also do the Diffie-Hellman groups need to be
repeated on every single proposal. 

I think we should add some text explaining that. 

Room: This may be missing functionality involving how an endpoint deals with
a KE payload that is wrong for the selected proposal. Charlie Kaufman:
Should always start with stronger KE payload, there is text on this, but can
benefit from clarification.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 8 Dec 2008 16:16:22 -0500

We already allow flexibility in expressing proposals; i.e., 
P=(AES256,{SHA1|MD5}) is equivalent to (P1=(AES256,SHA1), P2=(AES256,MD5)) 
and neither is prohibited by the RFCs.  I think this should lead us to 
explicitly extend the flexibility to DH groups.  In fact, I had assumed 
from my reading of the RFCs that this was already allowed implicitly.  If 
we are to add any explicit text for this issue, I would advocate that we:

1) Explicitly allow for multiple proposals with distinct sets of DH 
groups.
2) For the case where a responder chooses a set of transforms from a 
proposal, and where the chosen DH transform does not match the KE payload, 
explicitly specify that the responder should respond with 
N(INVALID_KE_PAYLOAD) based on the DH group that the responder would have 
chosen from the given proposals.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Yaron Sheffer <[email-masked]>
To:
IPsecme WG <[email-masked]>
Date:
12/07/2008 01:28 PM
Subject:
[IPsec] #30: Conflicts in DH proposals

Tero: One of the questions that have been out long time, is that do all of 
the offered proposals must have identical Diffie-Hellman group lists. What 
does it mean if one of the proposals have different list than some other 
proposal. Can the KE payload include then be from such group that only 
exists in one of the lists. Also do the Diffie-Hellman groups need to be 
repeated on every single proposal. 
I think we should add some text explaining that. 
Room: This may be missing functionality involving how an endpoint deals 
with a KE payload that is wrong for the selected proposal. Charlie 
Kaufman: Should always start with stronger KE payload, there is text on 
this, but can benefit from clarification.[attachment "smime.p7s" deleted 
by Scott C Moonen/Raleigh/IBM] 
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 8 Dec 2008 23:22:53 +0200

On Dec 7, 2008, at 5:09 PM, Yaron Sheffer wrote:
> Tero: One of the questions that have been out long time, is that do  
> all of the offered proposals must have identical Diffie-Hellman  
> group lists. What does it mean if one of the proposals have  
> different list than some other proposal. Can the KE payload include  
> then be from such group that only exists in one of the lists. Also  
> do the Diffie-Hellman groups need to be repeated on every single  
> proposal.
>
> Room: This may be missing functionality involving how an endpoint  
> deals with a KE payload that is wrong for the selected proposal.  
> Charlie Kaufman: Should always start with stronger KE payload, there  
> is text on this, but can benefit from clarification.

I don't think we should mandate that all proposals share the same set  
of D-H groups.

I suggest replacing the following text from section 3.4:

    The DH Group # identifies the Diffie-Hellman group in which the Key
    Exchange Data was computed (see Section 3.3.2).  If the selected
    proposal uses a different Diffie-Hellman group (other than NONE),  
the
    message MUST be rejected with a Notify payload of type
    INVALID_KE_PAYLOAD.

with this:

    The DH Group # identifies the Diffie-Hellman group in which the Key
    Exchange Data was computed (see Section 3.3.2).  This Group # MUST
    match a DH Group specified in a proposal in the SA payload that is
    sent in the same message, and SHOULD match the strongest DH Group
    in any of the proposals of that SA payload. If none of the proposals
    in that SA payload specifies a DH Group, the KE payload MUST NOT be
    present. If the selected proposal uses a different Diffie-Hellman
    group (other than NONE), the message MUST be rejected with a Notify
    payload of type INVALID_KE_PAYLOAD.

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Dec 2008 15:11:48 +0200

> I don't think we should mandate that all proposals share the same set  

I can accept that...

>     payload of type INVALID_KE_PAYLOAD.

I do not think we can add new "SHOULD" in this time, i.e. I would
remove the ", and SHOULD match the strongest DH Group in any of the
proposals of that SA payload" part. There are problems to define
stength order for different Diffie-Hellman groups, especially if they
use different methods, i.e. some use elliptic curves and some are MODP
groups.

Otherwise the text looks good.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Sun, 14 Dec 2008 15:27:50 +0200

> Otherwise the text looks good.

how about, ", and should match the DH group is the most preferred  
group in the most preferred proposal, if such exists" - lower case  
should?

I'm fine with dropping it all together as you suggested.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Dec 2008 15:40:36 +0200

> group in the most preferred proposal, if such exists" - lower case  

That would be fine. In that case we could even use capital "SHOULD",
as I think the requirement of selecting most preferred group /
proposal is ok. I just do not want to have word "strongest" there as
that would be indicate we have some global strength order we could
sort them.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec