Subject: [IPsec] Issue #20 Common use case for multiple proposals

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2008 14:53:15 +0300

> >  2.7.  Cryptographic Algorithm Negotiation
> ...
> >     Each IPsec protocol proposal contains one or more transforms.  Each
> >     transform contains a transform type.  The accepted cryptographic
> >     suite MUST contain exactly one transform of each type included in the
> >     proposal.  For example: if an ESP proposal includes transforms
> >     ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
> >     AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
> >     of the ENCR_ transforms and one of the AUTH_ transforms.  Thus, six
> >     combinations are acceptable.
> 
> Perhaps we should add here paragraph explaining the most common reason
> of the multiple propsoals:
> 
>     If both combined mode ciphers and normal ciphers with integrity
>     protection needs to be proposed, the inititor needs to use two
>     proposals. One of them includes all the combined mode ciphers,
>     without the integrity algorithms (as combined mode ciphers are not
>     allowed to have any other integrity algorithm than none), and the
>     another includes normal ciphers and the integrity algoritms for
>     them.
> 
> ===Not done. This level of specificity is not needed, and we don't talk
> about combined modes in the original IKEv2 doc.

Lets put it this way, I myself hadn't realized that we need support
for multiple proposals for this reason before we started to implement
combined mode ciphers for ESP. Only other reason for supoprting
multiple proposals for crypto negotiation was things like not
supporting all combinations (not useful) and AH + ESP (not done this
way anymore). Because of this our implementation did have very strict
restrictions on the number of proposals you could have. We had to
change that when we implemented combined mode ciphers, as otherwise we
could not propose those ciphers with other ciphers at all.

Note, that we are not talking about using combined mode ciphers in the
IKEv2, but using them in the ESP, and that is already described in the
ESPv3 document (RFC4303).

I think it would be useful to point this out for the future
implementors too, as the current RFC4306 do allow negotiation of
combined mode ciphers for ESP. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 09:18:47 -0700

>combined mode ciphers for ESP.

An implementer not getting this is good enough reason to put it in.

--Paul Hoffman, Director
--VPN Consortium