Hi Tero, I think we're in violent agreement on:
> I am very worried when people start implementing those ciphers to > IKEv1, as there is no way to know which features of the RFC4303 they > decide to include too. I agree that completely removing them is not > the way we want to go forward, but I would want to strongly recommend > people not to add implementation for them when using IKEv1, and based > on the text in the RFC6071 I think working group agreed on that too. OTOH, I believe that combined-mode ciphers work fine with RFC 2406, provided that some care is taken in the SA negotiation - the combined mode cipher is negotiated as the encryption transform without an additional authentication transform, and the combined mode cipher generates the ESP authentication data. At least RFC 4106 (GCM) is clear on how to do this. > Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302 > for ESP and AH, so they seem to already require ESPv3. Not exactly - like RFC 4106 (GCM), RFC 4309 (CCM) is also written in a fashion that works with both versions of ESP (same encapsulation as RFC 4106, but the text doesn't contain as much explanation of the details). OTOH, use of RFC 4543 (GMAC) with IKEv1 is peculiar, as that results in an authentication transform masquerading as an IKEv1 encryption transform, although RFC 4543 does cite RFC 2409 (IKEv1) as usable for keying. Nonetheless, the following is ok with me: > I would like that recommendation to be reflected also in the IANA > page, so implementors who just pick numbers from there would get > warning that implementing those ciphers might not lead as good > interoperability as they would expect compared when using IKEv2. You > have to remember that quite of lot of implementors will simply go to > the IANA page, pick the algorithms from there, quickly check out the > RFCs listed there and then implement the algorithms. Many of them do > not start looking other RFCs related to the problems, and quite many > of them have never heard about RFC errata etc... My objection was to the suggestion that the IANA registry entries be removed - I have no problem discouraging use of IKEv1 in favor of IKEv2 here and in general. Thanks, --David > -----Original Message----- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Monday, April 11, 2011 9:02 AM > To: Black, David > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC > > david.bl...@emc.com writes: > > It's more than a decision to not include that capability - IKEv1 exchanges > > cannot be protected with combined mode algorithms without significant > > incompatible change to IKEv1, as explained in Section 1 of RFC 5282: > > That is clear, I do not think anybody even dreams using combined mode > ciphers on IKEv1. > > > OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written in > > a fashion that allowed their use with ESP (RFC 2406) to be negotiated by > > IKEv1 (and also for AH in the case of GMAC). > > The problem is that combined mode ciphers are not possible to be used > with RFC2406, as that does not support combined mode ciphers. To > support combined mode ciphers RFC4303 is needed. > > Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302 > for ESP and AH, so they seem to already require ESPv3. > > > I would strongly object to removal of the IANA registry entries that > > support this usage, although I agree that everyone should be using > > IKEv2 in preference to IKEv1. > > I am very worried when people start implementing those ciphers to > IKEv1, as there is no way to know which features of the RFC4303 they > decide to include too. I agree that completely removing them is not > the way we want to go forward, but I would want to strongly recommend > people not to add implementation for them when using IKEv1, and based > on the text in the RFC6071 I think working group agreed on that too. > > I would like that recommendation to be reflected also in the IANA > page, so implementors who just pick numbers from there would get > warning that implementing those ciphers might not lead as good > interoperability as they would expect compared when using IKEv2. You > have to remember that quite of lot of implementors will simply go to > the IANA page, pick the algorithms from there, quickly check out the > RFCs listed there and then implement the algorithms. Many of them do > not start looking other RFCs related to the problems, and quite many > of them have never heard about RFC errata etc... > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
