From owner-ipsec Thu May 1 08:46:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA04822 for ipsec-outgoing; Thu, 1 May 1997 08:42:54 -0400 (EDT) Date: Thu, 1 May 1997 15:48:07 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199705011248.PAA22358@ee.technion.ac.il> To: ipsec@tis.com, smamros@newoak.com Subject: Re: ISAKMP/Oakley pre-shared key issue Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, I do not find any reason for concern in the issue you bring up below. You talk about a brute-force search of the pre-shared key. Since this key is used only with prf's there is no reason to choose it from a small space (like 40 bits, etc). Brute-force search should be just infeasible. In addition, even if brute force search would be possible (a bit of rethorics in the ipsec mailing list is unavoidable :) the addition of g^xy to the hashed parameters does not add anything. If you want to find the key between A and B just initiate an exchange with B pretending to be A. Choose g^x, wait for B's responese (which will include HASH-R, where R=B) and now do an off-line search for the pre-shared key. On the other hand, adding g^xy to HASH-R and HASH-I does have a DISadvantage. Currently, the computation of g^xy out of g^x and g^y can be done after the exchange is finished. If you add the g^xy into the hashes you'll have to introduce the delay of this computation into the communication which is undesirable. Finally, regarding your comment >Since signatures (and now public-key encryption, according to the >notes from Memphis that were sent recently) both use g^xy to derive >SKEYID, as far as I know g^xy is NOT used in the public key encryption mode to derive SKEYID, only to derive SKEYID_a/e/g. ANd that's the right way to do it. In the signature mode we do use g^xy for SKEYID but the reason there is different (and one of the disadvantages of the signature mode). Hugo >A while back, we discussed the fact that the latest (-03) version >of the ISAKMP/Oakley resolution draft now requires that one use >Oakley Aggressive Mode whenever using pre-shared keys, if one plans >on using IDs that aren't IP addresses. If I remember right, an >idea was proposed to add a new ID type to the DOI draft which would >allow an opaque ID to be used to find the proper key. This is all >fine and good. > >However, this opens up something else that I hadn't realized until >just now. In Aggressive Mode, HASH_R is transmitted in the clear. >That isn't a problem by itself, but what is a problem is that the >only "secret" used to derive HASH_R in the -03 draft is the >pre-shared key itself (as part of SKEYID). Everything else is >something that is transmitted in the clear between the two parties. >This means that one can open up the whole exchange by doing a >brute-force key search; moreover, one can then impersonate either >party, assuming the key isn't changed. > >The previous version of the ISAKMP/Oakley resolution draft (-02) was >not as vulnerable, because the Diffie-Hellman shared secret (g^xy) >was also used to help derive HASH_R. (Of course, that version >was vulnerable to the man-in-the-middle D-H attack that was discussed >here just a short while ago; that was fixed by using the D-H public >values in the hash calculations in the -03 draft. But g^xy is now >left out, at least when using pre-shared keys.) > >It seems to me that this situation can be handled by adding g^xy >to the derivation of SKEYID when using pre-shared keys, as follows: > SKEYID = prf(pre-shared key, Ni | Nr | g^xy) >Since signatures (and now public-key encryption, according to the >notes from Memphis that were sent recently) both use g^xy to derive >SKEYID, I would hope that this would not be too great of a change >for the draft authors. And I can't see that this would weaken >anything, if the other authentication methods use it, but I'm not >a "real" cryptographer. Do the real cryptographers here believe >that this change would be a good idea? > >-Shawn Mamros >E-mail to: smamros@newoak.com > From owner-ipsec Thu May 1 10:02:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05364 for ipsec-outgoing; Thu, 1 May 1997 10:01:36 -0400 (EDT) Date: Thu, 1 May 1997 17:03:41 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199705011403.RAA24818@ee.technion.ac.il> To: ho@earth.hpc.org, kent@bbn.com Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk On the issue of ESP with optional AH I worte a few days ago: > If there are applications that consciously decide to take all these risks > I suggest they negotiate the EMPTY-MAC as their authentication > algorithm (no processing penalty) rather than having ipsec explictly > allowing integrity-less IP security. Hilarie recently wrote: >From ho@earth.hpc.org Tue Apr 29 17:01:47 1997 > > ... > I expressed doubt as to the wisdom of leaving this judgment up to the >individual user or system administrator, given that it is less than >straightforward to analyze the safety of such a decision and that, >with the exception of very low speed lines, the performance is not >greatly impacted by requiring integrity. I could see having it be a >property of the transform --- a transform designer can specify the >null integrity algorithm if he knows that the encryption algorithm has >built-in integrity --- but I don't find the DAP example compelling. > Following these sugestions and Steve's recent comments I propose to mandate integrity with ESP and to have editorial notes that 1) emphasize the importance of integrity in ESP and 2) suggest that in the particular cases where an application decides that the costof authentication together with ESP is not worthwhile (e.g., since integrity is provided by a different mechanism in that application) then the communicating parties can negotiate a "null integrity algorithm". Hugo From owner-ipsec Fri May 2 00:07:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA10530 for ipsec-outgoing; Fri, 2 May 1997 00:06:01 -0400 (EDT) Message-Id: <199705020428.AAA21555@relay.rv.tis.com> Date: Fri, 2 May 97 0:04:05 EDT From: Karen Seo To: wsimpson@greendragon.com cc: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk William, >>> From: Karen Seo >>> a) send the PMTU information to all 3 hosts. As you >>> observed, H1 and H2 aren't the intended recipients >>> for the PMTU information and won't know what to do >>> with it. >>> >>This would be the wrong thing to do. Be conservative in what you send. (Apologies for missing this part of your message in my previous reply...) Good point. This is what the Appendix is trying to say. Just to clarify... the above option was included for completeness. In cases where the security gateway cannot determine the originating source, the Appendix recommends the that the security gateway "hold the PMTU information until another too-big packet arrives and then use that packet and the PMTU information to construct a ICMP PMTU for the originating host (H0). Thanks again, Karen From owner-ipsec Fri May 2 07:30:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12737 for ipsec-outgoing; Fri, 2 May 1997 07:29:13 -0400 (EDT) Date: Thu, 1 May 1997 16:51:02 -0400 (EDT) From: David Mason Message-Id: <199705012051.QAA06728@dira.rv.tis.com> To: ipsec@tis.com, mjs@terisa.com, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, wdmaugh@tycho.ncsc.mil Subject: isakmp-07.txt Cc: dmason@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk You've probably already heard the following a couple hundred times... In draft-ietf-ipsec-isakmp-07.txt: The reference to "Figure 3.2" in the first sentence of Section 3.2 should be "Figure 3". In the section "3.14 Notification Payload", at the end of the paragraph: o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 octets for each SPI being deleted. "being deleted" should be deleted. At the end of the third paragraph of section "4.1 Security Association Establishment" (.txt page 42), references to certain aspects of the examples in section "4.1.1 Security Association Establishment Examples" are incorrect: Example 1 only shows two transforms for ESP not three and Example 2 only shows one transform for AH AND one transform for ESP OR ... You should probably mention in section 4.1.1 that the Nounce payload in example one was omitted for space reasons. -dave (dmason@tis.com) P.S.: Please let me know if you'd prefer I didn't send you mail like this. From owner-ipsec Fri May 2 11:51:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14619 for ipsec-outgoing; Fri, 2 May 1997 11:46:27 -0400 (EDT) To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-cast-128-cbc-00.txt Date: Fri, 02 May 1997 10:44:57 -0400 Message-ID: <9705021044.aa23388@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP CAST-128-CBC Algorithm Author(s) : R. Pereira, G. Carter Filename : draft-ietf-ipsec-esp-cast-128-cbc-00.txt Pages : 5 Date : 05/01/1997 This draft describes the CAST-128 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-cast-128-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-cast-128-cbc-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-cast-128-cbc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970501162454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-cast-128-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-cast-128-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970501162454.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri May 2 22:07:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA17912 for ipsec-outgoing; Fri, 2 May 1997 22:05:34 -0400 (EDT) Message-Id: <199705030217.TAA10628@mailsun2.us.oracle.com> Date: 02 May 97 19:09:03 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: No Noise was Re: Test... X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:owner-ipsec@portal.ex.tis.com's message of 29-Apr-97 05:00 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_10705989_0_11919705022018120" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=_ORCL_10705989_0_11919705022018120 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Please stop this noise (below) on the mailing list! Paul Lambert (ipsec chair) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_10705989_0_11919705022018120 Content-Type:message/rfc822 Date: 29 Apr 97 05:00:56 From:"Rodney Thayer " To:Dan.McDonald@eng.sun.com,(Dan,McDonald) Subject:Re: Test... Cc:ipsec@tis.com Return-Path: X-Sender:rodney@pop3.pn.com X-Mailer:Windows Eudora Light Version 3.0.1 (32) In-Reply-To:<199704290153.SAA22730@kebe.eng.sun.com> Sender:owner-ipsec@ex.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" Gee you must be getting all sorts of work done! At 06:53 PM 4/28/97 -0700, you wrote: >Sorry 'bout this, but I haven't received any IPsec mail lately. > >Curious, >Dan > > Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" --=_ORCL_10705989_0_11919705022018120-- From owner-ipsec Tue May 6 14:39:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13388 for ipsec-outgoing; Tue, 6 May 1997 14:27:17 -0400 (EDT) Message-Id: <199705061833.OAA01724@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "William Allen Simpson" Cc: ipsec@tis.com Subject: Re: policy versus protocol In-Reply-To: wsimpson's message of Mon, 28 Apr 1997 15:50:24 +0000. <5752.wsimpson@greendragon.com> Date: Tue, 06 May 1997 14:33:01 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk [I've been away from my mail for a while]. Bill, While I agree that it's often good to seperate policy from protocol, the policies of two implementations which want to interoperate need to be "compatible"; this means that policy *does* have ramifications for interoperability, and that that discussions about possible policies and policy frameworks *is* in scope for the IETF. - Bill From owner-ipsec Wed May 7 14:55:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22400 for ipsec-outgoing; Wed, 7 May 1997 14:48:53 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 1997 13:49:16 -0500 To: wdmaugh@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com From: Tom_Markham@securecomputing.com (Tom Markham) Subject: ISAKMP commit and notify usage Cc: ipsec@tis.com, cwilliams@cylink.com, balenson@tis.com, sabbott@tcel.com, gupta@us.ibm.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I am trying to understand the usage of the ISAKMP commit bit flag and notify messages. The ISAKMP header contains a flags field which contains a commit bit. When set by the sender this tells the peer ISAKMP not to use the (ISAKMP or IPSEC ?) SA until the sender transmits an informational exchange. Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that once an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the ISAKMP SA. - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? As an example which of the following Identity Protection Exchanges is correct? 1. No ISAKMP Encryption Until Notified Initiator direction Responder Note (1) HDR: SA ==> Begin ISAKMP - SA (2) <== HDR; SA (3) HDR; KE; Nonce ==> Commit flag set (4) <== HDR; KE; Nonce Key generated (5) HDR; Notify ==> Information Exchange is not protected by the SA (6) HDR*; IDii; AUTH ==> ID is encrypted (7) <== HDR*; IDir; AUTH 2. No IPSEC Encryption Until Notified Initiator direction Responder Note (1) HDR: SA ==> Begin ISAKMP - SA (2) <== HDR; SA (3) HDR; KE; Nonce ==> Commit flag set (4) <== HDR; KE; Nonce Key generated (5) HDR*; IDii; AUTH ==> ID is encrypted (6) <== HDR*; IDir; AUTH (7) HDR; Notify ==> Information Exchange is protected by the SA - What notify message type payload is used to commit/tell the peer ISAKMP that it is time to start using the encryption key/SA? - Is there an integrity check on the Notification Payload? Does each piece of notification data define its own integrity mechanism? The OAKLEY error payload appends a Sig/prf Payload. Thanks, Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Wed May 7 16:08:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22820 for ipsec-outgoing; Wed, 7 May 1997 16:07:34 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199705072030.QAA07984@relay.rv.tis.com> Date: Wed, 7 May 97 16:13:53 EDT To: IPSEC@tis.com Subject: ISAKMP/OAKLEY Negotiation Discrepancy and Question Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. 1) Hi. I believe I see a discrepancy between the figure shown in the , section 5.7.1 'Phase 1 using Oakley Main Mode', the first collections of payloads and the figure shown in the , section 3.6 'Transform Payload'. shows the RESERVED area of the Transform Payload (not the generic header RESERVED area), in both Transform 1 and 2 to be between the 'Next Payload' and the 'Transform-ID' fields. In example , I am assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. shows the RESERVED2 area of the Transform Payload (not the generic header RESERVED area), to be following the 'Transform-ID'. 'Next Payload' and the "Payload Length' fields. Question: If this is a discrepancy, which is correct? Ans: ______________________________________________________________ 2) In listed above in question 1), 'OAKLEY' is in the 'Transform-ID' field. I have looked in and but I do not find the transform id values listed anywhere. I also looked in the but I don't see anything that looks like a really good answer there either. Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' of the document? Ans: ______________________________________________________________ Thanks in advance for your help. -- Jim Ryder From owner-ipsec Wed May 7 16:29:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22913 for ipsec-outgoing; Wed, 7 May 1997 16:29:20 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199705072029.QAA25968@relay.hq.tis.com> Date: Wed, 7 May 97 16:35:39 EDT To: IPSEC@tis.com Subject: Correction to Previous Question Sender: owner-ipsec@ex.tis.com Precedence: bulk Excuse me. In the discrepancy, I said this: to be between the 'Next Payload' and the 'Transform-ID' fields ************ I meant to be between the 'Transform #' and the 'Transform-ID' fields *********** -- Jim From owner-ipsec Thu May 8 07:25:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29073 for ipsec-outgoing; Thu, 8 May 1997 07:21:33 -0400 (EDT) Message-Id: <199705081121.HAA29073@portal.ex.tis.com> Date: Wed, 07 May 1997 17:05:20 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: discussion list for IPsec SNMP MIB Cc: ietf-ipsec-mib@sneaker.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri Blumenthal and I have set up a mailing list for discussion on an SNMP MIB for IPsec. It's a "Majordomo" list, you subscribe by sending a message to: ietf-ipsec-mib-request@sneaker.net with "subscribe" as the body of the message. We have a (very very) rough draft of a MIB document now and we'll be discussing that for starters. -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Fri May 9 13:46:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09950 for ipsec-outgoing; Fri, 9 May 1997 13:38:31 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199705091738.NAA29801@relay.hq.tis.com> Date: Fri, 9 May 97 13:33:07 EDT To: IPSEC@tis.com Subject: Please help with answer to discrepancy question Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi. 1) Hi. I believe I see a discrepancy between the figure shown in the , section 5.7.1 'Phase 1 using Oakley Main Mode', the first collections of payloads and the figure shown in the , section 3.6 'Transform Payload'. shows the RESERVED area of the Transform Payload (not the generic header RESERVED area), in both Transform 1 and 2 to be BETWEEN the 'Transform #' and the 'Transform-ID' fields. In example , I am assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. shows the RESERVED2 area of the Transform Payload (not the generic header RESERVED area), to be FOLLOWING the 'Transform-ID'. Question: Which is correct? Ans: ______________________________________________________________ 2) In listed above in question 1), 'OAKLEY' is in the 'Transform-ID' field. I have looked in and but I do not find the transform id values listed anywhere. I also looked in the but I don't see anything that looks like a really good answer there either. Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' of the document? Ans: ______________________________________________________________ Thanks in advance for your help. -- Jim Ryder From owner-ipsec Fri May 9 15:36:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10587 for ipsec-outgoing; Fri, 9 May 1997 15:33:52 -0400 (EDT) Date: Fri, 9 May 97 15:38:36 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9705091938.AA01119@dolphin.ncsc.mil> To: jryder@vnet.ibm.com Subject: Re: Please help with answer to discrepancy question Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Jim, > 1) > > Hi. I believe I see a discrepancy between > > > the figure shown in the > , section 5.7.1 'Phase 1 using > Oakley Main Mode', the first collections of payloads > > and > > > the figure shown in the > , section 3.6 'Transform Payload'. > > > shows the RESERVED area of the Transform Payload (not the generic > header RESERVED area), in both Transform 1 and 2 to be BETWEEN the > 'Transform #' and the 'Transform-ID' fields. In example , I am > assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. > > shows the RESERVED2 area of the Transform Payload (not the generic > header RESERVED area), to be FOLLOWING the 'Transform-ID'. > > Question: Which is correct? > I'll give you my interpretation, but we'll need to hear the same thing from Dan Harkins and/or Dave Carrel (authors of the ISAKMP/Oakley draft). If you look at section 4.1.1 of you'll see two full examples of the payloads. I think the drawing in is leftover from the format in the ISAKMP-05 or -06 Internet Draft. I believe the agreement made between the ISAKMP, ISAKMP/Oakley, and IPSEC DOI I-D editors was that the Transform # field and the Transform ID field were together followed by the 2 octet RESERVED2 field. Again, we should hear from Dan Harkins and/or Dave Carrel to make sure we're in agreement. > 2) In listed above in question 1), 'OAKLEY' is in the > 'Transform-ID' field. I have looked in and but I do not find the > transform id values listed anywhere. I also looked in the > but I don't see anything that looks > like a really good answer there either. > > Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform > value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' > of the document? > Again, we probably need to hear from Dan and/or Dave and Derrell Piper (author of the IPSEC DOI I-D). All transform values are listed in the IPSEC DOI I-D. I believe you are correct in saying that the Transform ID is the value listed in section 4.2 of the IPSEC DOI I-D. Dan/Dave/Derrell??? Any input? Doug Maughan wdm@tycho.ncsc.mil From owner-ipsec Mon May 12 10:56:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28267 for ipsec-outgoing; Mon, 12 May 1997 10:49:06 -0400 (EDT) Message-Id: <3.0.32.19970512103856.006f8ee0@linus.isoc.org> X-Sender: burack@linus.isoc.org X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 12 May 1997 10:38:57 -0400 To: ipsec@ans.net From: Martin Burack Subject: INET'97 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings. Because of your interest in security, electronic commerce, privacy, and related areas, we thought you would want to know about the INET'97 conference, taking place next month. INET'97 is the crossroads at which the world's cyberspace leaders meet to exchange experiences, share information, and shape the future of the Internet and its related internetworking technologies. Regardless of your expertise, you'll come away with plenty of practical ideas. It is the one Internet event you must not miss! I look forward to seeing you there. Marty Burack Executive Director Internet Society burack@isoc.org *********************************** PLENARY SPEAKERS Dr. Glenn Ricart Executive Vice President and Chief Technology Officer Novell, Inc. Mr. Ira Magaziner Senior Advisor to the President of the United States for Policy Development. A Minister of the Malaysian government *********************************** A SAMPLING OF INET'97 CONFERENCE SESSIONS (subject to change) Security Privacy on the Internet Seamless VPN Network Access Control for DHCP Envir. E-mail Security Standards Capability-Based Usage Control Scheme A System For Public Keys for Network Transferring Objects Service Internet Commerce EDI: Concepts and Effects 3rd Gen Web Applications, Residential Economics of Internet Access Using Internet & Intranets What the Internet is Telling Us About Itself Small Businesses-Realities Case Studies A WWW Directory Service Architecture Online Stock Transactions Norwegian Tourism Industry NII in Taiwan Collaborative Environments The WebDesk Framework Multi-User Domains InterMUD Communications Multicasting Network Technology and Engineering Measurement and Statistics Network Technology Routing Satellite-based Networking ATM High Bandwidth Apps Plus additional sessions on: Policy and Regulation Education User Applications Regional Development A list of papers and panels, along with abstracts, can be viewed at: http://www.isoc.org/inet97 ********************************************* INET97 "THE INTERNET: GLOBAL FRONTIERS" The Seventh Annual Conference of the Internet Society 24-27 June 1997 Putra World Trade Center, Kuala Lumpur, Malaysia Pre-Conference Events: Technical Tutorial - June 23 and 24, 1997 K-12 Workshop - June 24, 1997 African Networking Symposium - June 24, 1997 Developing Countries Workshop - June 15-22, 1997 *********************************** The INET 97 registration fee covers attendance at all INET 97 conference sessions June 24-June 27, 1997: Opening Reception, Gala evening, luncheons, coffee breaks, and all conference materials, including the conference program, book of abstracts and CD-ROM proceedings. Pre-conference events have separate registration fees. DISCOUNTED ACCOMMODATIONS Discounted housing accommodations are available at three lovely hotels: The Pan Pacific Kuala Lumpur, The Legend and The Dynasty. DISCOUNTED AIRLINE RESERVATIONS Special INET97 airline rates are available for travel to and from Kuala Lumpur. The negotiated arrangements will reflect savings on all flights, and a savings of 15-50% on Malaysia Airlines, the Official Airline for INET97. TOURS Pre-and post-conference tours are available for INET 97 registrants. These tours emphasize culture, people, flora and fauna, with choices for all ages and economic standing. THE INTERNET SOCIETY (ISOC): is a nonprofit, non-governmental organization providing leadership in the management of the many issues and concerns which the new applications of the Internet are generating. Its diverse membership includes more than 100 key organizations and about 7,000 individual members in 150 countries. For more information, or to register: URL: http://www.isoc.org/inet97 Voice: +1 (703) 648-9888 Post: Internet Society Fax: +1 (703) 648-9887 12020 Sunrise Valley Drive, e-mail: Reston, Virginia U.S.A. 20191-3429 DON'T WAIT SIGN UP TODAY! From owner-ipsec Mon May 12 14:05:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29970 for ipsec-outgoing; Mon, 12 May 1997 14:04:21 -0400 (EDT) Message-Id: <199705121810.LAA02365@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: wdm@epoch.ncsc.mil (W. Douglas Maughan) Cc: jryder@vnet.ibm.com, ipsec@tis.com Subject: Re: Please help with answer to discrepancy question In-Reply-To: Your message of "Fri, 09 May 1997 15:38:36 EDT." <9705091938.AA01119@dolphin.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 May 1997 11:10:49 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Doug, Jim, > > > > the figure shown in the > > , section 5.7.1 'Phase 1 using > > Oakley Main Mode', the first collections of payloads > > > > and > > > > > > the figure shown in the > > , section 3.6 'Transform Payload'. > > > > shows the RESERVED area of the Transform Payload (not the generic > > header RESERVED area), in both Transform 1 and 2 to be BETWEEN the > > 'Transform #' and the 'Transform-ID' fields. In example , I am > > assuming that the 'OAKLEY' present in the field is the 'Transform-ID'. > > > > shows the RESERVED2 area of the Transform Payload (not the generic > > header RESERVED area), to be FOLLOWING the 'Transform-ID'. > > > I'll give you my interpretation, but we'll need to hear the same thing > from Dan Harkins and/or Dave Carrel (authors of the ISAKMP/Oakley > draft). If you look at section 4.1.1 of you'll see two full > examples of the payloads. I think the drawing in is leftover from > the format in the ISAKMP-05 or -06 Internet Draft. I believe the > agreement made between the ISAKMP, ISAKMP/Oakley, and IPSEC DOI I-D > editors was that the Transform # field and the Transform ID field were > together followed by the 2 octet RESERVED2 field. Again, we should hear > from Dan Harkins and/or Dave Carrel to make sure we're in agreement. Yes, that's right. The payload explosions in 5.7.1 of the resolution document are incorrect. The transform payload is as Doug describes. But, 5.7.1 is incorrect for another reason, and section 4.1.1 of the base ISAKMP draft shares this. Figure 6 and section 3.5 of the base ISAKMP draft show a spi-size field which denotes the size of the *variable length* SPI. Section 4.1.1 does not have this field and sets the SPI to 8 octets (same with 5.7.1 in the resolution document). Section 2.4 of the base ISAKMP draft says "For uniformity, all SPIs are 8 octets long" but this I think is a leftover from the ISAKMP-05 or ISAKMP-06 draft which did not contain a spi-size in the proposal payload. Doug, is this correct? The spi is, in fact, variable and it's size is determined by the spi-size field? > > 2) In listed above in question 1), 'OAKLEY' is in the > > 'Transform-ID' field. I have looked in and but I do not find the > > transform id values listed anywhere. I also looked in the > > but I don't see anything that looks > > like a really good answer there either. > > > > Question: Is the OAKLEY transform-id to use the KEY_OAKLEY (1) transform > > value listed in section 4.4.2 'IPSEC ISAKMP Transform Values' > > of the document? The transform-ID for phase 1 negotiation (as defined by the resolution doc) is the same as the protocol-- PROTO_ISAKMP from 4.4.1 of the DOI. The transform-IDs for other protocols are described later in the DOI under the respective protocol description. Dan. From owner-ipsec Mon May 12 15:03:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00305 for ipsec-outgoing; Mon, 12 May 1997 15:03:44 -0400 (EDT) Message-Id: <199705121909.MAA02432@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tom_Markham@securecomputing.com (Tom Markham) Cc: wdmaugh@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com, ipsec@tis.com, cwilliams@cylink.com, balenson@tis.com, sabbott@tcel.com, gupta@us.ibm.com, isakmp-oakley@cisco.com Subject: Re: ISAKMP commit and notify usage In-Reply-To: Your message of "Wed, 07 May 1997 13:49:16 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 May 1997 12:09:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Tom, > I am trying to understand the usage of the ISAKMP commit bit flag and > notify messages. > > The ISAKMP header contains a flags field which contains a commit bit. When > set by the sender this tells the peer ISAKMP not to use the (ISAKMP or > IPSEC ?) SA until the sender transmits an informational exchange. > Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that > once an ISAKMP SA has been established, the Informational Exchange MUST be > transmitted under the protection provided by the ISAKMP SA. > > - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? It prevents use of the IPsec SAs. It wouldn't make sense to use this for phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to be intended for the forthcoming phase 2 exchange. The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley doc) is a 3 message exchange and upon receipt of the responder's only message, the initiator has all the information necessary to stuff the IPsec SAs into its SA table. If this is done before the final message is composed (a hash from initiator to responder) there is a possibility of that SA being used by the kernel (or IPsec process or whatever depending on your OS flavor). If the timing is right (or wrong I guess) valid IPsec packets could arrive at the responder before hash which completed the exchange and allowed the responder to stuff the SAs in its own SA table. These packets would be dropped. If the COMMIT bit was set by either party, the Quick Mode exchange would become a 4 message exchange and the initiator would not stuff its SAs until receipt of the notify message. The responder would stuff its SAs first. Yes, this would make it ready for use before the intiator was ready but since the initiator started this its got some packets queued up and waiting to be sent. It's unlikely that the responder also has packets queued up and waiting, it could, but it's just unlikely. The timing would have to be real horrible (and the SA would have to be sharable-- no PFS) for the responder to use the SA before the initiator was ready. Anyway, I personally don't see this as a big problem and haven't had any trouble using ISAKMP and IPsec without the COMMIT bit. > - What notify message type payload is used to commit/tell the peer ISAKMP > that it is time to start using the encryption key/SA? Good question. I think it's the CONNECTED notify message from 3.14.1. > - Is there an integrity check on the Notification Payload? Does each piece > of notification data define its own integrity mechanism? The OAKLEY error > payload appends a Sig/prf Payload. That is to be added to the next rev of the ISAKMP/Oakley document. Once the ISAKMP SA has been established SKEYID_a should be used to protect informational exchanges in the same fashion it is used to protect Quick Mode exchanges-- i.e. HDR*, HASH, NOTIFY. Where HASH = prf(SKEYID_a, M-ID, NOTIFY). regards, Dan. From owner-ipsec Tue May 13 13:30:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08060 for ipsec-outgoing; Tue, 13 May 1997 13:21:11 -0400 (EDT) Message-Id: <3.0.32.19970513102353.00920530@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 May 1997 10:25:34 -0700 To: ipsec@tis.com From: John Burke Subject: Re: ISAKMP commit and notify usage Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe more needs to be said to clarify the need for Commit, and I believe Dan H. is not right to say, that Commit is not necessary in phase I. The strongest reason which demands use of Commit is, the possibility of losing the final message of an exchange in the network. ISAKMP is being used at the UDP layer and so has no protections against loss except its own prescription for retransmissions. The party who sends the final message has no indication that the message was lost and retransmission is required, particularly for the case where that party is going to send the first message afterward. A party sending the last message of Phase I, will sometimes have a Phase II initiation which they are going to send immediately after. But this should wait until the party receives confirmation from the other side. At 12:09 PM 5/12/97 -0700, Daniel Harkins wrote: > Hi Tom, > >> I am trying to understand the usage of the ISAKMP commit bit flag and >> notify messages. >> >> The ISAKMP header contains a flags field which contains a commit bit. When >> set by the sender this tells the peer ISAKMP not to use the (ISAKMP or >> IPSEC ?) SA until the sender transmits an informational exchange. >> Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that >> once an ISAKMP SA has been established, the Informational Exchange MUST be >> transmitted under the protection provided by the ISAKMP SA. >> >> - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? > > It prevents use of the IPsec SAs. It wouldn't make sense to use this for >phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to >be intended for the forthcoming phase 2 exchange. I would disagree that Commit is unnecessary in Phase I, per what I discuss above. > The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley >doc) is a 3 message exchange and upon receipt of the responder's only >message, the initiator has all the information necessary to stuff the IPsec >SAs into its SA table. If this is done before the final message is composed >(a hash from initiator to responder) there is a possibility of that SA >being used by the kernel (or IPsec process or whatever depending on your OS >flavor). If the timing is right (or wrong I guess) valid IPsec packets could >arrive at the responder before hash which completed the exchange and allowed >the responder to stuff the SAs in its own SA table. These packets would be >dropped. While it is okay that one designs protocol which makes it easier to work within the current operating systems, still such problems as Dan describes above actually constitute bugs in implementation either of the operating system or of the ISAKMP. One cannot hope to use net protocol design to fix all the bugs in various implementations. It is necessary however that protocol deal with the hostile net environments in which the user public generally will be operating, and assuming that all messages can be lost is one of the basics which net protocols must cover. > If the COMMIT bit was set by either party, the Quick Mode exchange would >become a 4 message exchange and the initiator would not stuff its SAs >until receipt of the notify message. The responder would stuff its SAs first. >Yes, this would make it ready for use before the intiator was ready but >since the initiator started this its got some packets queued up and waiting >to be sent. It's unlikely that the responder also has packets queued up and >waiting, it could, but it's just unlikely. The timing would have to be real >horrible (and the SA would have to be sharable-- no PFS) for the responder to >use the SA before the initiator was ready. > > Anyway, I personally don't see this as a big problem and haven't had any >trouble using ISAKMP and IPsec without the COMMIT bit. The fact that one hasn't had trouble at this point of experience in ISAKMP protocol does not strike me as evidence that protections are not needed. Some network environments are much more hostile than others and protocol design is supposed to deal with it. Cylink intends to take that line in its implementation. > [ other things: fine.] > regards, > > Dan. A further problem in the ISAKMP draft: it prescribes retransmissions even for the final message, but discusses no way in which one can be provoked to retransmit a final message. I think the following considerations are necessary. The final message can always be lost, even if it is the "Connected" message. The party who expects to receive the final message would in that case receive instead the encrypted traffic which follows (for the case of completing Phase I, read, a Phase II initiation). Now if the party was awaiting the "Connected" message, AND the received message can be verified as correct, they can assume the other party completed the SA. In all other cases the only action one can take here is, to retransmit the last ISAKMP message one sent, trying to provoke the partner to retransmit the final message. This implies that, if you are the party sending the final message, then you should retain that message for a while, with the SA establishment last-state; it can be saved in LRU buffers, and it can be discarded when you get evidence the partner has established the SA. Best regards, John Burke Cylink, Sunnyvale, CA. From owner-ipsec Tue May 13 21:01:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11030 for ipsec-outgoing; Tue, 13 May 1997 20:59:23 -0400 (EDT) Date: Tue, 13 May 1997 21:05:48 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199704291302.JAA28064@earth.hpc.org> References: Yourmessage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ho@earth.hpc.org (Hilarie Orman) From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: hugo@ee.technion.ac.il, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie + Hugo, As in my immediately preceeding message, I apologize for being tardy in my response. I've thought about the idea of including a null integrity transform in ESP, as you have both suggested, and I don't think it's a good idea. Note that there seems to be general agreement that using ESP w/o authentication is OK if one also applies AH to packets, so there is already a precendent for situations where no authentication algorithm would be selected. Thus, adding a null authentication algorithm would, I fear, create the potential for confusion, since it already would be appropriate thing to negotiate in some circumstances. Also, negotiation of a null authentication algorithm seems equivalent to negotiation of NO authentication algorithm, so I don't see the benefit from that perspective either. Instead, I suggest that we leave this section of ESP as it is, and note in the architecture document the security implications of not including authentication in ESP when Ah also is not applied to packets. That discussion will observe that some uses of AH with ESP avoid the need for autentication in ESP but that use of ESP without AH is dangerous in most other ciscumstances and thus such use should be negotiated only under very carefully controlled circumstances. Steve From owner-ipsec Tue May 13 21:01:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11018 for ipsec-outgoing; Tue, 13 May 1997 20:58:55 -0400 (EDT) Date: Tue, 13 May 1997 21:05:41 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199705011403.RAA24818@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@tis.com From: Stephen Kent Subject: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In an effort to reach closure on the suggested changes to the latest ESP spec, I suggest the following revision, in addition to my earlier message about authenticationless ESP: - The optional IV field will be removed; if an encryption algorithm requires an IV, it will be transmitted as the initial portion of the ciphertext payload. The definition of the encryption algorithm as provided for use with ESP, will specify the presence (or absence) or an IV, and describe its length. the recent I-Ds on RC5 and CAST adopt this approach to algorithm definition. I'm still not sure that we have concensus on what to do about the AR counter field in ESP. If authentication is NOT negotiated, then it seems somewhat odd to include this field. It would align the start of the payload on an 8-byte boundary, though this would not appear to be strictly required by IPv6 conventions. However, if folks rellly want the payload to be 8-byte aligned, I'll make the AR counter mandatory, as in AH, even if authentication is not selected. I'm looking for feedback on this, so votes are solicited. Finally, in talking with a couple of active contributors, I've gotten the impression that there is support for encryptionless ESP, as defined in the current I-D. The argumemts are that this should be easy to implement (since it is just ESP without encryption turned on), it is more efficient than AH, and it is both appropriate and adequate in tunnel mode, as an alternative to tunnel mode AH. So, I'd like to conduct a straw poll on this topic too. Steve From owner-ipsec Tue May 13 21:01:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11019 for ipsec-outgoing; Tue, 13 May 1997 20:58:55 -0400 (EDT) Date: Tue, 13 May 1997 21:05:44 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199704281959.MAA00938@dharkins-ss20.cisco.com> References: Your message of "Fri, 18 Apr 1997 11:31:42 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Daniel Harkins From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Sorry to be late in responding, but intervening conferences have kept me busy. The message I get is that the idea of negotiating the use of anti-replay, and of negotiating window size in AH (or ESP), is unattractive for several reasons: - this is really a recipient security concern, and thus need not be negotiated with the sender - it adds to the complexity of SA negotiation, making more work for implementors - more complex negotiations introduce the opportunity for security bugs These are all valid observations. However, I do find the argument about sender knowledge of the window size and fault isolation compeling. Just assuming that the receiver is enforcing AR abd that the window size is 32 is simple, but also simplistic. Also, when I tend to use the phrase "I don't find this argument compelling" it is usually wityh regard to changinf the status quo, i.e., an argument should be compelling to warrant changing the existing spec. I note that there are published I-Ds for additional AH transforms call for AR, but the base document does not, so a compliant implementation that chose to implement AR would have to negotiate a transform that included AR, separate from the default AR mode of no AR. So, the argument that needs to be compelling is why one ought to change from the published specs, which would require negotiation of AR. Nonetheless, I propose the following compromise. Have the sender always transmit the AR counter, thus preserving the 8-byte AH alignment when using the default auth data size of 12 bytes. Allow the receiver to determine, unilaterally, whether to check the AR counter, and to do so against a window size chosen byb the receiver. Make 32 the default window size, and allow for large window sizes, in multiples of 32. However, have the receiver notify the sender of the selected window size (if any) as part of the SA negotiation. This simplifies the negotiation since only the receiver needs tell the sender of the former's selected window size, but now the sender has specific info about the security service parameters empoyed on the SA. This differs from the implementors' agreement only in the last detail. Hopefully it does not introduce significant complexity (the receiver need only declare a constant response if it's election of AR is constant) in the code. What does the WG say? I'd like to receive straw poll votes on this. Steve From owner-ipsec Tue May 13 21:50:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11295 for ipsec-outgoing; Tue, 13 May 1997 21:50:33 -0400 (EDT) Message-Id: <3.0.32.19970514015549.008a4100@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 14 May 1997 01:55:55 +0000 To: Stephen Kent From: "Steven M. Bellovin" Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: Daniel Harkins , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:05 PM 5/13/97 -0400, Stephen Kent wrote: > >Nonetheless, I propose the following compromise. Have the sender always >transmit the AR counter, thus preserving the 8-byte AH alignment when using >the default auth data size of 12 bytes. Allow the receiver to determine, >unilaterally, whether to check the AR counter, and to do so against a >window size chosen byb the receiver. Make 32 the default window size, and >allow for large window sizes, in multiples of 32. However, have the >receiver notify the sender of the selected window size (if any) as part of >the SA negotiation. This simplifies the negotiation since only the >receiver needs tell the sender of the former's selected window size, but >now the sender has specific info about the security service parameters >empoyed on the SA. While I'm still not convinced that the receiver need say anything -- there are many more parameters one could send for fault isolation, such as TCP timer parameters and various queue length limits -- this is probably a reasonable compromise. I do feel fairly strongly that the AR field should always be present. When fields are in some sense optional, the question of whether or not to transmit them turns on the relative cost of possibly unneeded bytes versus the complexity of dealing with variable-format headers. In this case, I expect that the AR field will almost always be used; thus, it's worth carrying even for the rare cases where it would be ignored. Besides, the 8-byte alignment is important for IPv6. I ran some calculations on the space overhead for AH, using actual packet size distributions. With no AR field, we could possibly truncate the hash calculation to 8 bytes (though I suspect we'd actually use the full 16 bytes). The total space required was 6% over the base value. With AR, and a 12-byte HMAC, the overhead was 9%. The difference of 3% is a small fraction of the normal monthly traffic growth. I conclude that it's irrelevant to performance. I believe that I'm using old size distribution data, but since the trend has been towards increased packet sizes -- and hence for less of a percentage hit for a fixed increment -- my numbers are quite conservative. From owner-ipsec Wed May 14 10:24:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15643 for ipsec-outgoing; Wed, 14 May 1997 10:15:37 -0400 (EDT) From: svakil@usr.com Mime-Version: 1.0 Date: Wed, 14 May 1997 09:11:53 -0500 Message-ID: <379CD511.3000@usr.com> To: ipsec@tis.com Subject: Re[2]: ISAKMP commit and notify usage Content-Type: multipart/mixed; boundary="IMA.Boundary.334026368" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.334026368 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part John, Your example fits the phase 1 aggressive exchange. From the ISAKMP + Oakley draft: Oakley Aggressive mode with signatures in conjunction with ISAKMP is described as follows: Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni, IDii --> 2. <-- HDR, SA, KE, Nr, IDir, [ CERT, ] SIG_R 3. HDR, [ CERT, ] SIG_I --> In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R respectively. If the responder sets the Commit flag in message #2, then how is the Initiator going to generate message #3? In 2, the responder tells the initator "Don't use the SA 'till you receive a notification from me". But, the initiator needs to use the signature algorithm from the SA to generate SIG_I in mesasge #3. So, the initiator waits for a notify message from the responder to generate message #3, and the responder waits for message #3 from the initiator to generate the notify!!! Seems like I'm missing something here. Sumit A. Vakil Software Engineer Routing Consulting Engineering US Robotics, Access Corp. ______________________________ Reply Separator _________________________________ Subject: Re: ISAKMP commit and notify usage Author: John Burke at Internet Date: 5/13/97 10:25 AM I believe more needs to be said to clarify the need for Commit, and I believe Dan H. is not right to say, that Commit is not necessary in phase I. The strongest reason which demands use of Commit is, the possibility of losing the final message of an exchange in the network. ISAKMP is being used at the UDP layer and so has no protections against loss except its own prescription for retransmissions. The party who sends the final message has no indication that the message was lost and retransmission is required, particularly for the case where that party is going to send the first message afterward. A party sending the last message of Phase I, will sometimes have a Phase II initiation which they are going to send immediately after. But this should wait until the party receives confirmation from the other side. At 12:09 PM 5/12/97 -0700, Daniel Harkins wrote: > Hi Tom, > >> I am trying to understand the usage of the ISAKMP commit bit flag and >> notify messages. >> >> The ISAKMP header contains a flags field which contains a commit bit. When >> set by the sender this tells the peer ISAKMP not to use the (ISAKMP or >> IPSEC ?) SA until the sender transmits an informational exchange. >> Subsection 4.8 of the ISAKMP spec - Informational Exchange - states that >> once an ISAKMP SA has been established, the Informational Exchange MUST be >> transmitted under the protection provided by the ISAKMP SA. >> >> - Does this prevent use of the encryption key/SA by ISAKMP or only IPSEC? > > It prevents use of the IPsec SAs. It wouldn't make sense to use this for >phase 1 and, in fact, I would interpret receipt of this bit in phase 1 to >be intended for the forthcoming phase 2 exchange. I would disagree that Commit is unnecessary in Phase I, per what I discuss above. > The point of this bit is that a Quick Mode exchange (from the ISAKMP+Oakley >doc) is a 3 message exchange and upon receipt of the responder's only >message, the initiator has all the information necessary to stuff the IPsec >SAs into its SA table. If this is done before the final message is composed >(a hash from initiator to responder) there is a possibility of that SA >being used by the kernel (or IPsec process or whatever depending on your OS >flavor). If the timing is right (or wrong I guess) valid IPsec packets could >arrive at the responder before hash which completed the exchange and allowed >the responder to stuff the SAs in its own SA table. These packets would be >dropped. While it is okay that one designs protocol which makes it easier to work within the current operating systems, still such problems as Dan describes above actually constitute bugs in implementation either of the operating system or of the ISAKMP. One cannot hope to use net protocol design to fix all the bugs in various implementations. It is necessary however that protocol deal with the hostile net environments in which the user public generally will be operating, and assuming that all messages can be lost is one of the basics which net protocols must cover. > If the COMMIT bit was set by either party, the Quick Mode exchange would >become a 4 message exchange and the initiator would not stuff its SAs >until receipt of the notify message. The responder would stuff its SAs first. >Yes, this would make it ready for use before the intiator was ready but >since the initiator started this its got some packets queued up and waiting >to be sent. It's unlikely that the responder also has packets queued up and >waiting, it could, but it's just unlikely. The timing would have to be real >horrible (and the SA would have to be sharable-- no PFS) for the responder to >use the SA before the initiator was ready. > > Anyway, I personally don't see this as a big problem and haven't had any >trouble using ISAKMP and IPsec without the COMMIT bit. The fact that one hasn't had trouble at this point of experience in ISAKMP protocol does not strike me as evidence that protections are not needed. Some network environments are much more hostile than others and protocol design is supposed to deal with it. Cylink intends to take that line in its implementation. > [ other things: fine.] > regards, > > Dan. A further problem in the ISAKMP draft: it prescribes retransmissions even for the final message, but discusses no way in which one can be provoked to retransmit a final message. I think the following considerations are necessary. The final message can always be lost, even if it is the "Connected" message. The party who expects to receive the final message would in that case receive instead the encrypted traffic which follows (for the case of completing Phase I, read, a Phase II initiation). Now if the party was awaiting the "Connected" message, AND the received message can be verified as correct, they can assume the other party completed the SA. In all other cases the only action one can take here is, to retransmit the last ISAKMP message one sent, trying to provoke the partner to retransmit the final message. This implies that, if you are the party sending the final message, then you should retain that message for a while, with the SA establishment last-state; it can be saved in LRU buffers, and it can be discarded when you get evidence the partner has established the SA. Best regards, John Burke Cylink, Sunnyvale, CA. --IMA.Boundary.334026368 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 378B28D0; Tue, 13 May 97 13:27:25 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id NAA24582; Tue, 13 May 1997 13:06:25 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08060 for ipsec-outgoing; Tue, 13 May 1997 13:21:11 -0400 (EDT) Message-Id: <3.0.32.19970513102353.00920530@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 May 1997 10:25:34 -0700 To: ipsec@tis.com From: John Burke Subject: Re: ISAKMP commit and notify usage Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.334026368-- From owner-ipsec Wed May 14 12:32:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16579 for ipsec-outgoing; Wed, 14 May 1997 12:21:19 -0400 (EDT) Date: Wed, 14 May 1997 09:27:25 -0700 (MST) Message-Id: <199705141627.JAA09792@baskerville.CS.Arizona.EDU> From: "Mason J. Katz" To: ipsec@tis.com Subject: UofA linux ipsec release Sender: owner-ipsec@ex.tis.com Precedence: bulk ANNOUNCEMENT ------------ The University of Arizona, is releasing its first version of Linux IPSEC. Complete information about this software can be found at OVERVIEW -------- This software is based on the x-kernel and runs as a user space process with access to network traffic. A single Linux kernel loadable module is used to divert all incoming and outgoing Ethernet frames to an x-kernel process. Throughput for DES/MD5 traffic, measured on a 120Mhz Pentium, is approximately 220kb/s. Keys must be managed manually, or with Photuris. There is currently no support for ISAKMP/Oakley, and it does not support anti-replay counters. REQUIREMENTS ------------ - Linux Kernel V 2.0.x (Intel only) - Proven's Pthreads (available from webpage) BACKGROUND ---------- Over the course of this project, our research has focused on developing highly modular protocols for network security. We attempted to demonstrate that security enhancements could be added to a well-constructed protocol architecture in a manner that is easy, clean, and without unnecessary performance impact. We felt we demonstrated this with our x-kernel implementation, and chose a more standard platform for distributing our software. We then developed the idea of a dual-stack architecture based on Linux kernel loadable modules. This architecture allowed us to use all our previous work, without modification, and allows Unix applications to take advantage of a platform with stronger security mechanisms. Although we are not currently tracking the IPSEC architecture, we believe that the released version can be brought up to date and extended to allow for more services. It is being released as a reference architecture for adding advanced network capabilities to Linux and for experimenting with security policies. SURVEY ------ Name of Implementation : x-kernel IPSEC Version Described : 1.0 Organization : Univ. of Arizona, Dept of CS Which IP versions are supported : IPv4 Implements RFC-1828 AH MD5 : YES Implements RFC-1829 ESP DES-CBC : YES Implements AH HMAC MD5 : NO Implements AH HMAC SHA-1: NO Implements Combined ESP (DES+MD5+Replay, etc) : NO Other AH Implemented Transforms : NO Other ESP Implemented Transforms : ESP-3DES Transport mode : YES Tunnel mode : YES Key Management : Manual, Photuris (draft 8, Elliptical curves), Platforms : x-kernel, Linux Lineage of IPsec Code : University of Arizona Lineage of Key Mgmt Code: University of Arizona Location of Source Code : http://www.cs.arizona.edu/security/hpcc-blue/ linux.html ftp://ftp.cs.arizona.edu/xkernel/ xkernel.v3.2.security.tar.Z POINTS of Contact : Mason Katz Claimed Interoperability: From owner-ipsec Wed May 14 15:05:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17547 for ipsec-outgoing; Wed, 14 May 1997 14:46:44 -0400 (EDT) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" , "'svakil@usr.com'" Subject: RE: Re[2]: ISAKMP commit and notify usage Date: Wed, 14 May 1997 14:46:14 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the conclusion I came to when implementing the commit bit. For phase 1 I check for exchange type, if its not Aggressive I'll signal Invalid flag if the commit bit is set. It didn't seem to make much sense for Main Mode. ---- Greg Carter Entrust Technologies carterg@entrust.com >---------- >From: svakil@usr.com[SMTP:svakil@usr.com] >Sent: Wednesday, May 14, 1997 10:11 AM >To: ipsec@tis.com >Subject: Re[2]: ISAKMP commit and notify usage > ><> > John, > Your example fits the phase 1 aggressive exchange. > > From the ISAKMP + Oakley draft: > > Oakley Aggressive mode with signatures in conjunction with ISAKMP is > described as follows: > > Initiator Responder > ----------- ----------- > 1. HDR, SA, KE, Ni, IDii --> > > 2. <-- HDR, SA, KE, Nr, IDir, > [ CERT, ] SIG_R > > 3. HDR, [ CERT, ] SIG_I --> > > In both modes, the signed data, SIG_I or SIG_R, is the result of the > negotiated digital signature algorithm applied to HASH_I or HASH_R > respectively. > > If the responder sets the Commit flag in message #2, then how is the > Initiator going to generate message #3? In 2, the responder tells the > initator "Don't use the SA 'till you receive a notification from me". > But, the initiator needs to use the signature algorithm from the SA to > generate SIG_I in mesasge #3. So, the initiator waits for a notify > message from the responder to generate message #3, and the responder > waits for message #3 from the initiator to generate the notify!!! > Seems like I'm missing something here. > > Sumit A. Vakil > Software Engineer > Routing Consulting Engineering > US Robotics, Access Corp. > > > From owner-ipsec Wed May 14 15:20:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17646 for ipsec-outgoing; Wed, 14 May 1997 15:05:21 -0400 (EDT) Message-Id: <199705141911.PAA12081@codex.cis.upenn.edu> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Cc: kent@bbn.com Date: Wed, 14 May 1997 15:11:14 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I oppose encryptionless ESP. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM3oOUb0pBjh2h1kFAQGVVQQAoCGBpO4QJULgv/lDV9kg0TIp9m4EV+fs 2/696TtL/CV6WXqsD7Zo2xrKiCSff8aANBHfS1i3H7pGRQT/Hu40+KG7A/6BfoYh CswuFM7iOVNMEKAa8c1SQQsovnceBlAOdP+9as7Kv5DZM1uAFXoQHIioIJlnFR6Z 9cnT/8nSyCU= =0mHX -----END PGP SIGNATURE----- From owner-ipsec Wed May 14 15:25:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17664 for ipsec-outgoing; Wed, 14 May 1997 15:09:54 -0400 (EDT) Message-Id: <199705141915.PAA12106@codex.cis.upenn.edu> To: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: kent@bbn.com Date: Wed, 14 May 1997 15:15:27 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I don't like negotiating arbitrary AR sizes (even in multiples of 32). If 32 might not sufficient, then have a choice between 32 and 64. I sincerely doubt anyone will bother to implement anything larger. Cheers, - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM3oPTr0pBjh2h1kFAQFQqwQAkluzPtdPQegly4kHVFfixmeifzXgKCNY UbJ2+bedYbOI+Pf8vdr7A02nwR4GN+lRuBhD6kjWTrdc86p/RoyYnpjiS1nMdJGg ucIOJwLILaQoxpSlQKt093p1f6A4DhOpzbHrK+SI9EuNFRGu7YQxalheLlNlK7PR TRaPjLiCglA= =t+hV -----END PGP SIGNATURE----- From owner-ipsec Wed May 14 15:55:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17903 for ipsec-outgoing; Wed, 14 May 1997 15:54:17 -0400 (EDT) Date: Wed, 14 May 1997 16:00:59 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705141915.PAA12106@codex.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos, Larger window sizes are multiples of 32, so the term "arbitrary" may be no more appropriate for them as it is for the base size of 32. Recall that we chose 32 mostly because of the ability to do efficient window management in a 32-bit machine, which is sort of arbitrary, right? There is no requirement for a receiver to support anything other than 32, so I'm not sure what (non-local) burden is implied if a receiver does choose to support bigger windows. However, if the Wg wants to mandate support for ONLY a fixed set of window sizes, maybe 32 and 64 would suffice. Steve From owner-ipsec Wed May 14 15:55:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17909 for ipsec-outgoing; Wed, 14 May 1997 15:54:43 -0400 (EDT) Date: Wed, 14 May 1997 16:01:05 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705141911.PAA12081@codex.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos, I don't mean to say your vote (well, maybe I do ;-)), but could you briefly describe your reason for voting against encryptionless ESP? Steve From owner-ipsec Wed May 14 15:59:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17933 for ipsec-outgoing; Wed, 14 May 1997 15:59:47 -0400 (EDT) Message-Id: <199705142006.AA135450365@relay.hp.com> To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: kent's message of Tue, 13 May 1997 21:05:41 -0400. Date: Wed, 14 May 1997 16:06:04 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > - The optional IV field will be removed; if an encryption algorithm > requires an IV, it will be transmitted as the initial portion of the > ciphertext payload. This makes sense and only impacts document modularity, not interoperability. I strongly support this proposal. > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. I'm mildly opposed to this, on the grounds that it complicates an authentication-only ipsec implementation. - Bill From owner-ipsec Wed May 14 16:10:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18003 for ipsec-outgoing; Wed, 14 May 1997 16:10:19 -0400 (EDT) Message-Id: <199705142017.AA150991028@relay.hp.com> To: Stephen Kent Cc: Daniel Harkins , ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: kent's message of Tue, 13 May 1997 21:05:44 -0400. Date: Wed, 14 May 1997 16:17:07 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Nonetheless, I propose the following compromise. Have the sender always > transmit the AR counter, thus preserving the 8-byte AH alignment when using > the default auth data size of 12 bytes. Allow the receiver to determine, > unilaterally, whether to check the AR counter, and to do so against a > window size chosen byb the receiver. Make 32 the default window size, and > allow for large window sizes, in multiples of 32. However, have the > receiver notify the sender of the selected window size (if any) as part of > the SA negotiation. Seems like a reasonable compromise. It should not require significant code for the sender to ignore the additional attribute; the receiver need only send it if it supports variable replay window sizes (and thus already has significant additional complexity); and, if the receiver erroneously omits the attribute but does support larger-than-default windows, you can still interoperate. The attribute should be defined as "replay window *at least* this large" - Bill From owner-ipsec Wed May 14 16:22:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18108 for ipsec-outgoing; Wed, 14 May 1997 16:21:22 -0400 (EDT) From: Uri Blumenthal Message-Id: <9705142026.AA55965@hawpub.watson.ibm.com> Subject: Re: ESP revisions straw poll To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Wed, 14 May 1997 16:26:29 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199705142006.AA135450365@relay.hp.com> from "Bill Sommerfeld" at May 14, 97 04:06:04 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld says: > > .......impression that there is support for encryptionless ESP, > > as defined in the current I-D. > > I'm mildly opposed to this........... Count me on. I rather dislike this feature and see no reason for its existence. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Wed May 14 16:32:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18176 for ipsec-outgoing; Wed, 14 May 1997 16:31:57 -0400 (EDT) Message-Id: <199705142034.QAA06294@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Stephen Kent cc: "Angelos D. Keromytis" , ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-reply-to: Your message of "Wed, 14 May 1997 16:00:59 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 14 May 1997 16:34:32 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > Larger window sizes are multiples of 32, so the term "arbitrary" > may be no more appropriate for them as it is for the base size of 32. > Recall that we chose 32 mostly because of the ability to do efficient > window management in a 32-bit machine, which is sort of arbitrary, right? > There is no requirement for a receiver to support anything other than 32, > so I'm not sure what (non-local) burden is implied if a receiver does > choose to support bigger windows. However, if the Wg wants to mandate > support for ONLY a fixed set of window sizes, maybe 32 and 64 would suffice. I'm curious -- how wide to TCP windows get on a high bandwidth delay product link? Perry From owner-ipsec Wed May 14 16:57:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18370 for ipsec-outgoing; Wed, 14 May 1997 16:57:01 -0400 (EDT) Message-Id: <199705142103.RAA12759@codex.cis.upenn.edu> To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Wed, 14 May 1997 16:01:05 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13905.863643757.1@dsl.cis.upenn.edu> Date: Wed, 14 May 1997 17:02:38 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > > I don't mean to say your vote (well, maybe I do ;-)), but could you >briefly describe your reason for voting against encryptionless ESP? > Certainly; for one, i don't see the point. I don't think it's that much of a performance gain over straight AH. Second, it's yet another option, so yet another place where things can go wrong in an implementation. Finally (and most importantly), do we really want to allow some form of authentication where the IP header (the addresses) is *not* authenticated ? I believe we don't, but perhaps there is some reason for it ? -Angelos From owner-ipsec Wed May 14 17:11:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18444 for ipsec-outgoing; Wed, 14 May 1997 17:11:00 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199705142117.OAA10711@kebe.eng.sun.com> Subject: Re: ESP revisions straw poll To: ipsec@tis.com Date: Wed, 14 May 1997 14:17:31 -0700 (PDT) In-Reply-To: <9705142026.AA55965@hawpub.watson.ibm.com> from "Uri Blumenthal" at May 14, 97 04:26:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Encryptionless ESP may cause more harm than good. By its nature, ESP is "encryption enabling technology" and is therefore not exportable w/o jumping through various hoops. Even if your product is only using encryptionless ESP, it may still have to jump through hoops. AH is not encryption enabling technology, and an AH that has IP or IPv6 as its next header (commonly called, "tunnel-mode AH") solves the problems an encryptionless ESP solves. Its only disadvantage is including some of the IP header fields in the AH computation. Given a (possibly slight) performance loss vs. legal headaches and hassles, I'll swallow the loss. Bottom line: I do not like encryptionless ESP. Dan From owner-ipsec Wed May 14 17:38:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18618 for ipsec-outgoing; Wed, 14 May 1997 17:38:07 -0400 (EDT) Message-Id: <199705142144.OAA04294@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: Your message of "Tue, 13 May 1997 21:05:41 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 14:44:19 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. The argumemts are that this should be easy to implement > (since it is just ESP without encryption turned on), it is more efficient > than AH, and it is both appropriate and adequate in tunnel mode, as an > alternative to tunnel mode AH. So, I'd like to conduct a straw poll on > this topic too. I give this a thumbs down. I get the feeling that another generic tunneling protocol is being proposed with authenticationless ESP and encryptionless ESP. We're going to end up with EP and I don't think that's really solving the problem at hand. It has never made sense to me to have ESP not authenticate the outer IP header. I don't have any solid numbers on whether ESP authentication by itself is faster than AH authentication but my gut feeling is there can't be *that* big a difference. I also can't see why one wouldn't want to authenticate as much as possible. We've moved beyond simple wordsmithing in these changes. The patient is now under general anesthetic and we're carving a hole in his chest. In that light, I'd like to propose a final operation (if he was under local anesthetic I wouldn't dare). I'd like to see making authentication uniform. And, of course, doing away with encryptionless (and authenticationless) ESP. regards, Dan. From owner-ipsec Wed May 14 18:04:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18795 for ipsec-outgoing; Wed, 14 May 1997 18:04:16 -0400 (EDT) Message-ID: <337A37C4.6B19@redbacknetworks.com> Date: Wed, 14 May 1997 15:08:04 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Stephen Kent CC: ipsec@tis.com Subject: Re: ESP revisions straw poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I don't mean to say your vote (well, maybe I do ;-)), but could you > briefly describe your reason for voting against encryptionless ESP? Steve, I don't mean to sound pissy, but I'm a bit pissed. This issue was discussed quite a bit in Memphis. Quite a few people spoke out on both sides and then a show of hands was taken to see how folks felt. Overwhelmingly the consensus was NOT to have encryptionless ESP. You seem to disagree with this, and now it appears that you are using your handle on the documents to hold this issue in an endless state of discussion until your opinion wins out. Please, let move on and not kill IPSEC with endless document wrangling. Very good points have been made on both sides. But it's time to move on. Dave Carrel From owner-ipsec Wed May 14 18:55:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA19134 for ipsec-outgoing; Wed, 14 May 1997 18:55:23 -0400 (EDT) From: pau@watson.ibm.com Date: Wed, 14 May 1997 19:08:48 -0400 Message-Id: <9705142308.AA24508@secpwr.watson.ibm.com> To: kent@bbn.com Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: jasKIGeBNdcKCsKhmwHdmQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. The argumemts are that this should be easy to implement > (since it is just ESP without encryption turned on), it is more efficient > than AH, and it is both appropriate and adequate in tunnel mode, as an > alternative to tunnel mode AH. So, I'd like to conduct a straw poll on > this topic too. > > Steve > > Steve, as a person who has been implementing IPSEC and KMP since 1994, I like to offer my $0.02 opinions against encryptionless ESP. 1. It would make it very confusing to distinguish between ESP and AH. This is serious because not all users/administartors of IPSEC are experts on IPSEC. If they are confused, they may define the wrong IPSEC policy and lose all security. 2. It would make it even harder to code/do ISAKMP negotiation. 3. AH does incur some extra overhead because it covers IP header. However, according to our actual measurement (published in the 5th USENIX UNIX Security Conf.), this overhead is trivial compared to time spent in computing MD5 digest. So I feel encryptionless ESP does not save that much. Whoever want peformance should optimize their crypto implementations; the saving would be much greater. Pau-Chen From owner-ipsec Wed May 14 19:33:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA19377 for ipsec-outgoing; Wed, 14 May 1997 19:32:36 -0400 (EDT) Message-Id: <3.0.1.32.19970514190803.006fdafc@nntpd.lkg.dec.com> X-Sender: altamatt@nntpd.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 14 May 1997 19:08:03 -0400 To: Stephen Kent From: Matt Thomas Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com In-Reply-To: References: <199705141911.PAA12081@codex.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:01 PM 5/14/97 -0400, Stephen Kent wrote: >Angelos, > > I don't mean to say your vote (well, maybe I do ;-)), but could you >briefly describe your reason for voting against encryptionless ESP? I'll give you mine. The first is that I want to ship an authentication- only IPsec implementation. This is real easy if all I have to deal with AH. If I have to worry about including support encryption-less ESP it will greatly complicate matters. If you want the attributes of an encryptionless ESP, modify the definition of AH to allow it, then get it to be negotiated (the default being the old AH behavior). -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Wed May 14 19:38:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA19395 for ipsec-outgoing; Wed, 14 May 1997 19:38:37 -0400 (EDT) Message-Id: <3.0.1.32.19970514194341.006c012c@nntpd.lkg.dec.com> X-Sender: altamatt@nntpd.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 14 May 1997 19:43:41 -0400 To: Daniel Harkins , Stephen Kent From: Matt Thomas Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com In-Reply-To: <199705142144.OAA04294@dharkins-ss20> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:44 PM 5/14/97 -0700, Daniel Harkins wrote: > We've moved beyond simple wordsmithing in these changes. The patient >is now under general anesthetic and we're carving a hole in his chest. >In that light, I'd like to propose a final operation (if he was under >local anesthetic I wouldn't dare). I'd like to see making authentication >uniform. And, of course, doing away with encryptionless (and >authenticationless) ESP. Hear. Hear. Except for the authenticationless. If only has to do AH to get the IP header, you don't want to do another authentication. (I'd rather see ESP follow the same exact rules as AH...) -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Wed May 14 20:04:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA19557 for ipsec-outgoing; Wed, 14 May 1997 20:04:09 -0400 (EDT) Message-Id: <199705150010.RAA04425@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Tue, 13 May 1997 21:05:44 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 17:10:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > Nonetheless, I propose the following compromise. Have the sender always > transmit the AR counter, thus preserving the 8-byte AH alignment when using > the default auth data size of 12 bytes. Allow the receiver to determine, > unilaterally, whether to check the AR counter, and to do so against a > window size chosen byb the receiver. Make 32 the default window size, and > allow for large window sizes, in multiples of 32. However, have the > receiver notify the sender of the selected window size (if any) as part of > the SA negotiation. This simplifies the negotiation since only the > receiver needs tell the sender of the former's selected window size, but > now the sender has specific info about the security service parameters > empoyed on the SA. > > This differs from the implementors' agreement only in the last detail. > Hopefully it does not introduce significant complexity (the receiver need > only declare a constant response if it's election of AR is constant) in the > code. If I understand this correctly, the initiator of the KMP can choose to add this attribute to his security suite offering to inform the responder of his AR window size. He can also choose not to send it and the default is assumed by the responder. Likewise, the responder can choose to send this attribute back describing his AR window size regardless of whether the initiator sent one (and the attribute value the initiator sends has no bearing on the value the responder sends). In other words, this is not a negotiable attribute; it is an informational attribute. If that understanding isn't correct ignore the rest of this email but please straighten me out, While complexity isn't introduced, something else is. We'd always understood that the responder in the KMP would either accept or reject a proposed suite of services in its entirety and not change anything in the offer or add anything that wasn't in the offer. This changes that. Granted, it's a simple change and a check for "didn't add anything or change anything-- except for replay window size" is pretty easy, but I want the WG to realize this change is being proposed before a show of hands. IPsec SA negotiation takes place under the protection of the ISAKMP SA so I don't think this is opening up a security hole. In the way I understand this compromise, I'm fine with it. regards, Dan. From owner-ipsec Wed May 14 21:36:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA20127 for ipsec-outgoing; Wed, 14 May 1997 21:34:56 -0400 (EDT) Message-ID: <01BC6096.46834460@BIGHUGE> From: Rob Adams To: "'Stephen Kent'" , "'ipsec@tis.com'" Subject: RE: ESP revisions straw poll Date: Wed, 14 May 1997 18:40:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk No Optional IV. IV is included in payload. A good model now since we don't do varied keys a la Hughes anymore. Replay field always in the packet, always sent, used by receiver or not. Aligns the packet, fewer options, yada yada yada... Replay window size is irrelevant. No encryptionless ESP. Not enough gain (don't do a few byte moves/clears) for the complexity of another option. If we're going to do this, bag AH altogether and just make the MAC cover the header in ESP, as Dan, I think suggested. I believe this is what we agreed on in Memphis. -Rob -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Tuesday, May 13, 1997 6:06 PM To: ipsec@tis.com Subject: ESP revisions straw poll Folks, In an effort to reach closure on the suggested changes to the latest ESP spec, I suggest the following revision, in addition to my earlier message about authenticationless ESP: - The optional IV field will be removed; if an encryption algorithm requires an IV, it will be transmitted as the initial portion of the ciphertext payload. The definition of the encryption algorithm as provided for use with ESP, will specify the presence (or absence) or an IV, and describe its length. the recent I-Ds on RC5 and CAST adopt this approach to algorithm definition. I'm still not sure that we have concensus on what to do about the AR counter field in ESP. If authentication is NOT negotiated, then it seems somewhat odd to include this field. It would align the start of the payload on an 8-byte boundary, though this would not appear to be strictly required by IPv6 conventions. However, if folks rellly want the payload to be 8-byte aligned, I'll make the AR counter mandatory, as in AH, even if authentication is not selected. I'm looking for feedback on this, so votes are solicited. Finally, in talking with a couple of active contributors, I've gotten the impression that there is support for encryptionless ESP, as defined in the current I-D. The argumemts are that this should be easy to implement (since it is just ESP without encryption turned on), it is more efficient than AH, and it is both appropriate and adequate in tunnel mode, as an alternative to tunnel mode AH. So, I'd like to conduct a straw poll on this topic too. Steve From owner-ipsec Wed May 14 23:40:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA20674 for ipsec-outgoing; Wed, 14 May 1997 23:39:33 -0400 (EDT) Date: Thu, 15 May 97 03:02:02 GMT From: "William Allen Simpson" Message-ID: <5866.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > - The optional IV field will be removed; if an encryption algorithm > requires an IV, it will be transmitted as the initial portion of the > ciphertext payload. The definition of the encryption algorithm as provided > for use with ESP, will specify the presence (or absence) or an IV, and > describe its length. the recent I-Ds on RC5 and CAST adopt this approach > to algorithm definition. > Yes. This is what we have always wanted. > I'm still not sure that we have concensus on what to do about the AR > counter field in ESP. If authentication is NOT negotiated, then it seems > somewhat odd to include this field. It would align the start of the payload > on an 8-byte boundary, though this would not appear to be strictly required > by IPv6 conventions. However, if folks rellly want the payload to be > 8-byte aligned, I'll make the AR counter mandatory, as in AH, even if > authentication is not selected. I'm looking for feedback on this, so votes > are solicited. > AR field (called "Sequence Number") should immediately follow the SPI. Always present, 8-byte aligned. It should start at 1. It should always be incremented by sender, even when authentication is not present. > Finally, in talking with a couple of active contributors, I've gotten the > impression that there is support for encryptionless ESP, as defined in the > current I-D. The argumemts are that this should be easy to implement > (since it is just ESP without encryption turned on), it is more efficient > than AH, and it is both appropriate and adequate in tunnel mode, as an > alternative to tunnel mode AH. So, I'd like to conduct a straw poll on > this topic too. > No. None of the arguments are compelling. - It is not needed, as we already have another mechanism. - any added complexity to negotiation adds complexity to implementation and testing. - the improvement in efficiency is in the measurement noise -- insignificant. On the other hand, as has been pointed out previously, we are powerless to stop someone from creating a "null encryption" transform. But, it should not be part of the base specification. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Thu May 15 09:00:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23679 for ipsec-outgoing; Thu, 15 May 1997 08:59:10 -0400 (EDT) Message-Id: <3.0.32.19970515130122.008ade80@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 15 May 1997 13:02:24 +0000 To: perry@piermont.com From: "Steven M. Bellovin" Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: Stephen Kent , "Angelos D. Keromytis" , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:34 PM 5/14/97 -0400, Perry E. Metzger wrote: > >Stephen Kent writes: >> Larger window sizes are multiples of 32, so the term "arbitrary" >> may be no more appropriate for them as it is for the base size of 32. >> Recall that we chose 32 mostly because of the ability to do efficient >> window management in a 32-bit machine, which is sort of arbitrary, right? >> There is no requirement for a receiver to support anything other than 32, >> so I'm not sure what (non-local) burden is implied if a receiver does >> choose to support bigger windows. However, if the Wg wants to mandate >> support for ONLY a fixed set of window sizes, maybe 32 and 64 would suffice. > >I'm curious -- how wide to TCP windows get on a high bandwidth delay >product link? We're talking apples and oranges here -- the "window" under discussion for ipsec is the out-of-order packet window, which has little to do with the size of a TCP window. The former is intended to protect us against routing and network-level weirdnesses; the latter is a bound on performance. But if you're interested in the TCP window size, see RFC1323. Briefly, though, the effective window size variable is raised to 32 bits from 16. Thus, you can get really good performance if you can allocate 4 gigabytes of main memory for TCP input buffers... From owner-ipsec Thu May 15 10:49:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24448 for ipsec-outgoing; Thu, 15 May 1997 10:46:58 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 09:46:45 -0500 To: Greg Carter From: Tom_Markham@securecomputing.com (Tom Markham) Subject: RE: Re[2]: ISAKMP commit and notify usage Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >This is the conclusion I came to when implementing the commit bit. >For phase 1 I check for exchange type, if its not Aggressive I'll signal >Invalid flag if the commit bit is set. It didn't seem to make much >sense for Main Mode. >---- I do not see anything in the ISAKMP spec which limits the use of the commit bit to the agressive mode. Granted this may have been the driving reason for the commit. I would like to allow the general use of the commit bit by initiator or responder in any mode. This allows support for security policies and implementations (e.g. multicast) which may require ISAKMP to access another machine prior to allowing encrypted traffic to flow. Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Thu May 15 11:37:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24813 for ipsec-outgoing; Thu, 15 May 1997 11:37:13 -0400 (EDT) Message-Id: <199705151533.IAA05289@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Tom_Markham@securecomputing.com (Tom Markham) Cc: Greg Carter , ipsec@tis.com Subject: Re: Re[2]: ISAKMP commit and notify usage In-Reply-To: Your message of "Thu, 15 May 1997 09:46:45 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 08:33:36 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > >This is the conclusion I came to when implementing the commit bit. > >For phase 1 I check for exchange type, if its not Aggressive I'll signal > >Invalid flag if the commit bit is set. It didn't seem to make much > >sense for Main Mode. > >---- > > I do not see anything in the ISAKMP spec which limits the use of the commit > bit to the agressive mode. Granted this may have been the driving reason > for the commit. I witnessed the birth of the commit bit and it's driving reason was for phase 2 exchanges (Quick Mode). Period. > I would like to allow the general use of the commit bit by initiator or > responder in any mode. This allows support for security policies and > implementations (e.g. multicast) which may require ISAKMP to access another > machine prior to allowing encrypted traffic to flow. How (and why!) would you use this bit in a phase 1 exchange? How does multicast change anything? Phase 1 merely establishes the ISAKMP peer-to-peer communication channel. I don't see the point in using the commit bit there. Dan. From owner-ipsec Thu May 15 12:19:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24990 for ipsec-outgoing; Thu, 15 May 1997 12:17:51 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 11:20:51 -0500 To: Daniel Harkins From: Tom_Markham@securecomputing.com (Tom Markham) Subject: Re: Re[2]: ISAKMP commit and notify usage Cc: Tom_Markham@securecomputing.com (Tom Markham), Greg Carter , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 8:33 AM 5/15/97, Daniel Harkins wrote: >How (and why!) would you use this bit in a phase 1 exchange? How does >multicast change anything? Phase 1 merely establishes the ISAKMP peer-to-peer >communication channel. I don't see the point in using the commit bit there. I was not clear. I agree that the commit bit is used to hold off phase 2 exchanges. Using commit to hold off part of a phase 1 exchange does not make sense. Greg wrote >This is the conclusion I came to when implementing the commit bit. >For phase 1 I check for exchange type, if its not Aggressive I'll signal >Invalid flag if the commit bit is set. It didn't seem to make much >sense for Main Mode. Greg implied that commit was only valid in agressive mode and I am saying that there may be other times when the commit bit could be used. I gave multicast as an example of when commit *might* be used. I have not seen any multicast, IPSEC/ISAKMP systems yet so I do not want to take away a tool which might be useful to them. Here is a hypothetical situation which does not involve multicast. Imagine someone behind a firewall establishing a SA from their desktop to a remote server. 1. Their workstation does the ISAKMP exchange with the remote server to establish the AH and ESP keys. The firewall would allow ISAKMP exchanges through because it could perform some filtering. 2. Their workstation passes the AH (but not ESP) key to the firewall so the firewall can authenticate packets before letting them pass. 3. The server and workstation begin exchanging IPSEC (AH and ESP) protected traffic. The firewasl allows authenticated AH packets to bypass the remaining firewall filters. In this case I would use the commit bit to hold off IPSEC traffic until I had the AH key in place in the firewall. I hope this reduces the confusion. Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Thu May 15 13:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25682 for ipsec-outgoing; Thu, 15 May 1997 13:48:11 -0400 (EDT) Message-Id: <199705151753.NAA14039@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Re[2]: ISAKMP commit and notify usage In-reply-to: Your message of "Thu, 15 May 1997 11:20:51 CDT." Date: Thu, 15 May 1997 13:53:03 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tom" == Tom Markham writes: Tom> Greg implied that commit was only valid in agressive mode and Tom> I am saying that there may be other times when the commit bit Tom> could be used. I don't agree that your scenario is reasonable. I have no opinion about the commit bit though. Tom> I gave multicast as an example of when commit *might* be Tom> used. I have not seen any multicast, IPSEC/ISAKMP systems yet Tom> so I do not want to take away a tool which might be useful to Tom> them. Here is a hypothetical situation which does not involve Tom> multicast. Imagine someone behind a firewall establishing a Tom> SA from their desktop to a remote server. Tom> 1. Their workstation does the ISAKMP exchange with the remote Tom> server to establish the AH and ESP keys. The firewall would Tom> allow ISAKMP exchanges through because it could perform some Tom> filtering. Tom> 2. Their workstation passes the AH (but not ESP) key to the Tom> firewall so the firewall can authenticate packets before Tom> letting them pass. How do you pass the key to the firewall? Write that spec, then let's talk about the commit bit :-) :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM3tNdqZpLyXYhL+BAQHp/QMAtRSWkYAgnVsz4/QqOduabZ/D1ij04qxz rVFXjUucMgUpelvxVrtLURT0AQDJVe470wFPgA0Ig8mnSweXPZA6WWBhcyyUDrNF DSooK0a7k2P7vfamJYUKGE0UmwPo2DPb =xN3/ -----END PGP SIGNATURE----- From owner-ipsec Thu May 15 14:34:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25953 for ipsec-outgoing; Thu, 15 May 1997 14:33:56 -0400 (EDT) To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-revised-enc-mode-00.txt Date: Thu, 15 May 1997 14:32:24 -0400 Message-ID: <9705151432.aa13211@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A revised encryption mode for ISAKMP/Oakley Author(s) : R. Canetti, P. Cheng, H. Krawczyk Filename : draft-ietf-ipsec-revised-enc-mode-00.txt Pages : 6 Date : 05/06/1997 The ISAKMP/Oakley document [HC97] describes a proposed standard for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated and secret keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. The public-key encryption method of carrying out Phase 1 of the key exchange in the ISAKMP/Oakley document requires two public key encryption and decryption operations from both the Initiator and the Responder. The present document describes a small modification to this method. The resulting method requires only one public key encryption and decryption operation from each party, while maintaining (and even improving on) the strong security properties of the ISAKMP/Oakley public-key encryption mode. Remark: This document is NOT self-contained. It uses notation and definitions of [HC97]. It is best read in conjunction with [HC97]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-revised-enc-mode-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-revised-enc-mode-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970515142834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-revised-enc-mode-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970515142834.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu May 15 15:01:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26067 for ipsec-outgoing; Thu, 15 May 1997 14:58:34 -0400 (EDT) X-Sender: markham@mailhost.sctc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 14:00:36 -0500 To: dharkins@cisco.com From: Tom_Markham@securecomputing.com (Tom Markham) Subject: Re: Re[2]: ISAKMP commit and notify usage Cc: Greg Carter , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks I am clearly confused about the use of the commit bit. Is the following is a valid interpretation. The commit bit refers to use of the "following association." If the commit bit is set during phase 1, it means not to begin phase 2 until the notify/connected is received. If the commit bit is set during phase 2, it means not to send the IPSEC traffic until the notify/connected is received. Commit does not mean that exchanges within the current phase are not encrypted. Tom Markham markham@securecomputing.com Secure Computing Corporation Phone (612) 628-2754 2675 Long Lake Road Fax: (612) 628-2701 Roseville, MN 55113 www.securecomputing.com From owner-ipsec Thu May 15 15:23:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26230 for ipsec-outgoing; Thu, 15 May 1997 15:22:39 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142103.RAA12759@codex.cis.upenn.edu> References: Your message of "Wed, 14 May 1997 16:01:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:26:47 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos and Pau, As I mentioned in my message, the most obvious apporpriate use of ESP w/o encryption is in tunnel mode, where authenitcation of the outer IP addresses does not appear to be critical. This is a common scenario for VPNs, and might be used in conjunction with a transport mode encypted ESP, in nested fashion, e.g., to provide security to a server or desktop behind the firewall. As for the performance concern, we disagree. We are implementing ESP without encryption, in tunnel mode, for inter-router authentication and our analysis suggested that this was preferable to AH in tunnel mode. While I agree with Pau's observation that the greatest gain in a software implementation is to be had in better hash algorithm implementations, there is still the issue of the additional hit due to header copying. Also, I have been approached by some folks who are looking to implement ESP in hardware (e.g., outboard of a supercomputer). The selective authentication characteristics of AH make that hard, while the ESP pure encapsulation design is amenable to efficient DMA processing. Steve From owner-ipsec Thu May 15 15:23:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26224 for ipsec-outgoing; Thu, 15 May 1997 15:22:09 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142034.QAA06294@jekyll.piermont.com> References: Your message of "Wed, 14 May 1997 16:00:59 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:21:55 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, A good question, but one that requires translating from TCP window measurements (in bytes) to IPSEC units (packets), as Steve Bellovin pointed out. I don't know who has the data to make this translation. However, we have seen smoe statistics cited that note modest numbers of packets arriving out of order in some circumstances, and that prompted us to abandon the window size of 1 that had been in a previous draft of AH. It is the lack of good data in this area, plus the move to bigger, faster pipes, that makes it hard to figure out if 32 or 64 is big enough, although such numbers seem reasonable for today's Internet. Steve From owner-ipsec Thu May 15 15:44:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26359 for ipsec-outgoing; Thu, 15 May 1997 15:44:20 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142144.OAA04294@dharkins-ss20> References: Your message of "Tue, 13 May 1997 21:05:41 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:47:56 -0400 To: Daniel Harkins From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, We have a serious communication problem here. ESP has always had a tunnel mode; the previous AH I-D and the architecture I-D lacked references to a tunnel mode for AH, and this has been fixed in the latest versions. I'm sure you are familiar with the existing RFCs and they explicitly do not mandate authentication for ESP, i.e., not all transforms include such functionality. I don't recall if you were a participant in the early days of the WG, but originally AH was envisioned as providing just authentication and ESP just encryption. We later expanded ESP to provide authentcation, because it was more efficient than having a separate AH layer. I recall this clearly, because I argued that it was appropriate. ESP is a clean encapsulation protocol, with a header and trailer. AH is a rather ungainly protocol, in that it reaches forward and selectively protects portions of the IP header. As I noted in another message today, this complicates implementations striving for a high degree of hardware integration. In IPv6, what is protected can become even more complex, given the increased complexity of the IP header structure. In most cases, not including the few parts of the IP header that are covered by AH (at least in IPv4) would seem to have relatively few security implications; in tunnel mode it seems largely superflous as most of the outer header fields would be discarded upon receipt anyway. In transport mode the source IP address would be unique relative to the SPI, so here too the need for such coverage seem minor. The obvious v4 motivation for AH is use of security labels, but these are very, very rarely used in the Internet; RFC 1108 is now historical! In v6, the source route extension is the best candiadte for coverage, so far. Thus there appear to be relatively few IP header fields (or options/extensions) that ARE covered by AH and that have security implications. Exactly what security problems do folks feel arise if none of the IP header is integrity protected, in each of the contexts cited above? I do have a suggestion, though, to help reach closure on this topic. What if we say that an IPSEC implementation MAY elect to send packets that are authenticated, but not encrypted? That makes the existing implementations compliant in this regard, yet holds open th opportunity for future implementations to offer this feature if there is sufficinet demand. An attempt to negotiate a set of algorithms that includes no encryption can be rejected just like an attempt to negotiate use of an encryption algorithm that is not supported. One could even encode this as a null encryption algorithm, as Bill Simpsom noted, if that would make processing any more uniform. Steve From owner-ipsec Thu May 15 15:44:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26373 for ipsec-outgoing; Thu, 15 May 1997 15:44:52 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970514194341.006c012c@nntpd.lkg.dec.com> References: <199705142144.OAA04294@dharkins-ss20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:50:27 -0400 To: Matt Thomas From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt, Proposing that ESP authentication be changed to operate the same way as AH would represent a major change, at a time when I hear implementors arguing strongly against making changes. Let me refer you to my very recent message that questions what security problems arise, in tunnel and transport modes, if undetected modification of IP headers and options take place. In performing the analysis, keep in mind what fields/options/extensions are covered by AH (the answer is very few) and what level of muxing can occur in each mode, relative to the IP address info. Steve From owner-ipsec Thu May 15 16:14:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26489 for ipsec-outgoing; Thu, 15 May 1997 16:09:52 -0400 (EDT) Message-Id: <199705152014.AA072247290@relay.hp.com> To: Matt Thomas Cc: Daniel Harkins , Stephen Kent , ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: matt.thomas's message of Wed, 14 May 1997 19:43:41 -0400. <3.0.1.32.19970514194341.006c012c@nntpd.lkg.dec.com> Date: Thu, 15 May 1997 16:14:50 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Hear. Hear. Except for the authenticationless. If [one] has to do AH > to get the IP header, you don't want to do another authentication. (I'd > rather see ESP follow the same exact rules as AH...) Hmm. Why can't you just do tunnel mode ESP in that case, where the inner IP header is the one which really needs protecting. - Bill From owner-ipsec Thu May 15 17:29:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26898 for ipsec-outgoing; Thu, 15 May 1997 17:28:09 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705142117.OAA10711@kebe.eng.sun.com> References: <9705142026.AA55965@hawpub.watson.ibm.com> from "Uri Blumenthal" at May 14, 97 04:26:29 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 15:29:19 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald), Matt Thomas From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan and Matt, If you ship AH by itself, you will be have an authention-only offering, but it won't be a complete IPSEC. That's fine for IPv4, and non-comliant for IPv6. For IP v6 compliance, both AH and ESP are required, thus whether we include or exclude an encryptionless mode of ESP will not affect the export license status of IPv6 implementations that, as required, support IPSEC. For IPv4, you are right that having an encryptionless mode of ESP will not make it easier to export ESP, but then it won't make it any harder either. I don't know about the rest of the WG members, but I do have personal experience in getting export licenses for crypto technology I have developed at BBN, so I appreciate what is involved. Nonetheless, the bottom line is that this proposed feature set for ESP will not change its export status. I don't think that I suggested otherwise in the discussion, but I apologize if anyone misunderstood the intent of the proposal. Steve From owner-ipsec Thu May 15 17:33:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26964 for ipsec-outgoing; Thu, 15 May 1997 17:33:41 -0400 (EDT) Date: Thu, 15 May 1997 17:40:21 -0400 (EDT) Message-Id: <199705152140.RAA10428@jekyll.piermont.com> From: "Perry E. Metzger" To: ipsec@tis.com Subject: ESP without encryption Reply-to: perry@piermont.com X-Reposting-Policy: please ask before redistributing Sender: owner-ipsec@ex.tis.com Precedence: bulk I think the ESP without encryption issue was settled at Memphis -- for good or ill, consensus seemed to be "no ESP without encryption" and it appears that consensus continues to be that way. I think we should accept the consensus and move on. Perry From owner-ipsec Thu May 15 17:45:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27031 for ipsec-outgoing; Thu, 15 May 1997 17:45:41 -0400 (EDT) Message-Id: <199705152152.OAA05636@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: Your message of "Thu, 15 May 1997 15:47:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 14:52:01 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, As Strother Martin said in Cool Hand Luke, "What we haf he-uh, is a faili-yure to com-yune-a-cate". (It's hard to effect an accent in email, but I'm sure you're familiar with that famous quote and the southified manner in which is was made). I'm not a IPsec old timer but I am familiar with the existing RFCs; I know ESP has always had a tunnel mode and I know that the previous AH doc did not. I also remember the discussions to add authentication to ESP. What I was suggesting was to have uniformity in authentication. That is, to have ESP include the intransient fields of the outer IP header in its integrity check in the same fashion as AH does. I was not suggesting that AH be scrapped nor was I suggesting adding tunnelling capability to a protocol that already has it. I know this is a new suggestion and perhaps it will be shot down but since the changes being discussed on this list will change the bits-on-the-wire I felt it was not inappropriate to suggest it. The ungainlyness of such a protocol is in the eye of the beholder, I guess. To me, ESP is a security protocol, not a generic tunnelling protocol. It could be made into a generic tunnelling protocol by making encryption and authentication optional I don't see the point. If you need a "clean encapsulating protocol" then why not use GRE tunnels (RFC1701)? My proposal is that AH does authentication, ESP does encryption with authentication. And the scope of the integrity check is identical for each. Dan. > We have a serious communication problem here. ESP has always had a > tunnel mode; the previous AH I-D and the architecture I-D lacked references > to a tunnel mode for AH, and this has been fixed in the latest versions. > I'm sure you are familiar with the existing RFCs and they explicitly do not > mandate authentication for ESP, i.e., not all transforms include such > functionality. I don't recall if you were a participant in the early days > of the WG, but originally AH was envisioned as providing just > authentication and ESP just encryption. We later expanded ESP to provide > authentcation, because it was more efficient than having a separate AH > layer. I recall this clearly, because I argued that it was appropriate. > > ESP is a clean encapsulation protocol, with a header and trailer. > AH is a rather ungainly protocol, in that it reaches forward and > selectively protects portions of the IP header. As I noted in another > message today, this complicates implementations striving for a high degree > of hardware integration. In IPv6, what is protected can become even more > complex, given the increased complexity of the IP header structure. > > In most cases, not including the few parts of the IP header that > are covered by AH (at least in IPv4) would seem to have relatively few > security implications; in tunnel mode it seems largely superflous as most > of the outer header fields would be discarded upon receipt anyway. In > transport mode the source IP address would be unique relative to the SPI, > so here too the need for such coverage seem minor. The obvious v4 > motivation for AH is use of security labels, but these are very, very > rarely used in the Internet; RFC 1108 is now historical! In v6, the source > route extension is the best candiadte for coverage, so far. Thus there > appear to be relatively few IP header fields (or options/extensions) that > ARE covered by AH and that have security implications. > Exactly what security problems do folks feel arise if none of the IP header > is integrity protected, in each of the contexts cited above? > > I do have a suggestion, though, to help reach closure on this > topic. What if we say that an IPSEC implementation MAY elect to send > packets that are authenticated, but not encrypted? That makes the existing > implementations compliant in this regard, yet holds open th opportunity for > future implementations to offer this feature if there is sufficinet demand. > An attempt to negotiate a set of algorithms that includes no encryption can > be rejected just like an attempt to negotiate use of an encryption > algorithm that is not supported. One could even encode this as a null > encryption algorithm, as Bill Simpsom noted, if that would make processing > any more uniform. From owner-ipsec Thu May 15 18:20:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27171 for ipsec-outgoing; Thu, 15 May 1997 18:20:04 -0400 (EDT) Message-Id: <199705152204.AA225823849@relay.hp.com> To: Stephen Kent Cc: Dan.McDonald@Eng.sun.com (Dan McDonald), Matt Thomas , ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: kent's message of Thu, 15 May 1997 15:29:19 -0400. Date: Thu, 15 May 1997 18:04:07 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Your experiences are directly at odds with my experiences dealing with export control issues, where frameworks (like ESP) which provide for end-user-accessible bulk encryption are problematic even if the encryption functionality is disabled. I suspect that we may be seeing the ... subjective ... nature of the crypto export control process at work here. - Bill From owner-ipsec Thu May 15 19:14:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA27419 for ipsec-outgoing; Thu, 15 May 1997 19:12:10 -0400 (EDT) Message-Id: <199705152318.TAA20621@codex.cis.upenn.edu> To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Thu, 15 May 1997 15:26:47 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15536.863738248.1@dsl.cis.upenn.edu> Date: Thu, 15 May 1997 19:17:28 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > As I mentioned in my message, the most obvious apporpriate use of >ESP w/o encryption is in tunnel mode, where authenitcation of the outer IP >addresses does not appear to be critical. This is a common scenario for >VPNs, and might be used in conjunction with a transport mode encypted ESP, >in nested fashion, e.g., to provide security to a server or desktop behind >the firewall. I still believe AH is what they should do. > As for the performance concern, we disagree. We are implementing >ESP without encryption, in tunnel mode, for inter-router authentication and >our analysis suggested that this was preferable to AH in tunnel mode. >While I agree with Pau's observation that the greatest gain in a software >implementation is to be had in better hash algorithm implementations, there >is still the issue of the additional hit due to header copying. Also, I >have been approached by some folks who are looking to implement ESP in >hardware (e.g., outboard of a supercomputer). The selective authentication >characteristics of AH make that hard, while the ESP pure encapsulation >design is amenable to efficient DMA processing. I didn't notice any significant differences in performance in any of the pure-software implementations i've been involved in. Following the rule of "optimizing the common case", i'd still optimize the hash function first. Also, i think the cost of header copying is probably overestimated; if one keeps enough space in the begining of the buffer/mbuf/skbuf/whatever, it is possible to do all the copying in the processor cache (L1). This is really minimal overhead. This also solves the hardware hashing problem (and for large packets, copying the header won't matter if you also have to copy the whole packet in a contiguous memory block, as opposed to it being in an mbuf chain or what have you). I'm not saying you don't have some arguments in favour of encryptionless ESP. However: a) the implementors at Memphis decided against it b) i've seen no one speak publically for it on the list except you c) i've talked to two people off the list who are for it, and one changed his mind d) it's about time we stop arguing So, i'll insist on no encryptionless ESP. Regards, -Angelos From owner-ipsec Thu May 15 20:19:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27775 for ipsec-outgoing; Thu, 15 May 1997 20:18:49 -0400 (EDT) Message-Id: <3.0.1.32.19970515202057.0076ef58@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 15 May 1997 20:20:57 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: revisions denial-of-draft attack Cc: jis@MIT.EDU, iab@ietf.org, PALAMBER@us.oracle.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >From: David Carrel >To: Stephen Kent >Please, let move on and not >kill IPSEC with endless document wrangling. This sentiment might well have rough consensus. -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition iQCVAgUBM3uoVcKmlvJNktGxAQHz0AQAqxqr9MHzv1ZowCJYVxngHVSzhWAWkuQT W5zqgKvyFqRwCXQFytiSDskwATGpIc9pB34cOe6wkQAtLElsgpYomKuyDWdrxXxo N8B+OCSu3bsH5OJDVVRJDgG/7T8iT6TaL8/C2HzLWxlKkI941esss3txyv7fviuE xbqcYGG+6sk= =2901 -----END PGP SIGNATURE----- From owner-ipsec Fri May 16 04:48:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00052 for ipsec-outgoing; Fri, 16 May 1997 04:45:05 -0400 (EDT) From: suren@teil.soft.net (S. Arockia Suren) Message-Id: <199705161947.OAA06335@teil.soft.net> Subject: Clarification please! To: ipsec@tis.com Date: Fri, 16 May 1997 14:17:05 -0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I beleive all negotiated SAs (ISAKMP SA as well Protocol SA) are bidirectional. The exchange of the respective SPI indicates so. Also the new exchanges described in Oakley resolution are also bidirectional. But ISAKMP draft says .. "Thus, ISAKMP SAs are bidirectional in nature". Is this only for ISAKMP SAs are also for Protocol SAs. Is there a possibility that Protocol SAs could be unidirectional either now or in the future. Thankx in advance, Suren. From owner-ipsec Fri May 16 08:55:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA01363 for ipsec-outgoing; Fri, 16 May 1997 08:54:22 -0400 (EDT) Date: Fri, 16 May 1997 08:57:23 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705161257.IAA08949@earth.hpc.org> To: suren@teil.soft.net Cc: ipsec@tis.com In-reply-to: Yourmessage <199705160858.BAA04918@baskerville.CS.Arizona.EDU> Subject: Re: Clarification please! Sender: owner-ipsec@ex.tis.com Precedence: bulk ESP and AH SA's are unidirectional. Oakley facilitates negotiation of a pair of SPI's, each one referring to a unique SA, going in "opposite" directions. You might think of the pair as being a bi-directional SA, but the terminology is probably more confusing than helpful. Hilarie From owner-ipsec Fri May 16 10:27:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01837 for ipsec-outgoing; Fri, 16 May 1997 10:25:01 -0400 (EDT) From: suren@teil.soft.net (S. Arockia Suren) Message-Id: <199705170130.UAA21421@teil.soft.net> Subject: Re: Clarification To: ipsec@tis.com Date: Fri, 16 May 1997 20:00:56 -0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >> I beleive all negotiated SAs (ISAKMP SA as well Protocol SA) >> are bidirectional. The exchange of the respective SPI indicates >> so. Also the new exchanges described in Oakley resolution >> are also bidirectional. But ISAKMP draft says .. "Thus, ISAKMP >> SAs are bidirectional in nature". Is this only for ISAKMP SAs >> are also for Protocol SAs. Is there a possibility that Protocol >> SAs could be unidirectional either now or in the future. >> > ESP and AH SA's are unidirectional. > > Oakley facilitates negotiation of a pair of SPI's, each one referring to > a unique SA, going in "opposite" directions. You might think of the pair > as being a bi-directional SA, but the terminology is probably more confusing > than helpful. > > Hilarie I agree. ISAKMP SAs are bidrectional because any of the negotiators can start phase2. Similarly after oakley negotiations any party can start to send IP packets. I would like to know if the later would be true in the future also. Does ISAKMP allow negotiations that will be used in only one direction inspite of SPIs exchanged. Suren. From owner-ipsec Fri May 16 12:43:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02672 for ipsec-outgoing; Fri, 16 May 1997 12:39:46 -0400 (EDT) Date: Fri, 16 May 1997 12:43:00 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705161643.MAA15687@earth.hpc.org> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been very puzzled by the opposition to auth-only ESP, so much so that I went back and reviewed messages from August 1995, in which I had tried to suggest it, and in which I thought there had been rough consensus that it was a good idea. Disappointingly, I now see that I was overly subtle, and the concept was confused with tunneling AH. But for the volume of IPSO argument at the time, I would have continued arguing for it back then. Auth-only ESP seems to be completely consistent with the design goals of the working group; note that encryption is entirely up to the sender in any case, so Steve Kent's suggestion that it MAY be done seems completely reasonable. Seriously, how can a group that bought into AH view an accommodation for auth-only as more than a triviality in terms of implementation? If belief has any merit in this discussion, and I note that more and more responses seem to be appealing to subjectivity, I believe that the market will ultimately choose to use ESP and ignore AH, and I further believe that this will be a good thing. In full honesty, I was concerned about the comment that suggested key negotiation would be more difficult with auth-only ESP, and I was hoping that someone with a little spare time could check on whether or not this is true; key negotiation requires confidentiality for some part of the exchange, and if there is a possibility of specifying an algorithm that was in the confidentiality class but didn't really provide the service, this would be Very Bad. A further belief, don't worry about IPSEC, it has been astoundingly resilient to the ravages of eternal argument. Though sometimes I worry ... IPSEC is a protocol As dead as dead can be First it killed a working group And now its killing me Hilarie From owner-ipsec Fri May 16 13:24:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03023 for ipsec-outgoing; Fri, 16 May 1997 13:23:21 -0400 (EDT) Message-Id: <199705161730.AA281943799@relay.hp.com> To: ho@earth.hpc.org (Hilarie Orman) Cc: suren@teil.soft.net, ipsec@tis.com Subject: Re: Clarification please! In-Reply-To: ho's message of Fri, 16 May 1997 08:57:23 -0400. <199705161257.IAA08949@earth.hpc.org> Date: Fri, 16 May 1997 13:29:58 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > You might think of the pair as being a bi-directional SA, but the > terminology is probably more confusing than helpful. Agreed. This seems to be a common, umm, "terminology barrier" which newcomers (myself included) trip over. Part of the problem is that nobody has yet come up with a decent name for a "set of related SA's". - Bill From owner-ipsec Fri May 16 13:51:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03152 for ipsec-outgoing; Fri, 16 May 1997 13:45:24 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705152204.AA225823849@relay.hp.com> References: kent's message of Thu, 15 May 1997 15:29:19 -0400. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 May 1997 13:50:09 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Perhaps I wasn't clear enough in my message. Let me try to restate my position, which may not be different from yours, but which seemed to be at odds with some of the previous messages: - AH and ESP are both (U.S.) export controlled, because they employ crypto - AH, because it does not provide confidentiality (encryption) and because the algorithms mandated for support ar hash/MAC algorithms, should be exportable under commodity jurisdiction license, which is relatively easy to get. Source code may be exportable (not just object code), but that's always a bit trickier. - ESP, with mandatory support for DES encryption, is much more strictly export controlled. Under current practice, unless there is a facility for key recovery, or credible plans in place for such, it iwll be very difficult to export an ESP implementation (even in object code form), and source code is definately a problem. Adding other (e.g., weaker) algorithms doesn't help with export, so long as a 56-bit DES is part of the package, as is currently required for ESP compliance. Adding another protocol feature, such as encryptionless ESP, will not make export any harder, not any easier. Steve From owner-ipsec Fri May 16 14:38:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03539 for ipsec-outgoing; Fri, 16 May 1997 14:36:51 -0400 (EDT) Message-Id: <199705161843.AA095628200@relay.hp.com> To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: kent's message of Fri, 16 May 1997 13:50:09 -0400. Date: Fri, 16 May 1997 14:43:19 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk [Maybe I'm just being dense, but there seems to be very broad consensus here against authentication-only ESP..] Steve, Thank you, it turns out that we are closer to agreement than I thought. Now, it may look to some like I'm caving in to the U.S. export control folks here, but no, I'm just being pragmatic about trying to get as much of the functionality deployed as quickly as possible. Pragmatically, there are going to be folks who are interested in deploying *subsets* of ipsec; in particular, an authentication-only implementation which leaves out bulk confidentiality services. My sense is that it will be easier to get export approval for an implementation which leaves out ESP entirely instead of one which "dumbs it down" by making it authentication-only, but like I said, given the subjective nature of the export control process it may well depend on how well you present your case to the gov't. In any event, not having to worry about authentication-only ESP would certainly make it easier to manage a "dual mode" source base.. - Bill From owner-ipsec Fri May 16 15:16:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03792 for ipsec-outgoing; Fri, 16 May 1997 15:12:21 -0400 (EDT) Message-Id: <01BC620C.56F72BA0@erussell-1.ftp.com> From: "Edward A. Russell" To: "'ipsec@tis.com'" , "'suren@teil.soft.net'" Subject: RE: Clarification and a single SA Date: Fri, 16 May 1997 15:17:58 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >>S. Arockia Suren (suren@teil.soft.net) said on 5/16/97 at 10:46 AM > > > ISAKMP SAs are bidrectional because any of the negotiators can >start phase2. Similarly after oakley negotiations any party can start to >send IP packets. I would like to know if the later would be true in the >future also. Does ISAKMP allow negotiations that will be used in only >one direction inspite of SPIs exchanged. > >Suren. > The last question in the above paragrah is getting lost. ISAKMP does not allow for a SINGLE one way SA to be negotiated. Always an identical pair (in terms of policy). This is unfortunate since it may be desirable to have bulk outbound transfers of secure data be encrypted, but the inbound acks could be only authenticated or even in the clear in order to save processing time. I suppose there is nothing to prevent TWO pairs of SAs from being negotiated (an secure Inbound/Outbound pair which is really only used for outbound, and an insecure Inbound/Outbound pair which is really only used for inbound) but that seems a bit wasteful and requires some input from the system's policy or application as to which outbound SA to use, for example. Edward Russell erussell@ftp.com From owner-ipsec Fri May 16 17:31:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04690 for ipsec-outgoing; Fri, 16 May 1997 17:28:53 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199705162135.OAA26975@kebe.eng.sun.com> Subject: Re: Clarification please! To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Fri, 16 May 1997 14:35:22 -0700 (PDT) Cc: ho@earth.hpc.org, suren@teil.soft.net, ipsec@tis.com In-Reply-To: <199705161730.AA281943799@relay.hp.com> from "Bill Sommerfeld" at May 16, 97 01:29:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Agreed. This seems to be a common, umm, "terminology barrier" which > newcomers (myself included) trip over. > > Part of the problem is that nobody has yet come up with a decent name > for a "set of related SA's". I've heard these tossed around by myself and others from time to time: SA PAIR - A pair of unidirectional SAs that provide protection on a unicast session by covering each direction. They are otherwise matched. e.g. SA spi=0x2112, AH, HMAC-MD5, A -> B SA spi=0x5150, AH, HMAC-MD5, B -> A SA BUNDLE - A set of SAs that provide different protections. e.g. SA spi=0x1001001, ESP, 3DES, , A -> B SA spi=0x82069, AH, HMAC-SHA1, A -> B Any comments? Dan From owner-ipsec Fri May 16 18:21:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04935 for ipsec-outgoing; Fri, 16 May 1997 18:20:22 -0400 (EDT) Message-Id: <199705162244.SAA01135@relay.rv.tis.com> Date: Fri, 16 May 97 18:25:50 EDT From: Charles Lynn To: ipsec@tis.com cc: Stephen Kent , CLynn@bbn.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I have a few comments on the recent postings. First, a procedural issue. > a) the implementors at Memphis decided against it It is my understanding that consensus includes more than implementers who were able to make it to an IETF meeting. It includes the whole working group, whether or not they were able to get to a face to face meeting. Second, there also seems to be a strong feeling that the working group should "Do The Right Thing" to provide the best security services we are collectively able to standardize for the users of the IP layer, i.e., our customers. This philosophy implies that whether or not something is hard to export should not be of primary concern. Thus arguments like: > By its nature, ESP is "encryption enabling technology" and is > therefore not exportable w/o jumping through various hoops. Even if > your product is only using encryptionless ESP, it may still have to > jump through hoops. do not belong in our technical arena. If we do not like what our politicians have decided, we can (more or less easily :-) change the politicians. If they want to provide incentives for businesses in other countries to develop their own IPSEC code, so be it. But if they implement the IETF's IPSEC architecture, they'll be using a good architecture, not one designed around export/import laws. As an example of this philosophy, the decision was made to mandate ESP as MUST be implemented for IPv6, even though ESP might be hard to export. From RFC 1883, "IPv6 Specification", Security Considerations This document specifies that the IP Authentication Header [RFC-1826] and the IP Encapsulating Security Payload [RFC-1827] be used with IPv6, in conformance with the Security Architecture for the Internet Protocol [RFC-1825]. Many have commented on not wanting an encryptionless ESP. One reason given is that AH is fine, and the extra work to munge headers is not very expensive, relative to the crypto code. That argument sounds correct, and if moving the bits were the only issue, that would be fine. I think that the main reason AH, as defined, is not a suitable replacement for an encryptionless ESP is that it does not provide an application with a way to perform end-to-end authentication of a payload without also trying protect other header fields whose value can be predicted a priori. I think that relying on such prediction is a big impediment to further internet growth and evolution. Just because we can predice what an IP base header will look like does not mean that we will be able to predict what, e.g., Routing Extension Header versions 1, 2, ... will look like in the future. I do not think that our customers will appreciate the argument that they can no longer use AH until they and their peers upgrade their systems, because they bought a NAT box or because of a change in the routing system needed to provide additional services or deal with exponential growth. Thus I think AH, as defined, places unnecessary restrictions on the evolution of the internet routing system, which needs all the freedom it can get to get our packets delivered. After all, except for the community using security labels, what additional security is provided by trying to protect the outer headers? In tunnel mode they are discarded. In end-to-end mode, if I get a packet, and verify that it is authentic because the body was processed by someone who shares a secret with me, I don't care what the header looks like. I am willing to leave the "try to protect the outer header" AH functionality for the community that thinks it is useful, if others are willing to provide a mechanism that allows another community to protect bodies without concern for headers. One way this mechanism could be provided would be to use a bit in the AH Reserved field to indicate that the authenticated information begins at the start of the AH header and ends at the end of the IP frame. This would permit evolution while not encountering the export problems folks feel is associated with ESP. Another reason for not trying to protect the IP addresses is that doing so encourages their use as security related identifiers. One of the lessons that I thought was learned from the IPv4 experience was that requiring security to be based on network attachment point identifiers, such as IP, NSAP, or ATM addresses, is a Bad Idea. Given the requirement for plug and play and dynamic address assignment that IPv6 is trying to meet, it seems like promoting the use of the IP address as a security identifier will make it more difficult for our IPSEC customers in the future when the identifiers change and certificates have to be replaced (and, I suspect, associated CRLs updated, etc.). I do not think that this is the direction we want to be going. Third, based on the email that I have seen, most folks agree with moving the IV out of the ESP header and into the beginning of the Payload Data area. I agree that this is a reasonable thing to do. But it has a hidden cost for IPv6. In IPv6 tunnel mode, the inner IPv6 header, which must be aligned on a 64-bit boundary, follows the 64-bit aligned ESP header and the algorithm dependent and negotiated IV. (Some have argued that this alignment is not strictly required. Others that it is. The "be conservative in what you send and liberal in what you accept" argues we follow the strict viewpoint.) Thus the space occupied by the IV field has to be a multiple of 64 bits to meet the IPv6 requirements. It seems this requires that, if the size of the IV is a function of the algorithm or is negotiated, then the negotiation protocol would have to be aware during the negotiation process of the IP version being protected. That seems rather complicated to me. I would instead suggest the architecture or ESP doc require that IV field size MUST be a multiple of 64 bits, and also specify how to pad IVs of other sizes to a multiple of 64 bits. Since most algorithms that I am aware of already use 64-bit IVs, this would not cause any additional processing. It would make it so that (some vendor's) deployed software would not suddenly break when a new algorithm which uses other sized IVs is deployed in the future. What do others think about making this a requirement? In summary: Removal of optional IV from ESP header: Yes, but require any IV field to be a multiple of 64 bits. AR field (both AH and ESP): Independent of any decisions about authentication with ESP: Always present, starts at 1 and always set by the sender. Receiver may process or ignore, with a window size selected by the receiver, minimum of 32 packets. I do not see a need for the sender to be informed of the actual size, but have no objections to it. Encryptionless ESP: In favor, but willing to accept equivalent functionality in AH. Charlie From owner-ipsec Fri May 16 19:03:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05130 for ipsec-outgoing; Fri, 16 May 1997 19:01:22 -0400 (EDT) Message-Id: <199705162307.QAA06419@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Charles Lynn Cc: ipsec@tis.com, Stephen Kent Subject: Re: ESP revisions straw poll In-Reply-To: Your message of "Fri, 16 May 1997 18:25:50 EDT." <199705162244.SAA01135@relay.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 May 1997 16:07:59 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, I take an immediate issue with your first point and therefore your conclusion. Your 2nd and 3rd seem reasonable at first read but your 1st just jumped out and bit me. > I have a few comments on the recent postings. > > First, a procedural issue. > > > a) the implementors at Memphis decided against it > > It is my understanding that consensus includes more than implementers > who were able to make it to an IETF meeting. It includes the whole > working group, whether or not they were able to get to a face to face > meeting. The overwhelming majority of people in Memphis gave encryptionless ESP a big thumbs down. An overwhelming majority of people who are posting to this list are also giving encryptionless ESP a big thumbs down. If that's not a consensus then please define what you feel is a consensus. Do you want 51% of the people who subscribe to this list? [snip] > In summary: [snip] > Encryptionless ESP: > In favor, but willing to accept equivalent functionality in AH. But are you willing to accept the wishes of the working group which may be at odds with yours (collectively, that is, as a member of the "IPSEC Document Editing Team")? If not then I'm sure someone else in this WG will step up-to-the-plate and assume control of the documents. Imagine if one year ago someone said that today key management would be basically solved-- minor edit/clarification notwithstanding-- but the basic architecture and protocol documents would be subject to contentious arguement and document wrangling. I would've laughed in their face! It's kind of funny in a perverted sort of way. Dan. From owner-ipsec Fri May 16 19:24:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05229 for ipsec-outgoing; Fri, 16 May 1997 19:23:22 -0400 (EDT) Message-Id: <199705162329.TAA26820@codex.cis.upenn.edu> To: Charles Lynn cc: ipsec@tis.com, Stephen Kent Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Fri, 16 May 1997 18:25:50 EDT." <199705162244.SAA01135@relay.rv.tis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17127.863825326.1@dsl.cis.upenn.edu> Date: Fri, 16 May 1997 19:28:47 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705162244.SAA01135@relay.rv.tis.com>, Charles Lynn writes: > It is my understanding that consensus includes more than implementers > who were able to make it to an IETF meeting. It includes the whole > working group, whether or not they were able to get to a face to face > meeting. It has also been the IETF "policy" that decisions are made by running code and rough consensus. I believe that a very large percentage of the implementors was at the IETF, and the majority of messages on this list has been against encryptionless ESP. Including yours, that makes 3 messages in favour of e-ESP (Steve, Hillary and you); i've seen many more against. I believe the matter has been discussed for a while and the WG has indeed decided against e-ESP. Let's not talk about this for so long that people will (again) walk away in disgust. > I am willing to leave the "try to protect the outer header" AH > functionality for the community that thinks it is useful, if others > are willing to provide a mechanism that allows another community to > protect bodies without concern for headers. You can do tunneling (IP in IP), with the inner packet being AH protected, ie: [IP][IP][AH][whatever] But more importantly, IPsec is a network layer protocol. It gives some assurances to the application. If the application cannot live with those, it should certainly use some higher layer security protocol (such as TLS). Trying to put in IPsec all the functionality of all protocol layers is a mistake. > One way this mechanism could be provided would be to use a bit in the > AH Reserved field to indicate that the authenticated information > begins at the start of the AH header and ends at the end of the IP > frame. This would permit evolution while not encountering the export > problems folks feel is associated with ESP. I think i could live with this, and it might not be too hard to do. > assignment that IPv6 is trying to meet, it seems like promoting the > use of the IP address as a security identifier will make it more > difficult for our IPSEC customers in the future when the identifiers > change and certificates have to be replaced (and, I suspect, > associated CRLs updated, etc.). I do not think that this is the > direction we want to be going. I'll remind you that IP addresses are supposed to be used as part of a security identifier; an address along with an SPI indicates the SA to use. Additionally, i don't see how dynamic IP will be hampered by IPsec in this respect, assuming a well thought out certificate scheme is in place; specifically, certificates for mobile agents should not include any IP addresses (this is a necessary but probably not sufficient condition). > negotiation protocol would have to be aware during the negotiation > process of the IP version being protected. That seems rather > complicated to me. I would instead suggest the architecture or ESP > doc require that IV field size MUST be a multiple of 64 bits, and > also specify how to pad IVs of other sizes to a multiple of 64 bits. > Since most algorithms that I am aware of already use 64-bit IVs, this > would not cause any additional processing. It would make it so that > (some vendor's) deployed software would not suddenly break when a new > algorithm which uses other sized IVs is deployed in the future. What > do others think about making this a requirement? I'm puzzled by this. Why wouldn't the standard padding at the end of the ESP payload be enough to handle alignment problems ? -Angelos From owner-ipsec Fri May 16 20:50:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA05576 for ipsec-outgoing; Fri, 16 May 1997 20:48:22 -0400 (EDT) Message-ID: <337D0139.374D@redbacknetworks.com> Date: Fri, 16 May 1997 17:52:09 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Charles Lynn CC: ipsec@tis.com, Stephen Kent Subject: Re: ESP revisions straw poll References: <199705162244.SAA01135@relay.rv.tis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > First, a procedural issue. > > > a) the implementors at Memphis decided against it > > It is my understanding that consensus includes more than implementers > who were able to make it to an IETF meeting. It includes the whole > working group, whether or not they were able to get to a face to face > meeting. Charlie, this working group has suffered a very long time from "procedural issues". The effect is pretty clear. Do we have a nailed down doc yet?? At the wg mtg's we try to agree to something. Then after the mtg, people argue about it on the list and claim "procedure" since they either don't like the outcome or just like to be heard (you know who you are). So things get argued around until the next mtg. Then at the meeting, when things get contentious, someone wearing a hat says: "Let's take this one to the list." On the list nothing get's said or nothing get's decided. Then a bunch of people are frustrated, so at the next mtg we try to agree to something. Then after the mtg, people argue about it on the list and claim procedure ... We need to accept one of our decisions and agree that it represents a reasonable consensus. The folks at the Memphis mtg represent the vast lions share of IPSEC developers. Crying "procedure" at this point is nothing more than sour grapes. It would be nice if the chair(s) would help focus this rather than sit silently in the gallery. The documents need to come out now with the current group consensus, or please let someone else finishe them. Dave Carrel (convinced that the "process" is NOT working.) From owner-ipsec Fri May 16 22:54:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06086 for ipsec-outgoing; Fri, 16 May 1997 22:50:53 -0400 (EDT) Message-Id: <199705170250.WAA18264@relay.hq.tis.com> Date: Fri, 16 May 97 22:55:41 EDT From: Charles Lynn To: Daniel Harkins cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I was not able to attend the WG meeting. I do not know what fraction of the WG was there. I suspect that there are many more WG members than I have seen responded to the straw poll. > But are you willing to accept the wishes of the working group which may > be at odds with yours (collectively, that is, as a member of the "IPSEC > Document Editing Team")? Sure I'm willing to accept the wishes of the working group for IETF standards. Many folk contribute ideas that do not end up in standards, but which help to make the things that get standardized better. Maybe seeing the usefulness of an authentication mechanism that does not require predicting what a packet will look like the future is one of those ideas; maybe not. Time and the customers will decide. For example, a couple minor changes to the IP Routing Extension Header would have made it trivial to process/forward and secure. But for whatever reason it was not done and now we have to spend the cycles living with it (making AH processing more complex), or changing the spec, based on implementation experience, as it works its way through the standardization process. It is a lot easier for all concerned if we can get it right, or as close to right as we can collectively achieve, the first time around. Needless to say, I would like to use as much of the IPSec work as possible as a basis for code I, and probably a lot of other folk with customers, have to deliver Real Soon Now, and not have to reinvent some of the wheel. Charlie BTW, if it was not clear that my comments are my own as an implementer, let me clarify that now. I was not speaking as a member of the "IPSEC Document Editing Team" when I responded to the straw poll. From owner-ipsec Fri May 16 23:15:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA06203 for ipsec-outgoing; Fri, 16 May 1997 23:13:53 -0400 (EDT) Message-Id: <199705170326.UAA26094@mailsun2.us.oracle.com> Date: 16 May 97 20:02:34 -0700 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: ESP New Draft Cc: PALAMBER@us.oracle.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk There has been considerable debate on the "changes" to the ESP specification. A new draft of ESP will be published before May 23. This new draft should focus the wide ranging discussions on this mailing list. We will expedite the progression of this specification and have a "last call" review start as soon as it is published. When this specification is published I urge the working group to submit concise and constructive comments in a form that could be readily incorporated into the specification. The "changes" in this new specification should not be significant! ESP implementations conforming to the Memphis implementors agreements will be conformant to this specification. The only issues for the ESP specification are the optional "value added" capabilities of ESP that include auth-only-ESP. These capabilities have been intensely debated because they allow a choice between the architectural application of the AH protocol versus the ESP protocol. As working group chair, I see no clear consensus to forbid the use of ESP with a null encryption algorithm (a.k.a auth-only-ESP). There have been many strong statements made to the mailing list recommending that ESP always encrypt. I've also talked to implementors developing auth-only-ESP as a "valued added" option. ESP has the flexibility to support any algorithm. Clear guidelines need to be provided that define the usage of these algorithms including the use of a null encryption algorithm. Auth-only ESP does not provide exactly the same security services as AH. The technical capabilities of AH versus auth-only ESP are best worked out in the market. The proposed text (from Steve Kent) to document this capability in ESP as a "MAY elect" is a reasonable compromise. Standards conformance of IPSEC implementations will not be based on this mode of operation. The implementors that met in Memphis clearly demanded that there be no options at all in ESP. These agreements are appropriate for the mandatory to implement capabilities. The fervor to interoperate should not close off all options for value added capabilities that "may" be implemented. The raging debate on auth-only ESP should be represented by only a small section of text describing when it is appropriate to use a null algorithm ("may" versus "should not"). The release of the new ESP specification next week should provide an opportunity for clear comments on the text representing these issues. Regards, Paul A. Lambert ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Sat May 17 00:09:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA06422 for ipsec-outgoing; Sat, 17 May 1997 00:07:23 -0400 (EDT) Message-Id: <199705170409.AAA27578@codex.cis.upenn.edu> To: "PALAMBER.US.ORACLE.COM" cc: ipsec@tis.com, jis@MIT.EDU Subject: Re: ESP New Draft In-reply-to: Your message of "16 May 1997 20:02:34 PDT." <199705170326.UAA26094@mailsun2.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17341.863842069.1@dsl.cis.upenn.edu> Date: Sat, 17 May 1997 00:07:50 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705170326.UAA26094@mailsun2.us.oracle.com>, "PALAMBER.US.ORACLE. COM" writes: > >As working group chair, I see no clear consensus to forbid the use of ESP with >a null encryption algorithm (a.k.a auth-only-ESP). There have been many >strong statements made to the mailing list recommending that ESP always >encrypt. I've also talked to implementors developing auth-only-ESP as a >"valued added" option. ESP has the flexibility to support any algorithm. >Clear guidelines need to be provided that define the usage of these algorithms >including the use of a null encryption algorithm. Paul, we had a straw poll on this list, and we had a large number of implementors decide in the Memphis meeting. Both were against auth-only-ESP. How in heaven can you say that there is no clear consensus ? There are 3 (count, three) people who spoke for auth-only-ESP on this mailing list. I was under the impression the WG chair is NOT supposed to make decisions when there *IS* a rough consensus (and this is not even rough). Finally, even if people do go ahead and hack their code to do encryptionless ESP, this doesn't mean we should ratify their decision by allowing it in the docs if we believe it's wrong. And all the discussion i've seen on this WG (list, meeting) indicates that the majority thinks it's wrong. Cheers, -Angelos PS. You say you've talked to implementors who added this as a "value added" option. Why don't they talk for themselves on this list? I don't doubt your saying so, but i'm curious why they don't express their opinion on the list if they like encryptionless ESP so much. Only implementor i've seen so far was Charlie (from BBN). From owner-ipsec Sat May 17 00:12:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA06454 for ipsec-outgoing; Sat, 17 May 1997 00:11:25 -0400 (EDT) From: "Ahmod Bakr El-Sayed: -SC" Organization: Computer Systems Engineering, RMIT To: ho@earth.hpc.org (Hilarie Orman) Date: Sat, 17 May 1997 14:19:04 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: enskip cobfuguration CC: ipsec@tis.com In-reply-to: <199705161257.IAA08949@earth.hpc.org> References: Yourmessage <199705160858.BAA04918@baskerville.CS.Arizona.EDU> X-mailer: Pegasus Mail for Windows (v2.53/R1) Message-ID: <1678EFD02D2@huntsman.cse.rmit.edu.au> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi this is Burt from Australia I am doing thesis on Implemenation of IPSEC with firewalls i have used the ENSKIP and SUN SKKIP I am having a very serious problem with the ENSKIP .. I would be very greateful if i could hear any sugestion I compiled the latest ENSKIP enskip-0.66 successfully on solaris 2.5 box when i started " make install" i got a kernel crash. i repeated the installation step by step on hand from the command line,, and sure it is the add_drv command i.e adding the kernel drive which makes the crash please i appreciate your help. Have a very G'DAY BURT From owner-ipsec Sat May 17 00:43:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA06579 for ipsec-outgoing; Sat, 17 May 1997 00:41:54 -0400 (EDT) Message-Id: <199705170441.AAA19459@relay.hq.tis.com> Date: Sat, 17 May 97 0:43:40 EDT From: Charles Lynn To: David Carrel cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk David, > this working group has suffered a very long time from "procedural > issues". The effect is pretty clear. Do we have a nailed down doc > yet?? I sure hope so. I thought that was one of the purposes for the poll. > On the list nothing get's said or nothing get's decided. I think it is the responsibility of the chairs to keep things moving. If there is nothing happening, the chair should send a message to encourage folks to state their thoughts (maybe even have a straw poll :-), judge the responses, and move on. > The documents need to come out now with the current group consensus, Yes. I will do what I can to see that it happens. Charlie From owner-ipsec Sat May 17 01:05:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA06682 for ipsec-outgoing; Sat, 17 May 1997 01:04:24 -0400 (EDT) Message-Id: <199705170503.BAA19674@relay.hq.tis.com> Date: Sat, 17 May 97 0:42:31 EDT From: Charles Lynn To: "Angelos D. Keromytis" cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos, > You can do tunneling (IP in IP), with the inner packet being AH > protected, ie: [IP][IP][AH][whatever] Yes, that is one way to work around the problem. Cost: 20 (40) unnecessary bytes per IPv4 (IPv6) packet sent over the lifetime of the protocol. When viewed from the perspective of a security gateway, [IP][IP][AH][IP][whatever], just makes things more likely to run into path MTU / fragmentation problems. > It has also been the IETF "policy" that decisions are made by running > code and rough consensus. Speaking of running code, does anyone have operational experience on how well Path MTU discovery works? It has been standardized for a long time. Re: encryptionless ESP > I believe the matter has been discussed for a while and the WG has > indeed decided against e-ESP. Yes, it has been discussed for a long while. There was a request for a poll and I responded with what I think is the best solution and my rational for thinking so. > But more importantly, IPsec is a network layer protocol. It gives some > assurances to the application. If the application cannot live with > those, it should certainly use some higher layer security protocol > (such as TLS). Trying to put in IPsec all the functionality of all > protocol layers is a mistake. Good points. But providing functionality needed by several layer N protocols at a lower layer has merit. > I'll remind you that IP addresses are supposed to be used as part of a > security identifier; an address along with an SPI indicates the SA to > use. Since you raised the issue, do you know the rational for that decision? I can see how it might make construction of third party wire tapping devices a little easier. However, as an implementor, I would not implement it that way. I would make the SPI space within a box be unique, not have several spaces, one per address -- IPv4, IPv6 link local, IPv6 global, (dare I say multicast?), per interface, ... Why go through all the extra work? Bigger tables, bigger hash keys ... From the outside, things work. If the box receives a packet not addressed to it, it gets dropped before any SPI lookup. If it is addressed to the box, the purported SPI either works or it doesn't. If it works, whoever shared the key, so the packet would be accepted; if it didn't work, it would set off those audit or not alarms and be dropped. > Additionally, i don't see how dynamic IP will be hampered by IPsec in > this respect, assuming a well thought out certificate scheme is in > place; specifically, certificates for mobile agents should not include > any IP addresses (this is a necessary but probably not sufficient > condition). >From what I've had a chance to read, that may be a big assumption. Thinking ahead a few years, what fraction of hosts and networks will be mobile (at the IP level) or be subject to renumbering, possibly due to switching providers? Hopefully, someone is working out all the nasty little details. Re: IV field padding: > I'm puzzled by this. Why wouldn't the standard padding at the end of > the ESP payload be enough to handle alignment problems ? No. Maybe a picture would help. 64-bit boundaries (not to scale) | | | | | | | | | +-------+-------+-------+---- +-------+-------+------------+-------+ |IP6 Hdr|Rtg Hdr|ESP Hdr| IV |IP6 Hdr|Rtg Hdr|User Payload|ESP Pad| +-------+-------+-------+---- +-------+-------+------------+-------+ When the decapsulating system gets this packet, it will "strip off" the headers before the (IV and) inner IPv6 header, and then have to process that header and possibly others beyond it (inner Rtg Hdr in this example). It is expected that the outer IPv6 base header and extension headers are aligned so those systems that demand data alignment can process the packet. But this system has to also process the inner headers. Maybe the inner routing header needs to be advanced, and IPv6 addresses shuffled around. If the IV field is not a multiple of 64 bits, it breaks the alignment between the outer and inner headers, then the vendor is stuck realigning the the packet, which is a good way to reduce performance. Some have argued that the encrypted portion (IV through ESP Pad) would have to be copied anyway so it doesn't really matter. In some cases that argument works. But requiring the IV field to be a multiple of 64 bits would make it work in all cases, allowing the vendors to simplify their implementations. Given current technology, it only costs a few words, and would nail things down unambiguously. I think it is a reasonable requirement. If others feel otherwise, we should know so that the working group documents can warn vendors not to make "assumptions". Thanks for your feedback, Charlie From owner-ipsec Sat May 17 01:49:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA06837 for ipsec-outgoing; Sat, 17 May 1997 01:46:54 -0400 (EDT) Message-Id: <199705170553.BAA27969@codex.cis.upenn.edu> To: Charles Lynn cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Sat, 17 May 1997 00:42:31 EDT." <199705170521.BAA27799@codex.cis.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17487.863848324.1@dsl.cis.upenn.edu> Date: Sat, 17 May 1997 01:52:04 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705170521.BAA27799@codex.cis.upenn.edu>, Charles Lynn writes: > >Yes, that is one way to work around the problem. Cost: 20 (40) >unnecessary bytes per IPv4 (IPv6) packet sent over the lifetime of the >protocol. When viewed from the perspective of a security gateway, >[IP][IP][AH][IP][whatever], just makes things more likely to run into >path MTU / fragmentation problems. That's true. I was only saying that one can do that if one really wants to. But i believe that one shouldn't care. Opinions obviously vary. >Yes, it has been discussed for a long while. There was a request for >a poll and I responded with what I think is the best solution and >my rational for thinking so. Apologies if it seemed like i was dismissing your opinion and rational. I was just counter arguing. >Good points. But providing functionality needed by several layer N >protocols at a lower layer has merit. As long as this doesn't break things or makes them more complicated than they ought to be (and they're complicated enough as it is). >Since you raised the issue, do you know the rational for that >decision? I can see how it might make construction of third party >wire tapping devices a little easier. However, as an implementor, I An SPI is guaranteed (supposedly) to be unique per address. That makes the pair SPI/address unique on any lookup table. SPIs are needed because two boxes might have more than one SAs shared, and addresses are needed to distinguish between the same SPI value among different boxes. Presumably, the issuer of SPIs issues unique SPIs per box, which means the same SPI will not occur for more than one address of that box. Given that, the receiver of an IPsec packet need not concern oneself with the address once he's established that the packet is destined for him. Hope this answers. [At this point, your message was destroyed by MH...fun. So i probably missed what you said about dynamic IP.] >No. Maybe a picture would help. [snip] I see the problem now. About something you mentioned: all the implementations i've been involved in do in-place decryption, so copying would be unnecessary. I suppose 64-bit multiple IVs is reasonable then. Cheers, -Angelos From owner-ipsec Sat May 17 03:40:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA07248 for ipsec-outgoing; Sat, 17 May 1997 03:35:23 -0400 (EDT) Message-Id: <3.0.32.19970517073224.008ae900@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 17 May 1997 07:39:00 +0000 To: Charles Lynn From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: "Angelos D. Keromytis" , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:42 AM 5/17/97 EDT, Charles Lynn wrote: >Speaking of running code, does anyone have operational experience on >how well Path MTU discovery works? It has been standardized for a >long time. Judging from packet traces, it's barely used. That is, there are very many packets at around 512 or 576 bytes, and almost none above it. > > >> I'll remind you that IP addresses are supposed to be used as part of a >> security identifier; an address along with an SPI indicates the SA to >> use. > >Since you raised the issue, do you know the rational for that >decision? I can see how it might make construction of third party >wire tapping devices a little easier. However, as an implementor, I >would not implement it that way. I would make the SPI space within a >box be unique, not have several spaces, one per address -- IPv4, IPv6 >link local, IPv6 global, (dare I say multicast?), per interface, ... >Why go through all the extra work? Bigger tables, bigger hash keys >... From the outside, things work. If the box receives a packet not >addressed to it, it gets dropped before any SPI lookup. If it is >addressed to the box, the purported SPI either works or it doesn't. >If it works, whoever shared the key, so the packet would be accepted; >if it didn't work, it would set off those audit or not alarms and be >dropped. That's an implementation decision. What's important is that the sender must be prepared to deal with multiple SPIs. Also bear in mind the multicast case, where someone else -- the group leader -- is assigning the SPI. > >> Additionally, i don't see how dynamic IP will be hampered by IPsec in >> this respect, assuming a well thought out certificate scheme is in >> place; specifically, certificates for mobile agents should not include >> any IP addresses (this is a necessary but probably not sufficient >> condition). > >>From what I've had a chance to read, that may be a big assumption. >Thinking ahead a few years, what fraction of hosts and networks will >be mobile (at the IP level) or be subject to renumbering, possibly due >to switching providers? Hopefully, someone is working out all the >nasty little details. With IPv6, 100% of hosts will be subject to renumbering. From owner-ipsec Sat May 17 04:06:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA07380 for ipsec-outgoing; Sat, 17 May 1997 04:05:27 -0400 (EDT) Message-Id: <3.0.32.19970517080913.008c1d80@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 17 May 1997 08:09:22 +0000 To: ho@earth.hpc.org (Hilarie Orman) From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk My original reaction was "no, I don't like this idea". After all, we have permitted ESP through the firewall, based solely on the protocol ID and the destination address pointing to the secure tunnel endpoint on the inside. Do I really want unencrypted traffic flowing that way? Then I realized that someone could define and implement an arbitarily weak "encryption" algorithm and use it, if the tunnel permitted. Anyone for 40-bit RC4? 4-bit RC4? Rot-n? (The spec for Rot-n might make a great April 1 RFC, save that last April 1, someone actually implemented it as an encryption mode for ssh and other folks took it seriously... Me -- I want a monoalphabetic substitution. Done computer-style, there are 256! possible keys -- by my calculations, about 1684 bits, which puts triple IDEA to shame...) In other words, the firewall or its trusted peer have to participate in the key management dialog, if you want to pass encrypted traffic only if it is above a certain strength level. As a complement to AH, it's harmless. As a replacement, it's superior. (Folks may remember my long arguments against the AH architecture. This is much cleaner.) My major concern is that APIs be structured so that *no one* gets this mode by accident. From owner-ipsec Sat May 17 11:01:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08915 for ipsec-outgoing; Sat, 17 May 1997 10:54:25 -0400 (EDT) Date: Sat, 17 May 1997 10:57:53 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705171457.KAA25821@earth.hpc.org> To: Dan.McDonald@Eng.sun.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199705162142.OAA24624@baskerville.CS.Arizona.EDU> Subject: Re: Clarification please! Sender: owner-ipsec@ex.tis.com Precedence: bulk > SA PAIR - A pair of unidirectional SAs that provide protection > on a unicast session by covering each direction. They > are otherwise matched. > e.g. SA spi=0x2112, AH, HMAC-MD5, A -> B > SA spi=0x5150, AH, HMAC-MD5, B -> A Asymmetry has been a design goal from the earliest drafts, so I'd never considered the case above to be anything other than a subcase of a normal pair. > SA BUNDLE - A set of SAs that provide different protections. > e.g. SA spi=0x1001001, ESP, 3DES, , A -> B > SA spi=0x82069, AH, HMAC-SHA1, A -> B > Any comments? I'd call it an asymmetric pair, myself. A "bundle" conjures up a more general concept --- I'd use it to describe things like "use AH with spi xxxx and ESP with spi xxxx outgoing, and expect AH with spi yyyy and ESP with spi yyyy incoming" etc. Hilarie From owner-ipsec Sat May 17 11:39:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09081 for ipsec-outgoing; Sat, 17 May 1997 11:37:24 -0400 (EDT) Date: Sat, 17 May 1997 11:34:52 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705171534.LAA26900@earth.hpc.org> To: ipsec@tis.com Subject: Workshop announcement Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm reposting this announcement because a couple of people told me that they didn't notice the first posting (in March) and wanted a repost, and because I wanted to note that much good could come of exposing many of the issues that this group wrestles with exposed to the formal security community (but not a formal spec of the RFC process or the semantics of MUST vs. SHOULD, thank you). Hope this will be of interest to more than a couple of you. ============================================================================= DIMACS Workshop on Design and Formal Verification of Security Protocols Sept. 3-5, 1997 Organizers: Hilarie Orman, DARPA and Catherine Meadows, Naval Research Laboratory As we come to rely more and more upon computer networks to perform vital functions, the need for cryptographic protocols that can enforce a variety of security properties has become more and more important. Thus it is no surprise that in recent years a number of new protocols have been proposed for such applications as electronic credit card transactions, Web browsing, and so forth. Since it is notoriously difficult to design cryptographic protocols correctly, this increased reliance on them to provide security has become cause for some concern. This is especially the case since many of the new protocols are extremely complex. In answer to these needs, research has been intensifying in the application of formal methods to cryptographic protocol verification. Recently this work has matured enough so that it is starting to see application to real-life protocols. The goal of this workshop is to facilitate this process by bringing together those were are involved in the design and standardization of cryptographic protocols, and those who are developing and using formal methods techniques for the verification of such protocols. To this end we plan to alternate papers with panels soliciting new paths for research. We are particularly interested in paper and panel proposals addressing new protocols with respect to their formal and informal analysis. Other topics of interest include, but are not limited to - Progress in belief logics - Use of theorem provers and model checkers in verifying crypto protocols - Interaction between protocols and cryptographic modes of operation - Methods for unifying documentation and formal, verifiable specification - Methods for incorporating formal methods into crypto protocol design - Verification of cryptographic API systems - Formal definition of correctness of a cryptographic protocol - Arithmetic capability required for proofs of security for number theoretic systems - Formal definitions of cryptographic protocol requirements - Design methodologies - Emerging needs and new uses for cryptographic protocols - Multiparty protocols, in particular design and verification methods We encourage attendees to bring tools for demonstration. Information about availability of facilities for demonstration will be posted later. To submit a paper to the workshop, submit a one or two page abstract, in Postscript or ASCII to both organizers at the email addresses given below by June 16, 1997. Authors will be notified of acceptance or rejection of abstracts by July 1. Full papers will be due by August 1. Copies of papers will be distributed at the workshop. We also plan to publish a proceedings. Participation in the workshop is *not* limited to those giving presentations. If you would like to attend the workshop, a registration form is available at http://dimacs.rutgers.edu/Workshops/Cryptographic/reg_form.html. Information on accommodations and travel arrangements is available at http://dimacs.rutgers.edu/Workshops/general/accommodations.html and http://dimacs.rutgers.edu/Workshops/general/travel.html. Information on the workshop in general is at http://dimacs.rutgers.edu/Workshops/Cryptographic. Organizers Hilarie Orman Catherine Meadows DARPA ITO Naval Research Laboratory 3701 N. Fairfax Drive Code 5543 Arlington VA 22203-1714 Washington, DC 20375 phone: (703)696-2234 phone: (202)-767-3490 email: orman@darpa.mil email:meadows@itd.nrl.navy.mil From owner-ipsec Sat May 17 12:41:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09305 for ipsec-outgoing; Sat, 17 May 1997 12:35:56 -0400 (EDT) Date: Sat, 17 May 1997 12:39:29 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705171639.MAA28820@earth.hpc.org> To: ipsec@tis.com Subject: Workshop announcement Sender: owner-ipsec@ex.tis.com Precedence: bulk The need for more verification is evident in this problem that was pointed out to me re the workshop: http://dimacs.rutgers.edu/Workshops/Cryptographic The correct URL is: http://dimacs.rutgers.edu/Workshops/Security Hilarie From owner-ipsec Sat May 17 15:22:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09970 for ipsec-outgoing; Sat, 17 May 1997 15:14:27 -0400 (EDT) Date: Sat, 17 May 97 18:39:48 GMT From: "William Allen Simpson" Message-ID: <5889.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Charles Lynn > Speaking of running code, does anyone have operational experience on > how well Path MTU discovery works? It has been standardized for a > long time. > Yes. Since Apple installed OpenTransport on several million machines the past 6 months, I've been getting much nicer packet sizes from many servers, including the mail server indicated above. They didn't get Karns' algorithm, or Nagles' algorithm, or slow start, or TCP PSH, or any number of other details correct, but they do seem to have Path MTU working.... Now, if we could only get all those old SunOS and BSD 4.2 machines upgraded.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 17 20:53:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11431 for ipsec-outgoing; Sat, 17 May 1997 20:51:28 -0400 (EDT) Message-Id: <199705180058.RAA07653@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "PALAMBER.US.ORACLE.COM" Cc: ipsec@tis.com Subject: Re: ESP New Draft In-Reply-To: Your message of "16 May 1997 20:02:34 PDT." <199705170326.UAA26094@mailsun2.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 17 May 1997 17:58:16 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, I'm confused by your recent note on the new ESP draft. You mention: > The "changes" in this new specification should not be significant! ESP > implementations conforming to the Memphis implementors agreements will be > conformant to this specification. The only issues for the ESP specification > are the optional "value added" capabilities of ESP that include auth-only-ESP. If implementations which conform to the Memphis agreement are conformant to the specification then there can be no "value added" encryptionless ESP since in Memphis there was overwhelming agreement that this not be allowed. > As working group chair, I see no clear consensus to forbid the use of ESP > with a null encryption algorithm (a.k.a auth-only-ESP). I'm really at a loss here. In Memphis I was a bit distracted by the March Of The Peabody Ducks but I do remember that around 4/5 of the people discussing encryptionless ESP were against it. On the list it's about 3:1 against. Presidents claim a mandate with 55% of a vote; this is a veritable landslide! As mentioned on the list recently: a compelling argument must be made for *change*, not for the status quo. The status quo is no encryptionless ESP. There has been no compelling argument for change. (And it's not just me saying this). You also said that you spoke to people implementing encryptionless ESP. Who? And to what specification are they coding? Since ESP currently does not allow encryptionless ESP and there are no published transforms defining such a beast I'm curious who they are. Everybody who has anything close to running code has announced their existance and no one has said they have encryptionless ESP. (Having taken part in recent IPsec bakeoffs, I'm not just spouting off). Lack of a compelling argument; clear consensus against; no running code (and in fact, all running code is contrary). I'm puzzled why you come to the conclusion you did. Dan. From owner-ipsec Mon May 19 09:15:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19988 for ipsec-outgoing; Mon, 19 May 1997 09:07:15 -0400 (EDT) Message-Id: <2.2.32.19970518203632.0073b184@po2.bbn.com> X-Sender: lsanchez@po2.bbn.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 18 May 1997 16:36:32 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: "Luis A. Sanchez" Subject: Re: Clarification please! Cc: sommerfeld@apollo.hp.com, ho@earth.hpc.org, suren@teil.soft.net, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >I've heard these tossed around by myself and others from time to time: > > SA PAIR - A pair of unidirectional SAs that provide protection > on a unicast session by covering each direction. They > are otherwise matched. >Any comments? > Dan, I've used the term SA PAIR as well. Now, suppose HOST A wants to talk to HOST B using AH-ESP(transport) w/3DES end2end. To further complicate things, suppose that both HOST A and B are required to use AH with their Security Gateways (A' and B') for all outgoing traffic as depicted below: |---------- AH-ESP(transport)-----------| HOST A ------- A' ------------ B'------ HOST B |---AH-- -| |---AH---| Using your notation, HOST A would have 3 SA PAIRs "related" to the same session: e.g. SA spi=0x1001001, ESP, 3DES, , A -> B SA spi=0x5150000, ESP, 3DES, , B -> A SA spi=0x2112, AH, HMAC-MD5, A -> B SA spi=0x5150, AH, HMAC-MD5, B -> A SA spi=0x82069, AH, HMAC-SHA1, A -> A' SA spi=0x10738, AH, HMAC-SHA1, A' -> A HOST B would have an equivalent set of SA PAIRs. It might be useful to have a way to describe this SA relationship too. Perhaps we could define: SA Composite (SAC)= {Set of SA PAIRs related to the same unicast session} >I'd call it an asymmetric pair, myself. A "bundle" conjures up a more >general concept --- I'd use it to describe things like "use AH with >spi xxxx and ESP with spi xxxx outgoing, and expect AH with spi yyyy >and ESP with spi yyyy incoming" etc. "SA Bundles" per Hilarie's definition could be elements of a SAC. Luis From owner-ipsec Mon May 19 09:49:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20279 for ipsec-outgoing; Mon, 19 May 1997 09:48:18 -0400 (EDT) Message-Id: <199705181434.KAA03548@codex.cis.upenn.edu> To: wdmaugh@tycho.ncsc.mil Subject: ISAKMP cookies Cc: mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com, ipsec@tis.com Date: Sun, 18 May 1997 10:34:08 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Could we remove the wording from the draft that talks about clogging and how cookies prevent it ? Clearly, in ISAKMP, cookies do nothing of that sort; the Responder has to create state after receiving the first message of a Main or Aggressive Mode, to keep the proposal/transforms/attributes it's decided to accept. On the other hand, if we do want to do anti-clogging, a simple HDR exchange before the current Main/Aggressive Mode would suffice. Cheers, - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM38TX70pBjh2h1kFAQFemgQAgBHqWbuuUBC86y2WhC11+x5p6RRiPD1l qDlC52u5qjV/Q4sBrN4TByE9aibeaW8L2hdjKPGriR6R8rSB9jJxE05mvm0Km99X groLo1swK7JLudEm3SS/uKoMBh8SGm/C1cXFGKO4wpBxppNPziEj0KSfkPGFWWvB qVywHzaTV5o= =WiSd -----END PGP SIGNATURE----- From owner-ipsec Mon May 19 10:56:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20722 for ipsec-outgoing; Mon, 19 May 1997 10:55:18 -0400 (EDT) Date: Mon, 19 May 1997 10:57:14 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705191457.KAA21933@earth.hpc.org> To: angelos@dsl.cis.upenn.edu Cc: wdm@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com, ipsec@tis.com In-reply-to: Yourmessage <199705191358.GAA01423@baskerville.CS.Arizona.EDU> Subject: Re: ISAKMP cookies Sender: owner-ipsec@ex.tis.com Precedence: bulk There have always been two possible aspects to anti-clogging (or denial of service prevention). One is to defer allocation of space, the other is to defer computation. I'm happy to have the term refer to either one, insofar as the protocol assists either or both. Hilarie From owner-ipsec Mon May 19 12:27:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21226 for ipsec-outgoing; Mon, 19 May 1997 12:24:50 -0400 (EDT) Message-Id: <199705191631.MAA19978@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Charles Lynn cc: Daniel Harkins , ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Fri, 16 May 1997 22:55:41 EDT." <199705170250.WAA18264@relay.hq.tis.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 12:31:32 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles Lynn writes: > I was not able to attend the WG meeting. I do not know what fraction > of the WG was there. I suspect that there are many more WG members > than I have seen responded to the straw poll. I know I'm chiming in a bit late, but let me chime in anyway. The working group in Memphis was almost unanimous in striking down encryptionless ESP. The working group here, on line, obviously has overwhelming consensus in that direction. Continued discussion of this matter is divisive and unnecessary -- it is obvious which way the working group has decided. Regardless of the "platonic truth" of the question of whether encryptionless ESP is good or bad, the world will survive just fine without it, and it is obvious at this point that the only result of continuing the discussion will be the same outcome. I would ask the people pushing encryptionless ESP to gracefully withdraw rather than continue in this disruptive direction. Everyone loses an argument occassionally. We've all been forced to accept things we don't like. Lets move on. Perry From owner-ipsec Mon May 19 12:27:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21236 for ipsec-outgoing; Mon, 19 May 1997 12:26:50 -0400 (EDT) Message-Id: <199705191633.MAA19986@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "Angelos D. Keromytis" cc: "PALAMBER.US.ORACLE.COM" , ipsec@tis.com, jis@MIT.EDU Subject: Re: ESP New Draft In-reply-to: Your message of "Sat, 17 May 1997 00:07:50 BST." <199705170409.AAA27578@codex.cis.upenn.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 12:33:36 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Angelos D. Keromytis" writes: > >As working group chair, I see no clear consensus to forbid the use > >of ESP with a null encryption algorithm (a.k.a auth-only-ESP). > >There have been many strong statements made to the mailing list > >recommending that ESP always encrypt. I've also talked to > >implementors developing auth-only-ESP as a "valued added" option. > >ESP has the flexibility to support any algorithm. Clear guidelines > >need to be provided that define the usage of these algorithms > >including the use of a null encryption algorithm. > > Paul, we had a straw poll on this list, and we had a large number of > implementors decide in the Memphis meeting. Both were against > auth-only-ESP. How in heaven can you say that there is no clear > consensus ? I strongly agree. This is one of the few times that I've seen near unanimity for *anything* in the IETF. I didn't see *anyone* at Memphis ask for encryptionless ESP. > I was under the impression the WG chair is NOT supposed to make > decisions when there *IS* a rough consensus (and this is not even > rough). Also true enough. Perry From owner-ipsec Mon May 19 13:09:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA21500 for ipsec-outgoing; Mon, 19 May 1997 13:08:51 -0400 (EDT) Message-Id: <199705191715.NAA21137@codex.cis.upenn.edu> To: ho@earth.hpc.org (Hilarie Orman) cc: wdm@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, mjs@terisa.com, ipsec@tis.com Subject: Re: ISAKMP cookies In-reply-to: Your message of "Mon, 19 May 1997 10:57:14 EDT." <199705191457.KAA21933@earth.hpc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3159.864062022.1@dsl.cis.upenn.edu> Date: Mon, 19 May 1997 13:13:42 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705191457.KAA21933@earth.hpc.org>, Hilarie Orman writes: >There have always been two possible aspects to anti-clogging (or >denial of service prevention). One is to defer allocation of space, >the other is to defer computation. I'm happy to have the term refer >to either one, insofar as the protocol assists either or both. I'm simply puzzled why we moved away from the Photuris model of cookies; as you remember, cookies there prevented both problems. And if you can't do any protocol negotiation (or even worse, if your machine crawls to a halt), it doesn't matter if the reason is memory exhaustion or too much computation. Especially since it will be trivial for anyone, anywhere, to make any ISAKMP daemon run out of memory as it stands now. Cheers, -Angelos PS. Most of the over-the-network attacks i've seen in the last two years cause the target system to run out of memory (usually run out of memory dedicated for some service). Let's not replicate those protocol failures here. From owner-ipsec Mon May 19 16:38:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22821 for ipsec-outgoing; Mon, 19 May 1997 16:36:52 -0400 (EDT) Date: Mon, 19 May 1997 16:40:10 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705192040.QAA02337@earth.hpc.org> To: perry@piermont.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199705191637.JAA12223@baskerville.CS.Arizona.EDU> Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > Regardless of the "platonic truth" of the > question of whether encryptionless ESP is good or bad, the world will > survive just fine without it, It's not a platonic argument, it's a practical one about high-speed nets, perceived utility of AH, and expected market directions. Platonic would be, "And do you not already have an algorithm that hashes contiguous blocks of data? And do you have a framework for handling an extensible set of block-oriented algorithms? And you often process packets without care for the header value, other than destination address? Then, have you not already implemented the spirit of auth-only ESP, and is it not implied by the code base you built, although you thought you were coding to a different spec altogether? Then is not auth-only ESP a done deal, roughly implemented in running code, not merely a shadow thrown on the wall by yahoos in the internet ether?" Hilarie From owner-ipsec Mon May 19 18:05:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23368 for ipsec-outgoing; Mon, 19 May 1997 18:03:54 -0400 (EDT) Message-Id: <199705192210.SAA21465@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: ho@earth.hpc.org (Hilarie Orman) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Mon, 19 May 1997 16:40:10 EDT." <199705192040.QAA02337@earth.hpc.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 18:10:11 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie Orman writes: > > Regardless of the "platonic truth" of the > > question of whether encryptionless ESP is good or bad, the world will > > survive just fine without it, > > It's not a platonic argument, it's a practical one about high-speed > nets, perceived utility of AH, and expected market directions. I think you don't understand what I meant, Hillarie. Out there, somewhere, floating in Platonic Ideals Space, is the "Truth" with a capital T about whether encryptionless ESP is "good" or "bad". We all make our arguments, try to convince one another, and we come to a consensus. Of course, we never actually reach the "Truth"*. What we get is an approximation that is possibly very far away. However, being finite beings, we can never actually reach the "Truth", and could spend infinite time in a futile attempt to get there (thus never achieving our goal of having a deployed system), so we have developed this procedure to get as close as we can to the "Truth". Well, we went through that process, and we hit an answer which was that we had solid assessed consensus to drop encryptionless ESP. Some people feel this is the wrong decision. However, we can't ever achieve the "right" decision, only what most people think is "right". We have certainly arrived there -- there is strong and obvious consensus. Now, I realize that it might not be pleasant for the losers, but we have *all* been on the losing side of one argument or another in this process, and we just have to accept that we've lost and live with it and move on. This should especially be the case given that western civilization will survive even if we made a not entirely perfect decision here. Indeed, at worst, we will lose some bandwidth or some such. So, given all this, can we just accept that most people think we should drop encryptionless ESP and move on? Perry *By the way, it isn't even clear that there is a "Truth" -- engineering, unlike mathematics, rarely has a single right answer. From owner-ipsec Mon May 19 20:09:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24065 for ipsec-outgoing; Mon, 19 May 1997 20:06:54 -0400 (EDT) Message-Id: <199705200013.RAA03011@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Mon, 19 May 97 17:13:17 -0700 To: perry@piermont.com Subject: Re: ESP revisions straw poll cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199705192210.SAA21465@jekyll.piermont.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk > Now, I realize that it might not be pleasant for the losers, but > we have *all* been on the losing side of one argument or another > in this process, and we just have to accept that we've lost and > live with it and move on. > I thought the purpose here is collaboration. Why do we have to have winners and losers? -dpg From owner-ipsec Mon May 19 20:28:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24228 for ipsec-outgoing; Mon, 19 May 1997 20:28:26 -0400 (EDT) Message-Id: <199705200034.UAA21894@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: dennis.glatting@plaintalk.bellevue.wa.us cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Mon, 19 May 1997 17:13:17 PDT." <199705200013.RAA03011@imo.plaintalk.bellevue.wa.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 19 May 1997 20:34:46 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dennis Glatting writes: > > Now, I realize that it might not be pleasant for the losers, but > > we have *all* been on the losing side of one argument or another > > in this process, and we just have to accept that we've lost and > > live with it and move on. > > I thought the purpose here is collaboration. Why do we have to > have winners and losers? Because some things are mutually exclusive. We can't both permit and not permit encryptionless ESP, for example. This means that if there are groups arguing in favor of both, one of those groups necessarily does not see its desires adopted. Overall, of course, I think this *is* a collaboration. However, individual arguments end up with people losing on occassion. Perry From owner-ipsec Tue May 20 09:03:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28040 for ipsec-outgoing; Tue, 20 May 1997 08:59:03 -0400 (EDT) Date: Tue, 20 May 1997 09:04:31 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705201304.JAA13211@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: ESP revisions straw poll X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Perry E. Metzger" > > Dennis Glatting writes: > > I thought the purpose here is collaboration. Why do we have to > > have winners and losers? > > Because some things are mutually exclusive. We can't both permit and > not permit encryptionless ESP, for example. This means that if there > are groups arguing in favor of both, one of those groups necessarily > does not see its desires adopted. As Bill Simpson and others have pointed out, you can't "not permit" auth-only ESP; the only thing you can do is refuse to include it in the base ESP specification. Someone can always come along and write a Rot-13 or Identity encryption transform document, and implementors can write code to implement it. It becomes a hard sell to claim that IPSEC implementations which support additional ESP transforms over and above the minimum requirements are "non-compliant" - implementations that support both the Standard transforms and value-added transforms will be common. Thus the argument becomes where will the null encryption transform get documented - as a MAY IMPLEMENT component of the base ESP specification having no effect on compliance, or in a separate transform document. I don't have any illusions that there is a Platonic Ideal IPSEC Standard that we mortals can glimpse but dimly - auth-only ESP may be Good, Bad, both, or neither. I just think it's silly to write a separate < 1 page RFC to specify something that: 1) has semantic and performance properties that are useful to some, 2) is short and easy to describe in the base ESP specification, 3) has zero impact on developers' compliance with the standard, and 4) will be implemented if there's market demand and won't be otherwise, *regardless* of where it is documented. From owner-ipsec Tue May 20 09:56:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28392 for ipsec-outgoing; Tue, 20 May 1997 09:51:33 -0400 (EDT) Message-Id: <199705201357.JAA02213@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 09:04:31 EDT." <199705201304.JAA13211@argon.ncsc.mil> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 May 1997 09:57:57 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk David P. Kemp writes: > I don't have any illusions that there is a Platonic Ideal IPSEC Standard > that we mortals can glimpse but dimly - auth-only ESP may be Good, Bad, > both, or neither. > > I just think it's silly to write a separate < 1 page RFC to specify > something that: > > 1) has semantic and performance properties that are useful to some, > 2) is short and easy to describe in the base ESP specification, > 3) has zero impact on developers' compliance with the standard, and > 4) will be implemented if there's market demand and won't be otherwise, > *regardless* of where it is documented. What you are doing here is having the argument over. My point was that we've had the argument, and that of course there are points on both sides -- naturally good points given that most of the people in the discussion are intelligent -- but a decision was made already and there isn't evidence that consensus has shifted so much or that the arguments have changed so much that the decision should be re-thought. This is not to say we in the IETF carve our decisions in stone, but we *do* have to finally make them every once in a while. Even if in this case by some stretch the consensus changed, in general it is a bad idea to discuss things forever. Engineering is often a tradeoff between time and perfection. We have operated at a very slow pace for many years now in IPSec -- we are getting close to "shoot the engineers and ship" time. After a while, you have to make a decision on outstanding issues and accept it. We made one already. Perry From owner-ipsec Tue May 20 10:14:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28553 for ipsec-outgoing; Tue, 20 May 1997 10:13:06 -0400 (EDT) Message-Id: <199705201419.KAA27177@codex.cis.upenn.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 09:04:31 EDT." <199705201304.JAA13211@argon.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4780.864137881.1@dsl.cis.upenn.edu> Date: Tue, 20 May 1997 10:18:01 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Thus the argument becomes where will the null encryption transform >get documented - as a MAY IMPLEMENT component of the base ESP specification >having no effect on compliance, or in a separate transform document. If some people really want it, then they can go ahead and write their own transform document. It should never appear in the base ESP document. I'd much rather have vendors say they don't support ESP (or that they have two versions of IPsec, one domestic and one exportable), than them claiming they support "a version of ESP that is almost as secure as the standard says, and it's exportable!". And before you go off saying that this statement is (obviously) not true, let me just remind you that truth and marketing are not necessarily compatible terms. Cheers, -Angelos PS. I still think ESP should stand for "Encrypting Security Protocol"...we're IPsec after all, not "Internet Encapsulating Protocol WG". But that's just me (and a few others :) From owner-ipsec Tue May 20 10:21:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28610 for ipsec-outgoing; Tue, 20 May 1997 10:21:35 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-esp-des3-x-01.txt Date: Tue, 20 May 1997 09:48:13 -0400 Message-ID: <9705200948.aa28776@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP Triple DES Transform Author(s) : P. Karn, P. Metzger, W. Simpson Filename : draft-simpson-esp-des3-x-01.txt Pages : 14 Date : 05/19/1997 This document describes the "Triple" DES-EDE3-CBC security transform for the IP Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-esp-des3-x-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des3-x-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-esp-des3-x-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970519172020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-esp-des3-x-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-des3-x-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970519172020.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue May 20 10:52:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA28802 for ipsec-outgoing; Tue, 20 May 1997 10:52:05 -0400 (EDT) Message-Id: <2.2.32.19970520150634.00bf8f98@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 May 1997 11:06:34 -0400 To: kent@bbn.com, ipsec@tis.com From: Naganand Doraswamy Subject: Straw Poll Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I vote for the notify message to indicate the window size. As Bill S mentioned, the initiator can ignore this message if it wants to and it does not add any overhead for ISAKMP or IPsec. I dont like encryptionless ESP. It might be a little bit more efficient than AH but it does introduce lot of confusion. I would say that some one can use AH if they want to authenticate the pckets. Also, I am for making the replay mandatory both in AH and ESP. I hope I am not too late in giving my views. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue May 20 11:00:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28853 for ipsec-outgoing; Tue, 20 May 1997 11:00:06 -0400 (EDT) Message-Id: <2.2.32.19970520151445.00be3c08@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 May 1997 11:14:45 -0400 To: "PALAMBER.US.ORACLE.COM" From: Naganand Doraswamy Subject: Re: ESP New Draft Cc: ipsec@tis.com, PALAMBER@us.oracle.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, I strongly disagree with you statement that there is enough interest for encryptionless ESP that we should add support for it. In Memphis there was overwhelming majority for adding support for it and in my option we SHOULD not add support for this. As Matt Thomas metioned it will much more difficult to ship only auth version of IPsec and this is unnecessary complication without much profit. I request you to seriously reconsider your decision and adding support for this. Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue May 20 11:16:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28966 for ipsec-outgoing; Tue, 20 May 1997 11:14:35 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705201357.JAA02213@jekyll.piermont.com> References: Your message of "Tue, 20 May 1997 09:04:31 EDT." <199705201304.JAA13211@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 May 1997 11:20:33 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, I now have new appreciation for what Ran and Paul have endured as co-chairs for this group. In initiating this straw poll, I clear did a bad job, e.g., by not following the lead that Ran established in the ones that he administered. For example, I failed to establish the duration over whioch the poll would be conducted, and I failed to mention that private "votes" (ones not sent to the list) would be counted, etc. Mea culpa; I was too informal in trying to conduct this informal poll So, let's assume the end of this week is the closing date, thus having about a two-week interval for votes. Also, private votes count too. I criticized Ran privately for this practice in the past, and now I understand his rationale, i.e., I have received a few votes in favor of encryptionless ESP that were not made public because of fear of getting pilloried on this list. It's unfortunate that we have a deserved reputation for such animosity on this list. Meanwhile, I'll try to generate a message that I thibnk captures the major points, pro and con, over this issue, in an effort to clarify the discussion, as I have also received some messages indicating some confusion. Given all of the traffic, and the length of some of the messages, such confusion is to be expected. Steve From owner-ipsec Tue May 20 11:30:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29046 for ipsec-outgoing; Tue, 20 May 1997 11:30:37 -0400 (EDT) Message-Id: <199705201536.AA158672619@relay.hp.com> To: "Angelos D. Keromytis" Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: ESP revisions straw poll In-Reply-To: angelos's message of Tue, 20 May 1997 10:18:01 +0100. <199705201419.KAA27177@codex.cis.upenn.edu> Date: Tue, 20 May 1997 11:36:58 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'd much rather have vendors say they don't support ESP (or that > they have two versions of IPsec, one domestic and one exportable), > than them claiming they support "a version of ESP that is almost as > secure as the standard says, and it's exportable!". Right. That's a much clearer expression of my opinion on the subject than I've been able to manage to date.. - Bill From owner-ipsec Tue May 20 11:36:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29106 for ipsec-outgoing; Tue, 20 May 1997 11:36:39 -0400 (EDT) Message-Id: <199705201542.LAA03958@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 11:20:33 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 May 1997 11:42:56 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > I now have new appreciation for what Ran and Paul have endured as > co-chairs for this group. In initiating this straw poll, I clear did a > bad job, e.g., by not following the lead that Ran established in the ones > that he administered. For example, I failed to establish the duration over > whioch the poll would be conducted, and I failed to mention that private > "votes" (ones not sent to the list) would be counted, etc. Mea culpa; I > was too informal in trying to conduct this informal poll Steve; I realize that some other people care passionately about the encryptionless ESP issue. Myself, I don't care much, quite frankly. I'm happy either way, and I have no personal leanings. I also think it makes no real practical difference. *I REALLY MEAN THIS*. I have no personal axe to grind here. However, I'm a bit of a stickler for following procedure. We had a meeting at Memphis and the issue wasn't even close. We had close to unanimity against encryptionless ESP. This being the IETF, we follow the consensus. It wasn't even a rough consensus -- it was pretty damn close to everyone. I don't see any reason to believe this has changed. I understand that some people might perhaps feel that not all ideas have been completely expressed, but I think we've already had closure on this. If we feel free to re-open every possible point just because we dislike the outcomes, then how can we possibly make progress? I wanted 3DES to be mandatory to implement and I gave up on that early on -- I didn't even make much of a public argument, given that it was clear consenus wasn't with me. Should I follow your precedent and begin arguing the point now? Shall we re-open the question of IV lengths? The reason the IETF process works is because people agree to follow the rules. If we don't follow the rules, it falls apart. Perry From owner-ipsec Tue May 20 13:16:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29784 for ipsec-outgoing; Tue, 20 May 1997 13:14:40 -0400 (EDT) Message-Id: <3.0.32.19970520171706.008d11b0@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 20 May 1997 17:17:22 +0000 To: Stephen Kent From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: perry@piermont.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm inclined to write a draft defining a null encryption transform... At 11:20 AM 5/20/97 -0400, Stephen Kent wrote: >Perry, > > I now have new appreciation for what Ran and Paul have endured as >co-chairs for this group. In initiating this straw poll, I clear did a >bad job, e.g., by not following the lead that Ran established in the ones >that he administered. For example, I failed to establish the duration over >whioch the poll would be conducted, and I failed to mention that private >"votes" (ones not sent to the list) would be counted, etc. Mea culpa; I >was too informal in trying to conduct this informal poll > > So, let's assume the end of this week is the closing date, thus >having about a two-week interval for votes. Also, private votes count too. >I criticized Ran privately for this practice in the past, and now I >understand his rationale, i.e., I have received a few votes in favor of >encryptionless ESP that were not made public because of fear of getting >pilloried on this list. It's unfortunate that we have a deserved >reputation for such animosity on this list. > > Meanwhile, I'll try to generate a message that I thibnk captures >the major points, pro and con, over this issue, in an effort to clarify the >discussion, as I have also received some messages indicating some >confusion. Given all of the traffic, and the length of some of the >messages, such confusion is to be expected. > >Steve > > > From owner-ipsec Tue May 20 13:37:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29920 for ipsec-outgoing; Tue, 20 May 1997 13:37:39 -0400 (EDT) Date: Tue, 20 May 1997 13:42:56 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705201742.NAA13520@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: ESP revisions straw poll X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Perry E. Metzger" > > I realize that some other people care passionately about the > encryptionless ESP issue. Myself, I don't care much, quite > frankly. I'm happy either way, and I have no personal leanings. I also > think it makes no real practical difference. *I REALLY MEAN THIS*. > I have no personal axe to grind here. > > However, I'm a bit of a stickler for following procedure. We had a > meeting at Memphis and the issue wasn't even close. We had close to > unanimity against encryptionless ESP. This being the IETF, we follow > the consensus. It wasn't even a rough consensus -- it was pretty damn > close to everyone. > > [...] > > The reason the IETF process works is because people agree to follow > the rules. If we don't follow the rules, it falls apart. Well, we are closer to agreement than I thought. I too don't think this issue makes much practical difference, and my personal opinion is based on an intangible aesthetic preference, not hard technical requirements. And I share the discomforting feeling that procedure is being abused. However, I find it interesting that two people can observe the same set of events under the same set of ground rules, and still come to radically different conclusions. My interpretation: * The two public IPSEC sessions in Memphis were not making a great deal of progress, so the developers-only session was convened on the spot to hash out the issues and propose solutions to the WG at large. * The developers group had nearly unanimous agreement not to support ESP without encryption. * The document editor issued a call for comments on the set of open issues, one of the developers objected to including auth-only-ESP in the list of issues to be discussed, and Angelos claimed that no one on the list (and only two persons in private, one of whom later recanted) wanted it. * In response to this claim, at least eight people (including Bellovin, Orman, Simpson, Glatting, Lynn, Kent, Lambert, Kemp) expressed support for it (to varying degrees) on the public list. The IETF process absolutely requires that any "decisions" reached at meetings be confirmed by discussions on the mailing list. In many cases, the decisions reached at the meeting are confirmed on the list, either by active discussion or by silent consent. In this case, the discussion is active. It is incorrect to claim that consensus was reached in Memphis, because by IETF definition no decisions made there can be final. And it is incorrect to claim that consensus was reached earlier on the list and is now being revisited by sore losers, because until the "straw poll" message, no consensus had been requested. Many people don't feel the need to discuss their opinions on the list until an explicit solicitation is issued. The process *is* being followed. When the poll is over, I'll accept the results, whatever they are. From owner-ipsec Tue May 20 18:07:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA01823 for ipsec-outgoing; Tue, 20 May 1997 18:06:11 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705201542.LAA03958@jekyll.piermont.com> References: Your message of "Tue, 20 May 1997 11:20:33 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 May 1997 18:12:57 -0400 To: perry@piermont.com From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry, I don't intend to ride roughshood over IETF procedures, and I believe my characterization of how the straw poll is being conducted is consistent with how this WG has conducted such polls in the past. As for the Memphis IETF meeting, I have been informed that the second day implementors meeting did express a clear, overwhelming intent to not support auth-only ESP. No argument there However, consistent with IETF procedures, that decision is not the final say for the WG. I could observe that when I briefed the WG attendees at the San Jose meeting there seemed to be support FOR this mode of ESP. (I admit that the minutes from that meeting don't do a great job of recording all the details, but a completely modular ESP was part of the presentation that I gave. It's also a pity that the proceedings don't include those slides!) That previous show of support (in San Jose) clearly was not the last word, else we could argue that the matter was closed at that point, four months earlier than the Memphis meetings. Steve From owner-ipsec Tue May 20 18:57:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02073 for ipsec-outgoing; Tue, 20 May 1997 18:57:44 -0400 (EDT) Message-Id: <199705202303.TAA18619@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 09:57:57 EDT." <199705201357.JAA02213@jekyll.piermont.com> Date: Tue, 20 May 1997 19:03:09 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Since it seems that we need to show the support on the list *AGAIN*, I'll add my $0.02. I do not support reopening this issue. I support the consensus reached at memphis. If you need AH, use AH. And, as David has pointed out: > I just think it's silly to write a separate < 1 page RFC to specify > something that: > > 1) has semantic and performance properties that are useful to some, > 2) is short and easy to describe in the base ESP specification, > 3) has zero impact on developers' compliance with the standard, and > 4) will be implemented if there's market demand and won't be otherwise, > *regardless* of where it is documented. Since writing such a document is so very easy, I would suggest that those that are interested in having encryption-less ESP write that document, and advance it to standard on its own. There is no reason to put any mention in the base document. :!mcr!: | Network security programming, currently Michael Richardson | with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM4ItoqZpLyXYhL+BAQGFZwMAiaXWmkjinL5tffn9s7ZbXJ8zZUYBXC9x UNM95s/ONiSGkBZEf5OHkwQrYBY8Tk8QmrrD0dakYpwObr8JOfCqSF1wh4STpX3P WREUuRvWH2I0QDCm78HJC/yInWnnN7BD =UXlg -----END PGP SIGNATURE----- From owner-ipsec Wed May 21 01:13:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA03863 for ipsec-outgoing; Wed, 21 May 1997 01:10:49 -0400 (EDT) Date: Wed, 21 May 97 04:50:24 GMT From: "William Allen Simpson" Message-ID: <5906.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > So, let's assume the end of this week is the closing date, thus > having about a two-week interval for votes. Also, private votes count too. > I criticized Ran privately for this practice in the past, and now I > understand his rationale, i.e., I have received a few votes in favor of > encryptionless ESP that were not made public because of fear of getting > pilloried on this list. It's unfortunate that we have a deserved > reputation for such animosity on this list. > Private "votes" do _NOT_ count. Ever. They are not part of the record. When the "process" is examined, in the IESG or in court, the private messages will be meaningless. You want to come to the dance, you have to pay the piper. And that means public position statements are publicly rebutted, fragile egos not-with-standing. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed May 21 01:13:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA03862 for ipsec-outgoing; Wed, 21 May 1997 01:10:48 -0400 (EDT) Date: Wed, 21 May 97 04:58:28 GMT From: "William Allen Simpson" Message-ID: <5907.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: dpkemp@missi.ncsc.mil (David P. Kemp) > And I share the discomforting feeling that procedure is being abused. > > * The two public IPSEC sessions in Memphis were not making a great deal > of progress, so the developers-only session was convened on the spot to > hash out the issues and propose solutions to the WG at large. > The IPSec meetings for several years have not made any tangible progress. > * The developers group had nearly unanimous agreement not to support > ESP without encryption. > Yep. > * In response to this claim, at least eight people (including Bellovin, > Orman, Simpson, Glatting, Lynn, Kent, Lambert, Kemp) expressed > support for it (to varying degrees) on the public list. > Woah! You've got me in the wrong camp! I'm against encryptionless ESP, as mandatory to support, or even as _mentioned_ in the ESP base. What I noted was that an "encryptionless" transform could be written. It could have its own RFC number. Bellovin has recently offered. I noted these things in order to bring the argument to a conclusion, since the "encryptionless" camp could have their wishes as a non-mandatory entension. But they don't seem to be satisfied. They want to be mandatory. > The IETF process absolutely requires that any "decisions" reached at > meetings be confirmed by discussions on the mailing list. Absolutely, but that has happened. It's been a month and a half! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed May 21 02:55:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA04416 for ipsec-outgoing; Wed, 21 May 1997 02:53:50 -0400 (EDT) Message-Id: <199705210700.AAA03677@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 21 May 97 00:00:24 -0700 To: "William Allen Simpson" Subject: Re: ESP revisions straw poll cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <5906.wsimpson@greendragon.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 21 May 97 04:50:24 GMT From: "William Allen Simpson" > > From: Stephen Kent > > So, let's assume the end of this week is the closing date, thus > > having about a two-week interval for votes. Also, private votes count too. > > I criticized Ran privately for this practice in the past, and now I > > understand his rationale, i.e., I have received a few votes in favor of > > encryptionless ESP that were not made public because of fear of getting > > pilloried on this list. It's unfortunate that we have a deserved > > reputation for such animosity on this list. > > > > Private "votes" do _NOT_ count. Ever. They are not part of the > record. When the "process" is examined, in the IESG or in court, > the private messages will be meaningless. > Why don't private votes count? They do in public elections. What does examination of any IETF process in court have to do with anything? I don't see why private messages cannot be a matter of record. Since you mentioned the court system, private correspondence is often presented as evidence. You need look only as far as McVeigh and Kaczynski. > You want to come to the dance, you have to pay the piper. And that > means public position statements are publicly rebutted, > fragile egos not-with-standing. > Sounds a bit like a fraternity. -dpg From owner-ipsec Wed May 21 03:53:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA04766 for ipsec-outgoing; Wed, 21 May 1997 03:52:53 -0400 (EDT) Message-Id: <199705210759.DAA27328@codex.cis.upenn.edu> To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 20 May 1997 13:42:56 EDT." <199705201742.NAA13520@argon.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7946.864201449.1@dsl.cis.upenn.edu> Date: Wed, 21 May 1997 03:57:29 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705201742.NAA13520@argon.ncsc.mil>, David P. Kemp writes: > >* The document editor issued a call for comments on the set of open issues, > one of the developers objected to including auth-only-ESP in the list > of issues to be discussed, and Angelos claimed that no one on the list > (and only two persons in private, one of whom later recanted) wanted it. I never said noone; i said 3 (at that point, Kent, Glatting and Hilarie has spoken for it - and i did forget Lynn). As for private, it should be obvious i meant private with me (in response to my first message). I have no idea how many people talked to Steve. >* In response to this claim, at least eight people (including Bellovin, > Orman, Simpson, Glatting, Lynn, Kent, Lambert, Kemp) expressed > support for it (to varying degrees) on the public list. I must have missed Simpson' message, and i thought Steve (Bellovin) was just sick and tired of the arguing, not for e-ESP... -Angelos From owner-ipsec Wed May 21 07:32:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06033 for ipsec-outgoing; Wed, 21 May 1997 07:29:22 -0400 (EDT) Message-Id: <3.0.32.19970521113228.00890250@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 21 May 1997 11:34:48 +0000 To: "Angelos D. Keromytis" From: "Steven M. Bellovin" Subject: Re: ESP revisions straw poll Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:57 AM 5/21/97 +0100, Angelos D. Keromytis wrote: >I must have missed Simpson' message, and i thought Steve (Bellovin) >was just sick and tired of the arguing, not for e-ESP... Both, actually. Encryptionless ESP is the way AH should have been designed. (I objected to the current scheme at least as far back as Stockholm.) But yes, I'm tired of arguing. I'll settle for something that's ugly, less efficient, and unclean if it's here *now*... From owner-ipsec Wed May 21 08:44:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06830 for ipsec-outgoing; Wed, 21 May 1997 08:42:22 -0400 (EDT) Message-Id: <199705211248.IAA28217@codex.cis.upenn.edu> To: "Steven M. Bellovin" cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Wed, 21 May 1997 11:34:48 -0000." <3.0.32.19970521113228.00890250@127.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8381.864218820.1@dsl.cis.upenn.edu> Date: Wed, 21 May 1997 08:47:01 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19970521113228.00890250@127.0.0.1>, "Steven M. Bellovin" wri tes: > >Both, actually. Encryptionless ESP is the way AH should have been designed. >(I objected to the current scheme at least as far back as Stockholm.) But >yes, I'm tired of arguing. I'll settle for something that's ugly, less >efficient, and unclean if it's here *now*... Several people have mentioned that what the AH computation covers could be negotiated (wether it's the current scheme or just hte payload) by the key management layer. I don't think there would be many objections to that. -Angelos PS. I personally wouldn't object to a separate null encryption transform document either; i just don't want null-encryption in the base document. From owner-ipsec Wed May 21 09:49:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07402 for ipsec-outgoing; Wed, 21 May 1997 09:46:23 -0400 (EDT) Date: Wed, 21 May 1997 16:52:42 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199705211352.QAA14416@ee.technion.ac.il> To: smb@research.att.com Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >yes, I'm tired of arguing. I'll settle for something that's ugly, less >efficient, and unclean if it's here *now*... Actualy from a pure cryptographic point of view there is something very clean and nice about an empty encryption: none of the known key search attacks will apply to this method (and I suspect that one can prove that even future attacks will not apply either). :) Hugo From owner-ipsec Wed May 21 09:49:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07412 for ipsec-outgoing; Wed, 21 May 1997 09:48:23 -0400 (EDT) To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-esp-des1-v2-00.txt Date: Wed, 21 May 1997 09:22:46 -0400 Message-ID: <9705210922.aa29493@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP DES-CBC Transform Author(s) : P. Karn, P. Metzger, W. Simpson Filename : draft-simpson-esp-des1-v2-00.txt Pages : 13 Date : 05/19/1997 This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-esp-des1-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des1-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-esp-des1-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970519171713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-esp-des1-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-des1-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970519171713.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed May 21 10:30:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07684 for ipsec-outgoing; Wed, 21 May 1997 10:25:27 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5907.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 10:24:54 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You just said: "I noted these things in order to bring the argument to a conclusion, since the "encryptionless" camp could have their wishes as a non-mandatory entension. But they don't seem to be satisfied. They want to be mandatory." While it is true that the current I-D would suggest mandatory support for encryptionless ESP, my message of 5/15 stated: "I do have a suggestion, though, to help reach closure on this topic. What if we say that an IPSEC implementation MAY elect to send packets that are authenticated, but not encrypted? That makes the existing implementations compliant in this regard, yet holds open th opportunity for future implementations to offer this feature if there is sufficinet demand. An attempt to negotiate a set of algorithms that includes no encryption can be rejected just like an attempt to negotiate use of an encryption algorithm that is not supported. One could even encode this as a null encryption algorithm, as Bill Simpsom noted, if that would make processing any more uniform." From owner-ipsec Wed May 21 10:30:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07685 for ipsec-outgoing; Wed, 21 May 1997 10:25:28 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5906.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 10:20:50 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Look back at the straw polls Ran executed and you'll see that he did precisely this. I'm not changing the rules, though I have objected to this way of doing business in the past. The unfortunate fact is that harsh messages from members of this list, and some of your previous messages are often cited as examples of this, have intimidated members of the list, disenfranchising them. This approach was adopted to counter this problem. Steve From owner-ipsec Wed May 21 11:02:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07935 for ipsec-outgoing; Wed, 21 May 1997 10:55:55 -0400 (EDT) From: Kai Martius Organization: UNIKLINIK TUD To: ipsec@tis.com Date: Tue, 21 May 1997 16:50:52 MET Subject: AH-Lite Reply-to: kai@imib.med.tu-dresden.de X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <2D745207181@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'm fairly new on this list (unfortunally, because the discussion is -mostly- very interesting), so I apologize for things I write or ask that may have been discussed months ago. First my opinion to the discussion about ESP with or w/o encryption: Authentication and integrity will be in much broader use than encryption, I believe. Beside export regulation issues there are much more nodes on the Net that want to verify authenticity and integrity of hosts/users/servers than nodes that have to provide privacy. Privacy is more an end-to-end issue i.e. application to application. Only in a VPN-construction where a security gateway detects unencrypted packets it has to use Tunnel-ESP. It's much more important the GW can use _autheticated_ adresses or -much better- certificates to make a policy-based decision what to do with that packet. I read the current I-D so that AH already provides authentication over the whole packet (except some header fields) - so why we need auth.-only ESP? (provokative question: why auth. in ESP on the whole? If you need authenticy / integrity use AH , if you need privacy too, use ESP!; ESP allone would only work with 'integrity-enabled' encryption mechanism) Because we won't see public key crypto for auth. purposes very soon, I see a problem in verifying AH on other systems than dst. system. Assuming fragmentation, AH could only be validated on dst. system (even if we use public key crypto). AH-tunnel would be a way, but I think thats a lot of overhead. So, is there a way to use AH for header-authentication only? I could imagine following processing: - Sender uses AH to authenticate the whole packet, SA with ultimate destination. - if there are nodes on the way that want to verify packets, the sender has to establish different SAs to this nodes. But: It only needs to authenticate appropriate header fields, because a concatenation to data portion is given through inclusion of first AH in ICV-computation. Extra AHs should be placed _before_ all other AHs. Problem: how to find the nodes that need a extra AH? (ICMP-message or special DNS-record - like proposed by Dan Harkins some times ago?). Question: Do I need another IP-Header together with extra AH (which would be AH-tunnel-mode without authenticating the whole packet again); but if the node is a router, packet won't be sent with dst. address .. ? Question: how could I maintain a SA without being the addressee of the packet? - this solution would also be possible, if gateways / routers on organisation boundaries don't want to verify packets from inside, but working on a VPN. Now the gateway / router has to establish the appropriate SA and inserts the extra AH. But: If there is no AH yet, it has to authenticate the whole packet. - every verified AH can be extracted from the packet. Any suggestions on this scheme? Thanks, Kai From owner-ipsec Wed May 21 11:40:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08215 for ipsec-outgoing; Wed, 21 May 1997 11:37:24 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 21 May 1997 09:44:01 -0600 From: Brad Davis To: dennis.glatting@plaintalk.bellevue.wa.us Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll -Reply Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk >>> Dennis Glatting 05/21/97 01:00am >Why don't private votes count? They do in public elections. Public elections are not consensus building exercises. If we were counting votes then this discussion would not even be happening. The proposal would have failed long ago. >I don't see why private messages cannot be a matter of record. >Since you mentioned the court system, private correspondence >is often presented as evidence. You need look only as far as >McVeigh and Kaczynski. Private messages are like private conversations at the IETF meetings, they are useful to discuss ideas and present positions, but they are not at all useful to build consensus. That requires the private messages become public. The WG chair cannot allow private messages to control the WG. If something is so sensitive that it cannot be brought up in a public meeting, then it must either be ignored, brought up to the IETF Board, or each member of the WG must be approached individually (and consensus built). In a court of law (US law), private messages are not part of the "record" until they are made public by being subpoenaed (except in certain cases of national security). They then become part of the public record and are admissible in the court. >> You want to come to the dance, you have to pay the piper. And that >> means public position statements are publicly rebutted, >> fragile egos not-with-standing. >Sounds a bit like a fraternity. We are, in the original sense of the word. Brad Davis U.S. Robotics From owner-ipsec Wed May 21 11:52:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08299 for ipsec-outgoing; Wed, 21 May 1997 11:50:26 -0400 (EDT) Message-Id: <199705211551.LAA07331@raptor.research.att.com> To: ipsec@tis.com Subject: Re: ESP revisions straw poll Date: Wed, 21 May 1997 11:51:34 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19970521113228.00890250@127.0.0.1>, "Steven M. Bell ovin" wri tes: > >Both, actually. Encryptionless ESP is the way AH should have been de signed. >(I objected to the current scheme at least as far back as Stockholm.) But >yes, I'm tired of arguing. I'll settle for something that's ugly, le ss >efficient, and unclean if it's here *now*... Several people have mentioned that what the AH computation covers could be negotiated (wether it's the current scheme or just hte payload) by the key management layer. I don't think there would be many objections to that. Well, count at least one... We should try very hard not to add extra complexity. My objection to the current AH specification is that it is complex to implement. Adding a negotiated variant would just add to the complexity. Besides, each variant would need to be analyzed for safety. Hmm -- we could make the scope of the authentication programmable. AH-scope: { bytes=1-5 byte-order=network bits=2-4 bit-order=intel base=ip bytes=7-8 byte-order=ibm bits=* base=udp bytes=* base=ip-options filter=java::ip_optionfilt(type,len) } Never mind, I'm feeling grouchy this morning... Let me be a bit more blunt than usual. *) I don't like complexity. Apart from the esthetics -- and those are important -- complex structures are buggy. Cryptographic protocols are *hard* to get right; the more of them we have, the less assurance we have that any of them individually are correct. More to the point, we have no assurance that arbitrary combinations are correct. We've already seen that the order of AH and ESP can be important (for example, against short-block guessing attacks). *) I don't like complex code. It's likely to be buggy. *) I don't like unnecessary multiplication of mechanism. This is especially true when there's no clear guidance -- especially guidance amenable to programmed decisions -- about when to use which variant. In this particular case, someone has suggested negotiating what AH covers. What is the basis for making the decision? *) I don't like mutating protocols. The problem with AH is that some fields are sometimes modified in transit. This is not under control of the end systems. In fact, it's rarely knowable to the users of the end systems, since they don't control what happens in the network cloud. The solution, such as it is, was to decree that certain fields have to be zeroed before the MAC computation. Leaving out the layering violation (see the point about code complexity above), in the 21 months since RFC 1826 the network cloud has changed its behavior. Section 3.2.3.1.1 of the Kent/Atkinson AH draft notes (with appropriate snideness) that the TOS field should now be zeroed, too, since some router vendors have chosen to violate RFC 791 and diddle those bits. And it's going to get worse -- see Section 3.2.3.1.2 for examples of what I mean. *) I don't like layering violations. AH requires that the IP header be calculated first, then AH called to fill in data that follows the IP header. *) I don't like meaningless cryptography. Almost two years ago, I posted a field-by-field analysis. I showed that the IP header fields are either irrelevant for security purposes, changed en route (and hence not protectable), or are or should be bound to the security association, and hence need not be authenticated on a per-packet basis. That's all well and good. It's also irrelevant -- others disagreed with me, for good and sufficient reason, and their arguments (and needs) carried the day. I've kept quiet about the issue since then, because I have another dislike: *) I don't like working groups that drag on forever, fine-tuning a protocol to the point of irrelevancy. Folks, we're under a deadline. There are real products out there that implement some version of IPSEC. There are things like PPTP that also include authentication and encryption. We need to finish *now*. The only reason we're discussing this again is because we realized that encryption almost always requires authentication. This may not be sufficient reason to reopen the question, especially given the immediately preceeding point. But yes, in an ideal world I'd opt for a clean AH, aka encryptionless ESP. --Steve Bellovin From owner-ipsec Wed May 21 13:24:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09050 for ipsec-outgoing; Wed, 21 May 1997 13:23:27 -0400 (EDT) Message-Id: <199705211729.NAA26963@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: dennis.glatting@plaintalk.bellevue.wa.us cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Wed, 21 May 1997 00:00:24 PDT." <199705210700.AAA03677@imo.plaintalk.bellevue.wa.us> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 May 1997 13:29:17 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dennis Glatting writes: > Why don't private votes count? They do in public elections. This isn't an election. We don't VOTE in the IETF. We express group consensus -- sometimes rough, sometimes not. Things done in private are hard for the group as a whole to assess. Perry From owner-ipsec Wed May 21 13:34:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09116 for ipsec-outgoing; Wed, 21 May 1997 13:33:55 -0400 (EDT) From: rivest@theory.lcs.mit.edu (Ron Rivest) Date: Wed, 21 May 97 10:32:08 EDT Message-Id: <199705211432.AA06746@swan.lcs.mit.edu> To: ipsec@tis.com Subject: Empty encryption Sender: owner-ipsec@ex.tis.com Precedence: bulk Gee, if we christen the identity (null) transform as an encryption technique, does that mean we have to apply for export approval to ship out a file-copy program? ;-) Cheers, Ron From owner-ipsec Wed May 21 15:14:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09970 for ipsec-outgoing; Wed, 21 May 1997 15:12:31 -0400 (EDT) Message-ID: <338300B3.37DA@Philosophers.GR> Date: Wed, 21 May 1997 10:03:32 -0400 From: Plato X-Mailer: Mozilla 3.0 (Macintosh; U; PPC) MIME-Version: 1.0 To: ipsec@tis.com Subject: IPsec and Platonic =?iso-8859-1?Q?Ideals=AE?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id JAA07484 Sender: owner-ipsec@ex.tis.com Precedence: bulk Gentlemen: It has recently come to my attention that your IETF WG is using the term "Platonic Ideal" to refer to certain aspects of ongoing work.  I would like to observe that one of my best known dialogues does, in fact, bear on the area of cryptography used for communication.  Most historians of ancient Greece have terroneously ranslated my text into a question of whether a tree falling in a forrest makes a noise if nobody is present to hear.  In fact, the original text asks the analogous question of whether a passive wiretapper, intercepting an encrypted (at the physical layer) staellite down link can be said to have effected wiretapping.  (I attribute the mis-translation to the fact that most historians are not very technical.)  With this in mind, I suggest that members of your WG exercise due restraint in referring to certain matters as being representative of Platonic Ideals®.  My attorney has suggested that I retroactively apply for a trademark on this term and its scope of applicability will certainly include the area in which the IPsec WG conducts its business, based on the properly translated dialogue I cited above. Sincerely, Plato From owner-ipsec Wed May 21 18:18:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11090 for ipsec-outgoing; Wed, 21 May 1997 18:17:02 -0400 (EDT) Date: Wed, 21 May 1997 18:20:08 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705212220.SAA01890@earth.hpc.org> To: ipsec@tis.com In-reply-to: Yourmessage <199705211925.MAA07040@baskerville.CS.Arizona.EDU> Subject: Re: IPsec and Platonic =?iso-8859-1?Q?Ideals=AE?= Sender: owner-ipsec@ex.tis.com Precedence: bulk > historians of ancient Greece have terroneously ranslated my text into We have some terroneous ranslators on this bus, too. Hilarie PS Thanks for the levity --- it is not falling (rising?) in an empty forest. From owner-ipsec Wed May 21 19:26:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11489 for ipsec-outgoing; Wed, 21 May 1997 19:25:36 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 19:33:00 -0400 To: ipsec@tis.com From: Stephen Kent Subject: new AH spec Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, You will soon receive a new I-D for AH, that includes fixes for all but one of the comments made after Memphis. The differences between this version and RFC 1826 are documented in a new section, so I won't bother describing them here. The one unresolved area has to do with AH placement in IPv6 headers. Dan McDonald and Charlie Lynn differed a bit on the wording of the text with regard to the semantics of destination options appearing before or after AH. I'm not sure how critical this residual issue is, but my analysis of the messages suggests that we did not come to a resolution. I'd appreciate it is Charlie and Dan could come up with wording that both are comfortable with, so that we can wrap up this spec. A revsised version of ESP will follow next week. As a reminder, I note that we began a few eeks ago by sending out the first of a series of messages that address topics for inclusion in the Security Architecture document. The first message addressed PMTU processing and elicited just a few responses, to which replies were sent. In the interest of resolving these issues so that implementors can proceed with confidence in releasing compliant IPsec products, we need to make progress on these topics as each is released (before we compose and distribute the Security Architectuire I-D). So, please go back and review the PMTU message, and review and respond to subsequent messages that will be released soon. Thanks, Steve From owner-ipsec Wed May 21 20:00:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11643 for ipsec-outgoing; Wed, 21 May 1997 19:59:34 -0400 (EDT) Message-Id: <199705220006.RAA10511@cs.pdx.edu> To: Stephen Kent cc: ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Tue, 13 May 1997 21:05:41 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10506.864259571.1@cs.pdx.edu> Date: Wed, 21 May 1997 17:06:11 -0700 From: Bill Trost Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: I've gotten the impression that there is support for encryptionless ESP.... So, I'd like to conduct a straw poll on this topic too. After all this wrangling, I'd like to submit a straw of "whatever, let's get this over with". I think encryptionless ESP is a fine idea, but I see no compelling need to mention it in the ESP draft. On the other hand, Hugo comments on the security characteristics of the Identity transform need to be included in *that* draft.... From owner-ipsec Wed May 21 20:58:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11995 for ipsec-outgoing; Wed, 21 May 1997 20:57:34 -0400 (EDT) Message-Id: <199705220103.SAA07168@greatdane.cisco.com> To: Stephen Kent cc: William Allen Simpson , ipsec@tis.com Subject: Re: ESP revisions straw poll In-reply-to: Your message of "Wed, 21 May 1997 10:20:50 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 1997 18:03:58 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I'm sure you were against using private "votes" for the very obvious reason that the holder of the straw poll can always ensure his personal viewpoint prevails. Whether there is precedence or not, this is bad-- unless of course we can all include the private discussions we've had in your final tally. Dan. > Look back at the straw polls Ran executed and you'll see that he > did precisely this. I'm not changing the rules, though I have objected to > this way of doing business in the past. The unfortunate fact is that harsh > messages from members of this list, and some of your previous messages are > often cited as examples of this, have intimidated members of the list, > disenfranchising them. This approach was adopted to counter this problem. From owner-ipsec Thu May 22 00:43:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA13110 for ipsec-outgoing; Thu, 22 May 1997 00:42:04 -0400 (EDT) Date: Thu, 22 May 97 04:24:05 GMT From: "William Allen Simpson" Message-ID: <5925.wsimpson@greendragon.com> To: Steven Bellovin Cc: ipsec@tis.com Subject: eliminate AH Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Steven Bellovin > *) I don't like meaningless cryptography. Almost two years > ago, I posted a field-by-field analysis. I showed that the IP > header fields are either irrelevant for security purposes, > changed en route (and hence not protectable), or are or should > be bound to the security association, and hence need not be > authenticated on a per-packet basis. > I don't remember this message, and cannot find it. Could you please point us to a date (or even a month), so that I can find it in my archives? > *) I don't like working groups that drag on forever, > fine-tuning a protocol to the point of irrelevancy. Folks, > we're under a deadline. There are real products out there that > implement some version of IPSEC. There are things like PPTP > that also include authentication and encryption. We need to > finish *now*. > My view is that we passed the deadline some years ago. Certainly, we passed our charter deadline. I think we passed the Internet commercial usefulness deadline, too. We have at least 4 Working Groups creating their own security protocols, because this WG never got done. We had something, and the "powers that be" declared it obsolete. > The only reason we're discussing this again is because we realized that > encryption almost always requires authentication. This may not be > sufficient reason to reopen the question, especially given the > immediately preceeding point. But yes, in an ideal world I'd opt > for a clean AH, aka encryptionless ESP. > Fine. Then, let's get rid of AH entirely. We started without AH, with swIPe in 1992-1993. I was a convert to the philosophy that orthogonality of function was important in this matter, for both political (export) and practical reasons; thus, that AH and ESP should be separate. Like many converts, I followed that path with zeal. I was willing to have the extra 8 bytes of overhead. But, the leader of that path, Ran Atkinson, recanted last year, saying it was a "serious mistake". He said this into a microphone, and we have his words on file. It is causing too much contention to keep going down this path. I don't want 2 different ways to authenticate. It's too complicated. We only need one way, for all the reasons given by Steve in his earlier message. If we have it in ESP, and cannot agree on when to use it and when not, then let's discard AH. Simplify. From owner-ipsec Thu May 22 08:50:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA16194 for ipsec-outgoing; Thu, 22 May 1997 08:48:07 -0400 (EDT) From: Uri Blumenthal Message-Id: <9705221254.AA19036@hawpub.watson.ibm.com> Subject: Re: Empty encryption To: rivest@theory.lcs.mit.edu (Ron Rivest) Date: Thu, 22 May 1997 08:54:06 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199705211432.AA06746@swan.lcs.mit.edu> from "Ron Rivest" at May 21, 97 10:32:08 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Ron Rivest says: >Gee, if we christen the identity (null) transform as an encryption technique, >does that mean we have to apply for export approval to ship out a file-copy >program? ;-) No, but be ready to spend some time in a federal facility, if they find out about your "cp" program exported to Mexico (:-). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu May 22 10:01:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16752 for ipsec-outgoing; Thu, 22 May 1997 09:57:51 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199705221403.HAA16250@netcom.netcom.com> Subject: Re: eliminate AH To: wsimpson@greendragon.com (William Allen Simpson) Date: Thu, 22 May 1997 07:03:46 -0700 (PDT) Cc: smb@research.att.com, ipsec@tis.com In-Reply-To: <5925.wsimpson@greendragon.com> from "William Allen Simpson" at May 22, 97 04:24:05 am Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 944 You may also be interested in Phil Rogaway's comments on IPSEC. It's a couple of years old now but it is probably still relevant. http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/ draft-rogaway-ipsec-comments-00.txt - Alex > > > From: Steven Bellovin > > *) I don't like meaningless cryptography. Almost two years > > ago, I posted a field-by-field analysis. I showed that the IP > > header fields are either irrelevant for security purposes, > > changed en route (and hence not protectable), or are or should > > be bound to the security association, and hence need not be > > authenticated on a per-packet basis. > > > I don't remember this message, and cannot find it. Could you please > point us to a date (or even a month), so that I can find it in my > archives? > > -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Thu May 22 10:27:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16904 for ipsec-outgoing; Thu, 22 May 1997 10:26:13 -0400 (EDT) Message-Id: <3.0.1.32.19970522103128.0077e4c0@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 10:31:28 -0400 To: "William Allen Simpson" From: Matt Thomas Subject: Re: eliminate AH Cc: ipsec@tis.com In-Reply-To: <5925.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:24 AM 5/22/97 GMT, William Allen Simpson wrote: >I don't want 2 different ways to authenticate. It's too complicated. I'd rather not have two methods as well. >We only need one way, for all the reasons given by Steve in his earlier >message. If we have it in ESP, and cannot agree on when to use it and >when not, then let's discard AH. Simplify. Or simply define AH as encryptionless ESP. (e.g. the processing rules are identical for both execpt that if you are using null-encryption the protocol field is AH else it's ESP). This does. however, mean that IPv6 routing headers and hop-by-hop options can not be authenticated. (the destination node options can be covered by placing them after the AH/ESP; this technique should work for the Mobile IPv6 routing header as well since it's transmitted in "final form" by the mobile host). -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu May 22 10:39:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16971 for ipsec-outgoing; Thu, 22 May 1997 10:37:43 -0400 (EDT) Message-Id: <3.0.32.19970522104135.00761ff0@mail.bbnplanet.com> X-Sender: smarcus@mail.bbnplanet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 22 May 1997 10:41:39 -0400 To: uri@watson.ibm.com From: Scott Marcus Subject: Re: Empty encryption Cc: Ron Rivest , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:54 AM 5/22/97 -0400, Uri Blumenthal wrote: >Ron Rivest says: >>Gee, if we christen the identity (null) transform as an encryption technique, >>does that mean we have to apply for export approval to ship out a file-copy >>program? ;-) > >No, but be ready to spend some time in a federal facility, if they >find out about your "cp" program exported to Mexico (:-). No problem! Just make sure that the null encryption (vacuously) uses short keys. ;^) -- Scott From owner-ipsec Thu May 22 10:51:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17039 for ipsec-outgoing; Thu, 22 May 1997 10:51:14 -0400 (EDT) Date: Thu, 22 May 1997 10:59 -0500 From: "Hapeman Dale" To: kent@bbn.com, trost@cs.pdx.edu Cc: ipsec@tis.com Subject: Re: ESP revisions straw poll Message-ID: <2EBCC26E@asq8po2.bah.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Below... ---------- >From: Bill Trost >Subject: Re: ESP revisions straw poll > > >After all this wrangling, I'd like to submit a straw of "whatever, let's >get this over with". I think encryptionless ESP is a fine idea, but I see >no compelling need to mention it in the ESP draft. > I'd like to latch on an idea here... "I see no compelling need to mention it in the ESP draft". Currently: We have an *algorithm independent* encryption protocol (ESP) which has a conformance section that specifies which algorithms you must implement. We have an *algorithm independent* key management protocol (ISAKMP) which uses a separate document (a DOI) to describe the negotiation of available algorithms (among other things). We have an IPSec DOI that makes statements like "All implementations within the IPSEC DOI MUST support ESP_DES...". Therefore: I see no compelling need to mention ANY ALGORITHM IMPLEMENTATION REQUIREMENTS in the ESP draft. This means that the IPSec DOI document is more than a supplement to ISAKMP, it is essentially a high level policy for implementing IPSec. (I claim that, as the DOI is written, this is already true.) Now, back to the question at hand: Should encryptionless ESP be qualified as MUST, SHOULD, MAY, MAY NOT, SHOULD NOT, BETTER NOT, or ignored? From the DOI (draft-ietf-ipsec-ipsec-doi-02.txt) Section 4.4.4: _____________ 4.4.4, IPSEC ESP Transform Identifiers The Encapsulating Security Protocol (ESP) defines one mandatory and several optional transforms used to provide data confidentiality. The following table lists the defined ESP Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 ESP_DES_CBC 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 4.4.4.1 ESP_DES_CBC -- MAY be used for compatibility 4.4.4.2 ESP_DES -- MUST support ESP_DES along with the HMAC and REPLAY attributes. 4.4.4.3 ESP_3DES -- strongly encouraged to support ESP_3DES along with the HMAC and REPLAY attributes 4.4.4.4 ESP_RC5 -- (no requirement to implement stated) _____________ I claim that we could add: ESP_NADA 5 (or ESP_IDENTITY, or ... :-) and a section 4.4.4.5 that makes no statement concerning mandatory-ness (just as was done in the case of RC5). Note that this section could include any information needed in the "encryptionless transform" document some are asking for. Dale Hapeman hapemand@bah.com From owner-ipsec Thu May 22 11:15:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17197 for ipsec-outgoing; Thu, 22 May 1997 11:13:15 -0400 (EDT) Message-Id: <97May22.110746edt.11649@janus.tor.securecomputing.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: eliminate AH References: <5925.wsimpson@greendragon.com> In-reply-to: wsimpson's message of "Thu, 22 May 1997 00:24:05 -0400". <5925.wsimpson@greendragon.com> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 22 May 1997 11:12:03 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > We have at least 4 Working Groups creating their own security protocols, > because this WG never got done. We had something, and the "powers that > be" declared it obsolete. I wouldn't go that far. They're just solving different problems. Nonetheless, we are way past our deadlines, and people *are* going to get fed up and do it themselves if we don't shape up. The popularity of SSH, SSL, PPTP, etc. are all because of RUNNING CODE. If we change the bloody standards every 3 months, we'll *never* get running code, and we'll never obtain significant deployment. -- Harald Koch From owner-ipsec Thu May 22 11:23:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17296 for ipsec-outgoing; Thu, 22 May 1997 11:23:17 -0400 (EDT) Date: Thu, 22 May 97 11:27:27 EST From: "Whelan, Bill" Message-Id: <9704228643.AA864325641@netx.nei.com> To: smb@research.att.com, "William Allen Simpson" Cc: ipsec@tis.com Subject: Re: eliminate AH Sender: owner-ipsec@ex.tis.com Precedence: bulk I second the motion to eliminate AH from IPSec. Given the evolution of ESP, it has become redundant. The ESP document should define the - SPI - Mandatory - Sequence Number - Mandatory (I think?) - Opaque Payload Data - Mandatory but dependent upon the transform. - Authentication Data - Optional ESP may define restrictions on the length (e.g. a multiple of eight bytes) of the Opaque Payload Data, but otherwise not define content. Individual Transform documents would provide definitions for how the Opaque Payload Data is defined and would cover any needed fields including: - Initialization Vector - Optional - Payload Data - Mandatory - Padding - Optional - Next Header - Mandatory My two cents. Bill Whelan From owner-ipsec Thu May 22 19:01:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA19947 for ipsec-outgoing; Thu, 22 May 1997 18:58:57 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2EBCC26E@asq8po2.bah.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 1997 19:02:32 -0400 To: Hapeman Dale From: Stephen Kent Subject: Re: ESP revisions straw poll Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dale, Your comments re algorithm independence are applicable to both AH and ESP. I'd be happy to remove the afor compliant implementations and the ISAKMP DOI specs would not be applicable in such cases. So, unless we mandate ISAKMP use in all instances, we need to specify the required algorithms somewhere. One could have yet another RFC with these listed, but the previous RFCs did not take that approach did not adopt that approach, and so I stuck with the previous model. Steve From owner-ipsec Fri May 23 10:15:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24893 for ipsec-outgoing; Fri, 23 May 1997 10:09:22 -0400 (EDT) Message-Id: <199705231434.KAA27906@relay.rv.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: Dan.McDonald@Eng.Sun.COM (Dan McDonald) Date: Sat, 24 May 1997 02:57:37 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: V2 - Structuring SA proposals CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by portal.ex.tis.com id KAA24890 Sender: owner-ipsec@ex.tis.com Precedence: bulk RE: PF_key v2· I dont like/understand why/disagree with there being two extensions to achieve one objective - that of prioritising algorithms - this is effectively what the ASSOCIATION EXT and the PROPOSAL EXT achieve. Would it be better to have something like the following :- NOTE: alignment being ignored ;-) Base Header: struct sadb_msg { uint8_t sadb_msg_version; uint8_t sadb_msg_type; uint8_t sadb_msg_errno; uint8_t sadb_sa_type; uint8_t sadb_sa_state; uint8_t sadb_sa_spi; uint16_t sadb_msg_len; uint32_t sadb_msg_seq; uint32_t sadb_msg_pid; } Proposal Extension: struct sadb_prop { uint16_t sadb_prop_len; uint16_t sadb_prop_num_combs; uint16_t sadb_prop_replay; (cant flags indicate we want replay ?) uint16_t sadb_prop_flags; } Combination Extension: struct sadb_comb{ uint8_t sadb_comb_num; uint8_t sadb_comb_len; uint8_t sadb_comb_auth; uint8_t sadb_comb_encr; uint16_t sadb_comb_auth_keylen_min; uint16_t sadb_comb_auth_keylen_max; uint16_t sadb_comb_encr_keylen_min; uint16_t sadb_comb_encr_keylen_max; } Elfed **************************************************** Elfed T. Weaver Defence Evaluation & Research Agency Malvern UK +44 01684 894795 weaver@hydra.dra.hmg.gb From owner-ipsec Fri May 23 11:26:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25451 for ipsec-outgoing; Fri, 23 May 1997 11:22:44 -0400 (EDT) Date: Fri, 23 May 1997 11:25:51 -0400 From: "Waterhouse, Richard" Subject: RE: eliminate AH To: "'William Allen Simpson'" , "'C. Harald Koch'" Cc: "'ipsec@tis.com'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > >We have at least 4 Working Groups creating their own security protocols, > >Nonetheless, we are way past our deadlines, and people *are* going to get >fed up and do it themselves if we don't shape up. > >The popularity of SSH, SSL, PPTP, etc. are all because of RUNNING CODE. >>> ISAKMP is supposed to be for more general use than just negotiating IP security. Yet I can detect no trace of any effort to coordinate its use it with any of the other Internet security mechanisms. Is there any such effort underway that is simply not visible to me ? From owner-ipsec Fri May 23 11:36:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25572 for ipsec-outgoing; Fri, 23 May 1997 11:36:24 -0400 (EDT) Message-Id: <97May23.113813edt.11650@janus.tor.securecomputing.com> To: "Waterhouse, Richard" cc: "'ipsec@tis.com'" Subject: Re: eliminate AH References: In-reply-to: Richard.Waterhouse's message of "Fri, 23 May 1997 11:25:51 -0400". From: "C. Harald Koch" Date: Fri, 23 May 1997 11:42:30 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "Waterhouse, Richard" writes: > ISAKMP is supposed to be for more general use than just negotiating IP > security. Yet I can detect no trace of any effort to coordinate its > use it with any of the other Internet security mechanisms. Is there > any such effort underway that is simply not visible to me ? If we had: - a STABLE standard - running code I'm sure many of the other security people would adopt it. Since we have neither, they're busy inventing their own. -- Harald Koch From owner-ipsec Fri May 23 12:11:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25819 for ipsec-outgoing; Fri, 23 May 1997 12:11:30 -0400 (EDT) Message-Id: <199705231616.JAA09729@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "C. Harald Koch" Cc: "Waterhouse, Richard" , "'ipsec@tis.com'" Subject: Re: eliminate AH In-Reply-To: Your message of "Fri, 23 May 1997 11:42:30 EDT." <97May23.113813edt.11650@janus.tor.securecomputing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 09:16:56 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk "C. Harald Koch" wrote: > In message , "Waterhouse, Richard" writes: > > ISAKMP is supposed to be for more general use than just negotiating IP > > security. Yet I can detect no trace of any effort to coordinate its > > use it with any of the other Internet security mechanisms. Is there > > any such effort underway that is simply not visible to me ? > > If we had: > > - a STABLE standard > - running code > > I'm sure many of the other security people would adopt it. > > Since we have neither, they're busy inventing their own. Do you have any constructive comments on how to make the standard STABLE? What makes it un-STABLE? I and quite a few others have been able to code independent interoperable implementations from the existing docs in spite of its few known inconsistencies and issues open to interpretation. If you haven't please share your problems with others. You want running code? Visit http://www.cisco.com/public/library/isakmp/isakmp.html answer the questions and it's yours. Once I get the OK I'll be releasing version 7 compliant code (yes it exists, yes it's interoperated with other independent implementations); what's there is version 6. And to answer Richard: yes, there is movement but its just not visible yet. Dan. From owner-ipsec Fri May 23 12:49:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26051 for ipsec-outgoing; Fri, 23 May 1997 12:46:26 -0400 (EDT) Date: Fri, 23 May 1997 12:51:53 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705231651.MAA16706@argon.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP at other layers (was RE: eliminate AH) X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Waterhouse, Richard" > > >We have at least 4 Working Groups creating their own security protocols, > > > >Nonetheless, we are way past our deadlines, and people *are* going to get > >fed up and do it themselves if we don't shape up. > > > >The popularity of SSH, SSL, PPTP, etc. are all because of RUNNING CODE. > > >>> ISAKMP is supposed to be for more general use than just negotiating IP > security. Yet I can detect no trace of any effort to coordinate its > use it with any of the other Internet security mechanisms. Is there > any such effort underway that is simply not visible to me ? There is just more than a trace of effort at this point :-). The use of ISAKMP as the TLS key establishment mechanism was discussed as far back as the very first TLS WG meeting. But at that time the IPSEC WG was deep into KMP battles, first with Photuris, then with SKIP. There was not (and still is not) a referenceable RFC for ISAKMP, and little experience with running code. By contrast, the SSL v2 key negotiation mechanism (the "handshake layer") was already widely deployed, and the lessons learned from v2 were applied in the design of SSL v3, the baseline for TLS. Now that the TLS working group is about to publish TLS 1.0, the schedule pressure is off and a little more thought can be given to designing TLS 1.1 and beyond. The TLS discussions in Memphis included accommodating the needs of SSH, and enabling/migrating to the use of ISAKMP. This is just at the discussion stage, and there is certainly no consensus on what specifically needs to be done, but there is a faction that believes that the IETF should have a single KMP suitable for use at all network layers, reducing the need for security analyses for each different network protocol, and enabling new features/requirements to be designed and defined once and then reused for multiple protocols. Rather than having the IPSEC WG attempt to push ISAKMP out to other applications, it would be more effective for the other working groups to attempt to pull ISAKMP in. If there is a protocol you are particularly interested in, go to it's WG and speak up. From owner-ipsec Fri May 23 13:06:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26164 for ipsec-outgoing; Fri, 23 May 1997 13:05:31 -0400 (EDT) Hops: 0 Host: tis.com. Posted-Date: Fri, 23 May 1997 20:06:39 -0200 (GMT) Message-Id: <199705231707.UAA18667@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@tis.com Cc: "Whelan, Bill" Subject: Re: eliminate AH In-reply-to: Your message of "Thu, 22 May 1997 11:27:27 EST." <9704228643.AA864325641@netx.nei.com> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 May 1997 20:07:39 +0300 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk > I second the motion to eliminate AH from IPSec. Given the evolution > of ESP, it has become redundant. > > The ESP document should define the > - SPI - Mandatory > - Sequence Number - Mandatory (I think?) > - Opaque Payload Data - Mandatory but dependent upon the transform. > - Authentication Data - Optional [...] Astute readers of this list will note that this is pretty much what swIPe did more than four years ago. Did we really need four years of bit-shuffling to come back to (almost) the same protocol? /ji From owner-ipsec Fri May 23 13:32:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26339 for ipsec-outgoing; Fri, 23 May 1997 13:31:56 -0400 (EDT) Hops: 0 Host: tis.com. Posted-Date: Fri, 23 May 1997 20:36:50 -0200 (GMT) Message-Id: <199705231738.UAA18740@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@tis.com Subject: Re: eliminate AH In-reply-to: Your message of "Fri, 23 May 1997 11:42:30 EDT." <97May23.113813edt.11650@janus.tor.securecomputing.com> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 May 1997 20:38:07 +0300 From: John Ioannidis Sender: owner-ipsec@ex.tis.com Precedence: bulk > If we had: > > - a STABLE standard > - running code > > I'm sure many of the other security people would adopt it. We have lots of running code. We had half a dozen interoperable implementations in Dallas. Never mind that we had to go change the transforms again (I know it's for a good reason, but that's besides the point). I think the main thing we lack is a set of documents saying *how* and *where* to use IPSEC, what it buys people, and why they shouldn't just roll their own. Also, building some interfacing mechanisms to the key/certificate management stuff mechanisms such as SSH have may further promote the cause of IPSEC until we have a working generic key management mechanism. /ji PS: Yes, I can hear the shouts now: "Why don't *you* do it, JI?" From owner-ipsec Fri May 23 15:03:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26834 for ipsec-outgoing; Fri, 23 May 1997 15:02:29 -0400 (EDT) Message-Id: <97May23.150439edt.11651@janus.tor.securecomputing.com> To: Daniel Harkins cc: "Waterhouse, Richard" , "'ipsec@tis.com'" Subject: ISAKMP stability (was Re: eliminate AH) References: <199705231616.JAA09729@dharkins-ss20> In-reply-to: dharkins's message of "Fri, 23 May 1997 12:16:56 -0400". <199705231616.JAA09729@dharkins-ss20> From: "C. Harald Koch" Date: Fri, 23 May 1997 15:08:55 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199705231616.JAA09729@dharkins-ss20>, Daniel Harkins writes: > > What makes it un-STABLE? >From the point of view of other working groups, which is what we're discussing: - It's a draft document, not an RFC, and not scheduled to be published. - there has been no WG last call. - It's 3 months old, but we're still discussing changes. Given how long we've been working on it, 3 months is no time at all. Draft 3 is from November 1995, after all. - almost every revision has had large changes; even 6 -> 7 changes a couple of on-the-wire packet formats. All of this is fine for the IPsec working group; just don't expect anyone else to pay much attention until we've at least gone through last call. -- Harald From owner-ipsec Fri May 23 15:34:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26943 for ipsec-outgoing; Fri, 23 May 1997 15:31:28 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 15:39:44 -0400 To: ipsec@tis.com From: Karen Seo (by way of Stephen Kent) Subject: IPSEC AH -- document Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-04.txt 23 May 1997 IP Authentication Header Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPng and IPsec Working Groups. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header 23 May, 1997 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................4 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................5 3. Authentication Header Processing..................................5 3.1 Authentication Header Location...............................5 3.2 Outbound Packet Processing...................................7 3.2.1 Security Association Lookup.............................7 3.2.2 Sequence Number Field...................................8 3.2.3 Integrity Check Value Calculation.......................8 3.2.3.1 Handling Mutable Fields............................8 3.2.3.1.1 ICV Computation for IPv4......................9 3.2.3.1.2 ICV Computation for IPv6......................9 3.2.3.2 Padding...........................................10 3.2.3.2.1 Authentication Data Padding..................10 3.2.3.2.2 Implicit Packet Padding......................10 3.2.3.3 Authentication Algorithms.........................10 3.2.4 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Reassembly.............................................11 3.3.2 Security Association Lookup............................11 3.3.3 Sequence Number Verification...........................12 3.3.4 Integrity Check Value Verification.....................13 4. Auditing.........................................................13 5. Conformance Requirements.........................................14 6. Security Considerations..........................................14 7. Differences from RFC 1826........................................14 Acknowledgements....................................................15 References..........................................................15 Disclaimer..........................................................16 Author Information..................................................16 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header 23 May, 1997 1. Introduction The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the transmitter. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides an optional confidentiality (encryption) service. [This text will be revised, if necessary, pending the outcome of the auth- only ESP debate.] The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see "Security Architecture for the Internet Protocol" [KA97a]. It is assumed that the reader is familiar with the terms and concepts described in the document "Security Architecture for the Internet Protocol" [KA97a]. In particular, the reader should be familiar with the definitions of security services offered by AH (and by ESP), the concept of Security Associations, the different key management options available for AH (and ESP), and the ways in which AH can be used in conjunction with ESP. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header 23 May, 1997 2. Authentication Header Format +---------------+---------------+---------------+---------------+ | Next Header(8)| Payload Len(8)| RESERVED (16) | +---------------+---------------+---------------+---------------+ | Security Parameters Index (32) | +---------------+---------------+---------------+---------------+ | Sequence Number Field (32) | +---------------+---------------+---------------+---------------+ | | + Authentication Data (variable number of 32-bit words) | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the ICV computation. 2.1 Next Header The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). 2.2 Payload Length This 8-bit field specifies the length of AH, in 32-bit words (4-byte units), minus "2," i.e., the fixed portion (as defined in the original AH spec) of AH is not counted. (Since the Sequence Number field always present, the fixed portion of AH is now three 32-bit words. However, the "minus 2" length adjustment has been retained for backwards compatibility.) A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "0" value for this field, as there would be no corresponding Authentication Data field. 2.3 Reserved This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.) Kent, Atkinson [Page 4] Internet Draft IP Authentication Header 23 May, 1997 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this datagram, relative to the destination IP address contained in the IP header with which this security header is associated, and relative to the security protocol employed. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see "Security Architecture for the Internet Protocol" [KA97a] for more details). (A zero value may be used for local debugging purposes, but no AH packets should be transmitted with a zero SPI value.) 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The sequence number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. This field is always present, even if the receiver does not elect to enable the anti-replay service for a specific SA, in order to ensure 8-byte alignment for the IPv6 environment, when the default integrity algorithms are employed. 2.6 Authentication Data This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.2.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. 3. Authentication Header Processing 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (Use of transport mode in "bump-in-the- stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, is not recommended as these Kent, Atkinson [Page 5] Internet Draft IP Authentication Header 23 May, 1997 implementations may receive outbound IP fragments from the attached host and thus be unable to process these packets according to this specification.) In this mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis. BEFORE APPLYING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------- authenticated ------->| except for mutable fields In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet. BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hxh,rtg,frag| dest | | dest | | | |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Kent, Atkinson [Page 6] Internet Draft IP Authentication Header 23 May, 1997 Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. ------------------------------------------------ IPv4 | new IP hdr* | | orig IP hdr* | | | |(any options)| AH | (any options) |TCP | Data | ------------------------------------------------ |<-- authenticated except for mutable fields ->| -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-------- authenticated except for mutable fields --------->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. 3.2 Outbound Packet Processing In transport mode, the transmitter inserts the AH header after the IP header and before an upper layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the document, "Security Architecture for the Internet Protocol". 3.2.1 Security Association Lookup AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the document, "Security Architecture for the Internet Protocol". Kent, Atkinson [Page 7] Internet Draft IP Authentication Header 23 May, 1997 3.2.2 Sequence Number Field The transmitter increments the sequence number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number Field. A transmitter MUST not send a packet on an SA if doing so would cause the sequence number to cycle. An attempt to transmit a packet that would result in sequence number overflow is an auditable event. 3.2.3 Integrity Check Value Calculation 3.2.3.1 Handling Mutable Fields The AH ICV is computed over IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA. The ICV also encompasses the upper level protocol data, which is assumed to be immutable in transit. If a field is modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field also is set to zero in preparation for this computation. (Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation.) DISCUSSION: For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed here and classified as either mutable or immutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The mutable IPv4 header fields also are enumerated below. The ICV calculation is restricted to the immutable options and specified (base) header fields. Kent, Atkinson [Page 8] Internet Draft IP Authentication Header 23 May, 1997 3.2.3.1.1 ICV Computation for IPv4 The following IPv4 base header fields are zeroed prior to the computation of the ICV: - Time to Live (TTL) - Header Checksum - Offset - Flags - Type of Service (TOS) TTL is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. The TOS field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field. Since AH is applied only to non-fragmented IP packets, this field must always be zero, and thus it is excluded (even though it is predictable). The Flags field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Finally, the Header Checksum will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. The following IPv4 options are mutable: record route, timestamp, loose source routing, and strict source routing. These options are treated as zero-filled for purposes of the ICV computation. The IP Security Options, BSO and ESO (RFC-1038, RFC-1108) and the CIPSO (option number 134) option are included in the ICV calculation and are not zeroed. 3.2.3.1.2 ICV Computation for IPv6 In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed prior to performing the ICV calculation. IPv6 options contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All other options are also included in the ICV calculation. See the IPv6 specification [DH95] for more information. Note, for example, that the IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as an immutable Kent, Atkinson [Page 9] Internet Draft IP Authentication Header 23 May, 1997 option. The transmitter must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. 3.2.3.2 Padding 3.2.3.2.1 Authentication Data Padding As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors: - the length of the ICV - the IP protocol context (v4 or v6) For example, if a default, 96-bit truncated HMAC algorithm is selected, no padding is required for either IPv4 nor IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required for the IPv6 environment. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation. 3.2.3.2.2 Implicit Packet Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. 3.2.3.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations usually preclude use of such algorithms. As of this writing, the mandatory-to-implement authentication algorithms are Kent, Atkinson [Page 10] Internet Draft IP Authentication Header 23 May, 1997 based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.3 Inbound Packet Processing 3.3.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment,, e.g., the OFFSET field is non-zero, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.3.2 Security Association Lookup Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address and the SPI. (This process is described in more detail in the document, "Security Architecture for the Internet Protocol".) The SA dictates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates the key(s) required to validate the ICV. If no valid Security Association exists for this session (e.g., the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. Kent, Atkinson [Page 11] Internet Draft IP Authentication Header 23 May, 1997 3.3.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled on a per-SA basis. (Note that there are no provisions for managing transmitted sequence counter values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) If an SA establishment protocol such as Oakley/ISAKMP is employed, then the receiver SHOULD notify the transmitter, during SA establishment, if the receiver will provide anti-replay protection and SHOULD inform the transmitter of the window size. If the receiver has elected to enable the anti-replay service for this SA, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all AH implementations MUST support this window size. A larger window size MAY be employed by the receiver. If a larger window size is employed it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Number values lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in [KA97a]. If the received packet falls within the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the sequence number field, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. Kent, Atkinson [Page 12] Internet Draft IP Authentication Header 23 May, 1997 DISCUSSION: Note that if the packet is either inside the window and new, or outside the window on the "right" side, the receiver MUST authenticate the Sequence Number field before updating the bit mask (either turning on a bit or updating the "right" side of the window). 3.3.4 Integrity Check Value Verification The receiver computes the ICV over the appropriate fields of the packet, using the specified authentication algorithm, and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.2.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Now perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY Kent, Atkinson [Page 13] Internet Draft IP Authentication Header 23 May, 1997 result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the "Security Architecture for the Internet Protocol." If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the transmitter, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97]): - HMAC with MD5 - HMAC with SHA-1 6. Security Considerations Security is central to the design of this protocol, and this security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the document, "Security Architecture for the Internet Protocol". 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times, to meet IPv6 alignment requirements (even when anti-replay is not enabled for an SA). The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides Kent, Atkinson [Page 14] Internet Draft IP Authentication Header 23 May, 1997 rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. Acknowledgements For over 2 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, 9 June 1994, pp. 21-34. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, April 1993. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, Kent, Atkinson [Page 15] Internet Draft IP Authentication Header 23 May, 1997 February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, November 1991. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, May 1997. [KA97c] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, May 1997. [Riv92] Ronald Rivest, "The MD5 Digest Algorithm," RFC-1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, March 1996. [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20 October 1994. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent Randall Atkinson BBN Corporation @Home Network 70 Fawcett Street 385 Ravendale Drive Cambridge, MA 02140 Mountain View, CA 94043 USA USA skent@bbn.com rja@inet.org Telephone: +1 (617) 873-3988 Kent, Atkinson [Page 16] From owner-ipsec Fri May 23 17:21:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27556 for ipsec-outgoing; Fri, 23 May 1997 17:18:31 -0400 (EDT) Date: Fri, 23 May 97 20:53:57 GMT From: "William Allen Simpson" Message-ID: <5941.wsimpson@greendragon.com> To: ipsec@tis.com Subject: draft-simpson-esp-des1-v2-00.txt to Draft Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk This is an update of RFC-1829 to comport with the recent format decisions of the group. Although this is a subset of the previous bits-on-the-wire, this subset was required to be supported (32 bit field following the SPI), so there should not be any change in interoperability. This document covers only the following: Individual Transform documents would provide definitions for how the Opaque Payload Data is defined and would cover any needed fields including: - Initialization Vector - Payload Data - Padding - Payload Type There is a complete list of changes in the document, mostly editorial. In response to JI's recent note: yes, we have returned to swIPe after a 4 year diversion, and I added the acknowledgement and references. Jeff Schiller (the Security Area Director) has indicated that: RFC-1829 is the product of the IPSEC working group. It is for the working group to decide whether or not to advance it. I will happily act upon a recommendation of the working group as communicated to me by the chair. As interoperability has been demonstrated between 2 or more implementations, I ask that this document be immediately forwarded (within a few days) to the Area Director for advancement to Draft Standard. Then, the IESG will issue the 2 week IETF Last Call. By that time, we should have no problem compiling a more comprehensive list of interoperable implementations. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Fri May 23 19:09:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28003 for ipsec-outgoing; Fri, 23 May 1997 19:07:00 -0400 (EDT) Message-Id: <199705232309.TAA20267@raptor.research.att.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard Date: Fri, 23 May 1997 19:09:33 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Jeff Schiller (the Security Area Director) has indicated that: RFC-1829 is the product of the IPSEC working group. It is for the working group to decide whether or not to advance it. I will happi ly act upon a recommendation of the working group as communicated to me by the chair. As interoperability has been demonstrated between 2 or more implementations, I ask that this document be immediately forwarded (within a few days) to the Area Director for advancement to Draft Standard. I'm afraid I disagree; this document is not ready for advancement. First, it's the wrong document. Given the new structure (i.e., as described in draft-ietf-ipsec-new-esp-00.txt), there's far too much in your draft. The CAST-128 draft (draft-ietf-ipsec-esp-cast-128-cbc-00.txt) or RC5-CBC draft (draft-ietf-ipsec-esp-rc5-cbc-00.txt) are much better models for what's needed. (Bill, I realize you feel differently. I don't like documents that overspecify stuff -- changes to the base document's headers would require changes to your document as well, quite unnecessarily.) Second, given the new structure -- with authentication folded in with ESP -- I don't know of any implementations. I suppose one could say that the DES-CBC part is ready, but it's a bit hard to assess without the framework. From owner-ipsec Sat May 24 00:03:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA29205 for ipsec-outgoing; Sat, 24 May 1997 00:01:36 -0400 (EDT) Date: Sat, 24 May 97 03:27:18 GMT From: "William Allen Simpson" Message-ID: <5944.wsimpson@greendragon.com> To: Steven Bellovin cc: ipsec@tis.com Subject: Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Steven Bellovin > I'm afraid I disagree; this document is not ready for advancement. > First, it's the wrong document. Given the new structure (i.e., as > described in draft-ietf-ipsec-new-esp-00.txt), there's far too much > in your draft. The CAST-128 draft (draft-ietf-ipsec-esp-cast-128-cbc-00.txt) > or RC5-CBC draft (draft-ietf-ipsec-esp-rc5-cbc-00.txt) are much better > models for what's needed. Thanks for reading the document. Funny, Steve Kent sent a private message saying almost the same thing. I looked at those (CAST & RC5), and found them remarkably uninformative. I cannot imagine a "protocol" description without packet formats. They should put some packet formats in! I did move the weak key text from the security considerations up to the key sub-section to match them, though. Keeping related stuff like that together was a good idea. > (Bill, I realize you feel differently. I > don't like documents that overspecify stuff -- changes to the base > document's headers would require changes to your document as well, > quite unnecessarily.) > Changes to the base document headers would be a new protocol, and require a new IP Protocol number! Even "new" ESP is still just an SPI (the same as "old" ESP), with a 32-bit Sequence Number (which was one of the options in RFC-1829 and long described in swIPe). The only true change in "new" ESP is the requirement of the sequence field in all transforms, and adding an optional trailing Authenticator. That's all I've done here, update to match the "new" ESP environment. Can anyone imagine ICMP documents with the packet formats only starting after the Checksum field? Nope. The IETF tradition is to copy those definitions for context. True, it is boilerplate, but it certainly aids the implementor by providing context. Besides, the IV is calculated based on the SPI+Sequence fields. Showing them is pretty helpful to implementors. As an aside, I once tried putting the Photuris Cookies in only a single place, early in the _same_ document. After all, they are just the same boilerplate repeated over and over. Suddenly, the most frequently asked question was "where are the Cookies"? So, I still have that section describing the Cookies, but I also faithfully copy them into each packet format. It was only a little extra work, but it saved a lot of explanation in the long run.... I don't like _under_ specifying stuff. Each transform should stand on its own! > Second, given the new structure -- with authentication folded in with > ESP -- I don't know of any implementations. I suppose one could say > that the DES-CBC part is ready, but it's a bit hard to assess without > the framework. > The Authenticator is an optional field. Its specification and testing are outside the scope of DES-CBC. We don't test frameworks, we test protocols. Again, each transform should stand on its own! Besides, there are plenty of folks who have tested AH+ESP. Seems to work pretty well.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 03:41:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA00061 for ipsec-outgoing; Sat, 24 May 1997 03:39:38 -0400 (EDT) Message-Id: <3.0.32.19970524004450.00b0d490@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 24 May 1997 00:44:54 -0700 To: "William Allen Simpson" From: Bob Monsour Subject: Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard Cc: Steven Bellovin , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, While the wg and doc editors have been struggling to get the document structure "cleaned up", I respectfully submit that the two drafts you recently submitted appear to subvert that effort. In what is being refered to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd paragraph of section 3.2.3.2, Encryption Algorithms, states: At the time of writing, one mandatory-to-implement encryption algorithm and mode has been defined for ESP. It is based on the Data Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details of use of this mode are contained in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. The operative phrase is "but no overlap with this document". While I understand that you believe that it's important for the algorithm/transform documents to repeat certain field definitions from the base ESP document, in this case I find it couter-productive and prone to inducing errors. Let's take an example from from your DES draft (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft and RFC1829. It states: Padding zero or more octets. Prior to encryption, this field is filled with a series of integer values (beginning with zero), to align the Pad Length and Payload Type fields at the end of an eight octet boundary (counted from the beginning of the Payload Data). After decryption, it is examined for a valid series of integer values. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. In the "new" ESP draft (section 2.5) padding is defined as follows: The Padding bytes SHOULD be initialized with random data and they are transmitted. The transmitter can add 0-255 bytes of padding. Padding beyond that required for encryption algorithm blocksize alignment may be used to conceal the actual length of the payload, in support of traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations MUST support generation and consumption of padding. Lastly, RFC1829 states: Padding The size of this field is variable. Prior to encryption, it is filled with unspecified implementation dependent (preferably random) values, to align the Pad Length and Payload Type fields at an eight octet boundary. After decryption, it MUST be ignored. I don't understand how someone can write code to support the padding requirements that conform to RFC1829 or the "new" ESP and find that it will interoperate with code that is written to follow your new draft. An RFC1829 programmer will send the "preferably random" values in for padding and the implementor of your new draft will reject the incoming packet for lack of a "valid series of integer values". While you don't say exactly what to do in this case, it certainly leaves room for various interpretations (read that as potential interoperability problems). Would it not have been simple to create a draft that really matched the goal of matching the intentions of the "new" ESP draft and the wg? That would have been a great service to the wg. At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote: >I looked at those (CAST & RC5), and found them remarkably uninformative. >I cannot imagine a "protocol" description without packet formats. They >should put some packet formats in! I see these as algorithm/transform definitions, not protocols. They define how to take a set of data and transform it into another set of data. The context is, as stated simply and elegantly in the abstracts of the RC5 and CAST drafts (and these are the only words in the abstracts): This draft describes the CAST-128 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). This draft describes the RC5 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). (OK, so they share an author) >The only true change in "new" ESP is the >requirement of the sequence field in all transforms, and adding an >optional trailing Authenticator. That's all I've done here, update to >match the "new" ESP environment. Not so. The move to the "new" ESP environment involved a conscious document structure change, not just the protocol changes you mentioned. That structure change is intended to simplify the specifications by eliminating reduntant and potentially conflicting requirements (i.e., factoring out the common elements of the packet formats and leaving the transform docs to specify algorithmic details). >I don't like _under_ specifying stuff. Each transform should stand on >its own! B relating the transform drafts back to the base ESP draft (as you do and the RC5/CAST drafts do), then they DO stand on their own as separable transforms that support the packet formats as defined in ESP. They MUST be read AND used in conjunction with ESP and ONLY in conjunction with ESP. If you REALLY want them to stand on their own in the context of all the working groups, then I would go further to say that they should just describe the algorithms and not refer to any base packet formats. In that way they could be referenced by any base protocol spec such as TLS or ECP by way of IANA numbers. But in my relatively short IETF life, I wouldn't expect to see that happen at this stage and would be grateful to fulfill the intentions of the wg and the ESP draft (and for this purpose, we have the IPSec DOI). [To the doc editors and co-chairs, if no one is preparing drafts of DES and 3DES for use with the "new" ESP (similar in construct to the RC5 and CAST drafts), I volunteer to take on the task as long as I get some volunteers to review them prior to posting to double-check them.] Regards, Bob Monsour rmonsour@hifn.com From owner-ipsec Sat May 24 11:44:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02007 for ipsec-outgoing; Sat, 24 May 1997 11:39:12 -0400 (EDT) Date: Sat, 24 May 97 15:02:46 GMT From: "William Allen Simpson" Message-ID: <5952.wsimpson@greendragon.com> To: Bob Monsour Cc: ipsec@tis.com Subject: definitions versus protocols Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for the comments, especially from an implementor; but as a long-time participant, I cannot agree that this was the intent of most of the folks _I_ was talking to.... (a small group of folks reviewed the documents before I sent them off to the drafts repository). So, it looks like we really need a "straw poll" as to whether these should be merely "shims" or true protocols. Let's debate that in this thread for a week (ending May 30th), and see if there's a broader consensus one way or the other. As I mentioned, the CAST and RC5 (sharing an author) don't provide enough information to write any code. They just shim between real documents. That's my objection. I have a strong prejudice for working on code, and therefore have principly limited my efforts to code-generating documents. If these are "algorithm/transform definitions, not protocols", then they would not be able to be on the Standards Track. The IETF standardizes protocols, upon demonstrated interoperability. A shim would be easier to produce, but would only be an Informational RFC. > From: Bob Monsour > In what is being refered > to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd > paragraph of section 3.2.3.2, Encryption Algorithms, states: > > At the time of writing, one mandatory-to-implement encryption > algorithm and mode has been defined for ESP. It is based on the Data > Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode > [NIST80]. Details of use of this mode are contained in [need a new > I-D with DES-CBC and implicit IV generation, but no overlap with this > document]. > > The operative phrase is "but no overlap with this document". ... I do not treat the old "new" ESP draft as gospel. We've already agreed that it oversteps its bounds, and have more clearly defined its scope. My draft is based on the Memphis meeting. We await the "new" "new" ESP. > Would it not have been simple to create a draft that really matched the > goal of matching the intentions of the "new" ESP draft and the wg? That > would have been a great service to the wg. > I did my best, within the limitation of my understanding of what was desired by the broad group of implementors. > At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote: > >I looked at those (CAST & RC5), and found them remarkably uninformative. > >I cannot imagine a "protocol" description without packet formats. They > >should put some packet formats in! > > I see these as algorithm/transform definitions, not protocols. They define > how to take a set of data and transform it into another set of data. The > context is, as stated simply and elegantly in the abstracts of the RC5 and > CAST drafts (and these are the only words in the abstracts): > > This draft describes the CAST-128 block cipher algorithm as to be > used with the IPSec Encapsulating Security Payload (ESP). > > This draft describes the RC5 block cipher algorithm as to be used > with the IPSec Encapsulating Security Payload (ESP). > > (OK, so they share an author) > > >The only true change in "new" ESP is the > >requirement of the sequence field in all transforms, and adding an > >optional trailing Authenticator. That's all I've done here, update to > >match the "new" ESP environment. > > Not so. The move to the "new" ESP environment involved a conscious document > structure change, not just the protocol changes you mentioned. That > structure change is intended to simplify the specifications by eliminating > reduntant and potentially conflicting requirements (i.e., factoring out the > common elements of the packet formats and leaving the transform docs to > specify algorithmic details). > The decision by _Steve_ to do this was debated on the list, and I saw dissent. We need a nice general ESP document, but I have always seen the ESP document as the template and "applicability statement", and the transform documents as the protocols. Clearly, you and I have a difference of vision. > >I don't like _under_ specifying stuff. Each transform should stand on > >its own! > > B relating the transform drafts back to the base ESP draft (as you do and > the RC5/CAST drafts do), then they DO stand on their own as separable > transforms that support the packet formats as defined in ESP. They MUST be > read AND used in conjunction with ESP and ONLY in conjunction with ESP. If > you REALLY want them to stand on their own in the context of all the > working groups, then I would go further to say that they should just > describe the algorithms and not refer to any base packet formats. In that > way they could be referenced by any base protocol spec such as TLS or ECP > by way of IANA numbers. But in my relatively short IETF life, I wouldn't > expect to see that happen at this stage and would be grateful to fulfill > the intentions of the wg and the ESP draft (and for this purpose, we have > the IPSec DOI). > A very different vision. I am not in favor of transforms so general that they could be used without packet formats. That's what the algorithm documents (like CAST just published as an RFC) should do. The transforms are specific applications of the generic algorithms in concrete form. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 12:22:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02253 for ipsec-outgoing; Sat, 24 May 1997 12:20:45 -0400 (EDT) Date: Sat, 24 May 97 16:04:37 GMT From: "William Allen Simpson" Message-ID: <5955.wsimpson@greendragon.com> To: Bob Monsour Cc: ipsec@tis.com Subject: padding values Sender: owner-ipsec@ex.tis.com Precedence: bulk On the differences in text on padding values: > From: Bob Monsour > While I understand that you believe that it's important for the > algorithm/transform documents to repeat certain field definitions from the > base ESP document, in this case I find it couter-productive and prone to > inducing errors. Let's take an example from from your DES draft > (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft > and RFC1829. It states: > > Padding zero or more octets. > > Prior to encryption, this field is filled with a > series of integer values (beginning with zero), to > align the Pad Length and Payload Type fields at the > end of an eight octet boundary (counted from the > beginning of the Payload Data). > > After decryption, it is examined for a valid series > of integer values. > > This field is opaque. That is, the value is set > prior to encryption, and is examined only after > decryption. > Please read this in the context of the whole paper. See also: 2.2. Decryption ... The Pad Length is removed and examined. If pad checking is config- ured, and the padding octets are not the correct values for the Pad Length, then the payload is discarded, and the "Decryption Failed" error is indicated [RFC-xxxx]. ... Operational Considerations ... Pad Check Some earlier implementations used random pad values. Default: Off. ... The default is off because of interoperability concerns. > In the "new" ESP draft (section 2.5) padding is defined as follows: > > The Padding bytes SHOULD be initialized with random data and they are > transmitted. The transmitter can add 0-255 bytes of padding. Padding > beyond that required for encryption algorithm blocksize alignment may > be used to conceal the actual length of the payload, in support of > traffic flow confidentiality. However, inclusion of such additional > padding has adverse bandwidth implications and thus its use should be > undertaken with care. The Padding field is optional, but all > implementations MUST support generation and consumption of padding. > The ESP draft is wrong. It has a scoping error. The description of padding is to be left to the individual transforms. See the previous notes to this list on the implementors' agreement. If this is not fixed in the next draft of ESP, I'm sure someone will suggest a more specific change in wording. > Lastly, RFC1829 states: > > Padding > > The size of this field is variable. > > Prior to encryption, it is filled with unspecified implementation > dependent (preferably random) values, to align the Pad Length and > Payload Type fields at an eight octet boundary. > > After decryption, it MUST be ignored. > > I don't understand how someone can write code to support the padding > requirements that conform to RFC1829 or the "new" ESP and find that it will > interoperate with code that is written to follow your new draft. An RFC1829 > programmer will send the "preferably random" values in for padding and the > implementor of your new draft will reject the incoming packet for lack of a > "valid series of integer values". While you don't say exactly what to do in > this case, it certainly leaves room for various interpretations (read that > as potential interoperability problems). > Hopefully, not everyone will read only the first part of a draft, and will actually follow and implement the draft in its entirety. The values were previously "implementation dependent", which was open to various interpretations. The "preferably random" values turned out to be cryptographically wrong. At the request of the persons explicitly named in the Acknowledgements, the "implementation dependent" values were changed to specified values. This is not open to various interpretations. I realize that you are new to the list, and may have missed the earlier debates. Remembering that you like to use the same technique in multiple venues, I'll point out that these values are used in PPP DES encryption. And that non-random values are also specified in RSA's PKCS. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 13:13:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02489 for ipsec-outgoing; Sat, 24 May 1997 13:11:43 -0400 (EDT) Date: Sat, 24 May 97 17:04:04 GMT From: "William Allen Simpson" Message-ID: <5956.wsimpson@greendragon.com> To: ipsec@tis.com Subject: CAST & RC5 Abstract correction Sender: owner-ipsec@ex.tis.com Precedence: bulk There are some substantive errors in language in both the CAST and RC5 drafts. In the Abstracts: > This draft describes the CAST-128 block cipher algorithm as to be > used with the IPSec Encapsulating Security Payload (ESP). > > This draft describes the RC5 block cipher algorithm as to be used > with the IPSec Encapsulating Security Payload (ESP). > This will not always be a draft. "as to be used" is problematic phrasing. There is no IPSec protocol. ESP is called an IP protocol (IPv4) or IP payload (IPv6). I suggest: This document describes the block cipher interface elements used with the IP Encapsulating Security Payload (ESP). WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Sat May 24 14:01:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02700 for ipsec-outgoing; Sat, 24 May 1997 14:01:12 -0400 (EDT) Date: Sat, 24 May 97 17:56:26 GMT From: "William Allen Simpson" Message-ID: <5957.wsimpson@greendragon.com> To: ipsec@tis.com Subject: DES-CBC "interface" shim Sender: owner-ipsec@ex.tis.com Precedence: bulk Since Bellovin, Kent and Monsour have all requested a revision, for comparison purposes I have generated a shorter version without the protocol and implementation information. I ask other folks to please indicate your preferences. Network Working Group P Metzger Internet Draft [Piermont] W A Simpson [DayDreamer] expires in six months May 1997 The ESP DES-CBC Transform Interface draft-simpson-esp-des1-shim-00.txt (C) Status of this Memo This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Distribution of this memo is unlimited. Abstract This document describes the DES-CBC block cipher interface elements used with the IP Encapsulating Security Payload (ESP). Metzger & Simpson expires in six months [Page i] DRAFT ESP DES-CBC May 1997 1. Introduction The Encapsulating Security Payload (ESP) [RFC-1827] provides confi- dentiality for IP datagrams by encrypting the payload data to be pro- tected. This specification describes the ESP use of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algo- rithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. All implementations that claim conformance or compliance with the Encapsulating Security Payload specification MUST implement this DES- CBC transform. This document assumes that the reader is familiar with the related document "Security Architecture for the Internet Protocol" [RFC-1825], that defines the overall security plan for IP, and pro- vides important background for this specification. In this document, the key words "MUST", "optional", "recommended", "required", and "SHOULD", are to be interpreted as described in [RFC-2119]. 2. Algorithm and Mode P1 P2 Pi | | | IV->->(X) +>->->->(X) +>->->->(X) v ^ v ^ v +-----+ | +-----+ | +-----+ k->| Ek | ^ k->| Ek | ^ k->| Ek | +-----+ | +-----+ | +-----+ | ^ | ^ | +>->->+ +>->->+ +>->-> | | | C1 C2 Ci In DES-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 octet) plaintext block (P1). The keyed DES encryption function (Ek) generates the ciphertext (C1) for the block. For successive blocks, the previous ciphertext block is XOR'd with the current plaintext (Pi). The keyed DES encryption function (Ek) generates the ciphertext (Ci) for that block. The Cipher Block Chaining (CBC) method provides for re- synchronization when datagrams are lost. For more explanation and implementation information for DES, see [Schneier95]. Metzger & Simpson expires in six months [Page 1] DRAFT ESP DES-CBC May 1997 3. Keys The secret DES key shared between the communicating parties is 56-bits in length. The 56-bit key is stored as a 64-bit (8 octet) quantity, with the least significant bit of each octet used as a par- ity bit. 3.1. Weak Keys DES has 64 known weak keys, including so-called semi-weak keys and possibly weak keys [Schneier95, pp 280-282]. Implementations SHOULD take care not to select weak keys [CN94], although the odds of pick- ing one at random are low. When manually configured, these 64 keys SHOULD be be rejected. When dynamically configured via a key management protocol, any of these 64 keys MUST be rejected, and a replacement key requested. 3.2. Key Management When manually configured, 64-bits (8 octets) are configured. Keys with incorrect parity SHOULD be be rejected. When dynamically configured via a key management protocol, 64-bits (8 octets) are returned for each key. The least significant bit of each key octet is ignored (or set to parity when the implementation requires). 4. Initialization Vector This mode of DES requires an Initialization Vector (IV) that is 64-bits (8 octets) in length. Each datagram contains its own IV. This IV is intended to be unique for the lifetime of the secret DES session-key. When manually configured, the 64-bit IV is generated from the 32-bit Sequence Number field followed by (concatenated with) the bit-wise complement of the same 32-bit value. When dynamically configured via a key management protocol, the 64-bit IV is generated from the 32-bit SPI field followed by (concatenated with) the 32-bit Sequence Number field. The bit-wise complement of the 32-bit Sequence Number value is XOR'd with the first 32-bits Metzger & Simpson expires in six months [Page 2] DRAFT ESP DES-CBC May 1997 (SPI). Security Notes: Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit. The manually configured variant is required for backward compati- bility. It is appropriate when the associated SPI is unchanging. However, in a dynamic environment, the same data stream might be sent with more than one SPI. Including the changed SPI in the IV generation prevents analysis based on common leading blocks. Using the Sequence Number provides an easy method for preventing IV repetition, and is sufficiently robust for practical use with the DES algorithm. But, when used alone, cryptanalysis might be aided by the rare serendipitous occurrence where a corresponding bit position in the first DES block increments in exactly the same fashion as the Sequence Number. No commonly used IP Protocol/Payloads exhibit this property. Never-the-less, inclusion of the bit-wise complement ensures that Sequence Number bit changes are reflected twice in the IV. 5. Block Size The DES algorithm operates on blocks of 64-bits (8 octets). This often requires padding after the end of the unencrypted Payload Data. Both input and output result in the same number of octets. This facilitates in-place encryption and decryption. 6. ESP Padding The Padding field may be zero or more octets in length. Prior to encryption, this field is filled with a series of integer values (beginning with zero), to align the Pad Length and Payload Type fields at the end of an eight octet boundary (counted from the beginning of the Payload Data). After decryption, it may be examined for a valid series of integer values. Metzger & Simpson expires in six months [Page 3] DRAFT ESP DES-CBC May 1997 7. ESP Authenticator This optional variable-length field contains an Integrity Check Value (ICV) computed over the ESP data after encryption, beginning with the SPI and ending with the Payload Type. The length of the field depends upon the authentication function selected. DES-CBC does not provide integrity. When the ESP data is not other- wise verified (externally using AH or internally by the payload itself), it is recommended (but not required) that an ICV be provided here. The details of such functions are outside the scope of this document. 8. Performance Phil Karn has tuned DES software to achieve 10.45 Mbps with a 90 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other DES speed estimates may be found at [Schneier95, page 279]. Operational Considerations When used with manual keying, the specification provides only a few configurable parameters. SPI Configured SPIs are in the range 1 to 255. SPI LifeTime (SPILT) Manually configured LifeTimes are generally measured in days, while dynamic LifeTimes are specified in seconds. Default: 2,764,800 seconds (32 days). Maximum: implementation dependent. Pad Check Some earlier implementations used random pad values. Default: Off. Key The 56-bit key is configured as a 64-bit quantity, with appropri- ate parity included. Metzger & Simpson expires in six months [Page 4] DRAFT ESP DES-CBC May 1997 Each party configures a list of known SPIs and symmetric secret-keys. In addition, each party configures local policy that determines what access (if any) is granted to the holder of a particular SPI. For example, a party might allow FTP, but prohibit Telnet. Such consid- erations are outside the scope of this document. Security Considerations Users need to understand that the quality of the security provided by this specification depends completely on the strength of the DES algorithm, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the implemen- tations in all of the participating nodes. The cut and paste splicing attack described by [Bell95, Bell96] exploits the nature of all Cipher Block Chaining algorithms. When a block is damaged in transmission, on decryption both it and the fol- lowing block will be garbled by the decryption process, but all sub- sequent blocks will be decrypted correctly. If an attacker has legitimate access to the same key, this feature can be used to insert or replay previously encrypted data of other users of the same engine, revealing the plaintext. The usual (ICMP, TCP, UDP) trans- port checksum can detect this attack, but on its own is not consid- ered cryptographically strong. In this situation, user or connection oriented integrity checking is needed [RFC-1826]. The padding bytes have a predictable value. They provide a small measure of tamper detection on their own block and the previous block in CBC mode. This makes it somewhat harder to perform splicing attacks, and avoids a possible covert channel. This small amount of known plaintext does not create any problems for modern ciphers. At the time of writing of this document, [BS93] demonstrated a dif- ferential cryptanalysis based chosen-plaintext attack requiring 2^47 plaintext-ciphertext pairs, and [Matsui94] demonstrated a linear cryptanalysis based known-plaintext attack requiring only 2^43 plain- text-ciphertext pairs. Although these attacks are not considered practical, they must be taken into account. More disturbingly, [Weiner94] has shown the design of a DES cracking machine costing $1 Million that can crack one key every 3.5 hours. This is an extremely practical attack. One or two blocks of known plaintext suffice to recover a DES key. Because IP datagrams typically begin with a block of known and/or Metzger & Simpson expires in six months [Page 5] DRAFT ESP DES-CBC May 1997 guessable header text, frequent key changes will not protect against this attack. It is suggested that DES is not a good encryption algorithm for the protection of even moderate value information in the face of such equipment. Triple DES is probably a better choice for such purposes. However, despite these potential risks, the level of privacy provided by use of ESP DES-CBC in the Internet environment is far greater than sending the datagram as cleartext. Change History Changes from RFC-1829: Additional explanation of IV calculation. Inclusion of SPI in IV calculation improves IV uniqueness over multiple sessions. Updated performance estimates. IV field renamed to Sequence. Only one size is supported. Padding is a known series of integers, and is checked upon receipt. Added authentication section. Removed protocol implementation specification. Added operational parameters section. Updated references. Updated contacts. Minor editorial changes. Metzger & Simpson expires in six months [Page 6] DRAFT ESP DES-CBC May 1997 Acknowledgements The basic field naming and layout is based on "swIPe" [IBK93, IB93]. Participants in the IP Security Working Group modified this to a variable number of variable length fields. After a digression span- ning 4 years, actual implementors mandated a return to these fewer well-known fields. Some of the text of this specification was derived from work by Ran- dall Atkinson for the SIP, SIPP, and IPv6 Working Groups. Phil Karn provided the original Encryption and Decryption text, and was the motivator and founding member of the IP Security Working Group. Perry Metzger provided the original Security Considerations text, some of which is distributed throughout the document. William Allen Simpson was responsible for the name and semantics of the SPI, the IV calculation technique(s), editing and formatting. The use of known padding values was suggested in various forms by Robert Baldwin, Phil Karn, and David Wagner. This specification uses Self-Describing-Padding [RFC-1570]. Steve Bellovin, Steve Deering, Karl Fox, Charles Lynn, Craig Metz, Dave Mihelcic and Jeffrey Schiller provided useful critiques of ear- lier versions of this draft. References [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Presentation at the 32nd Internet Engi- neering Task Force, Danvers Massachusetts, April 1995. [Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Security Symposium, July 1996. [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993. [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994. Metzger & Simpson expires in six months [Page 7] DRAFT ESP DES-CBC May 1997 [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [FIPS-46-1] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [FIPS-74] US National Bureau of Standards, "Guidelines for Implement- ing and Using the Data Encryption Standard", Federal Infor- mation Processing Standard (FIPS) Publication 74, April 1981. [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [IB93] Ioannidis, J., and Blaze, M., "The Architecture and Imple- mentation of Network-Layer Security Under Unix", Proceedings of the Fourth Usenix Security Symposium, Santa Clara Cali- fornia, October 1993. [IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network- Layer Security for IP", Presentation at the 26th Internet Engineering Task Force, Columbus Ohio, March 1993. [Matsui94] Matsui, M., "Linear Cryptanalysis method dor DES Cipher," Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994. [RFC-1570] Simpson, W., "PPP LCP Extensions", DayDreamer, January 1994. [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC-1825] Atkinson, R., "Security Architecture for the Internet Proto- col", RFC-1825, Naval Research Laboratory, July 1995. [RFC-1826] Atkinson, R., "IP Authentication Header", RFC-1826, Naval Metzger & Simpson expires in six months [Page 8] DRAFT ESP DES-CBC May 1997 Research Laboratory, July 1995. [RFC-1827] Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC-1827, Naval Research Laboratory, July 1995. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Require- ment Levels", BCP 14, Harvard University, March 1997. [RFC-xxxx] Karn, P., and Simpson, W., "ICMP Security Failures Mes- sages", draft-simpson-icmp-ipsec-fail-02.txt, work in progress. [RFC-yyyy] Simpson, W., and Wagner, D., "Internet Security Transform Enhancements", draft-simpson-ipsec-enhancement-01.txt, work in progress. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. [Weiner94] Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93. Metzger & Simpson expires in six months [Page 9] DRAFT ESP DES-CBC May 1997 Contacts Comments about this document should be discussed on the ipsec@tis.com mailing list. Questions about this document can also be directed to: Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) bsimpson@MorningStar.com Metzger & Simpson expires in six months [Page 10] From owner-ipsec Mon May 26 11:38:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13525 for ipsec-outgoing; Mon, 26 May 1997 11:33:14 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Bob Monsour'" , "'William Allen Simpson'" Cc: "'ipsec@tis.com'" Subject: RE: definitions versus protocols Date: Mon, 26 May 1997 10:27:54 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I guess I should reply to this since I am that un-named shared author of both the RC5 and CAST128 ESP drafts. Bill, the layout and wording of the new style ESP algorithm documents came about from many months of discussions. As you know we have been moving towards Steve Kent's new template oriented ESP and moving away from 'transforms'. One of the major issues that I (and other people) wanted resolved was to not have any overlapping between the main ESP document and all other algorithm documents. After discussions in Memphis and several ANX bake-offs, I believed that we had enough information to produce a half-decent first draft of what an ESP algorithm document was suppose to look like. The result was the RC5 and CAST128 drafts. These two documents were co-written with their appropriate representatives (Baldwin and Carter) and were sent out to various implementers before officially submitting them to the IETF. Steve Kent also had some very good input to these documents. As one of the IPSec implementers, and as having written all of the code from scratch (i.e.. RFCs), I wanted to write a direct and to-the-point draft that a developer would be able to quickly retrieve the desired information and implement that cipher algorithm. Everything that isn't in these documents was already in the ESP draft. I think this line from the my drafts says it all; "Furthermore, this document is a companion to [Kent97] and MUST be read in its context." That being said, these two documents are first drafts and should be updated and are not "ready for prime time". Thus any constructive criticism and comments are appreciated. Roy Pereira TimeStep Corporation >---------- >From: William Allen Simpson[SMTP:wsimpson@greendragon.com] >Sent: Saturday, May 24, 1997 11:02 AM >To: Bob Monsour >Cc: ipsec@tis.com >Subject: definitions versus protocols > >Thanks for the comments, especially from an implementor; but as a >long-time participant, I cannot agree that this was the intent of most of >the folks _I_ was talking to.... (a small group of folks reviewed the >documents before I sent them off to the drafts repository). > >So, it looks like we really need a "straw poll" as to whether these >should be merely "shims" or true protocols. Let's debate that in this >thread for a week (ending May 30th), and see if there's a broader >consensus one way or the other. > >As I mentioned, the CAST and RC5 (sharing an author) don't provide >enough information to write any code. They just shim between real >documents. That's my objection. > >I have a strong prejudice for working on code, and therefore have >principly limited my efforts to code-generating documents. > >If these are "algorithm/transform definitions, not protocols", then they >would not be able to be on the Standards Track. The IETF standardizes >protocols, upon demonstrated interoperability. > >A shim would be easier to produce, but would only be an Informational RFC. > > >> From: Bob Monsour >> In what is being refered >> to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd >> paragraph of section 3.2.3.2, Encryption Algorithms, states: >> >> At the time of writing, one mandatory-to-implement encryption >> algorithm and mode has been defined for ESP. It is based on the Data >> Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode >> [NIST80]. Details of use of this mode are contained in [need a new >> I-D with DES-CBC and implicit IV generation, but no overlap with this >> document]. >> >> The operative phrase is "but no overlap with this document". >... > >I do not treat the old "new" ESP draft as gospel. We've already agreed >that it oversteps its bounds, and have more clearly defined its scope. >My draft is based on the Memphis meeting. We await the "new" "new" ESP. > > >> Would it not have been simple to create a draft that really matched the >> goal of matching the intentions of the "new" ESP draft and the wg? That >> would have been a great service to the wg. >> >I did my best, within the limitation of my understanding of what was >desired by the broad group of implementors. > > >> At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote: >> >I looked at those (CAST & RC5), and found them remarkably uninformative. >> >I cannot imagine a "protocol" description without packet formats. They >> >should put some packet formats in! >> >> I see these as algorithm/transform definitions, not protocols. They define >> how to take a set of data and transform it into another set of data. The >> context is, as stated simply and elegantly in the abstracts of the RC5 and >> CAST drafts (and these are the only words in the abstracts): >> >> This draft describes the CAST-128 block cipher algorithm as to be >> used with the IPSec Encapsulating Security Payload (ESP). >> >> This draft describes the RC5 block cipher algorithm as to be used >> with the IPSec Encapsulating Security Payload (ESP). >> >> (OK, so they share an author) >> >> >The only true change in "new" ESP is the >> >requirement of the sequence field in all transforms, and adding an >> >optional trailing Authenticator. That's all I've done here, update to >> >match the "new" ESP environment. >> >> Not so. The move to the "new" ESP environment involved a conscious document >> structure change, not just the protocol changes you mentioned. That >> structure change is intended to simplify the specifications by eliminating >> reduntant and potentially conflicting requirements (i.e., factoring out the >> common elements of the packet formats and leaving the transform docs to >> specify algorithmic details). >> >The decision by _Steve_ to do this was debated on the list, and I saw >dissent. We need a nice general ESP document, but I have always seen >the ESP document as the template and "applicability statement", and the >transform documents as the protocols. > >Clearly, you and I have a difference of vision. > > >> >I don't like _under_ specifying stuff. Each transform should stand on >> >its own! >> >> B relating the transform drafts back to the base ESP draft (as you do and >> the RC5/CAST drafts do), then they DO stand on their own as separable >> transforms that support the packet formats as defined in ESP. They MUST be >> read AND used in conjunction with ESP and ONLY in conjunction with ESP. If >> you REALLY want them to stand on their own in the context of all the >> working groups, then I would go further to say that they should just >> describe the algorithms and not refer to any base packet formats. In that >> way they could be referenced by any base protocol spec such as TLS or ECP >> by way of IANA numbers. But in my relatively short IETF life, I wouldn't >> expect to see that happen at this stage and would be grateful to fulfill >> the intentions of the wg and the ESP draft (and for this purpose, we have >> the IPSec DOI). >> >A very different vision. > >I am not in favor of transforms so general that they could be used >without packet formats. That's what the algorithm documents (like CAST >just published as an RFC) should do. The transforms are specific >applications of the generic algorithms in concrete form. > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > From owner-ipsec Mon May 26 12:21:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA13818 for ipsec-outgoing; Mon, 26 May 1997 12:21:08 -0400 (EDT) Message-Id: X-Aliased: From schmidt@rutil.Informatik.Uni-Oldenburg.DE (Torge Schmidt) From: "Torge Schmidt" Subject: ISAKMP/Oakley implementation availability To: ipsec@ex.tis.com Date: Mon, 26 May 1997 18:28:37 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi! Are there any ISAKMP/Oakley implementations, freely available out of the US? The IPsec survey results didn't mention any. Thanks, Torge From owner-ipsec Mon May 26 17:48:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15275 for ipsec-outgoing; Mon, 26 May 1997 17:47:44 -0400 (EDT) Message-Id: <199705262155.RAA27212@codex.cis.upenn.edu> To: "Torge Schmidt" cc: ipsec@ex.tis.com Subject: Re: ISAKMP/Oakley implementation availability In-reply-to: Your message of "Mon, 26 May 1997 18:28:37 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15619.864683538.1@dsl.cis.upenn.edu> Date: Mon, 26 May 1997 17:52:19 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "Torge Schmidt" writes: > >Are there any ISAKMP/Oakley implementations, freely available out of >the US? The IPsec survey results didn't mention any. > I'm writing an implementation of it at the moment, while enjoying the Greek beaches :-) A very rough, GPL'ed version of it will be available after the first week of June (after the AIAG interop). Someone will (hopefully) pick it up from there (i'm getting back to the US then, so i won't be able to work on it any more). As is usually the case with such matters, there will be an announcement in this list when the time comes (the stars are aligned, the Old Ones are coming back, the protocol is stable...umm, scratch that). Cheers, -Angelos From owner-ipsec Tue May 27 08:14:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20029 for ipsec-outgoing; Tue, 27 May 1997 08:11:26 -0400 (EDT) Message-Id: <3.0.32.19970525220315.00b1a400@earthlink.net> Date: Sun, 25 May 1997 22:03:22 -0700 To: "William Allen Simpson" From: Bob Monsour Subject: Re: definitions versus protocols Cc: Bob Monsour , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:02 PM 5/24/97 GMT, William Allen Simpson wrote: [snip...] >As I mentioned, the CAST and RC5 (sharing an author) don't provide >enough information to write any code. They just shim between real >documents. That's my objection. > >I have a strong prejudice for working on code, and therefore have >principly limited my efforts to code-generating documents. > >If these are "algorithm/transform definitions, not protocols", then they >would not be able to be on the Standards Track. The IETF standardizes >protocols, upon demonstrated interoperability. > >A shim would be easier to produce, but would only be an Informational RFC. I disagree. According to RFC2026 (Internet Standards Process), these "shim" docs fall into the class of Technical Specifications (as opposed to Applicability Statements), the definition of which follows: A Technical Specification is any description of a protocol, service, procedure, convention, or format. It may completely describe all of the relevant aspects of its subject, or it may leave one or more parameters or options unspecified. A TS may be completely self- contained, or it may incorporate material from other specifications by reference to other documents (which might or might not be Internet Standards). A TS shall include a statement of its scope and the general intent for its use (domain of applicability). Thus, a TS that is inherently specific to a particular context shall contain a statement to that effect. However, a TS does not specify requirements for its use within the Internet; these requirements, which depend on the particular context in which the TS is incorporated by different system configurations, are defined by an Applicability Statement. They clearly don't have to be "protocols". Perhaps the "shim" specs fall into the "convention" class. The "shim" specs "incorporates material from other specs by reference to other documents". From Section 4.1.2 of that same document, the following definition of the term "interoperable" is provided: For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. As for writing code from the "shim" specs, with the following specs in hand, (1) base ESP draft, (2) RC5 (or CAST) "shim" spec, and (3) detailed RC5 algorithm spec, I can clearly imagine writing a software module with a calling sequence that looks something like this: ESP_RC5(key, IV, plaintext) that would return the value of the resulting ciphertext. To do that I would have to refer to the ESP draft for the padding spec for how to make it pad. I'd also have to refer to the RC5 spec to code the algorithm. And the "shim" spec would tell me how to use the key and IV. While no two implementors would produce the same code, it's clear what the inputs are and what the outputs need to be from the "shim" spec and thus I would argue that the to implementors could demonstrate interoperability. )However, I would suggest that the interoperability in this case would be in the context of a complete ESP implementation.) >From the above definitions and the description of Informational (from RFC2026), I see no reason why the "shim" specs could not be Standards Track documents. [snip...] >> B relating the transform drafts back to the base ESP draft (as you do and >> the RC5/CAST drafts do), then they DO stand on their own as separable >> transforms that support the packet formats as defined in ESP. They MUST be >> read AND used in conjunction with ESP and ONLY in conjunction with ESP. If >> you REALLY want them to stand on their own in the context of all the >> working groups, then I would go further to say that they should just >> describe the algorithms and not refer to any base packet formats. In that >> way they could be referenced by any base protocol spec such as TLS or ECP >> by way of IANA numbers. But in my relatively short IETF life, I wouldn't >> expect to see that happen at this stage and would be grateful to fulfill >> the intentions of the wg and the ESP draft (and for this purpose, we have >> the IPSec DOI). >> >A very different vision. > >I am not in favor of transforms so general that they could be used >without packet formats. That's what the algorithm documents (like CAST >just published as an RFC) should do. The transforms are specific >applications of the generic algorithms in concrete form. I agree that I went further than was practical to make by point. However, I still believe that the amount of overlap between the "transform"/"shim" specs and the base ESP specs in your two drafts is excessive and potentially problematic for implementors and I don't see a problem with the "shim" approach. Thanks for your comprehensive responses to my comments. I hope that the debate on doc structure does not put yet another incremental drag on IPSec progress. We've certainly got enough of those. I strongly encourage/beg-for the wg co-chairs (or the AD if needed) to provide their guidance/leadership to get the group decision-focused wrt the littany of seemingly endless obstacles (small and large alike) in front of the group. -Bob From owner-ipsec Tue May 27 10:02:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21231 for ipsec-outgoing; Tue, 27 May 1997 10:01:10 -0400 (EDT) Date: Tue, 27 May 1997 10:06:46 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705271406.KAA18672@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: definitions versus protocols X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "William Allen Simpson" > > So, it looks like we really need a "straw poll" as to whether these > should be merely "shims" or true protocols. Let's debate that in this > thread for a week (ending May 30th), and see if there's a broader > consensus one way or the other. > > [...] > > I am not in favor of transforms so general that they could be used > without packet formats. That's what the algorithm documents (like CAST > just published as an RFC) should do. The transforms are specific > applications of the generic algorithms in concrete form. Since we are straw polling, I absolutely agree with Bob M. that the ESP document should be the protocol definition and that the transform documents should be orthogonal to the ESP specification. * This is good engineering practice - using the ESP document as a boilerplate template to derive standalone transforms is just begging for mistakes to creep in, both in the document editing stage and in the implementation stage. If you don't have redundant specifications, you can't have inconsistencies between the redundant copies. (You can still have mistakes, but you only have to fix them once.) * If all transform documents include copies of ESP, changes to the ESP protocol (bits-on-the-wire, or changes in interpretation of existing bits) would require reissuing *every* transform RFC, even if the ESP changes had no algorithm-specific component (example: change to the size of the AR counter). * Although IPSEC is the first consumer of the transform documents and IPSEC should be the focus of this working group's effort, I believe it is valuable to write the algorithm definitions in such a way that they could be referenced by other protocols (TLS, S/MIME, ...) if other working groups choose to do so. Including only algorithm-specific data in the transform documents facilitatates such reuse. * The IETF is not the ISO, where one must wade through endless chains of references, some of which may be difficult to obtain. RFCs are all available in one place, and implementors should find it no more difficult writing code from a single ESP specification and the algorithm-specific supplements than from standalone algorithm documents. In the case of multiple-algorithm implementations, I contend that the orthogonal approach makes the implementor's life easier. From owner-ipsec Tue May 27 14:09:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23233 for ipsec-outgoing; Tue, 27 May 1997 14:01:53 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5952.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 13:47:47 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: definitions versus protocols Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, We have other examples of RFCs that define just algorithms, so I don't agree with your observation that it is inappropriate to do the same for the algorithms we are using for AH and ESP. Also, note that the IETF does issue standards-track RFCs for things other than protocols, e.g., APIs, MIBs, ... Steve From owner-ipsec Tue May 27 16:41:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24538 for ipsec-outgoing; Tue, 27 May 1997 16:40:19 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5955.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 15:59:42 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: padding values Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, I've looked at all the message traffic since the Memphis meeting, and I do not see any reference to padding being algorithm-specific, as you suggest. Putting random values in tbe padding field has the well-known advantage that it helps counter known plaintext attacks that might result from padding with a constant value, e.g., "0". However, putting in the integer values you cite seems to reintroduce this sort of problem, if anyone didn't believe that known plaintext didn't exist from the encapsulated payload (as Bellovin analyzed in the case of both tunneled and transport mode uses of ESP). I can imagine an integrity bebefit for inclusion of such padding, in a cipher that provides error propogation to the end of the block, but that is not the case for CBC. It would seem that the major benefit for the padding you describe is the ability to detect mods to the last block (only) if no integrity service is elected, which seems a rather slim rationale for this approach to padding. Still, the issue you raise is a good one, i.e., do we want to leave definition of the contents of the padding field to the algorithm, or standardize it in the ESP spec. While I have cited one example of why algorithm-specific padding might be useful, I'm not sure that there are others. Also, note that this makes the interface to the decryption module slightly more complex, i.e., if one is to take advantage of the checking done on t his field, one must be prepared to receive an error indication of a sort that otherwise would be generated only by the authentication/integrity portion of ESP processing. With arbitrary padding, the decryption module merely decrypts the buffer and returns the purported plaintext, without trying to check for integrity (which is, arguably, not a function for a decryption routine). Steve From owner-ipsec Tue May 27 22:01:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26214 for ipsec-outgoing; Tue, 27 May 1997 21:59:55 -0400 (EDT) Date: Wed, 28 May 97 01:13:18 GMT From: "William Allen Simpson" Message-ID: <5970.wsimpson@greendragon.com> To: Stephen Kent Cc: ipsec@tis.com Subject: Re: padding values Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > I've looked at all the message traffic since the Memphis meeting, > and I do not see any reference to padding being algorithm-specific, as you > suggest. Steve, I'd say you didn't look very hard. Paging backwards through the text of my May archive, the most recent I saw was: Date: Thu, 22 May 97 11:27:27 EST From: "Whelan, Bill" Message-Id: <9704228643.AA864325641@netx.nei.com> ... ESP may define restrictions on the length (e.g. a multiple of eight bytes) of the Opaque Payload Data, but otherwise not define content. Individual Transform documents would provide definitions for how the Opaque Payload Data is defined and would cover any needed fields including: - Initialization Vector - Optional - Payload Data - Mandatory - Padding - Optional - Next Header - Mandatory I'm pretty sure we had a discussion last month, too, along with padding the IV to 32 or 64 bit boundaries. I'll find and summarize the rationale for integer padding in a separate message, as those messages by Wagner, Karn, and Baldwin (and the other discussants) are about a year and a half old.... The integer pad values have long been represented in the draft-simpson-esp-des3-x-00.txt that was out there for over a year, and many folks have implemented. > Still, the issue you raise is a good one, i.e., do we want to leave > definition of the contents of the padding field to the algorithm, or > standardize it in the ESP spec. ... More important, to me anyway, is that we cannot know of there is some other padding feature that will be required by some future transform. The need for padding (and the block size) is intimately tied to the algorithm, not the ESP headers. We need to know how long it is, but predicting contents for all future algorithms is beyond us. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue May 27 22:51:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26429 for ipsec-outgoing; Tue, 27 May 1997 22:50:54 -0400 (EDT) Date: Wed, 28 May 97 02:09:11 GMT From: "William Allen Simpson" Message-ID: <5971.wsimpson@greendragon.com> To: ipsec@tis.com Subject: padding values history Sender: owner-ipsec@ex.tis.com Precedence: bulk I've spent some time looking up some of the history. The original Karn proposal (circa 1992) specified padding with zeroes, and checking them upon receipt. In January 1995, various folks complained that checking values would slow down their implementations too much. So, the padding was changed to "unspecified implementation dependent values", and the checking was removed. In March 1995, some folks thought the values should be random to limit "known plaintext". There was some argument -- "(preferably random)" was added, but still left to the implementation. This was published. In February and March 1996, Wagner (with Bellovin) wrote up a "short message" attack, particularly useful for finding telnet passwords. The attack is aided by the lack of checking the trailing padding fields. In April 1996, RSA "purists" examined ESP. One of the issues raised by Baldwin was covert and subliminal channels. Although there are many in the IPSec transforms, using the 0,1,2,3,... self-describing padding was suggested as a way to minimize that problem in ESP. That's a reduction, not an elimination. There is still a small channel by specifying different padding multiples: 4, 12, 20 all give the same alignment, but the variation from packet to packet could pass a bit or two of covert data. Yes, this is getting esoteric. But the implementors at the time agreed to change to a known padding sequence, but make the checking optional, providing backward compatibility. This implementors' agreement was reflected in my drafts of that month. As to the complaint that this adds "known plaintext" for cryptanalysis, the PadLength can only be a few discrete values, and the PayloadType can only be a few discrete values, so there is already known text in that trailing block. Baldwin: "This small amount of known plaintext does not create any problems for modern ciphers." Bellovin: "... avoid use of weak ciphers." WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue May 27 23:20:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA26566 for ipsec-outgoing; Tue, 27 May 1997 23:19:54 -0400 (EDT) Date: Tue, 27 May 97 20:23:05 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9705280323.AA27879@mentat.com> To: ipsec@tis.com Subject: Re: IPSEC AH -- document Sender: owner-ipsec@ex.tis.com Precedence: bulk I have an architectural and implementation concern which stems from the excerpted (below) section 3.1 text from the latest AH document. I'm concerned that additional text has crept into this latest AH document, which is either simply incorrect or is going to limit flexibility of implementations. On this: 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (Use of transport mode in "bump-in-the- stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, is not recommended as these implementations may receive outbound IP fragments from the attached host and thus be unable to process these packets according to this specification.) ... I completely disagree with the parenthetical comment which has been added to this newest version of AH unless we're now getting into the business of restricting vendors/implementers on how they can implement their products. And for what benefit? Also, I don't recall seeing any discussion (either on the list or at Memphis) that led to this additional note. Perhaps someone could supply the background if there's something I've overlooked in the following? I didn't see any reason in the architectural PMTU/DF note last month dated 4/22, in fact in that note the bump-in-the-stack (BITS) approach was marked as being both Transport and Tunnel mode capable, along with the fragmentation issues. Transport mode *can* be properly implemented by a BITS IPSEC implementation ("underneath" the native IP stack), allowing end-hosts to avoid the overheads of Tunnel mode and to be configurable identically to native/integrated IPSEC implementations. As a vendor I see it can be attractive to customers to bring their older systems to full IPSEC protocol compliance without having to upgrade their OS or native protocol stack or buy external boxes. The text above about "outbound IP fragments" doesn't give an adequate reason for supporting the recommendation that BITS IPSEC implementations can't/shouldn't do Transport mode. In the extreme case (not that I recommend any implementers do this) one could have the BITS code "catch" all fragments before passing outbound to the driver/wire, reassemble/move them into contiguous memory, perform AH *exactly* as specified in this spec, and then refragment and pass on the packet fragments down to the driver/wire. There would be no "on the wire" difference from a native/integrated IPSEC implementation. So, other than implementation work to minimize performance impacts (which can be very low anyway if the native IP stack implements PMTU discovery itself), there's no protocol or interoperability problem with a BITS approach implementing Transport mode "according to this specification". Let the vendors and customers make the upgrade/cost/feature/performance trade-offs, lets not specify beyond what "goes on the wire". Or, since we sometimes have to describe how "to process these packets" to ensure that secure procedures are followed *within* a node lets do so in a manner which doesn't make certain implementation approaches, such as BITS, seem non-compliant. My text change recommendations would be to delete the above parenthetical text, since I hope its now clear its not "the full story". The other BITS-related text change I see (if we don't just want a "BITS implementations must perform the same on the wire as a native IPSEC stack" catch all) would be to follow the first sentence in the 3.2.4 Fragmentation section with something like: "For Transport mode BITS implementations, outbound fragments from the native stack of a single packet must be effectively reassembled back into a single IP packet before AH processing." Don't specify any more than that, I don't think any more needs to be specified for interoperability. -- Marc -- From owner-ipsec Wed May 28 09:48:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29943 for ipsec-outgoing; Wed, 28 May 1997 09:45:30 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9705280323.AA27879@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 09:51:54 -0400 To: Marc Hasson From: Stephen Kent Subject: Re: IPSEC AH -- document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, The text I added re BITS/BITW implementations was intentional, but maybe too strongly worded. No, there was no mention of this on the list; it was something that occurred to me while preparing the last revision and so I added it in for review this time around. Both the AH and ESP specs have been silent about these sorts of implementations in the past and because such implementations are being developed, I thought it was important to highlight what I thought might be a problem. Note that this comment is not a prohibition, just a recommendation, re this mode of use. You are right that the PMTU/DF note did not make any mention of this, because it did not occur to me in that context, when the work was done several weeks ago. The reason for the additional text is exactly what it says, i.e., because of the need to deal with fragments transmitted by the host. Perhaps the wording was too strong, and should merely be a warning that these implementations must be aware of the requirement to apply AH (and ESP) only to complete datagrams. I note that fragments created by the host might exist via two different interfaces in a multi-homed host, so a BITW device or very low level BITS code might not be able to do reassembly, IPsec, and then refragmnent, in that instance. Such implementations would have a similar problems for incoming fragements that arrive on separate interfaces and would be reassembled in the native IP implementation. So, those worst case scenarios motivated my recommendation. Still, I'm happy to change the wording to merely refelct the requirement that special care must be taken in these implementations to ensure the ability to properly perform AH and ESP, on both outbound and inbound traffic. Would that be OK? Steve From owner-ipsec Wed May 28 11:27:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00744 for ipsec-outgoing; Wed, 28 May 1997 11:26:31 -0400 (EDT) Date: Wed, 28 May 1997 11:28:01 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: Stephen Kent cc: Marc Hasson , ipsec@tis.com Subject: Re: IPSEC AH -- document In-Reply-To: Message-Id: <97May28.112331edt.11650@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 28 May 1997, Stephen Kent wrote: > The reason for the additional text is exactly what it says, i.e., > because of the need to deal with fragments transmitted by the host. > Perhaps the wording was too strong, and should merely be a warning that > these implementations must be aware of the requirement to apply AH (and > ESP) only to complete datagrams. I note that fragments created by the > host might exist via two different interfaces in a multi-homed host, so a > BITW device or very low level BITS code might not be able to do reassembly, > IPsec, and then refragmnent, in that instance. Such implementations would > have a similar problems for incoming fragements that arrive on separate > interfaces and would be reassembled in the native IP implementation. So, Seems to me that all incoming fragments have the same IP destination address, and thus must arrive on the same interface. Am I missing something? > those worst case scenarios motivated my recommendation. Still, I'm happy > to change the wording to merely refelct the requirement that special care > must be taken in these implementations to ensure the ability to properly > perform AH and ESP, on both outbound and inbound traffic. Would that be OK? Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@tor.securecomputing.com Fax 1 416 813 2001 From owner-ipsec Wed May 28 14:05:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01850 for ipsec-outgoing; Wed, 28 May 1997 13:57:08 -0400 (EDT) Date: Wed, 28 May 97 10:59:49 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9705281759.AA01844@mentat.com> To: kent@bbn.com, norm@tor.securecomputing.com Subject: Re: IPSEC AH -- document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm responding to Steve: > > The reason for the additional text is exactly what it says, i.e., > > because of the need to deal with fragments transmitted by the host. > > Perhaps the wording was too strong, and should merely be a warning that > > these implementations must be aware of the requirement to apply AH (and > > ESP) only to complete datagrams. I note that fragments created by the > > host might exist via two different interfaces in a multi-homed host, so a ^^^^^ exit? > > BITW device or very low level BITS code might not be able to do reassembly, > > IPsec, and then refragmnent, in that instance. Such implementations would > > have a similar problems for incoming fragements that arrive on separate > > interfaces and would be reassembled in the native IP implementation. So, > > Seems to me that all incoming fragments have the same IP destination address, > and thus must arrive on the same interface. Am I missing something? Norm, you bring up a valid issue for inbound. I think I agree that all the packet fragments, even though they may be routed differently, will probably arrive on the same interface/wire. Its hard to envision how they could not do so with standard routing but don't overlook static/explicit routes to get the fragments in via a different interface. However, depending upon whether you have the "weak" or "strong" IP end-system model, as mentioned in RFC 1122, it is permitted for a host to accept packet fragments on a different interface than the one addressed and then reassemble it with fragments that came in on the "correct" interface. A BITS (bump-in-the-stack) implementation that sat between IP and *all* drivers/interfaces could/should be designed to handle this. A BITW (bump-in-the-wire) implementation or an interface-card implementation (that didn't have "special hooks" into the IP system) could have more trouble to, as Steve is pointing out. Steve, assuming you meant "exit" above as I noted then I agree. A multi-home host could "spray" fragments of a single packet out different interfaces. I can think of multiple scenarios where a native IP stack may do this. However, in all the scenarios I can think of, a BITS implementation that sat between IP and all drivers/interfaces could easily resolve the issues, do you agree? Even a BITW interface-card solution could, with some "special hooks" back into the native IP code (though that would probably be "ugly"). A BITW implementation *could* have problems or may require special implementation support or operational restrictions for these worst-case, multi-home scenarios. Also, keep in mind that relatively few hosts (on a world-wide percentage basis) are multi-homed and so wouldn't have any problems at all with almost any reasonably-sane BITS or BITW implementation since there is only one path for packets. > > > those worst case scenarios motivated my recommendation. Still, I'm happy > > to change the wording to merely refelct the requirement that special care > > must be taken in these implementations to ensure the ability to properly > > perform AH and ESP, on both outbound and inbound traffic. Would that be OK? Steve, this would be OK. I'm fine on also specifically pointing out that fragmentation coupled with multi-homing may pose some extra challenges to BITS and BITW implementations, if you'd like. That appears to be the main point here. I'm also fine on removing all BITS/BITW references from everywhere but the Security Architecture and just have AH & ESP address the main IP/IPSEC integrated stack behavior model. Just let BITS/BITW implementers figure out how to interoperate with these in all IPSEC Transport/Tunnel modes and desired topologies/configurations. Your (and the group's) call. I understand your motivation to try and offer some guidance to BITS/BITW folks so I'm still OK with the previous paragraphs. I just want to avoid making any statements/judgements on what an implementation may be able to solve/do to conform with IPSEC. Your current wording about "not recommended...be unable to process these packets according to this specification" (given that IPSEC is something folks will be reading carefully since security is important and yet not with full understanding of a given implementation) is more than "strongly worded". Its equivalent to the IETF saying "don't do this" or "there be security holes here". Thanks. -- Marc -- From owner-ipsec Wed May 28 14:26:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02047 for ipsec-outgoing; Wed, 28 May 1997 14:23:11 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97May28.112331edt.11650@janus.tor.securecomputing.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 14:06:14 -0400 To: Norman Shulman From: Stephen Kent Subject: Re: IPSEC AH -- document Cc: Marc Hasson , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, The two interfaces may have different local addresses but the same IP address, in some circumstances. Admittedly this, and multihoming in general, is not all that common, but we ought to be cognizant of the most general cases in developing standards. Steve From owner-ipsec Wed May 28 16:10:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02671 for ipsec-outgoing; Wed, 28 May 1997 16:08:48 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9705281759.AA01844@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 16:07:09 -0400 To: Marc Hasson From: Stephen Kent Subject: Re: IPSEC AH -- document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Marc, Yes, I meant exit! And yes, we agree that a suitably high level BITS IPsec could deal with the problem, but a device driver level implementation would have difficulties. The major motivation for BITS implementations is backward compatability, as you noted, so relying on hooks in the IP implementation seems questionable. Still, I think we agree that a warning to implementors about the subtilties of BITS and BITW transport mode is OK, just so long as we don't suggest that such implementation ought not support this mode. I have already modified the text in the AH and ESP I-Ds to accommodate suhc wording, but mayeb moving it to the arch document is preferable (as it is a common problem). I'm flexible. Steve From owner-ipsec Wed May 28 16:55:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03053 for ipsec-outgoing; Wed, 28 May 1997 16:55:21 -0400 (EDT) Date: Wed, 28 May 97 13:58:04 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9705282058.AA02702@mentat.com> To: kent@bbn.com Subject: Re: IPSEC AH -- document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > Yes, I meant exit! And yes, we agree that a suitably high level > BITS IPsec could deal with the problem, but a device driver level > implementation would have difficulties. The major motivation for BITS > implementations is backward compatability, as you noted, so relying on > hooks in the IP implementation seems questionable. Still, I think we agree Agreed. Yes, a single-interface-only driver wouldn't solve the multi-interface reassembly problem. However, the "hooks" I was thinking only of in conjunction with BITW interface cards (not a "just under IP" BITS) and I sure didn't feel comfortable with that idea. Its worse than "questionable", its something that might make sense on some specific platform though one would wonder if it wasn't easier to just update the whole stack at that point or effectively have an "under IP" BITS extension anyway. I intended to show how much more difficulty a BITW would have, even if it was as close as an interface card (I guess I see why you might call that a BITS instead), than an "under IP" BITS in dealing with the multi-interface fragmentation issues. Also I didn't want, even in *that* ugly situation, to rule out the possibility that some clever BITW vendor may think of something we hadn't in order to support Transport mode in (some?) multi-interface machines. Sorry for any confusion, lets drop this bad "hook" suggestion I had. > that a warning to implementors about the subtilties of BITS and BITW > transport mode is OK, just so long as we don't suggest that such > implementation ought not support this mode. I have already modified the Good. > text in the AH and ESP I-Ds to accommodate suhc wording, but mayeb moving > it to the arch document is preferable (as it is a common problem). I'm > flexible. Either way sounds good to me. From my point of view you could leave it where you've now got it, in the interest of saving time. -- Marc -- From owner-ipsec Wed May 28 17:53:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03451 for ipsec-outgoing; Wed, 28 May 1997 17:52:55 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9705282058.AA02702@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 17:46:45 -0400 To: ipsec@tis.com From: Stephen Kent Subject: Re: IPSEC AH -- document Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Marc and I have exchanged some text and the proposed revision for the BITS and BITS use in transport mode follows: In this mode, note that "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use. Any objections? Steve From owner-ipsec Wed May 28 17:53:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03450 for ipsec-outgoing; Wed, 28 May 1997 17:52:54 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5971.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 17:58:16 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: padding values history Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Thanks for the historic analyiss of ESP padding. I've gone back and reviewed the messages in question, and I think we have some differences when it comes down to the cited motivations for padding with other than random bytes, although I agree with most of the history as you presented it. For exmaple, you cite e-mail from Steve Bellovin in the 2-3/96 timeframe. My records show that discussion ending with the following message from Steve to Phil Karn with regard to Wagner's attack: ------- Karn: I don't remember how the text got changed, but it's not important. The question is, do we want to change the ESP spec re padding? Bellovin: We could make that change, but I suspect that it's a palliative measure at best. The real answer is integrity-checking, done right. ----- So it would appear that Steve's response to Phil was that while padding with zeros would help with the cited attack, Steve's view was that the preferred approach was just to elect use of authentication/integrity if one wants to achieve that effect. >In April 1996, RSA "purists" examined ESP. One of the issues raised by >Baldwin was covert and subliminal channels. Although there are many in >the IPSec transforms, using the 0,1,2,3,... self-describing padding was >suggested as a way to minimize that problem in ESP. I didn't see any messages dealing with covert or subliminal channels in the old traffic, so I called Bob Baldwin and we discussed the matter. The issue he believes that you cited is that arbitrary padding allows covert exfiltration of data by the encryption module, but only to a legitimate receiver. Frankly, there is a much greater concern about malicious software somewhere in the system shipping out vast quantities of text over an SA, rather than hiding it in the padding. The second example you cite is completely different, i.e., a Trojan Horse can manipulate the length of the padding to effect a covert channel that is accessible to a passive wiretapper, and this is potentially a more serious concern, since it involves not an authorized destination for encrypted data, but an attacker intercepting the ciphertext. (It also is an attack first described in the literature in 1978, in two different authors, including me.) Note that the choice of padding has no effect on this smaller, but much more serious channel, so it is irrelevant to our padding content discussion. This is a long way of saying that the arguments you provided for using this sort of padding are not really supported, or strongly supported, by the evidence you cite. However, I have come to agree with your suggestion, i.e., that padding should be algorithm specific. For example, Bob pointed out to me that there is an ISO spec for DES-CBC that calls for the enumerated padding. Others may wish to use random padding. Those are good examples of why padding should be algorithm/mode-specific. So, I'm changing the padding discussion in ESP to reflect that. Steve From owner-ipsec Wed May 28 18:49:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03785 for ipsec-outgoing; Wed, 28 May 1997 18:48:54 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 18:53:51 -0400 To: ipsec@tis.com From: Stephen Kent Subject: another padding question ... Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I've reworded the padding field text as per my earlier message, to make padding content algorithm/mode specific. However, Bill also has suggested that padding be used to ensure that the Auth Data field, if present, be aligned on an 8-byte boundary. Previously published transform I-Ds for ESP do not call for 64 bit alignment, but rather refer to "approrpiate alignment" when discussing padding. The current version of the ESP I-D calls fo the Next Header field to end on 4-byte boundary, matching the diagram in the I-D, irrespective of the presence of the Auth Data field. I can see a good motivation for 4-byte alignment here, in any case, but 8-byte alignment seems less of a critical issue. It's just another field within the ESP format and we don't generally require such alignment for each of our protocol fields. In fact, the suggestion of requiring 8-byte alignment for the start of the Payload was not adopted. So, shall we sitck with the 4-byte alignment that has been called for previously, or is there a strong sentiment to up it to 8-bytes? Steve From owner-ipsec Thu May 29 10:40:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10090 for ipsec-outgoing; Thu, 29 May 1997 10:34:17 -0400 (EDT) Date: Thu, 29 May 1997 10:37:44 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199705291437.KAA02973@earth.hpc.org> To: ipsec@tis.com Subject: DOI and isakmp-oakley questions Sender: owner-ipsec@ex.tis.com Precedence: bulk The DOI talks about key lifetimes computed "under" an ESP or AH SA, noting that derived keys must expire at the same time. I don't understand what this means ... keys are computed under an ISA/Oak SA, not an ESP SA, aren't they? What does the text mean? In Quick Mode, you are required to throw away the new DH key; this hadn't been the original intent. The change means that you cannot assign a PFS key to a pair of communicants and then let them derive a series of further keys from that. They must either do a new Quick Mode to get new a new DH ephemeral key, or else they must derive a Quick Key from older Phase I material (that may be used for other communicants, as well). The QM note is related to the discussion of pre-shared key lookup. If you use key exchange to distribute a pre-shared Oakley SA, then you can assign a name to it, and then you can use QM with that SA. This might be cleaner than having a separate mechanism for assigning key id's. For the pre-shared key methods, may the KE be eliminated? The protocol remains sound, even though PFS is lost. Photuris had a very nice discussion about when to pick a new DH exponential. The observation was that you didn't need to compute a new exponential for every Phase I exchange, you can just change it every few minutes, as convenient. This might mean that you went through two Phase I negotiations with the same exponentials ... no harm, you've got the nonces that prevent generating the same keys. There's a claim that the DH exponents cannot be related to any other long-term info, including PRNG seeds. I'm not sure what this means, because the exponents must be derived from something, and if one comes up with something that reasonably random, uses that as the seed to a PRNG, and bases the exponents on that, I claim that's about as good as it gets. What's the subtlety that I'm missing? There's something about MODP ... I don't have the exact wording handy, but it should say that MODP is the modular exponeniation method for calculating Diffie-Hellman exponentials, rather than what it does say (something like MODP is the name of the group). Could the way new names are assigned for new groups be clarified? I'd intended to have the Initiator and Responder both supply name components. Does the resolution document intend to have the Responder supply a name ("description" field, I think?) in the response, or use the Initiator's proposed name? Going back to a point I've not described well in the past, I think it would help people understand identities a little better to strike words indicating that the the Phase I negotiation should be between trusted processes identified as isakmp daemons. The negotiation can be between any two identities, and multiple negotiations with disjoint sets of identities can be used. I know that the ISAKMP document is written from an architectural viewpoint that requires the key mgmt process to be trusted, and in that case having the Phase I identities "speak for" all Phase II identities is understandable, but it seems to be an overly restrictive initial assumption, and certainly beyond wire compatibility. Hilarie From owner-ipsec Thu May 29 11:33:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10527 for ipsec-outgoing; Thu, 29 May 1997 11:32:19 -0400 (EDT) Date: Thu, 29 May 97 15:13:23 GMT From: "William Allen Simpson" Message-ID: <5980.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: IPSEC AH -- document Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > implementation ought not support this mode. I have already modified the > text in the AH and ESP I-Ds to accommodate suhc wording, but mayeb moving > it to the arch document is preferable (as it is a common problem). I'm > flexible. > Architecture, please. Both because its common, and because it is not specifically related to the problems of the specific bits on the wire protocol. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Thu May 29 11:33:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10526 for ipsec-outgoing; Thu, 29 May 1997 11:32:18 -0400 (EDT) Date: Thu, 29 May 97 15:04:01 GMT From: "William Allen Simpson" Message-ID: <5979.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: another padding question ... Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > I've reworded the padding field text as per my earlier message, to > make padding content algorithm/mode specific. However, Bill also has > suggested that padding be used to ensure that the Auth Data field, if > present, be aligned on an 8-byte boundary. Previously published transform > I-Ds for ESP do not call for 64 bit alignment, but rather refer to > "approrpiate alignment" when discussing padding. yeah, those are the weasel words so that IPv4 has 32-bit alignment, and IPv6 has 64-bit alignment. It would be easier for the implementors to always have 64-bit alignment. It would be nice if we could only have one test instead of two. Please! > In fact, the suggestion of > requiring 8-byte alignment for the start of the Payload was not adopted. I beg to differ! SPI || Sequence == 64-bits. We rejected the Hughes draft with SPI || IV || Sequence, partly because the 64-bit IV wasn't aligned. As well as the fact that it didn't make sense to have an algorithm specific field mixed in with the generic fields, of course. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Thu May 29 12:22:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10851 for ipsec-outgoing; Thu, 29 May 1997 12:20:57 -0400 (EDT) Message-Id: <199705291626.JAA06292@fluffy.cisco.com> To: ho@earth.hpc.org (Hilarie Orman) cc: ipsec@tis.com Subject: Re: DOI and isakmp-oakley questions In-reply-to: Your message of "Thu, 29 May 1997 10:37:44 EDT." <199705291437.KAA02973@earth.hpc.org> Date: Thu, 29 May 1997 09:25:58 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk >The DOI talks about key lifetimes computed "under" an ESP or AH SA, >noting that derived keys must expire at the same time. I don't >understand what this means ... keys are computed under an ISA/Oak SA, >not an ESP SA, aren't they? What does the text mean? Hilarie, The only reference I can find to "under" in the latest draft is in the discussion of SA lifetimes: SA Life Type SA Duration Specifies the time-to-live for the overall security association. When the SA expires, all keys negotiated under the association (AH or ESP) must be renegotiated regardless of the time-to-live remaining for the keys. I don't understand what a key lifetime "under" an ESP or AH SA would mean either, so if it said that in the past, I must have fixed it. If there's a more specific section you think needs to be cleaned up that I missed, either post it here or email it to me directly. Thanks, Derrell From owner-ipsec Thu May 29 17:43:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA13085 for ipsec-outgoing; Thu, 29 May 1997 17:39:08 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5979.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 May 1997 17:40:52 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: another padding question ... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Thanks for the note. I'm not completely clear about the alignment requirement in the IPv6 context, and I think previous messages on this list suggest that the lack of clarity is widespread. Can you cite a specific IPv6 document that indicates the granularity at which 64-bit alignment must be maintained? We all understand the benefits of making the length of AH be zero mod 8, because it affects the alignment of the subsequent payload. However, in the ESP context, we're just talking about the position of the Auth Data field at the end of the packet. In some sense, it's just another field within ESP, and not all the ESP (or AH) fields can be 8-byte aligned. As for the inclusion of the sequence number to force 8-byte alignnment in ESP, you're right! I had to go back and review the messages. You and 1 or two other folks stated that that was intended, although I also got 1 or more "I don't know" rersponses re my question. So, thanks for the reminder; I'll make sure the sequence number field is a fixed part of the ESP format, even when authentictaion has not been elected as a service. Steve From owner-ipsec Thu May 29 19:15:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA13687 for ipsec-outgoing; Thu, 29 May 1997 19:14:10 -0400 (EDT) Message-Id: <199705292319.TAA17327@raptor.research.att.com> To: Stephen Kent cc: William Allen Simpson , ipsec@tis.com Subject: Re: another padding question ... Date: Thu, 29 May 1997 19:19:11 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for the note. I'm not completely clear about the alignment requirement in the IPv6 context, and I think previous messages on this list suggest that the lack of clarity is widespread. Can you cite a specific IPv6 document that indicates the granularity at which 64-bit alignment must be maintained? We all understand the benefits of making the length of AH be zero mod 8, because it affects the alignment of the subsequent payload. However, in the ESP context, we're just talking about the position of the Auth Data field at the end of the packet. In some sense, it's just another field within ESP, and not all the ESP (or AH) fields can be 8-byte aligned. Yup -- no higher-layer protocol than ESP will ever see the data. The question of interest is whether or not a 64-bit machine will be able to process or generate that field more quickly if it's 64-bit aligned. I strongly suspect that it doesn't matter -- it's not a lot of data that needs copying, and the cost of calculating the Auth Data field far dwarfs the cost of storing or retrieving the result, even if unaligned. From owner-ipsec Thu May 29 20:13:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13982 for ipsec-outgoing; Thu, 29 May 1997 20:13:36 -0400 (EDT) Message-Id: <3.0.1.32.19970529201906.0097c4b0@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 29 May 1997 20:19:06 -0400 To: Stephen Kent From: Matt Thomas Subject: Re: another padding question ... Cc: ipsec@tis.com In-Reply-To: References: <5979.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:40 PM 5/29/97 -0400, Stephen Kent wrote: >Bill, > > Thanks for the note. I'm not completely clear about the alignment >requirement in the IPv6 context, and I think previous messages on this list >suggest that the lack of clarity is widespread. Can you cite a specific >IPv6 document that indicates the granularity at which 64-bit alignment must >be maintained? We all understand the benefits of making the length of AH >be zero mod 8, because it affects the alignment of the subsequent payload. >However, in the ESP context, we're just talking about the position of the >Auth Data field at the end of the packet. In some sense, it's just another >field within ESP, and not all the ESP (or AH) fields can be 8-byte aligned. RFC 1883. All IPv6 headers must be aligned on 8 byte boundaries. What about encryption-less ESP? It would be foolish to make the unencrypted data unaligned since that might force a data copy. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Fri May 30 09:52:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18553 for ipsec-outgoing; Fri, 30 May 1997 09:49:51 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970529201906.0097c4b0@ranier.altavista-software.com> References: <5979.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 09:52:40 -0400 To: Matt Thomas From: Stephen Kent Subject: Re: another padding question ... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt, I've dropped encryptionless ESP as an explicit feature, although it can be added back in through the definition of a null encryption algorithm. Even though the vote was close enough to sugget that we do not have concensus (14 AGAINT, 12 FOR, including 4 private FOR votes), I decided to close the debate rather than prolong it. Given that we always include the 4-byte Sequence Number field, the start of the Payload is 8-byte aligned, irrespective of whether it is encrypted of not. The Auth Data field alignment question will be unaffacted by the use (or non-use) of encryption. Steve From owner-ipsec Fri May 30 09:55:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18618 for ipsec-outgoing; Fri, 30 May 1997 09:54:52 -0400 (EDT) Message-Id: <199705301401.KAA27197@relay.hq.tis.com> Date: Fri, 30 May 97 9:59:32 EDT From: Charles Lynn To: Stephen Kent cc: William Allen Simpson , ipsec@tis.com Subject: Re: another padding question ... Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Bill, et. al., In Message-Id: of Date: Thu, 29 May 1997 17:40:52 -0400 you say > However, in the ESP context, we're just talking about the position of the > Auth Data field at the end of the packet. In some sense, it's just another > field within ESP, and not all the ESP (or AH) fields can be 8-byte aligned. This may be one point of discussion, but it is not the only point about alignment and ESP. You asked: > Can you cite a specific IPv6 document that indicates the granularity > at which 64-bit alignment must be maintained? In Message-Id: <3.0.1.32.19970529201906.0097c4b0@ranier.altavista-software.com> of Date: Thu, 29 May 1997 20:19:06 -0400 Matt Thomas responded > RFC 1883. All IPv6 headers must be aligned on 8 byte boundaries. > > What about encryption-less ESP? It would be foolish to make the > unencrypted data unaligned since that might force a data copy. I would like to get the other ESP alignment issue resolved. Can the working group agree that the ESP IV field MUST be padded to a multiple of 64 bits to preserve the IPv6 alignment requirements required by RFC 1883? To save folk time searching the archives, in my message of Date: Fri, 16 May 97 18:25:50 EDT > Third, based on the email that I have seen, most folks agree with moving > the IV out of the ESP header and into the beginning of the Payload > Data area. I agree that this is a reasonable thing to do. But it > has a hidden cost for IPv6. In IPv6 tunnel mode, the inner IPv6 > header, which must be aligned on a 64-bit boundary, follows the > 64-bit aligned ESP header and the algorithm dependent and negotiated > IV. (Some have argued that this alignment is not strictly required. > Others that it is. The "be conservative in what you send and liberal > in what you accept" argues we follow the strict viewpoint.) Thus the > space occupied by the IV field has to be a multiple of 64 bits to > meet the IPv6 requirements. It seems this requires that, if the size > of the IV is a function of the algorithm or is negotiated, then the > negotiation protocol would have to be aware during the negotiation > process of the IP version being protected. That seems rather > complicated to me. I would instead suggest the architecture or ESP > doc require that IV field size MUST be a multiple of 64 bits, and > also specify how to pad IVs of other sizes to a multiple of 64 bits. > Since most algorithms that I am aware of already use 64-bit IVs, this > would not cause any additional processing. It would make it so that > (some vendor's) deployed software would not suddenly break when a new > algorithm which uses other sized IVs is deployed in the future. What > do others think about making this a requirement? As this was not clear to all, I amplified in response to a question in Message-Id: <199705170503.BAA19674@relay.hq.tis.com> of Date: Sat, 17 May 97 0:42:31 EDT > > I'm puzzled by this. Why wouldn't the standard padding at the end of > > the ESP payload be enough to handle alignment problems ? > > No. Maybe a picture would help. > > 64-bit boundaries (not to scale) > | | | | | | | | | > +-------+-------+-------+---- +-------+-------+------------+-------+ > |IP6 Hdr|Rtg Hdr|ESP Hdr| IV |IP6 Hdr|Rtg Hdr|User Payload|ESP Pad| > +-------+-------+-------+---- +-------+-------+------------+-------+ > > When the decapsulating system gets this packet, it will "strip off" > the headers before the (IV and) inner IPv6 header, and then have to > process that header and possibly others beyond it (inner Rtg Hdr in > this example). It is expected that the outer IPv6 base header and > extension headers are aligned so those systems that demand data > alignment can process the packet. But this system has to also process > the inner headers. Maybe the inner routing header needs to be > advanced, and IPv6 addresses shuffled around. If the IV field is not > a multiple of 64 bits, it breaks the alignment between the outer and > inner headers, then the vendor is stuck realigning the the packet, > which is a good way to reduce performance. Some have argued that the > encrypted portion (IV through ESP Pad) would have to be copied anyway > so it doesn't really matter. In some cases that argument works. But > requiring the IV field to be a multiple of 64 bits would make it work > in all cases, allowing the vendors to simplify their implementations. > Given current technology, it only costs a few words, and would nail > things down unambiguously. I think it is a reasonable requirement. > If others feel otherwise, we should know so that the working group > documents can warn vendors not to make "assumptions". Charlie From owner-ipsec Fri May 30 10:03:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18659 for ipsec-outgoing; Fri, 30 May 1997 10:03:21 -0400 (EDT) Message-Id: <2.2.32.19970530141721.00b96348@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 10:17:21 -0400 To: ipsec@tis.com, ietf-ppp@merit.edu From: Naganand Doraswamy Subject: IP Payload Compression Protocol (ippcp) working group Cc: narten@raleigh.ibm.com, naganand@ftp.com Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the tentative charter. It is yet to be approved by the IESG. If you have any comments/suggestions on the charter, kindly post it on the ippcp mailing list. -------------------------------------------------------------------------------- IP Payload Compression Protocol (ippcp) --------------------------------------- Charter Current status: proposed working group Chair(s): Naganand Doraswamy Internet Area Director(s) Jeff Burgan Thomas Narten Area Advisor: Thomas Narten Mailing lists: General Discussion: ippcp@external.cisco.com To Subscribe: mailer@cisco.com subscribe ippcp [email_addr] in body To Unsubscribe: mailer@cisco.com unsubscribe ippcp [email_addr] in body Archive: TBD Description of Working Group: Lossless data compression has commonly been deployed in layers below the IP layer (PPP being one example). However, the anticipated deployment of higher-layer encryption protocols (e.g., IPSec) threatens to reduce the effectiveness of lower-layer compression techniques since encrypted data cannot be compressed. The IP Payload Compression Protocol Working Group will develop protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by such protocols as IPSec. The Working Group will focus on the compression of independent payloads (i.e., independent datagrams) in a stateless manner. By stateless, we mean that decompression of a received packet does not rely on correct reception or correct ordering of previous packets. The immediate problem the Working Group will address is the development of a payload compression protocol for use in conjunction with IPSec. The working group will develop its specifications to support both IPv4 and IPv6. Although the primary motivation for this WG is the need to compress packets when IPSec is used, the WG will develop an architecture that does not preclude its use with other potential protocols or the absence of IPSec. The working group will identify and document the mechanisms that allow two communicating parties to negotiate the use of compression as well as the compression format to be employed. The Working Group will propose extensions to ISAKMP to support the negotiation of compression parameters. Use of ISAKMP as the immediate effort shall not preclude compression in the absence of IPsec. Alternate negotiation mechanisms (or even static negotiation), if appropriate, shall be identified and extended as needed to accommodate the use of payload compression functionality. Since compression will be negotiated, existing implementations of IP will interoperate with implementations that support compression. The output of this WG will consist of a base architectural document that provides the framework for how compression will be done, together with one or more documents giving specific compression algorithms and formats. The architectural document will describe how different compression algorithms can be negotiated and supported, but leave the documenting of specific compression algorithms to other documents. A registration mechanism for various compression formats will be specified as part of the base protocol. If possible, an existing registration mechanism for compression formats shall be used (e.g., Compression Control Protocol options of PPP). Goals and Milestones: Done Submit draft as justification for working group formation "Compression in IP Security", 3/97 Done Present draft to IP Security working group Done Present prototype IP compression implementation results to IPSec WG Done Draft charter for working group formation and submit to Area Directors Jun 97 Submit Internet-Draft on Base Architecture for IP Payload Compression Protocol Jun 97 Solicit drafts of compressed data formats from working group. Aug 97 Meet in Munich to discuss submitted drafts Revise drafts to reflect working group discussion/inputs Oct 97 Submit IP Payload Compression Protocol architectural document to the IESG for consideration as a Proposed Standard Oct 97 Submit specific compression transform document to the IESG for consideration as a Proposed Standard Dec 97 Meet in Washington, DC to discuss implementation issues relating to IP Payload Compression Protocol, compressed data format drafts, and possible future work of the group Internet Drafts: Posted Revised I-D Title/ ------ ------- ----------------------------------------------------- Mar 97 Compression in IP Security --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Fri May 30 10:09:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18697 for ipsec-outgoing; Fri, 30 May 1997 10:09:22 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199705301401.KAA16825@zafu.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 10:07:20 -0400 To: Charles Lynn From: Stephen Kent Subject: Re: another padding question ... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, We have already agreed to remove the IV field from the ESP format, and fold it into the Payload field, at the beginning (assuming that we have an explicit IV). So, we have finessed the alignment issue at the ESP format level. Depending on how the algorithm and its implementation work, there may not even be a need for an explicit IV to be a 64-bit multiple. Steve From owner-ipsec Fri May 30 10:12:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18757 for ipsec-outgoing; Fri, 30 May 1997 10:12:23 -0400 (EDT) Date: Fri, 30 May 97 14:05:33 GMT From: "William Allen Simpson" Message-ID: <5984.wsimpson@greendragon.com> To: ipsec@tis.com Subject: eliminate AH -- unanimous Sender: owner-ipsec@ex.tis.com Precedence: bulk Based on the responses to this list over the past week, it appears that the WG is unanimous that AH will be eliminated as redundant. That will vastly simplify operations, implementations, documentation and configuration. Welcome back, swIPe! WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Fri May 30 11:27:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19160 for ipsec-outgoing; Fri, 30 May 1997 11:25:27 -0400 (EDT) Message-Id: <3.0.1.32.19970530113246.006107b8@pophost.gte.com> X-Sender: sjj0@pophost.gte.com Disposition-Notification-To: X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 30 May 1997 11:32:46 -0400 To: ipsec@tis.com From: Stuart Jacobs Subject: Re: eliminate AH -- unanimous Cc: "William Allen Simpson" In-Reply-To: <5984.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Before the WG eliminates the AH, we must remember that there are other protocols being developed that rely on the AH option, specifically Mobile IP. Mobile IP control messages (Registration Request, Reg. Reply, BInd Update, Agent Advertisements, etc.) all rely on IP AH to provide authentication. If AH is dropped then Mobile IP will be forced to implement its own form of AH mechanism. At 02:05 PM 5/30/97 GMT, you wrote: >Based on the responses to this list over the past week, it appears that >the WG is unanimous that AH will be eliminated as redundant. > >That will vastly simplify operations, implementations, documentation and >configuration. > >Welcome back, swIPe! > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > > From owner-ipsec Fri May 30 11:30:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19195 for ipsec-outgoing; Fri, 30 May 1997 11:29:57 -0400 (EDT) Message-Id: <199705301535.LAA05259@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: eliminate AH -- unanimous In-reply-to: Your message of "Fri, 30 May 1997 14:05:33 GMT." <5984.wsimpson@greendragon.com> Date: Fri, 30 May 1997 11:35:31 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "William" == William Allen Simpson writes: William> Based on the responses to this list over the past week, William> it appears that the WG is unanimous that AH will be William> eliminated as redundant. Oh, I knew I should have got my head out of the code and said something. I do not agree. a) please announce this on the IPv6 groups. How do we authenticate v6 options is something I want to know. Are there v6 hop-by-hop options that we need to authenticate? AH is currently mandatory for v6, so now the v6 people are going to have to revise their drafts. b) I agree with Bellovin's observations about the futility of authenticating the things in the base IPv4 header. All that info can be stored in the SA anyway. c) However, if AH dies in the v4 world, then I'd rather it happened due to implementation and deployment experience rather than by decree right now. Finally, I think the US based vendors will be shooting themselves in the foot here. Fine, that benefits me. :!mcr!: | Network security programming, currently Michael Richardson | with DataFellows F-Secure IPSec WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM47zq6ZpLyXYhL+BAQGRIwL9H/EjXNwa1M4p232ioyOwaefbyWPlgfXu OCJtfqJrN+mkJBPVWY6Y7K7qVmIQYAy9RT7ZRJHoM/fY3vSXEN/Eo6LHcwfkY0aw QhPtLNTWUQ8tBgmPq8cB9NgAasEHcWxu =lJUM -----END PGP SIGNATURE----- From owner-ipsec Fri May 30 12:24:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19604 for ipsec-outgoing; Fri, 30 May 1997 12:22:08 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5957.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 12:28:36 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: DES-CBC "interface" shim Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, A couple of comments on your DES-CBC "shim" document (which we're calling "algorithm" documents in the AH and ESP I-Ds): - I'd suggest rewording the IV section to make it clear that the IVs used here are not carried explicitly in the ESP packet, but are constructed from values elsewhere in the ESP packet format, what the ESP I-D refers to as an "implicit" IV. Also, I hope your insistance on always including the sequence number field, wasting 4 bytes in the IPv4 context if anti-replay was not enabled, was not motivated by your desire to use it for IV computation here. -I don't see a need to include section 7, on the authentication data field. Steve From owner-ipsec Fri May 30 12:26:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19617 for ipsec-outgoing; Fri, 30 May 1997 12:24:39 -0400 (EDT) Message-Id: <3.0.1.32.19970530093103.008be960@lintjr.cisco.com> X-Sender: tbernste@lintjr.cisco.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 30 May 1997 09:31:03 -0700 To: ipsec@tis.com From: Terry Bernstein Subject: Don't eliminate AH In-Reply-To: <3.0.1.32.19970530113246.006107b8@pophost.gte.com> References: <5984.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't usually post to this list as I'm in marketing (I know that most of you will now delete this ;-) ), but I thought it was important to point out that we really need the IPSec protocol to become a finished standard ASAP. We have many real customers who want to deploy this today and the more changes that are made, the longer it will take to get working code in place. Yes, the protocol may not be perfect, but we can live with that and make the proper minor adjustments during the interoperability trials. If we don't continue moving forward toward standardization, then IPSec may become irrelevent as the market passes it by. Please, please STOP MAKING CHANGES that are not necessary to make the protocol work. -- terry -- -------------------------- Terry Bernstein Product Manager Cisco IOS Security tbernste@cisco.com From owner-ipsec Fri May 30 13:22:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19941 for ipsec-outgoing; Fri, 30 May 1997 13:20:11 -0400 (EDT) Message-Id: <199705301724.NAA12192@raptor.research.att.com> To: Stuart Jacobs cc: ipsec@tis.com, "William Allen Simpson" Subject: Re: eliminate AH -- unanimous Date: Fri, 30 May 1997 13:24:35 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Before the WG eliminates the AH, we must remember that there are other protocols being developed that rely on the AH option, specifically Mob ile IP. Mobile IP control messages (Registration Request, Reg. Reply, BIn d Update, Agent Advertisements, etc.) all rely on IP AH to provide authentication. If AH is dropped then Mobile IP will be forced to implement its own form of AH mechanism. Bill's suggestion is not that the functionality of AH be eliminated, but that it be eliminated syntactically as a header distinct from ESP. ESP with authentication and null encryption does the same thing, but with small changes to the definition of what is protected. From owner-ipsec Fri May 30 15:26:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20752 for ipsec-outgoing; Fri, 30 May 1997 15:23:00 -0400 (EDT) Message-Id: <199705301927.PAA23446@raptor.research.att.com> To: ipsec@tis.com cc: "William Allen Simpson" , kent@bbn.com Subject: Re: eliminate AH -- unanimous Date: Fri, 30 May 1997 15:27:12 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Ever since Bill posted his straw poll, I've been bothered by an intuitive feeling that AH and encryptionless ESP were not equivalent. This afternoon, I finally realized the crucial difference: AH can be deleted or ignored in a context-independent way. Consider, for example, a host that wishes to ignore authentication for the moment, or a firewall that wants to look at port numbers, or a network traffic monitor that wants to see what ports are being used. With AH, this is easy -- skip the number of words denoted by the length field, plug in the proper protocol id, and carry on. This can't be done with ESP without knowledge of the security association. Now -- whether or not we want to enable any of these abilities is a separate issue. But the distinction does exist. From owner-ipsec Fri May 30 15:39:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20886 for ipsec-outgoing; Fri, 30 May 1997 15:39:04 -0400 (EDT) Message-Id: <3.0.1.32.19970530154116.00738f04@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 30 May 1997 15:41:16 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: r.e. AH used by Mobile IP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk As I recall the latest architecture draft REQUIRES BOTH ESP and AH for a conformant implementation, a change from 1825. If I have that right, does this imply we are requiring ESP for Mobile IP? >To: Stuart Jacobs >cc: ipsec@tis.com, "William Allen Simpson" >Subject: Re: eliminate AH -- unanimous >Date: Fri, 30 May 1997 13:24:35 -0400 >From: Steven Bellovin >Sender: owner-ipsec@ex.tis.com > > Before the WG eliminates the AH, we must remember that there are other > protocols being developed that rely on the AH option, specifically Mob > ile > IP. Mobile IP control messages (Registration Request, Reg. Reply, BIn > d > Update, Agent Advertisements, etc.) all rely on IP AH to provide > authentication. If AH is dropped then Mobile IP will be forced to > implement its own form of AH mechanism. > >Bill's suggestion is not that the functionality of AH be eliminated, >but that it be eliminated syntactically as a header distinct from ESP. >ESP with authentication and null encryption does the same thing, but >with small changes to the definition of what is protected. > > From owner-ipsec Fri May 30 15:57:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA21034 for ipsec-outgoing; Fri, 30 May 1997 15:56:42 -0400 (EDT) Message-Id: <3.0.1.32.19970530160139.00ab9640@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 30 May 1997 16:01:39 -0400 To: "William Allen Simpson" , ipsec@tis.com From: Robert Moskowitz Subject: Re: eliminate AH -- unanimous In-Reply-To: <5984.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:05 PM 5/30/97 GMT, William Allen Simpson wrote: >Based on the responses to this list over the past week, it appears that >the WG is unanimous that AH will be eliminated as redundant. > I will not weigh in on this until around June 9th. This is after I have had a chance to review the implications of this with vendors that have implemented all of this work. I need to have a serious review of the various pros and cons. I have spoken with a number of people, but am not ready to voice my industry's position. BTW, it seems that redundancy is the norm in IETF. Plus what about 'security in depth' ??? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri May 30 16:39:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21322 for ipsec-outgoing; Fri, 30 May 1997 16:38:50 -0400 (EDT) From: Dan.McDonald@Eng.Sun.COM (Dan McDonald) Message-Id: <199705302045.NAA04850@kebe.eng.sun.com> Subject: Re: eliminate AH -- unanimous To: wsimpson@greendragon.com (William Allen Simpson) Date: Fri, 30 May 1997 13:45:49 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <5984.wsimpson@greendragon.com> from "William Allen Simpson" at May 30, 97 02:05:33 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Based on the responses to this list over the past week, it appears that > the WG is unanimous that AH will be eliminated as redundant. As someone else pointed out, I'd better get my head out of other problems and address this one. I'll give you folks one simple reason why you MUST NOT eliminate AH: E X P O R T C O N T R O L Even though there are valiant efforts within other portions of my company to circumvent this dain-bramage, export control is still a problem, and will continue to be a problem until the law is overturned. ESP, even if only used encryptionless is "encryption enabling" technology, and falls under close export-control scrutiny. AH does not, and can be slid out the door with relative ease. Steve B. also makes a point about the AH header semantics being what they are. Quit screwing with the spec, folks. Steve Kent and gang's clarifications are about as much as I can further stomach on this front. Now I have to go fight fires again. Enjoy, Dan From owner-ipsec Fri May 30 16:48:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21385 for ipsec-outgoing; Fri, 30 May 1997 16:47:52 -0400 (EDT) Date: Fri, 30 May 1997 13:54:38 -0700 Message-Id: <199705302054.NAA21063@gump.eng.ascend.com> From: Karl Fox To: Dan.McDonald@Eng.Sun.COM (Dan McDonald) Cc: wsimpson@greendragon.com (William Allen Simpson), ipsec@tis.com Subject: Re: eliminate AH -- unanimous In-Reply-To: <199705302045.NAA04850@kebe.eng.sun.com> References: <5984.wsimpson@greendragon.com> <199705302045.NAA04850@kebe.eng.sun.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald writes: > ESP, even if only used encryptionless is "encryption enabling" technology, > and falls under close export-control scrutiny. AH does not, and can be slid > out the door with relative ease. I have heard this now several times, and am puzzled by it. We sell an AH+ESP product, and had no problem at all getting export approval for ESP with 40-bit DES keys. All we had to do was make our product so that export versions can't be retrofitted to support >40 bit encryption. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Fri May 30 16:56:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21439 for ipsec-outgoing; Fri, 30 May 1997 16:56:21 -0400 (EDT) Date: Fri, 30 May 97 13:58:57 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9705302058.AA16520@mentat.com> To: ipsec@tis.com, smb@research.att.com Subject: Re: eliminate AH -- unanimous Sender: owner-ipsec@ex.tis.com Precedence: bulk > Ever since Bill posted his straw poll, I've been bothered by an > intuitive feeling that AH and encryptionless ESP were not equivalent. Another (minor to me) thing that makes them distinct, as of the latest specs I have on AH & ESP, is that AH authenticates explicit IPSO values without having to resort to the additional overhead (20 bytes IPv4, 40 bytes IPv6) of ESP tunnel mode to get the "same" authentication. -- Marc -- From owner-ipsec Fri May 30 17:29:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21598 for ipsec-outgoing; Fri, 30 May 1997 17:28:28 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 17:34:14 -0400 To: ipsec@tis.com From: Stephen Kent Subject: new AH and ESP specs Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Later this afternoon, the list will receive new AH and ESP specs. The AH spec contains revisions based on feedback received in response to the last list-only release, plus some general changes to make the AH and ESP specs more consistent. The ESP specs contains many changes from the pre-Memphis version, including all of the issues that have been hashed out on the list over the last two months. The one missing item in the ESP spec if a DES-CBC MUST IMPLEMENT algorithm spec to point to. I look to the implementor community to provide (or point to) the necessary document (which should be fairly small, as the recent RC5 and CAST documents illustrate) to complete the ESP I-D. If the WG does not find a need for any substantive changes, and with Paul's concurrance, we'll plan to post these as I-Ds through the IETF secretariat, by the end of next week. Hopefully, we can move to last call on these documents soon. Steve From owner-ipsec Fri May 30 18:05:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21792 for ipsec-outgoing; Fri, 30 May 1997 18:02:33 -0400 (EDT) Message-Id: <199705302208.SAA15535@relay.hq.tis.com> Date: Fri, 30 May 97 18:08:06 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: New draft -- IPSEC AH Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-auth-05.txt 30 May 1997 IP Authentication Header Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPsec Working Group. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. Kent, Atkinson [Page 1] Internet Draft IP Authentication Header 30 May, 1997 Table of Contents 1. Introduction......................................................3 2. Authentication Header Format......................................4 2.1 Next Header...................................................4 2.2 Payload Length................................................4 2.3 Reserved......................................................4 2.4 Security Parameters Index (SPI)...............................5 2.5 Sequence Number...............................................5 2.6 Authentication Data ..........................................5 3. Authentication Header Processing..................................6 3.1 Authentication Header Location...............................6 3.2 Outbound Packet Processing...................................8 3.2.1 Security Association Lookup.............................8 3.2.2 Sequence Number Generation..............................8 3.2.3 Integrity Check Value Calculation.......................8 3.2.3.1 Handling Mutable Fields............................8 3.2.3.1.1 ICV Computation for IPv4......................9 3.2.3.1.2 ICV Computation for IPv6......................9 3.2.3.2 Padding...........................................10 3.2.3.2.1 Authentication Data Padding..................10 3.2.3.2.2 Implicit Packet Padding......................10 3.2.3.3 Authentication Algorithms.........................11 3.2.4 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Reassembly.............................................11 3.3.2 Security Association Lookup............................11 3.3.3 Sequence Number Verification...........................12 3.3.4 Integrity Check Value Verification.....................13 4. Auditing.........................................................13 5. Conformance Requirements.........................................14 6. Security Considerations..........................................14 7. Differences from RFC 1826........................................14 Acknowledgements....................................................15 References..........................................................15 Disclaimer..........................................................16 Author Information..................................................17 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header 30 May, 1997 1. Introduction The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the transmitter. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see "Security Architecture for the Internet Protocol" [KA97a] (hereafter referred to as the "Security Architecture"). It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by AH (and by ESP), the concept of Security Associations, the different key management options available for AH (and ESP), and the ways in which AH can be used in conjunction with ESP. Kent, Atkinson [Page 3] Internet Draft IP Authentication Header 30 May, 1997 2. Authentication Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the ICV computation. 2.1 Next Header The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). 2.2 Payload Length This 8-bit field specifies the length of AH, in 32-bit words (4-byte units), minus "2," i.e., the fixed portion (as defined in the original AH spec) of AH is not counted. (Since the Sequence Number field is always present, the fixed portion of AH is now three 32-bit words. However, the "minus 2" length adjustment has been retained for backwards compatibility.) A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "0" value for this field, as there would be no corresponding Authentication Data field. 2.3 Reserved This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.) Kent, Atkinson [Page 4] Internet Draft IP Authentication Header 30 May, 1997 2.4 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this datagram, relative to the destination IP address contained in the IP header with which this security header is associated, and relative to the security protocol employed. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). (A zero value may be used for local debugging purposes, but no AH packets should be transmitted with a zero SPI value.) 2.5 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The sequence number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. This field is always present, even if the receiver does not elect to enable the anti-replay service for a specific SA, in order to ensure 8-byte alignment for the IPv6 environment, when the default integrity algorithms are employed. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Processing" section below). 2.6 Authentication Data This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.2.3 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. Kent, Atkinson [Page 5] Internet Draft IP Authentication Header 30 May, 1997 3. Authentication Header Processing 3.1 Authentication Header Location Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis. BEFORE APPLYING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------- authenticated ------->| except for mutable fields In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet. Kent, Atkinson [Page 6] Internet Draft IP Authentication Header 30 May, 1997 BEFORE APPLYING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hxh,rtg,frag| dest | | dest | | | |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. ------------------------------------------------ IPv4 | new IP hdr* | | orig IP hdr* | | | |(any options)| AH | (any options) |TCP | Data | ------------------------------------------------ |<-- authenticated except for mutable fields ->| -------------------------------------------------------------- IPv6 | | ext hdrs*| | | ext hdrs*| | | |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| -------------------------------------------------------------- |<-------- authenticated except for mutable fields --------->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. Kent, Atkinson [Page 7] Internet Draft IP Authentication Header 30 May, 1997 3.2 Outbound Packet Processing In transport mode, the transmitter inserts the AH header after the IP header and before an upper layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document. 3.2.1 Security Association Lookup AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document. 3.2.2 Sequence Number Generation The transmitter increments the Sequence Number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number Field. A transmitter MUST not send a packet on an SA if doing so would cause the sequence number to cycle. An attempt to transmit a packet that would result in sequence number overflow is an auditable event. 3.2.3 Integrity Check Value Calculation 3.2.3.1 Handling Mutable Fields The AH ICV is computed over IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA. The ICV also encompasses the upper level protocol data, which is assumed to be immutable in transit. If a field is modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field also is set to zero in preparation for this computation. (Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation.) DISCUSSION: For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed here and classified as either mutable or immutable. For Kent, Atkinson [Page 8] Internet Draft IP Authentication Header 30 May, 1997 IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The mutable IPv4 header fields also are enumerated below. The ICV calculation is restricted to the immutable options and specified (base) header fields. 3.2.3.1.1 ICV Computation for IPv4 The following IPv4 base header fields are zeroed prior to the computation of the ICV: - Time to Live (TTL) - Header Checksum - Offset - Flags - Type of Service (TOS) TTL is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. The TOS field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field. Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable). The Flags field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Finally, the Header Checksum will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. The following IPv4 options are mutable: record route, timestamp, loose source routing, and strict source routing. These options are treated as zero-filled for purposes of the ICV computation. The IP Security Options, BSO and ESO (RFC-1038, RFC-1108) and the CIPSO (option number 134) option are included in the ICV calculation and are not zeroed. 3.2.3.1.2 ICV Computation for IPv6 In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed prior to performing the ICV calculation. IPv6 options contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All other options are also included Kent, Atkinson [Page 9] Internet Draft IP Authentication Header 30 May, 1997 in the ICV calculation. See the IPv6 specification [DH95] for more information. Note, for example, that the IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as an immutable option. The transmitter must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. 3.2.3.2 Padding 3.2.3.2.1 Authentication Data Padding As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors: - the length of the ICV - the IP protocol context (v4 or v6) For example, if a default, 96-bit truncated HMAC algorithm is selected, no padding is required for either IPv4 nor for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required for the IPv6 environment. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation. 3.2.3.2.2 Implicit Packet Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Kent, Atkinson [Page 10] Internet Draft IP Authentication Header 30 May, 1997 3.2.3.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations usually preclude use of such algorithms. As of this writing, the mandatory-to-implement authentication algorithms are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.4 Fragmentation If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 3.3 Inbound Packet Processing 3.3.1 Reassembly If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, e.g., the OFFSET field is non-zero, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.3.2 Security Association Lookup Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address and the SPI. (This process is described in more detail in the Security Architecture document.) The SA dictates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates the key(s) Kent, Atkinson [Page 11] Internet Draft IP Authentication Header 30 May, 1997 required to validate the ICV. If no valid Security Association exists for this session (e.g., the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. 3.3.3 Sequence Number Verification All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) If an SA establishment protocol such as Oakley/ISAKMP is employed, then the receiver SHOULD notify the transmitter, during SA establishment, if the receiver will provide anti-replay protection and SHOULD inform the transmitter of the window size. If the receiver has enabled the anti-replay service for this SA, the receiver packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all AH implementations MUST support this window size. A larger window size MAY be established during SA negotiation. If a larger window size is negotiated it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to Kent, Atkinson [Page 12] Internet Draft IP Authentication Header 30 May, 1997 ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 3.3.4 Integrity Check Value Verification The receiver computes the ICV over the appropriate fields of the packet, using the specified authentication algorithm, and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID. DISCUSSION: Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.2.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Now perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 4. Auditing Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the Kent, Atkinson [Page 13] Internet Draft IP Authentication Header 30 May, 1997 AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the transmitter, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97]): - HMAC with MD5 - HMAC with SHA-1 6. Security Considerations Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1826 This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this Kent, Atkinson [Page 14] Internet Draft IP Authentication Header 30 May, 1997 service is now required at all times, to meet IPv6 alignment requirements (even when anti-replay is not enabled for an SA). The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document. Acknowledgements For over 2 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [ATK95] R. Atkinson, "The IP Authentication Header," RFC 1826, August 1995. [BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, 9 June 1994, pp. 21-34. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. Kent, Atkinson [Page 15] Internet Draft IP Authentication Header 30 May, 1997 [DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC-1883, December 1995. [GM93] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, April 1993. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, ?? 1997. [KA97c] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, ?? 1997. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, November 1991. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [Riv92] Ronald Rivest, "The MD5 Message Digest Algorithm," RFC- 1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, March 1996. [STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20 October 1994. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Kent, Atkinson [Page 16] Internet Draft IP Authentication Header 30 May, 1997 Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 385 Ravendale Drive Mountain View, CA 94043 USA E-mail: rja@inet.org Kent, Atkinson [Page 17] From owner-ipsec Fri May 30 19:31:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA22206 for ipsec-outgoing; Fri, 30 May 1997 19:30:32 -0400 (EDT) Date: Fri, 30 May 97 22:38:40 GMT From: "William Allen Simpson" Message-ID: <5991.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: DES-CBC "interface" shim Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > A couple of comments on your DES-CBC "shim" document (which we're calling > "algorithm" documents in the AH and ESP I-Ds): > Please change your terminology; that makes no sense. The "algorithm" document describes the actual algorithm (for example, RFC-2144). If you read the draft, I call it the "transform interface". It's less than a transform. Perhaps other folks can come up with a better term. Shim is good enough for the vernacular for now. > - I'd suggest rewording the IV section to make it clear that the > IVs used here are not carried explicitly in the ESP packet, but are > constructed from values elsewhere in the ESP packet format, what the ESP > I-D refers to as an "implicit" IV. Sure. > Also, I hope your insistance on always > including the sequence number field, wasting 4 bytes in the IPv4 context if > anti-replay was not enabled, was not motivated by your desire to use it for > IV computation here. > The implementors decided to keep the field, as the sender has no idea whether the receiver has implemented anti-replay. Of course, if they had dropped it, I would just keep the current RFC-1829 text having a 32-bit number in that location, which can be either a counter or pseudo-random. > -I don't see a need to include section 7, on the authentication > data field. > I'm sorry, I don't understand why not? The DES-CBC shim needs to talk about the need for integrity. That's algorithm dependent. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Fri May 30 19:45:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA22297 for ipsec-outgoing; Fri, 30 May 1997 19:45:33 -0400 (EDT) Message-Id: <3.0.1.32.19970530194658.006affe8@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 30 May 1997 19:46:58 -0400 To: Stephen Kent From: Rodney Thayer Subject: Re: new AH and ESP specs Cc: ipsec@tis.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk who wrote them? you and atkinson are listed (makes sense) but nobody else from BBN yet random people keep popping out of the sky to tell us things. could you put the true authors list on the documents? At 05:34 PM 5/30/97 -0400, you wrote: >Folks, > > Later this afternoon, the list will receive new AH and ESP specs. >The AH spec contains revisions based on feedback received in response to >the last list-only release, plus some general changes to make the AH and >ESP specs more consistent. The ESP specs contains many changes from the >pre-Memphis version, including all of the issues that have been hashed out >on the list over the last two months. The one missing item in the ESP spec >if a DES-CBC MUST IMPLEMENT algorithm spec to point to. I look to the >implementor community to provide (or point to) the necessary document >(which should be fairly small, as the recent RC5 and CAST documents >illustrate) to complete the ESP I-D. > > If the WG does not find a need for any substantive changes, and >with Paul's concurrance, we'll plan to post these as I-Ds through the IETF >secretariat, by the end of next week. Hopefully, we can move to last call >on these documents soon. > >Steve > > > > ---- ---- Rodney Thayer rodney@sabletech.com Sable Technology Corporation +1 617 332 7292 246 Walnut Street +1 617 332 7970 (Fax) Newton, MA 02160 From owner-ipsec Sat May 31 09:17:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25539 for ipsec-outgoing; Sat, 31 May 1997 09:15:43 -0400 (EDT) Message-Id: <3.0.32.19970530173507.00b4ee70@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 30 May 1997 17:35:09 -0700 To: Stephen Kent From: Bob Monsour Subject: Re: another padding question ... Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:53 PM 5/28/97 -0400, Stephen Kent wrote: >Folks, > > I've reworded the padding field text as per my earlier message, to >make padding content algorithm/mode specific. Steve, If I understand you correctly, by doing this we now require that the RC5 and CAST "shim" drafts have the padding specifics added to them. Here's what I think is a more graceful alternative. Leave the specification of padding in the base ESP draft, but add some language that says something like "each transform specification which specifies the algorithm and other characteristics of the confidentiality services in conjunction with this protocol MAY specify a form of padding which differs, and thus overrides, the specification of padding in this specification". That lets the RC5 and CAST drafts continue in effect without the need for change, but leaves the opportunity for algorithm/transform-specific padding requirements. Hope this isn't too late. -Bob From owner-ipsec Sat May 31 09:17:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25533 for ipsec-outgoing; Sat, 31 May 1997 09:14:13 -0400 (EDT) Message-Id: <199705302208.SAA15525@relay.hq.tis.com> Date: Fri, 30 May 97 18:08:43 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: New draft -- IPSEC ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-04.txt 30 May 1997 IP Encapsulating Security Payload (ESP) Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". This particular Internet Draft is a product of the IETF's IPsec working group. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol. Kent, Atkinson [Page 1] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................4 2.2 Sequence Number .............................................5 2.3 Payload Data.................................................5 2.4 Padding (for encryption).....................................5 2.5 Pad Length...................................................6 2.6 Next Header..................................................6 2.7 Authentication Data..........................................6 3. Encapsulating Security Protocol Processing........................6 3.1 ESP Header Location..........................................6 3.2 Outbound Packet Processing...................................9 3.2.1 Security Association Lookup.............................9 3.2.2 Sequence Number Generation..............................9 3.2.3 Packet Encryption.......................................9 3.2.3.1 Scope of Encryption.................................9 3.2.3.2 Encryption Algorithms..............................10 3.2.4 Integrity Check Value Calculation......................10 3.2.4.1 Scope of Authentication Protection................10 3.2.4.2 Authentication Padding............................10 3.2.4.3 Authentication Algorithms.........................11 3.2.5 Fragmentation..........................................11 3.3 Inbound Packet Processing...................................11 3.3.1 Pre-ESP Processing Overview............................11 3.3.2 Security Association Lookup............................11 3.3.3 Sequence Number Verification...........................12 3.3.4 Integrity Check Value Verification.....................13 3.3.5 Packet Decryption......................................13 4. Auditing.........................................................14 5. Conformance Requirements.........................................14 6. Security Considerations..........................................15 7. Differences from RFC 1827........................................15 Acknowledgements....................................................16 References..........................................................16 Disclaimer..........................................................18 Author Information..................................................18 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see below). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see "Security Architecture for the Internet Protocol" [KA97a] (hereafter referred to as the Security Architecture document). The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP (and by AH), the concept of Security Associations, the different key management options available for ESP (and AH), and the ways in which ESP can be used in conjunction with the Authentication Header (AH). Kent, Atkinson [Page 3] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) 2. Encapsulating Security Payload Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth. | Sequence Number | | Coverage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- | Payload Data (variable) | | ^ ~ ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Confid. | | Padding (0-255 bytes) | | Coverage +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections define the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an ICV. Whether or not an option is selected is defined as part of Security Association (SA) establishment. Thus the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs. 2.1 Security Parameters Index The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this datagram, relative to the destination IP address contained in the IP header (with which this security header is associated) and relative to the security protocol employed. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). (A zero value may be used within an ESP implementation for local debugging purposes, but no ESP packets should be transmitted with a zero SPI value.) The SPI field is mandatory. Kent, Atkinson [Page 4] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The Sequence Number must never be allowed to cycle; thus, it MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32-1 packets on an SA. The Sequence Number is mandatory. It is always included in an ESP packet, to ensure alignment of the Payload field on an 8-byte boundary (in support of IPv6). Even if authentication is not selected as a security service for the SA, or if ESP is employed in an IPv4 environment, this field MUST be present. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Processing" section below). 2.3 Payload Data Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an IV, then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length and any structure for such data, as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC. 2.4 Padding (for Encryption) If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. Any encryption algorithm used with ESP that requires padding MUST define its padding requirements in an RFC specifying how the algorithm is used with ESP. The content of this field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. Padding also may be required, irrespective of algorithm requirements, Kent, Atkinson [Page 5] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) to ensure that the resulting ciphertext terminates on a 4-byte boundary, i.e., the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure. Finally, padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations MUST support generation and consumption of padding. 2.5 Pad Length The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that the byte immediately preceding the pad length field is the last byte of the payload. The Pad Length field is mandatory. 2.6 Next Header The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory. 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field depends upon the authentication function selected. The mandatory-to-implement authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit ICV's because of the truncation convention adopted for use in IPsec. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. 3. Encapsulating Security Protocol Processing 3.1 ESP Header Location Like AH, ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and Kent, Atkinson [Page 6] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) provides protection for upper layer protocols, but not the IP header. (In this mode, note that for "bump-in-the-stack" or "bump-in-the- wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (The "ESP trailer" encompasses any Padding, plus the Pad Length, and Next Header fields.) BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | TCP | Data | Trailer |Auth| ------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->| In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet. Kent, Atkinson [Page 7] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hxh,rtg,frag|dest|ESP|dest| | | ESP | ESP| |IP hdr|if present**|opt*|Hdr|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- |<---- encrypted ---->| |<---- authenticated ---->| * = if present, could be before AH, after AH, or both ** = hop by hop, routing, fragmentation headers Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. ----------------------------------------------------------- IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| ----------------------------------------------------------- |<--------- encrypted ---------->| |<----------- authenticated ---------->| --------------------------------------------------------------- IPv6 | new* | ext hdrs*| | orig*| ext hdrs*| | | ESP | ESP| |IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth| --------------------------------------------------------------- |<---------- encrypted ----------->| |<----------- authenticated ---------->| * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. Kent, Atkinson [Page 8] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) 3.2 Outbound Packet Processing In transport mode, the transmitter encapsulates the upper layer protocol information in the ESP header/trailer, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document. 3.2.1 Security Association Lookup ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document. 3.2.2 Sequence Number Generation As noted above, the Sequence Number field is always included in ESP packets, even if this service, or the authentication service, has not been enabled for the SA. The transmitter increments the Sequence Number for this SA, checks to ensure that the counter has not cycled, and inserts the new value into the Sequence Number field. A transmitter MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in sequence number overflow is an auditable event. 3.2.3 Packet Encryption 3.2.3.1 Scope of Encryption In transport mode, the transmitter encapsulates the original upper layer protocol information into the ESP payload field, adds any necessary padding, and encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, and algorithm mode indicated by the SA. In tunnel mode, the transmitter encapsulates and encrypts the the entire original IP datagram (plus the Padding, Pad Length, and Next Header). If authentication is selected, encryption is performed first, before the authentication, and the encryption does not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the Kent, Atkinson [Page 9] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV. 3.2.3.2 Encryption Algorithms The encryption algorithm employed is specified by the SA. ESP is designed for use with symmetric encryption algorithms. Because IP packets may arrive out of order, each packet must carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. At the time of writing, one mandatory-to-implement encryption algorithm and mode has been defined for ESP. It is based on the Data Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details of use of this mode are contained in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. 3.2.4 Integrity Check Value Calculation 3.2.4.1 Scope of Authentication Protection If authentication is selected for the SA, the transmitter computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is performed prior to authentication. 3.2.4.2 Authentication Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Kent, Atkinson [Page 10] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) 3.2.4.3 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are suitable. As of this writing, the mandatory-to-implement authentication algorithms are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated to (the leftmost) 96 bits. Other algorithms, possibly with different ICV lengths, MAY be supported. 3.2.5 Fragmentation If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments. 3.3 Inbound Packet Processing 3.3.1 Pre-ESP Processing Overview If required, reassembly is performed prior to ESP processing. 3.3.2 Security Association Lookup Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number and Authentication Data fields should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable). If no valid Security Association exists for this session (for example, the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this Kent, Atkinson [Page 11] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. 3.3.3 Sequence Number Verification All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single, multicast SA. Thus the anti-replay service SHOULD NOT be used in a multi-sender multicast environment that employs a single, multicast SA.) If an SA establishment protocol such as Oakley/ISAKMP is employed, then the receiver SHOULD notify the transmitter, during SA establishment, if the receiver will provide anti-replay protection and SHOULD inform the transmitter of the window size. If the receiver enables the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The default window size is 32 and all ESP implementations MUST support this window size. A larger window size MAY be established during SA negotiation. If a larger window size is negotiated it MUST be a multiple of 32. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST Kent, Atkinson [Page 12] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds. DISCUSSION: Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate packet before updating the Sequence Number window data. 3.3.4 Integrity Check Value Verification If authentication has been selected, the receiver computes the ICV over the ESP packet minus the Authentication Data using the specified authentication algorithm and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below. If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID. DISCUSSION: Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the received value. (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will be described in the algorithm specification.) 3.3.5 Packet Decryption The receiver decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the session key that has been established for this traffic. If an explicit IV is present in the Payload Field, it is input to the decryption algorithm as per the algorithm specification. Kent, Atkinson [Page 13] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) If an implicit IV is employed, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. (Decryption may take place in parallel with authentication, but care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet.) After decryption, the original IP datagram is reconstructed and processed per the normal IP protocol specification. The exact steps for reconstructing the original datagram depend on the mode (tunnel vs transport) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field. Note that there are two ways in which the decryption can "fail". The selected SA may not be correct or the encrypted ESP packet could be corrupted. (The latter case would be detected if authentication is selected for the SA, as would tampering with the SPI. However, an SA mismatch might still occur due to tampering with the IP Destination Address.) In either case, the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not necessarily be detected by IPsec, and is the responsibility of later protocol processing. 4. Auditing Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action. 5. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described Kent, Atkinson [Page 14] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the transmitter, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms (specified in [KBC97] and in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. - DES in CBC mode - HMAC with MD5 - HMAC with SHA-1 6. Security Considerations Security is central to the design of this protocol, and this security considerations permeate the specification. Additional security- relevant aspects of using IPsec protocol are discussed in the Security Architecture document. 7. Differences from RFC 1827 This document differs from RFC 1827 in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document. Kent, Atkinson [Page 15] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) Acknowledgements Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92 IB93]. For over 2 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank the members of the IPSEC and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive help in the review and editing of this version of the specification. References [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org. [DH95] Steve Deering & Robert Hinden, Internet Protocol Version 6 (Ipv6) Specification, RFC 1883, December 1995. [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993. [ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft, ?? 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, ?? 1997. [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: Kent, Atkinson [Page 16] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) Keyed-Hashing for Message Authentication", RFC-2104, February 1997. [Ken91] Steve Kent, "US DoD Security Options for the Internet Protocol (IPSO)", RFC-1108, November 1991. [MS95] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", RFC-1829, August 1995. [NIST77] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [NIST80] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [NIST81] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [NIST88] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [Riv92] Ronald Rivest, "The MD5 Message Digest Algorithm," RFC- 1321, April 1992. [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 October 1994. [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. Kent, Atkinson [Page 17] Internet Draft IP Encapsulating 30 May 1997 Security Payload (ESP) Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Author Information Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA E-mail: kent@bbn.com Telephone: +1 (617) 873-3988 Randall Atkinson @Home Network 385 Ravendale Drive Mountain View, CA 94043 USA E-mail: rja@inet.org Kent, Atkinson [Page 18] From owner-ipsec Sat May 31 09:18:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25545 for ipsec-outgoing; Sat, 31 May 1997 09:16:44 -0400 (EDT) Message-Id: <3.0.32.19970530171142.00b51320@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 30 May 1997 17:12:38 -0700 To: "William Allen Simpson" From: Bob Monsour Subject: Perplexed by padding values (was "padding values") Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, At 04:04 PM 5/24/97 GMT, William Allen Simpson wrote: >Remembering that you like to use the same technique in multiple venues, >I'll point out that these values are used in PPP DES encryption. In looking at RFC1969 (The PPP DES Encryption Protocol (DESE), 6/96), it refers to RFC1570 (PPP LCP Extension, 1/94) for the self-described padding option. Note that a more recent version, in draft-ietf-pppext-lcpext-ds-01.txt (11/96) provides a similar description of padding. In those specs, the padding values start at '1', not '0' as you proposed in your DES/3DES drafts. While there is no pad length field in those specs, am I missing something with respect to the reason that your recent DES/3DES drafts start the padding at zero rather than one? As an example, in DESE, 3 bytes of padding would be represented by padding values of 1, 2, 3. In your recent DES/3DES drafts, 3 bytes of padding would be represented by padding values of 0, 1, 2, followed by a pad length field of 3. Is it simply the relative elegance of a monotonically increasing values of padding leading up to the pad length byte? For those of us trying to implement somewhat flexible hardware to support a variety of security protocols, including padding options/modes, this kind of tweak matters. I propose that we do as DESE does and start with a value of '1' unless there is a compelling security argument to be made. Regards, -Bob At 04:04 PM 5/24/97 GMT, William Allen Simpson wrote: >On the differences in text on padding values: > >> From: Bob Monsour >> While I understand that you believe that it's important for the >> algorithm/transform documents to repeat certain field definitions from the >> base ESP document, in this case I find it couter-productive and prone to >> inducing errors. Let's take an example from from your DES draft >> (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft >> and RFC1829. It states: >> >> Padding zero or more octets. >> >> Prior to encryption, this field is filled with a >> series of integer values (beginning with zero), to >> align the Pad Length and Payload Type fields at the >> end of an eight octet boundary (counted from the >> beginning of the Payload Data). >> >> After decryption, it is examined for a valid series >> of integer values. >> >> This field is opaque. That is, the value is set >> prior to encryption, and is examined only after >> decryption. >> >Please read this in the context of the whole paper. See also: > >2.2. Decryption >... > The Pad Length is removed and examined. If pad checking is config- > ured, and the padding octets are not the correct values for the Pad > Length, then the payload is discarded, and the "Decryption Failed" > error is indicated [RFC-xxxx]. >... > >Operational Considerations >... > Pad Check > Some earlier implementations used random pad values. > > Default: Off. >... > >The default is off because of interoperability concerns. > > >> In the "new" ESP draft (section 2.5) padding is defined as follows: >> >> The Padding bytes SHOULD be initialized with random data and they are >> transmitted. The transmitter can add 0-255 bytes of padding. Padding >> beyond that required for encryption algorithm blocksize alignment may >> be used to conceal the actual length of the payload, in support of >> traffic flow confidentiality. However, inclusion of such additional >> padding has adverse bandwidth implications and thus its use should be >> undertaken with care. The Padding field is optional, but all >> implementations MUST support generation and consumption of padding. >> >The ESP draft is wrong. It has a scoping error. The description of >padding is to be left to the individual transforms. See the previous >notes to this list on the implementors' agreement. > >If this is not fixed in the next draft of ESP, I'm sure someone will >suggest a more specific change in wording. > > >> Lastly, RFC1829 states: >> >> Padding >> >> The size of this field is variable. >> >> Prior to encryption, it is filled with unspecified implementation >> dependent (preferably random) values, to align the Pad Length and >> Payload Type fields at an eight octet boundary. >> >> After decryption, it MUST be ignored. >> >> I don't understand how someone can write code to support the padding >> requirements that conform to RFC1829 or the "new" ESP and find that it will >> interoperate with code that is written to follow your new draft. An RFC1829 >> programmer will send the "preferably random" values in for padding and the >> implementor of your new draft will reject the incoming packet for lack of a >> "valid series of integer values". While you don't say exactly what to do in >> this case, it certainly leaves room for various interpretations (read that >> as potential interoperability problems). >> >Hopefully, not everyone will read only the first part of a draft, and >will actually follow and implement the draft in its entirety. > >The values were previously "implementation dependent", which was open to >various interpretations. > >The "preferably random" values turned out to be cryptographically wrong. > >At the request of the persons explicitly named in the Acknowledgements, >the "implementation dependent" values were changed to specified values. >This is not open to various interpretations. > >I realize that you are new to the list, and may have missed the earlier >debates. > >Remembering that you like to use the same technique in multiple venues, >I'll point out that these values are used in PPP DES encryption. And >that non-random values are also specified in RSA's PKCS. > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > > From owner-ipsec Sat May 31 09:21:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25579 for ipsec-outgoing; Sat, 31 May 1997 09:19:44 -0400 (EDT) Message-Id: <3.0.1.32.19970531092527.009531bc@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 31 May 1997 09:25:27 -0400 To: Karen Seo , ipsec@tis.com From: Matt Thomas Subject: Re: New draft -- IPSEC AH Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199705302208.SAA15535@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >3.2.3.1.2 ICV Computation for IPv6 > > In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed > prior to performing the ICV calculation. IPv6 options contain a bit > that indicates whether the option might change (unpredictably) during > transit. For any option for which contents may change en-route, the > entire "Option Data" field must be treated as zero-valued octets when > computing or verifying the ICV. The Option Type and Opt Data Len are > included in the ICV calculation. All other options are also included > in the ICV calculation. See the IPv6 specification [DH95] for more > information. I think that we need to exclude (e.g. treat as zero) the flow-label and priority/reserved bits as well, especially if they are allowed to be changed inflight. [Since the version field is constant I'd exclude that as well so the first 32 bits of the IPv6 header are treated as zeroes.] Comments? -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Sat May 31 16:59:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27541 for ipsec-outgoing; Sat, 31 May 1997 16:56:20 -0400 (EDT) Message-Id: <199705312102.RAA28136@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Steven Bellovin cc: ipsec@tis.com, "William Allen Simpson" , kent@bbn.com Subject: Re: eliminate AH -- unanimous In-reply-to: Your message of "Fri, 30 May 1997 15:27:12 EDT." <199705301927.PAA23446@raptor.research.att.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 31 May 1997 17:02:49 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Bellovin writes: > Ever since Bill posted his straw poll, I've been bothered by an > intuitive feeling that AH and encryptionless ESP were not equivalent. > This afternoon, I finally realized the crucial difference: AH can be > deleted or ignored in a context-independent way. Consider, for > example, a host that wishes to ignore authentication for the moment, or > a firewall that wants to look at port numbers, or a network traffic > monitor that wants to see what ports are being used. With AH, this is > easy -- skip the number of words denoted by the length field, plug in > the proper protocol id, and carry on. This can't be done with ESP > without knowledge of the security association. That was why we originally had the distinction when the current formats originated at the Toronto meeting. Perry