My guess is that their requirements should be similar as those for rfc4307bis, 
but as you mention, the history of crypto suite deployment may be different.   
These profiles will be discussed in future meetings, so they might evolve. 

I agree that we should provide our rational for our choice. This will be useful 
for everyone, including other communities to make their own choice according to 
their own specifies.

BR, 
Daniel

-----Original Message-----
From: Paul Wouters [mailto:[email protected]] 
Sent: Tuesday, October 13, 2015 5:13 PM
To: Daniel Migault
Cc: Tero Kivinen; IPsecME WG; Yoav Nir
Subject: Re: RFC4307bis -- 3GPP inputs

On Tue, 13 Oct 2015, Daniel Migault wrote:

> 3GPP is also looking at updating its IKEv2 profile - most likely in 
> November. I beleive it would be good to know about it and eventually to 
> position RFC4307bis toward them. So far the differences I see with [1] are:

Are the requirements for the 3GPP IKEv2 profile (suite) the same as the 
requirements for RFC4307bis?

>    - DH group 19 (256-bit random ECP group) is MUST in 3GPP instead of SHOULD 
> in [1].
>    - PRF_HMAC_SHA2_384; is MUST in 3GPP and is not mentionned in [1].
>    - Diffie-Hellman group 20 (384-bit random ECP group) is SHOULD in 3GPP 
> instead of MAY in [1].
>    - DH group 2 (1024-bit MODP) is MUST NOT in 3GPP instead of SHOULD NOT in 
> [1].

Does 3GPP have a rationale for their decisions?  Without a rationale, it is a 
little hard to justify any decision or any change. Which is why I have been 
pushing that we add a rationale as well for RFC4307bis.

For instance, why is PRF_HMAC_SHA2_384 a MUST? Isn't PRF_HMAC_SHA2_256 good 
enough? Same for group 19/20. I can see that since 3GPP started out much later, 
they never deployed group 2, so a MUST NOT for them could make sense, but since 
group 2 is too common for internet hosts doing IKE, I can see why RFC4307bis 
wants to use SHOULD NOT.

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

Reply via email to