Re: [Ipsec] RE: MUST implement AES-CBC for IPsec ESP
Hi Yaakov, The following new text has been added to the draft. http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-bis-errata-03.txt Although there are no suggested or required combined algorithms at this time, AES-CCM [RFC4309] and AES-GCM [RFC4106] are of interest. AES-CCM has been adopted as the preferred mode in IEEE 802.11 [802.11i], and AES- GCM has been adopted as the preferred mode in IEEE 802.1ae [802.1ae]. Actually till version02 of the draft, I had a todo list(Appendix A.) which contained updating the status of new algorithms as one of the points in the agenda. However as I got no feedback on the same from the list, I did not go ahead and add any nenw algorithm status. Thanks, Vishwas On 1/22/07, Russ Housley <[EMAIL PROTECTED]> wrote: Yaakov: >Strangely missing is AES/GCM [RFC4106]. > >SHOULDn't this be a SHOULD ? None of the MUST/SHOULD algorithms are authenticated-encryption algorithms. This has not been proposed in the past, and it is very late in the processing of this document to propose it now. I'm pleased to entertain adding it the next time this document is updated. Russ ___ Ipsec mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ipsec ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: MUST implement AES-CBC for IPsec ESP
Yaakov: Strangely missing is AES/GCM [RFC4106]. SHOULDn't this be a SHOULD ? None of the MUST/SHOULD algorithms are authenticated-encryption algorithms. This has not been proposed in the past, and it is very late in the processing of this document to propose it now. I'm pleased to entertain adding it the next time this document is updated. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ipsec] Re: MUST implement AES-CBC for IPsec ESP
Steven, Counter mode is described in: W. Diffie and M. E. Hellman, "Privacy and Authentication: An Introduction to Cryptography," Proceedings of the IEEE, Vol. 67, March 1979, pp. 397-427. See Figure 18 on page 417. http://www-ee.stanford.edu/%7Ehellman/publications/32.pdf -- Bart Preneel --- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSICfax. +32 16 32 19 69 Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUM [EMAIL PROTECTED] http://www.esat.kuleuven.be/~preneel --- On Sat, 20 Jan 2007, Steven M. Bellovin wrote: > On Sat, 20 Jan 2007 14:45:26 -0800 > "Lawrence Rosen" <[EMAIL PROTECTED]> wrote: > > > > > For ESP encryption algorithms, the document that was sent out for > > > > Last Call contains the following table: > > > > > > > > RequirementEncryption Algorithm (notes) > > > > --- > > > > MUST NULL (1) > > > > MUST- TripleDES-CBC [RFC2451] > > > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > > > SHOULD AES-CTR [RFC3686] > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC > > > > to "MUST." > > > > Are any of these encryption algorithms patented? > > [...] > > > That leaves CTR mode. I doubt very much that it's patented, since it's > been very well known for many years and NIST rarely standardizes > patented algorithms in this space (which I know you appreciate...). > However, I don't have any citations to prove this negative. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > ___ > Ipsec mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ipsec > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: MUST implement AES-CBC for IPsec ESP
Russ Housley wrote: > During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, > we received a comment that deserves wide exposure. > > For ESP encryption algorithms, the document that was sent out for Last > Call contains the following table: > > RequirementEncryption Algorithm (notes) > --- > MUST NULL (1) > MUST- TripleDES-CBC [RFC2451] > SHOULD+AES-CBC with 128-bit keys [RFC3602] > SHOULD AES-CTR [RFC3686] > SHOULD NOT DES-CBC [RFC2405] (3) > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to > "MUST." > > I support this proposed change, and I have asked the author to make > this change in the document that will be submitted to the IESG for > consideration on the Telechat on January 25th. If anyone has an > objection to this change, please speak now. Please send comments on > this proposed change to the iesg@ietf.org or ietf@ietf.org mailing > lists by 2007-01-24. > > Russ Housley > Security AD Strangely missing is AES/GCM [RFC4106]. SHOULDn't this be a SHOULD ? Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: MUST implement AES-CBC for IPsec ESP
Jorge Contreras wrote: > Please note that any responses to your question "Are any of these > encryption algorithms patented?" are being provided by individuals in the > spirit of helpfulness and open sharing of information. Neither IETF nor > the IETF Trust provide assurances or advice as to whether or not > technology covered by IETF standards are covered by patent claims. The > exclusive mechanism for soliciting and disclosing patent claims within the > context of IETF activity is specified in RFC 3979, as we have discussed > before. Please do not take anyone's efforts to respond to your questions > as "official" IETF positions, as they are not and may not be relied upon > as such. I didn't take anyone's comments on this list as any reassurance of anything other than their own understanding of the situation. I just asked about patent coverage because I wondered if anyone knew. This kind of question comes up at other organizations I work with too. Asking a patent question on an IETF list should not conflict with the "exclusive mechanism" you describe. You should realize that I, perhaps more so than others on this list, would never rely on helpful and open emails on a public IETF list--no matter how expert the writers are--for official reassurances about patents, particularly third party patents. The people here don't read patent claims, nor should they have to for this purpose. That is in part why I am in favor of mandatory licensing by contributors in addition to disclosures. /Larry > -Original Message- > From: Contreras, Jorge [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 21, 2007 5:23 AM > To: Steven M. Bellovin; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] > Subject: RE: MUST implement AES-CBC for IPsec ESP > > Larry, > > Please note that any responses to your question "Are any of these > encryption algorithms patented?" are being provided by individuals in the > spirit of helpfulness and open sharing of information. Neither IETF nor > the IETF Trust provide assurances or advice as to whether or not > technology covered by IETF standards are covered by patent claims. The > exclusive mechanism for soliciting and disclosing patent claims within the > context of IETF activity is specified in RFC 3979, as we have discussed > before. Please do not take anyone's efforts to respond to your questions > as "official" IETF positions, as they are not and may not be relied upon > as such. > > Regards, > Jorge > > > > -Original Message- > > From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] > > Sent: Saturday, January 20, 2007 6:28 PM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] > > Subject: Re: MUST implement AES-CBC for IPsec ESP > > > > > > On Sat, 20 Jan 2007 14:45:26 -0800 > > "Lawrence Rosen" <[EMAIL PROTECTED]> wrote: > > > > > > > For ESP encryption algorithms, the document that was > > sent out for > > > > > Last Call contains the following table: > > > > > > > > > > RequirementEncryption Algorithm (notes) > > > > > --- > > > > > MUST NULL (1) > > > > > MUST- TripleDES-CBC [RFC2451] > > > > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > > > > SHOULD AES-CTR [RFC3686] > > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > > > The Last Call comment suggests changing the "SHOULD+" > > for AES-CBC > > > > > to "MUST." > > > > > > Are any of these encryption algorithms patented? > > > > > > > Almost certainly not. DES was patented, but the patent was never > > enforced; it has long since expired. (Trivia: IBM filed a statement > > saying that DES was royalty-free *if* used in one of the > > NIST-approvedd > > modes of operation. But they never went after anyone who used it in > > other ways.) To my knowledge, 3DES was never patented; even if it had > > been, it was first publicly described in 1979, so I doubt that any > > patent would still be valid. > > > > AES itself had to be unencumbered; see > > http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . > > The designers of Rijndael never even attempted to patent it; see the > > text quoted in RFC 3602 or the old Rijndael home page. > > > > CBC dates from at least 1980 -- I seem to recall 1978, but I > > d
RE: MUST implement AES-CBC for IPsec ESP
Larry, Please note that any responses to your question "Are any of these encryption algorithms patented?" are being provided by individuals in the spirit of helpfulness and open sharing of information. Neither IETF nor the IETF Trust provide assurances or advice as to whether or not technology covered by IETF standards are covered by patent claims. The exclusive mechanism for soliciting and disclosing patent claims within the context of IETF activity is specified in RFC 3979, as we have discussed before. Please do not take anyone's efforts to respond to your questions as "official" IETF positions, as they are not and may not be relied upon as such. Regards, Jorge > -Original Message- > From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 20, 2007 6:28 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] > Subject: Re: MUST implement AES-CBC for IPsec ESP > > > On Sat, 20 Jan 2007 14:45:26 -0800 > "Lawrence Rosen" <[EMAIL PROTECTED]> wrote: > > > > > For ESP encryption algorithms, the document that was > sent out for > > > > Last Call contains the following table: > > > > > > > > RequirementEncryption Algorithm (notes) > > > > --- > > > > MUST NULL (1) > > > > MUST- TripleDES-CBC [RFC2451] > > > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > > > SHOULD AES-CTR [RFC3686] > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > The Last Call comment suggests changing the "SHOULD+" > for AES-CBC > > > > to "MUST." > > > > Are any of these encryption algorithms patented? > > > > Almost certainly not. DES was patented, but the patent was never > enforced; it has long since expired. (Trivia: IBM filed a statement > saying that DES was royalty-free *if* used in one of the > NIST-approvedd > modes of operation. But they never went after anyone who used it in > other ways.) To my knowledge, 3DES was never patented; even if it had > been, it was first publicly described in 1979, so I doubt that any > patent would still be valid. > > AES itself had to be unencumbered; see > http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . > The designers of Rijndael never even attempted to patent it; see the > text quoted in RFC 3602 or the old Rijndael home page. > > CBC dates from at least 1980 -- I seem to recall 1978, but I > don't have > a citation handy. > > That leaves CTR mode. I doubt very much that it's patented, > since it's > been very well known for many years and NIST rarely standardizes > patented algorithms in this space (which I know you appreciate...). > However, I don't have any citations to prove this negative. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MUST implement AES-CBC for IPsec ESP
Thanks Steve. Oddly enough I have never heard of 3365 until now. Apologies to all for my posting earlier. regards, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MUST implement AES-CBC for IPsec ESP
On Sat, 20 Jan 2007 13:34:54 -0800 Lakshminath Dondeti <[EMAIL PROTECTED]> wrote: > What are the export implications due to this? A compliant ESP > implementation MUST include the DES cipher due to this change. With > status quo, a compliant ESP implementation can be used for integrity > protection alone with NULL encryption. > I don't understand your question. Apart from the Danvers doctrine -- the IETF makes technically sound decisions without regard to politics -- how do you conclude that DES MUST be included? The new document says SHOULD NOT. > > Russ Housley wrote: > > During the IETF Last Call for > > draft-manral-ipsec-rfc4305-bis-errata, we > received a comment that > > deserves wide exposure. > > > For ESP encryption algorithms, the document that was sent out for > > > Last > Call contains the following table: Requirement > > > Encryption Algorithm (notes) > > --- > > MUST NULL (1) > > MUST- TripleDES-CBC [RFC2451] > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > SHOULD AES-CTR [RFC3686] > > SHOULD NOT DES-CBC [RFC2405] (3) > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC > > > to > "MUST." I support this proposed change, and I have asked the > > > author to make this > change in the document that will be > > > submitted to the IESG for > consideration on the Telechat on > > > January 25th. If anyone has an > objection to this change, > > > please speak now. Please send comments on > this proposed change > > > to the iesg@ietf.org or ietf@ietf.org mailing lists > by > > > 2007-01-24. Russ Housley > > Security AD > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MUST implement AES-CBC for IPsec ESP
On Sat, 20 Jan 2007 14:45:26 -0800 "Lawrence Rosen" <[EMAIL PROTECTED]> wrote: > > > For ESP encryption algorithms, the document that was sent out for > > > Last Call contains the following table: > > > > > > RequirementEncryption Algorithm (notes) > > > --- > > > MUST NULL (1) > > > MUST- TripleDES-CBC [RFC2451] > > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > > SHOULD AES-CTR [RFC3686] > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC > > > to "MUST." > > Are any of these encryption algorithms patented? > Almost certainly not. DES was patented, but the patent was never enforced; it has long since expired. (Trivia: IBM filed a statement saying that DES was royalty-free *if* used in one of the NIST-approvedd modes of operation. But they never went after anyone who used it in other ways.) To my knowledge, 3DES was never patented; even if it had been, it was first publicly described in 1979, so I doubt that any patent would still be valid. AES itself had to be unencumbered; see http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . The designers of Rijndael never even attempted to patent it; see the text quoted in RFC 3602 or the old Rijndael home page. CBC dates from at least 1980 -- I seem to recall 1978, but I don't have a citation handy. That leaves CTR mode. I doubt very much that it's patented, since it's been very well known for many years and NIST rarely standardizes patented algorithms in this space (which I know you appreciate...). However, I don't have any citations to prove this negative. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Ipsec] Re: MUST implement AES-CBC for IPsec ESP
At 1:34 PM -0800 1/20/07, Lakshminath Dondeti wrote: What are the export implications due to this? Two answers: - None. TripleDES is already a MUST in RFC 4305, and thus it already has a strong crypto requirement. - Export from which country? To which country? Who knows? Why are you asking the IETF's armchair lawyers to start firing up their keyboards? :-) --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: MUST implement AES-CBC for IPsec ESP
> > For ESP encryption algorithms, the document that was sent out for Last > > Call contains the following table: > > > > RequirementEncryption Algorithm (notes) > > --- > > MUST NULL (1) > > MUST- TripleDES-CBC [RFC2451] > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > SHOULD AES-CTR [RFC3686] > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to > > "MUST." Are any of these encryption algorithms patented? /Larry Rosen Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) Stanford University, Lecturer in Law 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen Author of "Open Source Licensing: Software Freedom and Intellectual Property Law" (Prentice Hall 2004) > -Original Message- > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 20, 2007 1:35 PM > To: Russ Housley > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org > Subject: Re: MUST implement AES-CBC for IPsec ESP > > What are the export implications due to this? A compliant ESP > implementation MUST include the DES cipher due to this change. With > status quo, a compliant ESP implementation can be used for integrity > protection alone with NULL encryption. > > regards, > Lakshminath > > Russ Housley wrote: > > During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, we > > received a comment that deserves wide exposure. > > > > For ESP encryption algorithms, the document that was sent out for Last > > Call contains the following table: > > > > RequirementEncryption Algorithm (notes) > > --- > > MUST NULL (1) > > MUST- TripleDES-CBC [RFC2451] > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > SHOULD AES-CTR [RFC3686] > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to > > "MUST." > > > > I support this proposed change, and I have asked the author to make this > > change in the document that will be submitted to the IESG for > > consideration on the Telechat on January 25th. If anyone has an > > objection to this change, please speak now. Please send comments on > > this proposed change to the iesg@ietf.org or ietf@ietf.org mailing lists > > by 2007-01-24. > > > > Russ Housley > > Security AD > > > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MUST implement AES-CBC for IPsec ESP
What are the export implications due to this? A compliant ESP implementation MUST include the DES cipher due to this change. With status quo, a compliant ESP implementation can be used for integrity protection alone with NULL encryption. regards, Lakshminath Russ Housley wrote: During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, we received a comment that deserves wide exposure. For ESP encryption algorithms, the document that was sent out for Last Call contains the following table: RequirementEncryption Algorithm (notes) --- MUST NULL (1) MUST- TripleDES-CBC [RFC2451] SHOULD+AES-CBC with 128-bit keys [RFC3602] SHOULD AES-CTR [RFC3686] SHOULD NOT DES-CBC [RFC2405] (3) The Last Call comment suggests changing the "SHOULD+" for AES-CBC to "MUST." I support this proposed change, and I have asked the author to make this change in the document that will be submitted to the IESG for consideration on the Telechat on January 25th. If anyone has an objection to this change, please speak now. Please send comments on this proposed change to the iesg@ietf.org or ietf@ietf.org mailing lists by 2007-01-24. Russ Housley Security AD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
