Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)

[Tero Kivinen <[e-mail]>]

Yoav Nir writes:
> > Same here, and it also makes it so that we cannot say our
> > implementation is conforming rfc4307bis, even when we do already have
> > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to
> > implement algorithms in the new document, but we do also have code to
> > propose the RFC5114 MODP groups, if user configures them to be used.
> 
> I don’t think that’s the right way to interpret compliance with
> RFC4307bis. If you can configure your implementation to support only
> algorithms that are MUST, SHOULD, or MAY in the document, then you
> can configure your implementation to comply with 4307bis. I don’t
> think implementation compliance requires pulling out code. 

When rfc4307bis says MUST NOT do DES, and MUST NOT do 768-bit MODP, I
assume that to be conforming to that document, user is not able to
configure DES with 768-bit MODP group.

Of course MUST NOTs are difficult as it is really hard to show where
in your code you implement this specific MUST NOT (yes, there was one
customer asking us to point out where in code we implement each MUST
NOTs).

> Our implementation allows the user to key in long hex strings to
> construct MODP groups that are not available out of the box. With
> your interpretation we can never be compliant because they can
> always make up their own 512-bit group and add that to the available
> groups. 

That is different issue, as this is SHOULD feature in the RFC7296:

   parameters, up to certain size limits.  In support of this goal, all
   implementations of IKEv2 SHOULD include a management facility that
   allows specification (by a user or system administrator) of Diffie-
   Hellman parameters (the generator, modulus, and exponent lengths and
   values) for new Diffie-Hellman groups.  Implementations SHOULD
   provide a management interface through which these parameters and the
   associated Transform IDs may be entered (by a user or system
   administrator), to enable negotiating such groups.

Also there is nothing in the rfc4307bis saying that that is MUST
NOT...

On the otherhand if someone uses that interface to configure the
768-bit MODP group 1, then he is going against MUST NOT in rfc4307bis,
and his system is longer conforming... It might be good idea to limit
that interface so it will not allow any groups which are shorter than
1024-bits, just so users cannot do stupid things... 
-- 
[e-mail]