From owner-ipsec Tue Jul 1 07:46:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22738 for ipsec-outgoing; Tue, 1 Jul 1997 07:39:12 -0400 (EDT) Date: Mon, 30 Jun 1997 14:18:00 -0700 (PDT) From: Jim A Hoagland To: ipsec@tis.com cc: jhoagla@ideal.jf.intel.com, baiju@ideal.jf.intel.com Subject: ISAKMP SA negotiation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, As part of my research in formally specifying security policies for network connections, I am looking at ISAKMP and the negotiation of security associations. I have a question that I did not see addressed by the ISAKMP Internet Draft (2/21/97) or in the last few months archives of this mailing list, so I thought I'd pose it here. When, for a particular situation, multiple SA proposals are acceptable, how does one choose the one to use? This is how I see things. The initiator has a set of security policies which dictate what SA proposals to make for different contexts (i.e. certain types of connections). These proposals have a certain order of preference. Similarly, the responder have a set of policies for what proposals to accept in a particular context. Again, the responder has certain preferences for which it wants to be the outcome. Now a example to motivate the question. Site A wants to establish a connection with site B. Consulting its policies, it determines the SA proposals for the particular situation. There are 2 acceptable SAs, P1 and P2, with the preference being for P1. So, this is sent in P1, P2 order in an ISAKMP SA payload. Now, when site B receives the message, it consults its policies and determines what SAs are acceptable to it. It finds that both P1 and P2 are acceptable, but that P2 is preferred over P1. Knowing that site A prefers P1, which should site B choose to respond with? Thank you, Jim Hoagland |* James A. Hoagland *| |* Research Assistant, Computer Security Research Lab, UC Davis *| |* Grad. Tech. Intern, Internet Security, Intel Architecture Labs *| |* http://seclab.cs.ucdavis.edu/~hoagland/ *| From owner-ipsec Tue Jul 1 07:46:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22744 for ipsec-outgoing; Tue, 1 Jul 1997 07:40:11 -0400 (EDT) From: grant@letzlink.com Date: Mon, 30 Jun 1997 12:22:09 -0700 Message-Id: <199706301922.MAA06173@desertinn.nevwest.com> X-Advertisement: Visit http://www.iemmc.org for name removal information. To: grant@letzlink.com Subject: Let's Link Sender: owner-ipsec@ex.tis.com Precedence: bulk Let's consider linking! I invite you to visit Let's Link and add your site along with a brief description of your site content to our Internet Resource Center ... perhaps, our Let's Link & Links. Although, our "Add Your Link" service is FREE, we do ask you to reciprocate with a LINK at your site .... not required but highly appreciated. Our site visitation now exceeds 2,300 per/day! 25% Europe.... 70% North America... 5% Asia Regards, Frank Bertotti http://www.letzlink.com From owner-ipsec Tue Jul 1 08:37:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23078 for ipsec-outgoing; Tue, 1 Jul 1997 08:35:10 -0400 (EDT) Message-Id: <199707011238.IAA19672@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: jhoagla@ideal.jf.intel.com Cc: ipsec@tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Mary Quinn Subject: RE: ISAKMP SA negotiation Date: Tue, 01 Jul 1997 08:45:02 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id IAA23075 Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi Jim, >> >>Now, when site B receives the message, it consults its policies and >>determines what SAs are acceptable to it. It finds that both P1 and P2 >>are acceptable, but that P2 is preferred over P1. Knowing that site A >>prefers P1, which should site B choose to respond with? >> I have written an implementation of a policy data base/server. When resolving a list of proposals, the preferences of the initiator are honored. So in the above example, ISAKMP would use P1. Mary -----BEGIN PGP SIGNATURE----- Version: 2.9 iQCVAgUBM7j7yoqw4PUEyZEzAQHVOQP9HaumDr9vDSjPHptN2KMN4r62J5wlrR1M qV1fyn0CxJep7jArmrdEtSMQIgQ8b7vxlhWxdwOEt2UWCEZOWsJM6wG6tYyTJItz A/sQhhTjfRkVhFO8DwR2zYEwDWlqzkBaP+tp9g9Tz7KVyQu72QeKOFngUe21PAND YWfVSZPLZGA= =ljId -----END PGP SIGNATURE----- From owner-ipsec Tue Jul 1 10:57:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23957 for ipsec-outgoing; Tue, 1 Jul 1997 10:56:20 -0400 (EDT) Message-Id: <199707011503.IAA05572@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Mary Quinn Cc: jhoagla@ideal.jf.intel.com, ipsec@tis.com Subject: Re: ISAKMP SA negotiation In-Reply-To: Your message of "Tue, 01 Jul 1997 08:45:02 EDT." <199707011238.IAA19672@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Jul 1997 08:03:46 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Mary, >>Now, when site B receives the message, it consults its policies and >>determines what SAs are acceptable to it. It finds that both P1 and P2 >>are acceptable, but that P2 is preferred over P1. Knowing that site A >>prefers P1, which should site B choose to respond with? >> > > I have written an implementation of a policy data base/server. When > resolving a list of proposals, the preferences of the > initiator are honored. So in the above example, ISAKMP would use P1. That might be what you'd do but my implmementation chooses P2. In the example, B has his own policy priority settings; he wants P2 over P1. In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B would select P4. I never let someone else override my local policy. It was set like that for a reason. Dan. From owner-ipsec Tue Jul 1 11:18:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24096 for ipsec-outgoing; Tue, 1 Jul 1997 11:17:51 -0400 (EDT) Message-ID: From: Doug Scherbath To: "'ipsec@tis.com'" Subject: SA negotiation Date: Tue, 1 Jul 1997 11:26:48 -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@portal.ex.tis.com Precedence: bulk >>Hi Jim, >> >> >> >>Now, when site B receives the message, it consults its policies and >> >>determines what SAs are acceptable to it. It finds that both P1 and P2 >> >>are acceptable, but that P2 is preferred over P1. Knowing that site A >> >>prefers P1, which should site B choose to respond with? >> >> >> >>I have written an implementation of a policy data base/server. When resolving a list of proposals, the preferences of the >>initiator are honored. So in the above example, ISAKMP would use P1. >> >>Mary I disagree, if the Initiator makes more than one proposal, he is relinquishing control. If the proposer wants P1, he should only offer P1. If he will accept either then he must be prepared to have the responder choose. Another question on the subject: Key life duration... if the initiator proposal is identical to a responder policy except the key life associated with the entry is different eg. initiator proposes P1 (key life 100 seconds) and responder has a policy entry with key life of 150 seconds. I think even though the entries don't match, the responder should respond with 100 seconds (the more restrictive) Comments? From owner-ipsec Tue Jul 1 12:03:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24394 for ipsec-outgoing; Tue, 1 Jul 1997 12:01:52 -0400 (EDT) Message-Id: <199707011211.IAA11204@relay.hq.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: Daniel Harkins Date: Wed, 2 Jul 1997 05:07:17 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ISAKMP SA negotiation CC: jhoagla@ideal.jf.intel.com, ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Mary, > > >>Now, when site B receives the message, it consults its policies and > >>determines what SAs are acceptable to it. It finds that both P1 and P2 > >>are acceptable, but that P2 is preferred over P1. Knowing that site A > >>prefers P1, which should site B choose to respond with? > >> > > > > I have written an implementation of a policy data base/server. When > > resolving a list of proposals, the preferences of the > > initiator are honored. So in the above example, ISAKMP would use P1. > > That might be what you'd do but my implmementation chooses P2. In the > example, B has his own policy priority settings; he wants P2 over P1. > In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B > would select P4. I never let someone else override my local policy. It > was set like that for a reason. > > Dan. The above begs the question of who we believe the owner of the SA is and why they should be considered as the owner. Scenario: An initiators policy may require the initiator to dictate the confidentiality and integrity services applied to its messages - therefore the initiator should have its prioritisation respected. On the other hand the responder may want to dictate the authentication service on the message it will receive from the initiator then its policy dictates the it honours its prioritisation list. Since both initiator and responder policies agree that both SA's are acceptable do we have a problem ? Elfed **************************************************** Elfed T. Weaver Defence Evaluation & Research Agency Malvern UK weaver@hydra.dra.hmg.gb **************************************************** From owner-ipsec Tue Jul 1 13:51:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25265 for ipsec-outgoing; Tue, 1 Jul 1997 13:47:22 -0400 (EDT) Date: Tue, 1 Jul 1997 13:53:39 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199707011753.NAA07885@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: ISAKMP SA negotiation X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > That might be what you'd do but my implmementation chooses P2. In the > example, B has his own policy priority settings; he wants P2 over P1. > In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B > would select P4. I never let someone else override my local policy. It > was set like that for a reason. And what was that reason? :-) If A offered P1, you'd select P1. If A offered P2, you'd select P2. If A offered P3, you'd select P3. But if A offered P1,P2,P3,P4 you'd select P4. If all of the proposals are acceptable to your local policy, it's hard to make the argument that one is "more acceptable" than another, or that A's definition of "more acceptable" should be more or less valid than B's. One could document that one or the other behavior is required in this situation, but that wouldn't result in any greater interoperability than leaving it unspecified. I claim that it wouldn't result in "more security" either. From owner-ipsec Tue Jul 1 14:38:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25674 for ipsec-outgoing; Tue, 1 Jul 1997 14:34:21 -0400 (EDT) Message-Id: <199707011837.OAA24544@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: weaver@hydra.dra.hmg.gb, dharkins@cisco.com Cc: ipsec@tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Mary Quinn Subject: RE: ISAKMP SA negotiation Date: Tue, 01 Jul 1997 14:44:00 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA25671 Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>Reply to your message of 7/1/97 12:24 PM Dan and Elfred, Unless both machines are configured identically wrt policy, one of the machine's preferences is going to be violated. I don't see why it's better to violate the initiator's preference than to violate the receivers? >>Since both initiator and responder policies agree that both SA's are >>acceptable do we have a problem ? I don't think so. A machine should not be sending a policy configuration that it cannot support or tolerate. Mary -----BEGIN PGP SIGNATURE----- Version: 2.9 iQCVAgUBM7lP7Yqw4PUEyZEzAQE12gQAjKqt4qfMNbzQ7/xXeZz6tfWyvhCQztNR Xr0RswQ5e/GlIVqxS0jc/UNSaEkv9+kin5OcJskowpc+BsSOECrYeEYvVSpLchm0 FuFMLNCYQDlJR3w8zUxyMYT+phX72gfYaJy9pETIPLoDR9Zs60qTPFjFsMZ9MAbq alujWT4QcAc= =uVRh -----END PGP SIGNATURE----- From owner-ipsec Tue Jul 1 15:03:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25910 for ipsec-outgoing; Tue, 1 Jul 1997 15:01:22 -0400 (EDT) Date: Tue, 1 Jul 1997 12:00:59 -0800 From: Kevin Brock Subject: Re: ISAKMP SA negotiation To: "Elfed T. Weaver" , Daniel Harkins Cc: ipsec@tis.com, jhoagla@ideal.jf.intel.com X-Mailer: Z-Mail Pro 6.1 (Win32 - 021297), NetManage Inc. X-Priority: 3 (Normal) References: <199707011211.IAA11204@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 2 Jul 1997 05:07:17 +0000 "Elfed T. Weaver" wrote: > On Tue, 01 Jul 1997 08:03:46 -0700, Daniel Harkins wrote: > > That might be what you'd do but my implmementation chooses P2. In the > > example, B has his own policy priority settings; he wants P2 over P1. > > In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B > > would select P4. I never let someone else override my local policy. It > > was set like that for a reason. > > The above begs the question of who we believe the owner of the SA > is and why they should be considered as the owner. > > Scenario: > > An initiators policy may require the initiator to dictate the > confidentiality and integrity services applied to its messages - > therefore the initiator should have its prioritisation respected. > > On the other hand the responder may want to dictate the > authentication service on the message it will receive from the > initiator then its policy dictates the it honours its prioritisation > list. > > Since both initiator and responder policies agree that both SA's are > acceptable do we have a problem ? The problem with this is that the responder may want to enforce confidentiality on all messages in or out, regardless of the initiators preferences. Similarly for initiators and integrity. It's not that hard to envision situations where this is the case. If I'm offered a list of policies, I'm going to pick whichever one is most acceptable to my site, since, by offering me a list instead of a single choice, my peer has indicated that any of the offered choices are acceptable. If my list of policies was [P4,P2,P1,P3], the only time I would ever choose a policy other than P4 is if the other side didn't offer P4. Kevin Brock From owner-ipsec Wed Jul 2 12:31:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA03828 for ipsec-outgoing; Wed, 2 Jul 1997 12:26:01 -0400 (EDT) Message-Id: <3.0.1.32.19970702123233.009697b0@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: Wed, 02 Jul 1997 12:32:33 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: New IDs for workgroup Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted and I have completed an intense process of review of the current position of this workgroup and the creation of new IDs or the update of existing IDs to move us to closure. I have just instructed the authors of the following documents to submit them for publishing as IDs: draft-ietf-ipsec-Doc-Roadmap-00.txt draft-ietf-ipsec-auth-hmac-md5-96-00.txt * draft-ietf-ipsec-auth-hmac-sha-1-96-00.txt * draft-ietf-ipsec-ciph-des-derived-iv-00.txt draft-ietf-ipsec-ciph-des-explicit-iv-00.txt draft-ietf-ipsec-ciph-3des-derived-iv-00.txt (placeholder) draft-ietf-ipsec-ciph-cast-128-cbc-00.txt * draft-ietf-ipsec-ciph-rc5-cbc-00.txt * draft-ietf-ipsec-ciph-idea-00.txt draft-ietf-ipsec-ciph-blowfish-00.txt draft-ietf-ipsec-cbc-00.txt The following documents are at some state of readying for version updates (perhaps this week): The resolution of ISAKMP with Oakley The Internet IP Security Domain of Interpretation for ISAKMP IP Encapsulating Security Payload (ESP) IP Authentication Header This will be a lot of reading for all of you. As a degreed ecologist (along with CPS :), I admit that I have just killed an old growth douglas fir in the name of Internet Security :). But then I know how much so many of you like reading this stuff. For the new documents, when they come out in the next couple of days, read them carefully. The Document Roadmap is important glue. See if it helps you navigate between the various IPsec documents. The auth documents were designed to work for both AH and new ESP. See if they do, for you. The ciph documents were designed around a consistant outline that is in the Roadmap; see if you can transition from one to the next. There were 2 important areas where only very rough concensus was reached and it will be important for the workgroup to consider these. First off, we have come up with the terminology of derived and explicit IVs. There are 2 DES IDs, one working each way. The 3DES, is only derived, and my understanding is that all of the other ciphers use an explicit IV. Ted and I, along with the authors that feel strongly on this will construct the issues surrounding this. And we will see where it goes. Then there is the KEYMAT challenge, frequently called 'slicing and dicing'. I will know later today which document the strawman will show up in. There we two good proposals. One will end up in a document, I will see to it that the other gets posted to the list. As this is important for interoperable implementations, I expect that this can be resolved this month. The IPsec work group is made up of many individuals grouping into a few common interests. Everyone, please respect each other. Keep the discussion professional. And remember that the most effective argument is an alternate wording of a section of an ID. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Jul 2 15:15:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05019 for ipsec-outgoing; Wed, 2 Jul 1997 15:13:35 -0400 (EDT) Date: Wed, 2 Jul 1997 12:15:57 -0700 From: bishop@cs.ucdavis.edu (Matt Bishop) Message-Id: <199707021915.MAA20840@nob> To: ipsec@ans.net Subject: CFP: 1998 SNDSS (updated; last reminder!) Sender: owner-ipsec@ex.tis.com Precedence: bulk CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security Where: Catamaran Resort, San Diego, California When: March 11-13, 1998 GOAL: The symposium will foster information exchange between hardware and software developers of network and distributed system security services. The intended audience is those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. Encouraging and enabling the Internet community to apply, deploy, and advance the state of available security technology is the major focus of symposium. Symposium proceedings will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Architectures for large-scale, heterogeneous distributed systems * Security in malleable systems: mobile code, mobile agents, dynamic policy updates, etc. * Special problems: e.g. interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. * Integrating security services with system and application security facilities and with application protocols, including message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. * Fundamental services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification infrastructures, audit, and intrusion detection. * Telecommunications security, especially for emerging technologies -- very large systems like the Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Controls: firewalls, packet filters, application gateways * Object security and security objects * Network information resources and tools such as World Wide Web (WWW), Gopher, Archie, and WAIS. * Electronic commerce: payment services, fee-for-access, EDI, notary; endorsement, licensing, bonding, and other forms of assurance; intellectual property protections GENERAL CHAIR: David Balenson, Trusted Information Systems PROGRAM CHAIRS: Matt Bishop, University of California at Davis Steve Kent, BBN PROGRAM COMMITTEE: Steve Bellovin, AT&T Labs -- Research Doug Engert, Argonne National Laboratories Warwick Ford, VeriSign Li Gong, JavaSoft Rich Graveman, Bellcore Ari Juels, RSA Laboratories Tom Longstaff, CERT/CC Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Rich Parker, NATO Michael Roe, Cambridge University Rob Rosenthal, DARPA Wolfgang Schneider, GMD Darmstadt Christoph Schuba, Purdue University Win Treese, Open Market, Inc. Jonathan Trostle, Novell Gene Tsudik, USC/Information Sciences Institute Steve Welke, Institute for Defense Analyses LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses LOGISTICS CHAIR: Torryn Brazell, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals, for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by 1 August 1997, and should be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions should arrive well before 1 August. If electronic submission is difficult, submissions should be sent via postal mail. All submissions and program related correspondence (only) should be directed to the program chair: Matt Bishop, Department of Computer Science, University of California at Davis, Davis CA 95616-8562, Email: sndss98-submissions@cs.ucdavis.edu. Phone: +1 (916) 752-8060, FAX: +1 (916) 752-4767, Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/conferences/ndss98. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as in- dicated above. Authors and panelists will be notified of acceptance by 1 October 1997. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 1 November 1997. From owner-ipsec Thu Jul 3 12:31:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12482 for ipsec-outgoing; Thu, 3 Jul 1997 12:24:35 -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-ciph-rc5-cbc-00.txt Date: Thu, 03 Jul 1997 10:38:15 -0400 Message-ID: <9707031039.aa08439@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 RC5-CBC Algorithm Author(s) : R. Pereira, R. Baldwin Filename : draft-ietf-ipsec-ciph-rc5-cbc-00.txt Pages : 5 Date : 07/02/1997 This document describes the RC5 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-ciph-rc5-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-rc5-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-ciph-rc5-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: <19970703103402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-rc5-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-rc5-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970703103402.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jul 3 12:37:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12497 for ipsec-outgoing; Thu, 3 Jul 1997 12:29:08 -0400 (EDT) Message-Id: <3.0.1.32.19970703123337.00a3a430@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: Thu, 03 Jul 1997 12:33:37 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Re: New IDs for workgroup In-Reply-To: <3.0.1.32.19970702123233.009697b0@dilbert.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk More ciphers: draft-ietf-ipsec-ciph-desx-derived-iv-00.txt draft-ietf-ipsec-ciph-arcfour-00.txt And I did remember correctly that there was an 3DES, I had just lost my copy. That will be coming out. I should point out that some of the cipher documents are very short, and there is very little difference between the two auth documents. For now, their separateness should facilitate discussion/refinements. I suspect that a large number of these will all be done at the same time. Consider the value of publishing anthology RFCs. I can think of good reasons either way; I tend toward separate RFCs. Alternatively, we can follow the IANA MIME submission method, where most MIME types never come out as RFCs, rather they are published by IANA on their web site only and MIME programers have to know to go there. I have seen MIME definition papers longer than the ARCFOUR cipher document. Of course, there is probably two to three magnitude fewer ciphers than MIME types. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Jul 3 18:55:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14590 for ipsec-outgoing; Thu, 3 Jul 1997 18:55:06 -0400 (EDT) Date: Thu, 3 Jul 1997 19:02:52 -0400 Message-Id: <9707032302.AA09446@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: kent@bbn.com, kseo@bbn.com Cc: ipsec@tis.com Subject: [Steve Deering: state of IPsec specs] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I've received the following request from the chairs of the IPng working group. According to Ran Atkinson, who filled me in on some of the details, this had been discussed at the San Jose ipsec meeting in December, and there was general consensus to make this change. The IPng wg was apparently a little miffed that the discussion was happening in the ipsec wg instead of the ipng wg, but that jurisdictional tiff aside, there seems to be general consensus that this is a good thing to do. Apparently the ipng wg is thinking about allowing routers to make use of the 28 bits of the priority + flow label fields for some kind of fast tag switching or line switching applications, and so it would be useful if routers were allowed to change these fields while the packet is in flight. If someone needs a more thorough explanation, I suggest they contact someone in the ipng wg, since apparently these discussions are not yet completely reflected in the ipng documents, and I have not been actively tracking the ipng wg. - Ted ------- Forwarded Message X-Sender: deering@cheerios.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Jul 1997 11:33:31 -0700 To: Robert Moskowitz , "Ted T'so" From: Steve Deering Subject: state of IPsec specs Cc: hinden@ipsilon.com Bob and Ted, >From the chairs of IPng WG to the new chairs of IPsec WG: .... - The IPng WG decided in Memphis that we wish to exclude the first 32 bits of the IPv6 header (consisting of the Version, Priority, and Flow Label fields) from the authentication computation performed for the AH, so that they may be modified en route without breaking end-to-end authentication. This is a change from RFC 1826. We have heard conflicting reports about IPsec WG developments in this area, some saying that IPsec had already made on such a change (without consulting the IPng WG!), and others saying that no decision had been made yet. Could you please ensure that the desired change is made, or let us know why not? .... Bob and Steve ------- End Forwarded Message From owner-ipsec Thu Jul 3 20:32:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15004 for ipsec-outgoing; Thu, 3 Jul 1997 20:31:34 -0400 (EDT) Message-Id: <199707040036.UAA29790@raptor.research.att.com> To: "Theodore Y. Ts'o" cc: kent@bbn.com, kseo@bbn.com, ipsec@tis.com Subject: Re: [Steve Deering: state of IPsec specs] Date: Thu, 03 Jul 1997 20:36:21 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk The change would also be consistent with IPv4, where Precedence is excluded from AH. From owner-ipsec Thu Jul 3 23:29:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA15780 for ipsec-outgoing; Thu, 3 Jul 1997 23:28:37 -0400 (EDT) Date: Thu, 3 Jul 1997 23:36:30 -0400 Message-Id: <9707040336.AA09557@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Munich IETF meeting time Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk The IPSEC meeting at Munich has been scheduled for Friday at 0900, and it will be broadcast on the mbone. My apologies for the less-than-optimal time (for those who had been hoping to leave early), but other times would have created conflicts and there weren't other rooms large enough to accomodate our size group. - Ted From owner-ipsec Mon Jul 7 06:57:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA04630 for ipsec-outgoing; Mon, 7 Jul 1997 06:51:55 -0400 (EDT) Message-Id: <199707071101.OAA11743@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com, ipsec-dev@tis.com Subject: TTL and IPsec X-URL: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/ Date: Mon, 07 Jul 1997 14:01:05 +0300 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I'm going through some of our finer points of our implementation to get them all "correct" and I'm couldn't find any text to back a belief of mine up: An IPsec/VPN tunnel should consider itself to be a router, and decrement TTL, generating ICMP's as required. Should both ends consider themselves to be routers? I don't see anything in the documents that says this explicitely, but maybe I missed it. It also should say something to the effect that ICMP messages generated in response to a datagram that arrived via a tunnel should be sent back via the "same" tunnel. (e.g. in the outgoing SA of the SA bundle that makes up a "tunnel"). ] The sun rarely sets on Helsinki | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM8DMacmxxiPyUBAxAQHbvwL/XOynke40YOlbD/F+PsJYu4UYCb5K7vW0 2SFk8ty8bzqz8cn3rD6cFhl7Ko9ZaFQyIn9PHfm5dqGI8TSvz+fHwsmh69fUMJYl pZPZTDXE2MZRLmHizDIY3gwHzGL88X+7 =K1gE -----END PGP SIGNATURE----- From owner-ipsec Mon Jul 7 07:49:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA05125 for ipsec-outgoing; Mon, 7 Jul 1997 07:48:56 -0400 (EDT) Date: Thu, 03 Jul 97 14:31:00 PDT From: Jim Hoagland Message-ID: To: ipsec@tis.com Subject: RE: SA negotiation Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: Text Item This sounds reasonable to me. By sending multiple acceptable proposals, the initiator is giving the responder a choice of which to choose. The ISAKMP protocol, by indicating that the proposals are ordered by preference, merely conveys the initiators preferences to the responder. It is the responder's choice as to what proposal to choose, so it can choose whichever is more favorable. If there is more than one proposal that it equally likes the most, then it is being respectful for the responder to select the initiators more favorite one. There are a couple things that contribute to my point of view here: + the initiator (in general) has no way to know what the responder's policies and priorities are + a simple list of preferences does not convey how much the initiator prefers one proposal over another, even if there were some metric by which to compare initiators and responders preferences + if initiator can't trust the responder (the safe assumption), then it shouldn't send out a proposal that is not acceptable As for the key life duration negotiation issue, I agree that it makes since to go with the shorter-lived key proposal if the proposals only differ in the lifetime of the key. Given the number of possible lifetimes that can be suggested, what are the chances that initiator and responder come up with the same value? I don't know that answer, but it could be small. And going with the shorter lifetime is presumedly the more security alternative. Jim -----Original Message----- From: owner-ipsec@portal.ex.tis.com Sent: Tuesday, July 01, 1997 11:26 AM To: ipsec@tis.com Subject: SA negotiation I disagree, if the Initiator makes more than one proposal, he is relinquishing control. If the proposer wants P1, he should only offer P1. If he will accept either then he must be prepared to have the responder choose. Another question on the subject: Key life duration... if the initiator proposal is identical to a responder policy except the key life associated with the entry is different eg. initiator proposes P1 (key life 100 seconds) and responder has a policy entry with key life of 150 seconds. I think even though the entries don't match, the responder should respond with 100 seconds (the more restrictive) Comments? From owner-ipsec Mon Jul 7 07:49:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA05139 for ipsec-outgoing; Mon, 7 Jul 1997 07:49:25 -0400 (EDT) Date: Thu, 03 Jul 97 14:53:00 PDT From: Jim Hoagland Message-ID: To: ipsec@tis.com Subject: RE: ISAKMP SA negotiation Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: Text Item This does seem a bit strange. The initiator could just send out its favorite proposal and test for a response. The responder could wait until it sees its favorite proposal and perhaps accept a proposal it once rejected. If the initiator and the responder were being very competative and selfish, one could image the parties holding out on accepting proposals until it gets what it wants, playing a variant on the game of chicken. How would one prevent this? -----Original Message----- From: owner-ipsec@portal.ex.tis.com Sent: Tuesday, July 01, 1997 1:53 PM To: ipsec@tis.com Subject: Re: ISAKMP SA negotiation > That might be what you'd do but my implmementation chooses P2. In the > example, B has his own policy priority settings; he wants P2 over P1. > In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B > would select P4. I never let someone else override my local policy. It > was set like that for a reason. And what was that reason? :-) If A offered P1, you'd select P1. If A offered P2, you'd select P2. If A offered P3, you'd select P3. But if A offered P1,P2,P3,P4 you'd select P4. From owner-ipsec Mon Jul 7 09:24:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05729 for ipsec-outgoing; Mon, 7 Jul 1997 09:24:01 -0400 (EDT) Message-Id: <3.0.1.32.19970707092309.0068c0f0@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 07 Jul 1997 09:23:09 -0400 To: Jim Hoagland From: Rodney Thayer Subject: RE: ISAKMP SA negotiation 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 There is the implicit assumption that the two parties want to talk to each other... p.s. if you don't like the proposals you can generate traps ;-) At 02:53 PM 7/3/97 PDT, you wrote: > >Text item: Text Item > > >This does seem a bit strange. The initiator could just send out its favorite >proposal and test for a response. The responder could wait until it sees its >favorite proposal and perhaps accept a proposal it once rejected. If the >initiator and the responder were being very competative and selfish, one could >image the parties holding out on accepting proposals until it gets what it >wants, playing a variant on the game of chicken. How would one prevent this? > >-----Original Message----- >From: owner-ipsec@portal.ex.tis.com >Sent: Tuesday, July 01, 1997 1:53 PM >To: ipsec@tis.com >Subject: Re: ISAKMP SA negotiation > >> That might be what you'd do but my implmementation chooses P2. In the >> example, B has his own policy priority settings; he wants P2 over P1. >> In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B >> would select P4. I never let someone else override my local policy. It >> was set like that for a reason. > >And what was that reason? :-) > >If A offered P1, you'd select P1. >If A offered P2, you'd select P2. >If A offered P3, you'd select P3. >But if A offered P1,P2,P3,P4 you'd select P4. > > > > > From owner-ipsec Mon Jul 7 09:40:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05799 for ipsec-outgoing; Mon, 7 Jul 1997 09:40:01 -0400 (EDT) Message-Id: <3.0.1.32.19970707093520.006d23ac@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 07 Jul 1997 09:35:20 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: TTL and IPsec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I disagree that a tunnel endpoint should always decrement the TTL. If you're a client, and if you're near the edge of the TTL radius, you can drop things you shouldn't be dropping. Some people think that end systems that decrement the TTL too much are broken. Think about how you want 'traceroute' to look. TTL is going to get whacked out anyway, since the INNER IP header isn't going to have it's TTL decremented as the packet travels through the net. I bet someone with IP-over-IP experience has something to add to this... >To: ipsec@tis.com, ipsec-dev@tis.com >Subject: TTL and IPsec >X-URL: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/ >Date: Mon, 07 Jul 1997 14:01:05 +0300 >From: Michael Richardson >Sender: owner-ipsec@ex.tis.com > >-----BEGIN PGP SIGNED MESSAGE----- > > > I'm going through some of our finer points of our implementation to >get them all "correct" and I'm couldn't find any text to back a belief >of mine up: > > An IPsec/VPN tunnel should consider itself to be a router, and >decrement TTL, generating ICMP's as required. Should both ends >consider themselves to be routers? I don't see anything in the >documents that says this explicitely, but maybe I missed it. > It also should say something to the effect that ICMP messages >generated in response to a datagram that arrived via a tunnel should >be sent back via the "same" tunnel. (e.g. in the outgoing SA of the SA >bundle that makes up a "tunnel"). > >] The sun rarely sets on Helsinki | one quark [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ >] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ > > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3ia >Charset: latin1 >Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > >iQB1AwUBM8DMacmxxiPyUBAxAQHbvwL/XOynke40YOlbD/F+PsJYu4UYCb5K7vW0 >2SFk8ty8bzqz8cn3rD6cFhl7Ko9ZaFQyIn9PHfm5dqGI8TSvz+fHwsmh69fUMJYl >pZPZTDXE2MZRLmHizDIY3gwHzGL88X+7 >=K1gE >-----END PGP SIGNATURE----- > > From owner-ipsec Mon Jul 7 11:10:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06433 for ipsec-outgoing; Mon, 7 Jul 1997 11:10:04 -0400 (EDT) Message-Id: <199707071520.SAA12192@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: TTL and IPsec In-reply-to: Your message of "Mon, 07 Jul 1997 09:35:20 EDT." <3.0.1.32.19970707093520.006d23ac@pop3.pn.com> Date: Mon, 07 Jul 1997 18:20:34 +0300 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rodney" == Rodney Thayer writes: Rodney> I disagree that a tunnel endpoint should always decrement Rodney> the TTL. If you're a client, and if you're near the edge Rodney> of the TTL radius, you can drop things you shouldn't be Rodney> dropping. Some people think that end systems that Rodney> decrement the TTL too much are broken. Think about how Rodney> you want 'traceroute' to look. But, an end system doesn't forward the packet, so it shouldn't consider itself a router, and shouldn't decrement the TTL... Hmm. I can see that in the DataFellows implementation that this is going to have to be a flag since our engine does both client and gateway. Rodney> TTL is going to get whacked out anyway, since the INNER IP Rodney> header isn't going to have it's TTL decremented as the Rodney> packet travels through the net. I bet someone with Rodney> IP-over-IP experience has something to add to this... Yes, but there is nothing you can do about this. If you consider traceroute's usage, you want to see that the tunnel was a single hop. ] The sun rarely sets on Helsinki | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM8EJNMmxxiPyUBAxAQGNHQL9GzSwh6Wk6sgbQm5WzNhgt8mhBk+KiIQm ZUBSKgVRXQ2dHDO2F4UNCDy6MsrzaTRLeJWg5W2+Tj/NCwKsn4Nndi+VwVpfgjj7 6Utzm5NjqY0SnSDbswHMTORzBXrcqQjv =Cxdq -----END PGP SIGNATURE----- From owner-ipsec Mon Jul 7 11:45:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06628 for ipsec-outgoing; Mon, 7 Jul 1997 11:45:35 -0400 (EDT) Date: Mon, 7 Jul 1997 08:39:56 -0800 From: Kevin Brock Subject: Re: TTL and IPsec To: ipsec@tis.com, Rodney Thayer X-Mailer: Z-Mail Pro 6.1 (Win32 - 021297), NetManage Inc. X-Priority: 3 (Normal) References: <3.0.1.32.19970707093520.006d23ac@pop3.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 07 Jul 1997 09:35:20 -0400 wrote: > I disagree that a tunnel endpoint should always decrement the TTL. If > you're a client, and if you're near the edge of the TTL radius, you can > drop things you shouldn't be dropping. Some people think that end systems > that decrement the TTL too much are broken. Think about how you want > 'traceroute' to look. > > TTL is going to get whacked out anyway, since the INNER IP header isn't > going to have it's TTL decremented as the packet travels through the net. > I bet someone with IP-over-IP experience has something to add to this... I was just going over that RFC recently... According to that document (RFC2003): 1. The TTL of the inner IP is decremented by the encapsulator iff the datagram is being forwarded. 2. The TTL of the outer IP header is set according to the length of the tunnel, and is handled normally. 3. The TTL of the inner IP header is not decremented on decapsulation. 4. But, If the datagram is forwarded *after* decapsulation, the TTL is decremented. Since the tunnel can be thought of as a wire between the two endpoints, this makes perfect sense... Kevin Brock From owner-ipsec Mon Jul 7 13:11:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07225 for ipsec-outgoing; Mon, 7 Jul 1997 13:09:03 -0400 (EDT) Message-Id: <97Jul7.131011edt.11689@janus.tor.securecomputing.com> To: Kevin Brock cc: ipsec@tis.com, Rodney Thayer Subject: Re: TTL and IPsec References: <3.0.1.32.19970707093520.006d23ac@pop3.pn.com> In-reply-to: Your message of "Mon, 07 Jul 1997 12:39:56 -0400". From: "C. Harald Koch" Date: Mon, 7 Jul 1997 13:15:05 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > I was just going over that RFC recently... According to > that document (RFC2003): > > 1. The TTL of the inner IP is decremented by the encapsulator iff the > datagram is being forwarded. > 2. The TTL of the outer IP header is set according to the length of the > tunnel, and is handled normally. > 3. The TTL of the inner IP header is not decremented on decapsulation. > 4. But, If the datagram is forwarded *after* decapsulation, the TTL is > decremented. > > Since the tunnel can be thought of as a wire between the two endpoints, this > makes perfect sense... This treats an IPsec tunnel as a point-to-point link, as far as the inner IP packet is concerned. Makes perfect sense to me. Among other things, this makes the output of a traceroute through a tunnel 'look' right ... -- Harald Koch From owner-ipsec Mon Jul 7 15:23:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08117 for ipsec-outgoing; Mon, 7 Jul 1997 15:22:12 -0400 (EDT) Message-Id: <3.0.32.19970707122915.009a6370@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 07 Jul 1997 12:29:16 -0700 To: ipsec@tis.com From: John Burke Subject: Clarification on ISAKMP Informational Exchange Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk We've come up with these questions as we beef up Notify and Delete in our implementation, and I give answers that seem logical to me; could an authoritative voice please say what's required on these points? Can a Notification or Delete Payload appear other than in an Informational Exchange? Apparently not, because ISAKMP states that an exchange prescribes all the messages and all the payloads which are allowed, and none of the exchanges prescribe that Notify or Delete may appear within them. Most particularly: if you want to Notify for failure in Phase I, apparently you should make a new Informational Exchange with Message ID zero. Can one send/receive an unencrypted Informational Exchange? Apparently so, for Phase I, since Notifications are explicitly allowed for the earliest Phase I failures. Can a Phase I Informational Exchange be encrypted? Apparently so, since one could after the Keys have been exchanged. But it seems it is not required at that point, because the spec only demands protection for an Informational Exchange after a Phase I SA has been fully established. Note that if the Initiator doesn't like the Responder's message which sends KE in Phase I, the Initiator would send an unencrypted Notify but the Responder might believe the message must be discarded for not being encrypted, because it has established keys. [A smarter Responder would know at this point that key establishment is still provisional pending getting anything positive from the other.] Must a party make a new exchange: new cookies, and new message ID if applicable, for every different time it needs to send an informational message? New message ID (for Phase II): sure, it won't kill me. But, why bother, what's the point? New cookies: I presume no; It would raise difficulties, and be counterproductive, to put any new cookie in the message, because the cookie would not relate to anything the receiver has, and cannot be checked in any way. It seems to be demanded, but the justification stated is problematic, in "2.5.3 Anti-Clogging Token (``Cookie'') Creation": The details of cookie generation are implementation dependent, but MUST satisfy these basic requirements (originally stated by Phil Karn in [Karn]): [ . . . ] ISAKMP requires that the cookie be unique for each SA establishment, Notify, and SA Delete to help prevent replay attacks, therefore, the date and time MUST be added to the information hashed. Problem is: it claims new cookies will protect a Notify or Delete sent in an Informational Exchange. But how can it, since the one who receives the message has not sent a new cookie and so cannot verify the sender's liveliness? From owner-ipsec Mon Jul 7 17:25:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA09042 for ipsec-outgoing; Mon, 7 Jul 1997 17:24:14 -0400 (EDT) Message-Id: <3.0.32.19970707143003.009a5e40@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 07 Jul 1997 14:30:04 -0700 To: ipsec@tis.com From: John Burke Subject: Clarification on ISAKMP Commit-Bit Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk We would like a little authoritative clarification on the use of the Commit bit. I understand from the draft that support for receiving Commit is required in all the Session Establishment exchanges. We see reason to use Commit in all exchanges, as I discuss below. Also some quick questions. Question: I suppose it's correct to set the Commit bit on only the final message I send. Question: I suppose I can ignore a Commit bit in all messages received except the final one. Presumption: I presume it's wrong for me to set the Commit bit in an exchange where I am not going to send the final message, and the other end could give me "invalid flags". Now, the question that bears discussion: The ISAKMP draft is vague about exactly why anyone might choose to set the Commit bit, and permissive about when one could expect it. As I remember in discussion on this point on this mail list, a couple of individuals expressed their particular reason for finding Commit useful, and some seemed to be suggesting that there is no other reasonable use, implying I suppose that one need not support it in other exchanges? As best I remember, people put forth a scenario somewhat like this (don't have the original so can't vouch for accuracy): o In Aggressive Mode, the Initiator receives the first response, which includes KE; at this point Initiator can complete generating the ISAKMP SA session keys. o Initiator makes the final message, with Hash; it does not want this message encrypted. It sends the message out the socket to the kernel. o Initiator wants to stuff the keys down the PF Keys socket; the result of this will be the kernel will start encrypting for the ID pair. BUT: the daemon cannot find out whether the enqueued Hash message has gotten to IP output yet, so it cannot tell when it's okay to stuff in the keys. o By setting Commit, the Initiator demands the Notify from the Responder, and can wait for it before stuffing the keys. But I saw another consideration making Commit useful, and it makes sense in all the session establishment Exchanges: o The party who sends the last message of the exchange, would like assurance the final message arrives and is accepted. This can apply to all the exchanges: to Initiator in Quick or Aggressive mode and to Responder in Main Mode. In all cases it is possible that the first traffic to go out after the exchange is complete, can originate with the party who sent the final exchange message. Without this assurance, the sender of the final message can perform encryption on the message to follow and wind up throwing it down a hole because the other didn't get the final message and cannot complete the SA; recovery from this is a dirty business. o If the sender of the final exchange message sets Commit, then there will be positive assurance the final message arrived and the SA is established on both sides. The sender now has a basis to time out and retransmit the final message. If the Notify(Connected) gets lost but the Responder sends encrypted data right after it, the Initiator system has these choices: o Retransmit the final message, AND/OR: o Recognize that the SA is already (provisionally) established; if the message can be authenticated, then mark the SA as fully established. - John Burke From owner-ipsec Tue Jul 8 14:06:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15829 for ipsec-outgoing; Tue, 8 Jul 1997 13:57:04 -0400 (EDT) Message-ID: <01BC8B8E.CA7DF300.baiju@mailbox.jf.intel.com> From: "Baiju V. Patel" Reply-To: "baiju@mailbox.jf.intel.com" To: "'Rodney Thayer'" , "'Jim Hoagland'" Cc: "'ipsec@tis.com'" Subject: RE: ISAKMP SA negotiation Date: Tue, 8 Jul 1997 11:04:36 -0700 Organization: Intel X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Sender: owner-ipsec@ex.tis.com Precedence: bulk Playing the game of chicken is some what tricky for the responder. Moreover, it is a matter of policies on the responder (over which the initiator has no control) as to which proposal to accept. The fact that the initiator specified multiple proposal indicates that all of them are acceptable. If the responder plays "game of chicken" and the initiator is "honest to god" simple implementation, responder may end up not having secure communication at all. One can argue that the responder can initiate ISAKMP and thus will not loose opportunity to communicate as outlined by me above. However, this too is a matter of policy on the original initiator. I can see that some initiators may have a policy that they will always initiate security association (e.g., client in a client server paradigm or a firewall). Nothing stops initiator from trying multiple policies to get as "strict" acceptance of its policies (unless the responder is keeping track of denied SA negotiations and mistakes a initiator for someone launching denial of service attack). So, one can implement mechanisms that be guard against such "game of chicken" behavior up to an extent (I don't think there a perfect solution here). Baiju On Monday, July 07, 1997 6:23 AM, Rodney Thayer [SMTP:rodney@sabletech.com] wrote: > There is the implicit assumption that the two parties want to talk to each > other... > > p.s. if you don't like the proposals you can generate traps ;-) > > At 02:53 PM 7/3/97 PDT, you wrote: > > > >Text item: Text Item > > > > > >This does seem a bit strange. The initiator could just send out its favorite > >proposal and test for a response. The responder could wait until it sees its > >favorite proposal and perhaps accept a proposal it once rejected. If the > >initiator and the responder were being very competative and selfish, one > could > >image the parties holding out on accepting proposals until it gets what it > >wants, playing a variant on the game of chicken. How would one prevent this? > > > >-----Original Message----- > >From: owner-ipsec@portal.ex.tis.com > >Sent: Tuesday, July 01, 1997 1:53 PM > >To: ipsec@tis.com > >Subject: Re: ISAKMP SA negotiation > > > >> That might be what you'd do but my implmementation chooses P2. In the > >> example, B has his own policy priority settings; he wants P2 over P1. > >> In fact, if A offered P1, P2, P3, P4 and B wanted P4, P2, P1, P3, B > >> would select P4. I never let someone else override my local policy. It > >> was set like that for a reason. > > > >And what was that reason? :-) > > > >If A offered P1, you'd select P1. > >If A offered P2, you'd select P2. > >If A offered P3, you'd select P3. > >But if A offered P1,P2,P3,P4 you'd select P4. > > > > > > > > > > From owner-ipsec Tue Jul 8 14:36:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16062 for ipsec-outgoing; Tue, 8 Jul 1997 14:35:06 -0400 (EDT) Message-Id: <3.0.1.32.19970708143018.03230138@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 08 Jul 1997 14:30:18 -0400 To: "baiju@mailbox.jf.intel.com" From: Rodney Thayer Subject: RE: ISAKMP SA negotiation Cc: ipsec@tis.com In-Reply-To: <01BC8B8E.CA7DF300.baiju@mailbox.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:04 AM 7/8/97 -0700, you wrote: >If the responder plays "game of chicken" and the initiator >is "honest to god" simple implementation, responder may >end up not having secure communication at all. Exactly. And, depending on how the responder implements it's policy (decisions on when to use IPsec) and network management (decisions on when to tell whom that connectivity was or was not achieved) someone should notice this and fix it. From owner-ipsec Tue Jul 8 16:36:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17112 for ipsec-outgoing; Tue, 8 Jul 1997 16:34:48 -0400 (EDT) From: Barney Wolff To: ipsec@tis.com Date: Tue, 8 Jul 1997 16:35 EDT Subject: ISAKMP performance Content-Type: text/plain Message-ID: <33c2a4fe0.346c@databus.databus.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk The issue of ISAKMP performance has come up on the l2tp list, with a claim that the Diffie-Hellman negotiation takes too long to be viable when a box comes up after a failure. Does anyone have any figures on this, or a URL? Thanks, Barney Wolff From owner-ipsec Tue Jul 8 17:34:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17557 for ipsec-outgoing; Tue, 8 Jul 1997 17:33:54 -0400 (EDT) Message-Id: <199707082141.RAA08927@coredump.cis.upenn.edu> To: Barney Wolff cc: ipsec@tis.com Subject: Re: ISAKMP performance In-reply-to: Your message of "Tue, 08 Jul 1997 16:35:00 EDT." <33c2a4fe0.346c@databus.databus.com> Date: Tue, 08 Jul 1997 17:41:52 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <33c2a4fe0.346c@databus.databus.com>, Barney Wolff writes: >The issue of ISAKMP performance has come up on the l2tp list, with >a claim that the Diffie-Hellman negotiation takes too long to be >viable when a box comes up after a failure. Does anyone have any >figures on this, or a URL? The DH itself is not a big issue (although, if you have to re-establish 200 SAs...), but factor in the hashes/RSA signatures/DES encryption/lookups (files and/or DNS), and it adds up to quite a few seconds. My implementation (which did NOT do RSA signatures, but static key authentication) took anywhere between 7 to 12 seconds on a lightly loaded P120 (with *no* network delays) to establish an SA (that is, establish an ISAKMP SA and then an IPsec SA). Subsequent IPsec SAs took about 3 seconds. Take these numbers with a grain of salt, as i wasn't exactly doing any real measurements. As a comparison, Photuris draft-8 *with* RSA signatures took 5 seconds (on a P90, too!); i didn't get to implement the SPI_UPDATE messages back then, so i don't know what the cost of additional SAs would be (but presumably less than 5 seconds). All of the above are with an optimized (i'm told) maths library (GMP), but no hardware assistance for DES/MD5/SHA1. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM8K0H70pBjh2h1kFAQHfkQP+PAbqz2m79NLYT6h5SYac2sUSPsrty5iX wcOJvMsUB/eDVN1g0E/N9lIOPDhrNYdocJuNQZ6nJpSVAOxm8uYZE75NxUKWJpMF BDNPYTcoeFAvOrMgCJJeQEus4DX7NLxftMbpbarS+hdexBRnSPf7tuBS9ZZX/I3m VxBBuFMrYe4= =qz3e -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 9 13:17:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24350 for ipsec-outgoing; Wed, 9 Jul 1997 13:11:08 -0400 (EDT) Message-Id: <199707091719.UAA18527@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: returning ICMP messages X-URL: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/ Date: Wed, 09 Jul 1997 20:19:02 +0300 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Consider the following situation: company1 company2 A---Gw1----Gw2---E <*VPN**> Now assume that the VPN SA is a A<->E only SA. (e.g. ANX Simple test #3, see ... oops page fault finding ANX list archives). Okay, so things have high latency on this setup for some reason, and somewhat smart user on A does: traceroute E Gw1 sees that TTL = 1 on the about to be tunnelled packet, and generates an ICMP message. Traceroute increments the TTL, and then Gw2 sees that TTL=1 on a packet about to be forwarded and generates an ICMP to A. Gw2 is very smart, and makes sure that, despite whatever filters it has to establish what policy to apply packets, when generating ICMP's it should really reverse the SA's that were used to get that packet, and apply them. [i.e. Gw2 uses the existing VPN tunnel to get the ICMP back] Now, Gw1, being under very clear instructions about who at company2 may send packets to A, decrypts the packet from Gw2, realizes that it violates the policy on the SA it arrived on, drops the packet and does: vpn_partner_is_violating_policy[gw2]++ and perhaps refuses to talk to gw2 after it reaches some threshold. What can we do? Gw1 could realize that if gw2 wanted to send spoofed packets, it could spoof them as E anyway, so we might as well accept packets from gw2. Okay, now what about: company1 company2 A---Gw1----Gw2-----Gw3-----E <*VPN*> <*VPN*> So, the sequence is now: A--->E TTL=1 A<--Gw1 A--->E TTL=2 A<--Gw2 [Gw2 is okay, because Gw1 has an SA with it] A--->E TTL=3 A<--Gw3 OOPS! Gw1 doesn't know who Gw3. Is this a realistic scenario? I think it might be. Imagine that Gw3 is a portable bump-in-the-cord encryptor providing road-warrior services to notebook E, and that the SA between Gw1<->Gw2 could even be generally permissive about company1<->company2 packets. Some of Gw3's IP addresses might even be dynamically assigned. Since the encrypted packet came from the PPP interface, it might be reasonable to send the ICMP back with the src address set to that interface's address. The wire between Gw3 and E might be included in the SA from Gw1/Gw2, so using the destination interface's address in the ICMP might be more productive. Should Gw3 and Gw1 negotiate their own SA? They might be able to do that in the road-warrior case. If Gw3 was actually a bump-in-the-stack or host based tunnel there is no problem, since the packet isn't forwarded, so TTL isn't decremented. We might just forget about making traceroute work, but perhaps the TCP people have something to say about be unable to receive source quench messages, or the advantages of having prompt unreachable messages? (unlike some PC stacks...) So, my recommendation: 1. send ICMP with the source address set to the destination interface, rather than the one on which the tunneled packet was received. Now, what happens when the destination is another tunnel? What do current routers do? The router requirements doc (RFC1812) says: 4.3.2.4 ICMP Message Source Address Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted. If the interface has no IP addresses associated with it, the router's router-id (see Section [5.2.5]) is used instead. [Strangely, 5.2.5 is not about the router-id, section 2.2.7 is] Also, section 4.2.2.2 says: Routers are called upon to insert their address into Record Route, Strict Source and Record Route, Loose Source and Record Route, or Timestamp Options. When a router inserts its address into such an option, it MUST use the IP address of the logical interface on which the packet is being sent. Where this rule cannot be obeyed because the output interface has no IP address (i.e., is an unnumbered interface), the router MUST instead insert its router-id. The router's router-id is one of the router's IP addresses. The Router ID may be specified on a system basis or on a per-link basis. Which of the router's addresses is used as the router-id MUST NOT change (even across reboots) unless changed by the network manager. Relevant management changes include reconfiguration of the router such that the IP address used as the router-id ceases to be one of the router's IP addresses. Routers with multiple unnumbered interfaces MAY have multiple router-id's. Each unnumbered interface MUST be associated with a particular router-id. This association MUST NOT change (even across reboots) without reconfiguration of the router. DISCUSSION This specification does not allow for routers that do not have at least one IP address. We do not view this as a serious limitation, since a router needs an IP address to meet the manageability requirements of Chapter [8] even if the router is connected only to point-to-point links. IMPLEMENTATION One possible method of choosing the router-id that fulfills this requirement is to use the numerically smallest (or greatest) IP address (treating the address as a 32-bit integer) that is assigned to the router. ....... So, this would seem to answer the question about what source IP to use. The recommendation could then be amended to say that the "router-id" must be used when negotiating the SA, and therefore it becomes an acceptable address that can appear in *any* SA. So, filter code had better know about this. ] The sun rarely sets on Helsinki | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM8PH9smxxiPyUBAxAQGFYwL9Gag2yapy6r/NIwJHdvjCgPs4itJB2QUB mlAqteZ7mDiNJRDvSJZsYxco9PARi68yULcKu2ah71KtgGztqCnNneSujRnDnFZq THpQvor9FJlehKYzgYY3g9afvEPh7nqg =ktYU -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 9 14:42:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24869 for ipsec-outgoing; Wed, 9 Jul 1997 14:38:40 -0400 (EDT) Message-Id: <199707091846.OAA00256@coredump.cis.upenn.edu> To: ipsec@tis.com Subject: SPI orthogonality Date: Wed, 09 Jul 1997 14:46:17 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I believe this has not been answered (not "officially" anyway): are the SPI-spaces for AH and ESP orthogonal or not ? Meaning: are the SAs identified by tuples (SPI/Remote Address) or by (SPI/Remote Address/Protocol), where Protocol = {AH, ESP} ? - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM8Pceb0pBjh2h1kFAQGi8AP/RZ7nQci1Me2bvG+XZ8KN9rKG+6ZJqrbU Yfb8IEXNQLZw81XIMydywju+FIjodSZRs6GkDZ8HwB8h/HuPE6KoW+cfGhDCzVIW 1dgeXmerOZvC+vA0Wos5+ty9WAu1Dre91CszDDh7TPETRgjLNnmPfiQMlBsDtn+r Rg+UyWU/MpU= =MajO -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 9 14:58:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25082 for ipsec-outgoing; Wed, 9 Jul 1997 14:57:40 -0400 (EDT) Date: Wed, 9 Jul 1997 14:57:51 -0400 (EDT) Message-Id: <199707091857.OAA09672@carp.morningstar.com> From: Ben Rogers To: "Angelos D. Keromytis" Cc: ipsec@tis.com Subject: SPI orthogonality In-Reply-To: <199707091846.OAA00256@coredump.cis.upenn.edu> References: <199707091846.OAA00256@coredump.cis.upenn.edu> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos D. Keromytis writes: > -----BEGIN PGP SIGNED MESSAGE----- > > > I believe this has not been answered (not "officially" anyway): are > the SPI-spaces for AH and ESP orthogonal or not ? Meaning: are the SAs > identified by tuples (SPI/Remote Address) or by (SPI/Remote > Address/Protocol), where Protocol = {AH, ESP} ? > - -Angelos The last time I asked this question, it was as a result of inconsistencies between the IPsec and ISAKMP drafts. The response was that the IPsec draft was in error (and would be modified). SA's are indexed by SPI/Remote Address/Protocol triplets. ben From owner-ipsec Wed Jul 9 16:07:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25517 for ipsec-outgoing; Wed, 9 Jul 1997 16:06:44 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707092014.NAA16741@kebe.eng.sun.com> Subject: Re: SPI orthogonality To: ben@Ascend.COM Date: Wed, 9 Jul 1997 13:14:18 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199707091857.OAA09672@carp.morningstar.com> from "Ben Rogers" at Jul 9, 97 02:57:51 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 > > are the SAs > > identified by tuples (SPI/Remote Address) or by (SPI/Remote > > Address/Protocol), where Protocol = {AH, ESP} ? > > - -Angelos > > The response was that the IPsec draft was in error (and would be modified). > SA's are indexed by SPI/Remote Address/Protocol triplets. > > ben Yes, Ben is right. You can have an ESP SA while having an AH SA also with . Dan From owner-ipsec Wed Jul 9 16:07:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25523 for ipsec-outgoing; Wed, 9 Jul 1997 16:07:13 -0400 (EDT) Message-Id: <3.0.1.32.19970709160900.006b79bc@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 09 Jul 1997 16:09:00 -0400 To: "Angelos D. Keromytis" From: Rodney Thayer Subject: Re: SPI orthogonality Cc: ipsec@tis.com In-Reply-To: <199707091846.OAA00256@coredump.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- It was defined in the most recent Architecture draft. Page 6 of draft ietf-ipsec-arch-sec-01.txt. If you don't have a copy (it flushed out of the draft sites about three weeks ago) I'll post a URL. I believe a new one is on it's way. At 02:46 PM 7/9/97 EDT, you wrote: >I believe this has not been answered (not "officially" anyway): are >the SPI-spaces for AH and ESP orthogonal or not ? Meaning: are the SAs >identified by tuples (SPI/Remote Address) or by (SPI/Remote >Address/Protocol), where Protocol = {AH, ESP} ? >- -Angelos -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBM8Pv0MKmlvJNktGxAQEbgAQAqygmPg/ymOyqMsvtcQJp3IcoP1U3NKto HQcqcTkwHkPkDZ565QyCF6ktzx9+iOLvD2uooEQKc0aEiGvh/pknEyoU5NHtgNLb 6uHYzjgZeJ/2hc2yJXbmwNyDtH0Jx9TDmLN9kSunFW2cvD+aAz2Ul4oJD9Zw4UI5 3EiHAjv9eXU= =CH2u -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 9 17:03:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25883 for ipsec-outgoing; Wed, 9 Jul 1997 17:02:46 -0400 (EDT) Date: Wed, 9 Jul 97 20:34:21 GMT From: "William Allen Simpson" Message-ID: <6219.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: SPI orthogonality Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Ben Rogers > Angelos D. Keromytis writes: > > I believe this has not been answered (not "officially" anyway): are > > the SPI-spaces for AH and ESP orthogonal or not ? Meaning: are the SAs > > identified by tuples (SPI/Remote Address) or by (SPI/Remote > > Address/Protocol), where Protocol = {AH, ESP} ? > > The last time I asked this question, it was as a result of > inconsistencies between the IPsec and ISAKMP drafts. The response was > that the IPsec draft was in error (and would be modified). SA's are > indexed by SPI/Remote Address/Protocol triplets. > I agree. We resolved this point several years ago, but the Kent drafts are dense and unclear. Needs paragraphs and formatting. There are a few other semantic problems with the Kent draft. The SPI is not the same as a "SAID". The SPI identifies the "parameters" for the ESP "transform", not the Security Association itself. (The Security Association is identified by, for example, the Cookie pairs in Photuris or Oakley). I proposed the following change to the ESP SPI wording: 2.1. Security Parameters Index (SPI) The SPI is a 32-bit (4 byte) unsigned value identifying the Security Association parameters for the ESP transform. The value is relative to the IP Destination in the preceding IP Header of the datagram. The use of this value is orthogonal to usage of similar values by other related security protocols, such as the Authentication Header (AH). That is, the same value MAY be used by multiple protocols to concurrently indicate different Security Association parameters. The value zero indicates that no Security Association has been estab- lished, and is primarily used for testing. Values in the range 1 through 255 are reserved to the Internet Assigned Numbers Authority (IANA) for future use. A reserved SPI value will not normally be assigned by IANA unless the specification is openly available and documented in the RFC publication series. Values in the range 256 through 65535 are reserved for manual config- uration. Remaining values are utilized by automated Security Association man- agement. These values are recommended to be generated by a crypto- graphically random method, to protect against replay attacks and traffic analysis. This field is mandatory and transparent. That is, the field is always present, and the value is not concealed by encryption. 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 Jul 9 18:51:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26482 for ipsec-outgoing; Wed, 9 Jul 1997 18:49:46 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199707091846.OAA00256@coredump.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 9 Jul 1997 18:57:29 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: SPI orthogonality Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben and Rodney are right; SPIs are per security protocol, as well as per destination. We received no requests for changes to this text in the last round of I-D reviews. The text, essentially identical for both both AH and ESP, describes SPIs as follows: 2.X 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 AH/ESP implementation for local debugging purposes, but no AH/ESP packets should be transmitted with a zero SPI value.) The SPI field is mandatory. I'm not sure what Bill finds "unclear" in this description, but I leave it to the WG co-chairs to judge. His text does provide more details re SPI numeric ranges. However, that material was not present in the ESP of transform RFCs, or previous ESP drafts. I don't recall receiving Bill's "proposed" text as a response to any of the ESP I-Ds that have been published, so it was not included in the most recent ESP revisions. I also don't understand Bill's explanation of the difference between an SAID and an SPI, since an SA is identified by the SPI (in context). Bill's examples of Cookie pairs as the way an SA is defined, in the context of specific key management protocols, does not clarify the difference for me, and it would have to be generalized to encompass SAs that are manuallly keyed. This seems largely a moot issue, since the term "SAID" does not appear anywhere in the AH, ESP nor Arch Doc I-Ds. Steve From owner-ipsec Wed Jul 9 19:47:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA26872 for ipsec-outgoing; Wed, 9 Jul 1997 19:47:14 -0400 (EDT) Message-Id: <199707092354.QAA14009@pita.cisco.com> To: ben@Ascend.COM (Ben Rogers) cc: "Angelos D. Keromytis" , ipsec@tis.com Subject: Re: SPI orthogonality In-reply-to: Your message of "Wed, 09 Jul 1997 14:57:51 EDT." <199707091857.OAA09672@carp.morningstar.com> Date: Wed, 09 Jul 1997 16:54:13 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk >The last time I asked this question, it was as a result of >inconsistencies between the IPsec and ISAKMP drafts. The response was >that the IPsec draft was in error (and would be modified). SA's are >indexed by SPI/Remote Address/Protocol triplets. That is correct. FWIW though, I also know of several implementations that treat the SPI-space as a single namespace and I do not believe that there are any operational problems with doing so. I defy an outside observer to determine whether this is or is not the case... Derrell From owner-ipsec Thu Jul 10 08:06:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00815 for ipsec-outgoing; Thu, 10 Jul 1997 08:03:45 -0400 (EDT) Message-Id: <2.2.32.19970710120717.0073ea98@csmes.ncsl.nist.gov> X-Sender: frankel@csmes.ncsl.nist.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 08:07:17 -0400 To: Stephen Kent From: Sheila Frankel Subject: Re: SPI orthogonality Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >Ben and Rodney are right; SPIs are per security protocol, as well as per >destination. We received no requests for changes to this text in the last >round of I-D reviews. The text, essentially identical for both both AH and >ESP, describes SPIs as follows: > >2.X 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. This does seem to require separate SPI spaces for AH and ESP. However, that is not made clear in the Architecture document. The latest architecture draft that I've seen (draft-ietf-ipsec-arch-sec-01.txt) from Nov. 96, says (p. 6): "The combination of a given SPI and Destination Address uniquely identifies a particular Security Association. ... A single IPsec Security Association is a simplex connection with which either AH or ESP is employed." This means that an SA can only cover either AH or ESP, but not both. However, a single SPI space for both AH and ESP would appear to satisfy the requirements as set forth in the Architecture Draft. Since the Architecture Draft touches on this issue, it should do so in a totally unambiguous manner, for example: The combination of a given SPI, Destination Address, and Security Protocol (AH or ESP) uniquely identifies a particular "Security Association." The definition of SPI (p. 2 of the Architecture Draft) should also be changed. From owner-ipsec Thu Jul 10 09:16:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01326 for ipsec-outgoing; Thu, 10 Jul 1997 09:15:13 -0400 (EDT) Message-Id: <3.0.1.32.19970710092035.00862100@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 10 Jul 1997 09:20:35 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: SPI orthogonality - two comments In-Reply-To: <199707092354.QAA14009@pita.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk When we get to the stage of obscure boundry condition testing "for conformance" this will become interesting. Someone will come up with the following argument: "If SPI -n- is valid for ESP, and I send you a packet on SPI -n- that's an AH packet, and you fail to send me back a "Protocol Unreachable" ICMP message, you are in error." I'm not saying they are correct, I'm expecting some kind of test jig to make this sort of claim. This is in fact a good problem to look forward to, because it will only happen after we get the documents stabilized. But right now and, for the sake of argument, for the next 3-12 months, I believe you are right. At 04:54 PM 7/9/97 -0700, Derrell Piper wrote: >>The last time I asked this question, it was as a result of >>inconsistencies between the IPsec and ISAKMP drafts. The response was >>that the IPsec draft was in error (and would be modified). SA's are >>indexed by SPI/Remote Address/Protocol triplets. > >That is correct. FWIW though, I also know of several implementations that >treat the SPI-space as a single namespace and I do not believe that there >are any operational problems with doing so. I defy an outside observer to >determine whether this is or is not the case... From owner-ipsec Thu Jul 10 09:34:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01441 for ipsec-outgoing; Thu, 10 Jul 1997 09:34:15 -0400 (EDT) Date: Thu, 10 Jul 97 13:25:22 GMT From: "William Allen Simpson" Message-ID: <6222.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: SPI orthogonality Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > I'm not sure what Bill finds "unclear" in this description, but I leave it > to the WG co-chairs to judge. The WG co-chairs? What have they to do with this? 5 WG members already have expressed dissatisfaction with your text. Therefore, on its face, it must be unclear. I provided clear and unambiguous text. Use it. > I also don't understand Bill's explanation of the difference between an > SAID and an SPI, since an SA is identified by the SPI (in context). Wrong! I defined the name, acronym, and original SPI semantics. Don't try to twist my words. A Security Association is between parties. A KMP establishes security associations. The SPI is an indicator of a one-way list of parameters. It is specific to a protocol and a destination. There is no relation between SPIs in different directions, or even a requirement that SPIs come in pairs. The term SA implies such a relation. > Bill's > examples of Cookie pairs as the way an SA is defined, in the context of > specific key management protocols, does not clarify the difference for me, > and it would have to be generalized to encompass SAs that are manuallly > keyed. This seems largely a moot issue, since the term "SAID" does not > appear anywhere in the AH, ESP nor Arch Doc I-Ds. > The problem is that your text changes the semantics to those of a SAID (not that "SAID" is mentioned), which we _rejected_ many years ago (after what seemed like decades of argument on what trust relationship the SAID implies). Again, your understanding is incorrect. There is no problem with generalizing. The "act" of establishing manual keys encompasses SAs. 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 Jul 10 09:59:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01627 for ipsec-outgoing; Thu, 10 Jul 1997 09:58:51 -0400 (EDT) Date: Thu, 10 Jul 97 13:40:52 GMT From: "William Allen Simpson" Message-ID: <6223.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Padding Sender: owner-ipsec@ex.tis.com Precedence: bulk While I'm thinking about it, at least 4 WG members asked that the default padding be changed to be well-known, and 2 asked that it be the same Self-Describing-Padding that PPP is using. Yet, Kent's ESP text does not reflect the requests. I find Kent's text dense and difficult to understand, without such minor editorial devices as a single topic per paragraph and transitional sentences. Also, he misused the latin abbreviations "e.g." and "i.e.". Why use them at all, when the spelled out versions are just as many typed characters? This isn't calligraphy. Better yet, use the English. Here is a replacement: 2.4. Padding If a cipher algorithm requires the plaintext to be a multiple of some number of bytes (such as the block size of a block cipher), the Padding field is used to fill the plaintext to the size required by the algorithm. All implementations MUST support generation and consumption of such padding. In addition, padding MAY be used to conceal the actual length of the plaintext. However, inclusion of such additional padding has adverse bandwidth implications, and thus its use should be undertaken with care. Finally, when the Authenticator field is present, padding also may be required to ensure that the resulting ciphertext terminates on a 32-bit (4 byte) boundary. Prior to encryption, this field is filled with a series of integer values, to align the Pad Length and Payload Type fields at the end of the required boundary (measured from the beginning of the Transform Data). By default, each byte contains the index of that byte. For example, three pad bytes would contain the values 1, 2, 3. After decryption, this field MAY be examined for a valid series of integer values. Verification of the sequence of values is at the discretion of the receiver. This field is optional and opaque. That is, the value (when present) is set prior to encryption, and is examined only after decryption. 2.5. Pad Length The Pad Length (1 byte) indicates the amount of Padding immediately preceding it. It does not include the Pad Length and Payload Type fields. The range of valid values is 0 through 255. A value of zero indi- cates that no Padding is present. This field is mandatory and opaque. That is, the value is set prior to encryption, and is examined only after decryption. 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 Jul 10 10:06:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01681 for ipsec-outgoing; Thu, 10 Jul 1997 10:06:46 -0400 (EDT) Content-Type: Multipart/Mixed; Boundary="NextPart" 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-simpson-photuris-schemes-02.txt Date: Thu, 10 Jul 1997 09:41:36 -0400 Message-ID: <9707100941.aa07162@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 : Photuris: Extended Schemes and Attributes Author(s) : P. Karn, W. Simpson Filename : draft-simpson-photuris-schemes-02.txt Pages : 13 Date : 07/09/1997 Photuris is a session-key management protocol. Extensible Exchange Schemes are provided to enable future implementation changes without affecting the basic protocol. Additional authentication attributes are included for use with the IP Authentication Header (AH). Additional confidentiality attributes are included for use with the IP Encapsulating Security Protocol (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-photuris-schemes-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-schemes-02.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-photuris-schemes-02.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: <19970709164436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-photuris-schemes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-photuris-schemes-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970709164436.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jul 10 10:10:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01702 for ipsec-outgoing; Thu, 10 Jul 1997 10:09:50 -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-simpson-photuris-13.txt Date: Thu, 10 Jul 1997 09:41:25 -0400 Message-ID: <9707100941.aa07116@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 : Photuris: Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-simpson-photuris-13.txt Pages : 72 Date : 07/09/1997 Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms. 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-photuris-13.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-13.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-photuris-13.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: <19970709120347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-photuris-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-photuris-13.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970709120347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jul 10 10:46:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA02076 for ipsec-outgoing; Thu, 10 Jul 1997 10:45:51 -0400 (EDT) Date: Thu, 10 Jul 97 14:13:45 GMT From: "William Allen Simpson" Message-ID: <6224.wsimpson@greendragon.com> To: ipsec@tis.com Subject: ESP Introduction Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > I also don't understand Bill's explanation of the difference between an > SAID and an SPI, since an SA is identified by the SPI (in context). As I noted, this latter assumption is in error. Unfortunately, Kent's lack of understanding lead to a significant problem with the ESP terminology used throughout. For example, in the introduction, s/he writes: 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 Since the SPI is destination based, and does not imply a particular sender (especially in a multicast environment) or Security Association, "data origin authentication" is not provided by ESP. Technically, "data origin authentication" requires a long term key, usually verified in the form of a signature. It is a term normally reserved for applications such as email. ESP is defined for ephemeral keys. Again, "data origin authentication" is not provided by ESP. As I've noted before on this list, Internet Protocols do not provide "connectionless" anything. Perhaps Kent meant to use the technical term "datagram". Most of us would simply say "data integrity". In any case, the integrity can either be provided by the cipher or the independent authenticator algorithms, and should not be listed as a special "feature" of ESP. We argued this long ago. I remember a very critical Rogaway draft. Indeed, after defining it as a separate ESP feature, Kent consolidates it under "authentication" in the remainder of the draft. The term "gateway" is incorrect (obsolete term for "router") or limiting (as in application gateway). Inexplicably, the _useful_ RFC-1827 "Overview" is entirely missing. The RFC-1827 "Requirements Terminology" is missing, and should be RFC-2116. The RFC-1827 "Key Management" information is missing, although some of that belonged in the Architecture. The RFC-1827 "transform" language is missing. **** And, Kent has refused to incorporate the WG consensus that **** **** authentication-only should use AH, not ESP. **** In all, I found over a dozen errors in the Introduction alone. I won't bore you with all of them. **** Most egregious is that it is missing critical information **** **** from RFC-1827: the IP Next Header/Protocol number :-(. **** Here is a replacement: 1. Introduction The Encapsulating Security Payload (ESP) provides confidentiality for IP datagrams by encrypting the payload data to be protected. Depend- ing on the user's security requirements, either an upper protocol- layer segment (such as TCP or UDP) is encrypted (transport-mode), or an entire IP datagram is encrypted and tunneled to the destination (tunnel-mode). To work properly without changing the entire Internet infrastructure (particularly non-participating routers), ESP is placed within a datagram having unencrypted IP headers. The information in the unen- crypted IP headers is used to route the protected datagram. For more details about ESP in various network environments, see "Security Architecture for the Internet Protocol" [RFC-1825x]. That document provides important background for this specification, such as an explanation of Security Associations, forms of Security Associ- ation management, guidelines on transport and tunnel modes of opera- tion, and interaction between ESP and the Authentication Header (AH) [RFC-1826x]. ESP may optionally provide authentication and integrity. Users desiring authentication and/or integrity without confidentiality should use AH instead of ESP. ESP may also provide a form of anti-replay service, depending upon the selection of integrity. The enforcement of replay protection is solely at the discretion of the receiver. Security services can be provided between: - a pair of single user hosts, - a single user host and a security firewall router, or - a pair of firewall routers. In the latter case, together with the tunnel mode of encapsulation, ESP may provide traffic flow confidentiality. Traffic aggregation at the firewalls may be able to mask source to destination patterns of the protected internal users. In this document, the key words "MAY", "MUST", "optional", "recom- mended", "required", "SHOULD", and "SHOULD NOT", are to be inter- preted as described in [RFC-2119]. 1.1. Performance Use of this specification will increase the protocol processing costs in participating systems, and will also increase the communications latency. The increased latency is primarily due to time required for encryption and decryption of each datagram. This can be very time intensive to implement. 1.2. Construction ESP may appear as the final payload header. The header immediately preceding the ESP Header will always contain the value 50 (0x32) in its Next Header (Protocol) field. <-- Transparent --> <-- Opaque --> +-----------+-----------------+--------------+--------------+ | IP Header | other headers | ESP Header | ESP Data | +-----------+-----------------+--------------+--------------+ The Encapsulating Security Payload has two components. The transparent ESP Header consists of the unencrypted field(s) of the payload. The transparent field(s) of the unencrypted ESP Header inform the intended recipient how to properly process the opaque data. The opaque ESP Data consists of protected fields for the ESP trans- form(s). 1.3. Transforms Cipher and authenticator algorithms, and the precise format of opaque ESP data associated with them, are known as "ESP transforms". It is intended that the ESP format should be sufficiently general to permit the specification of new transforms as new cryptographic algorithms are developed. The parameter description requirements for companion transform docu- ments are described in [RoadMap]. When the optional authenticator transform requires a separate key, that key is generated after any cipher keys. 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 Jul 10 10:53:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA02191 for ipsec-outgoing; Thu, 10 Jul 1997 10:53:22 -0400 (EDT) Date: Thu, 10 Jul 1997 11:01:22 -0400 Message-Id: <199707101501.LAA25310@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent Cc: ipsec@tis.com In-Reply-To: Stephen Kent's message of Wed, 9 Jul 1997 18:57:29 -0400, Subject: Re: SPI orthogonality Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I think the main problem is one of terminology. To quote the SPI text: >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. This statement, while technically correct (the last clause is critical), is perhaps confusing to some in the case where a datagram has both AH and ESP applied to it. Suppose host A exchanges keying material with host B, and then uses said keying material to protect datagrams using both AH and ESP ---- how many security associations are there between host A and host B? Are there one, or are there two? If you answer that there is only one security association, then the first part of the above definition can be confusing --- because there are two SPI's, one for AH and one for ESP. I believe this is the crux of Bill's compliant. - Ted From owner-ipsec Thu Jul 10 11:26:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02416 for ipsec-outgoing; Thu, 10 Jul 1997 11:26:20 -0400 (EDT) Date: Thu, 10 Jul 1997 11:26:20 -0400 (EDT) Message-Id: <199707101526.LAA02416@portal.ex.tis.com> From: Ben Rogers Reply-To: ben@Ascend.COM (Ben Rogers) To: ipsec@tis.com Subject: Re: SPI orthogonality In-Reply-To: <199707092354.QAA14009@pita.cisco.com> References: <199707091857.OAA09672@carp.morningstar.com> <199707092354.QAA14009@pita.cisco.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell Piper writes: > >The last time I asked this question, it was as a result of > >inconsistencies between the IPsec and ISAKMP drafts. The response was > >that the IPsec draft was in error (and would be modified). SA's are > >indexed by SPI/Remote Address/Protocol triplets. > > That is correct. FWIW though, I also know of several implementations that > treat the SPI-space as a single namespace and I do not believe that there > are any operational problems with doing so. I defy an outside observer to > determine whether this is or is not the case... > > Derrell I'd guess that the problem lies in the fact that if my machine has a single SPI-space, and a remote machine proposes AH and ESP SA's with the same SPI (via SA management), I am unable to accept both of those SA's. (Note that these will both be indexed by SPI/Remote Addr, and since there is not a third index field, we will have a collision.) It seems that this is just a touch on the undesirable side. :) ben From owner-ipsec Thu Jul 10 12:05:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02659 for ipsec-outgoing; Thu, 10 Jul 1997 12:04:22 -0400 (EDT) Message-Id: <199707101612.JAA11739@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ben@Ascend.COM (Ben Rogers) Cc: ipsec@tis.com Subject: Re: SPI orthogonality In-Reply-To: Your message of "Thu, 10 Jul 1997 11:26:20 EDT." <199707101526.LAA02416@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 09:12:19 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben Rogers write: > Derrell Piper writes: > > >The last time I asked this question, it was as a result of > > >inconsistencies between the IPsec and ISAKMP drafts. The response was > > >that the IPsec draft was in error (and would be modified). SA's are > > >indexed by SPI/Remote Address/Protocol triplets. > > > > That is correct. FWIW though, I also know of several implementations that > > treat the SPI-space as a single namespace and I do not believe that there > > are any operational problems with doing so. I defy an outside observer to > > determine whether this is or is not the case... > > > > Derrell > > I'd guess that the problem lies in the fact that if my machine has a > single SPI-space, and a remote machine proposes AH and ESP SA's with the > same SPI (via SA management), I am unable to accept both of those SA's. > (Note that these will both be indexed by SPI/Remote Addr, and since > there is not a third index field, we will have a collision.) > > It seems that this is just a touch on the undesirable side. :) You manage your own namespace. If an implementation does what Derrell suggests (right or wrong) there shouldn't be a problem accepting SPIs from a peer that does not. You tell me how you want me to talk to you. Provided the SPI is less than 255 I don't care how you arrived at its value-- one monolithic namespace or not. As long as each peer manage its own namespace correctly there isn't a problem. Dan. From owner-ipsec Thu Jul 10 12:55:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02894 for ipsec-outgoing; Thu, 10 Jul 1997 12:54:51 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2.2.32.19970710120717.0073ea98@csmes.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 12:54:10 -0400 To: Sheila Frankel From: Stephen Kent Subject: Re: SPI orthogonality Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Shelia, The architecture I-D is very much out of date and is undergoing extensive revision. We'll make sure that the new arch doc is consistent with the SPI definition that appears in the AH and ESP specs. Steve From owner-ipsec Thu Jul 10 14:30:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03423 for ipsec-outgoing; Thu, 10 Jul 1997 14:29:53 -0400 (EDT) Message-ID: <33C52A77.5935@itd.nrl.navy.mil> Date: Thu, 10 Jul 1997 11:31:19 -0700 From: Randall Atkinson Organization: The Internet X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: SPI orthogonality References: <199707092354.QAA14009@pita.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > FWIW though, I also know of several implementations that > treat the SPI-space as a single namespace and I do not believe > that there are any operational problems with doing so. IF the destination address is a unicast IP address AND the node assigns its own SPIs, then I do not believe there will be an interoperability problem. My (possibly outdated or faulty) recollection is that while a destination node normally assigns its own SPI values, this is not a strict requirement of the IPsec specifications. So that assumption is probably not a safe one to make. One could easily imagine using a KDC (e.g. Kerberos) to distribute IPsec SAs and having that KDC allocate SPIs on behalf of the nodes using that KDC. In such a KDC situation, the second prerequisite would not hold and interoperability problems would result from an implementation treating the "SPI space as a single namespace". In some situations, it is _desirable_ for a KDC to be able to assign SPIs on behalf of its clients. Hence, mandating that each node assign its own SPI values seems unduly restrictive. Further, ESP and AH were intentionally designed to be independent of the key management protocol in use. For example, Photuris is rumoured to have an implementation now. Kerberos is easily extended to support IPsec. Other key management techniques (e.g. ANSI's KM protocol) are likely to also be used in some environments. IF the destination address is a multicast IP address (implicitly this means there is more than one member of the IP multicast group), then the receiving node generally is not the node assigning the SPIs for that destination address. This means that the second property (top) does not hold for multicast destination addresses. Hence, interoperability problems will result from an implementation treating the "SPI space as a single namespace". > I defy an outside observer to determine whether this is or is not > the case... I think I have outlined several specific situations where an outside observer _can_ determine whether a particular implementation supports separate SPI spaces. I would urge that implementers not currently conforming with this aspect of the IPsec specifications reconsider this portion of their implementation because of the interoperability issues that it causes. Best wishes, Ran rja@inet.org From owner-ipsec Thu Jul 10 14:31:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03465 for ipsec-outgoing; Thu, 10 Jul 1997 14:31:53 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707101839.LAA23255@kebe.eng.sun.com> Subject: Re: SPI orthogonality To: piper@cisco.com (Derrell Piper) Date: Thu, 10 Jul 1997 11:39:56 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199707092354.QAA14009@pita.cisco.com> from "Derrell Piper" at Jul 9, 97 04:54:13 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 > FWIW though, I also know of several implementations that > treat the SPI-space as a single namespace and I do not believe that there > are any operational problems with doing so. I defy an outside observer to > determine whether this is or is not the case... Two words: Manual Keying The aforementioned implementations might choke on the legitimate manual adds of: add esp 0x2112 224.0.0.1 .... add ah 0x2112 224.0.0.1 .... Though quite honestly, the proliferation of ISAKMP/Oakley I'm seeing both here and on ANX-Sec suggest that in a real operational environment, Derrell's challenge will go unmet for the very reasons Dan H. suggests in another note on this list already! Glad we made sure we're clear on the question. Dan McD. From owner-ipsec Thu Jul 10 14:56:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03636 for ipsec-outgoing; Thu, 10 Jul 1997 14:53:52 -0400 (EDT) Message-ID: <33C530A1.2989@itd.nrl.navy.mil> Date: Thu, 10 Jul 1997 11:57:37 -0700 From: Randall Atkinson Organization: The Internet X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: ipsec@tis.com Subject: Re: SPI orthogonality References: <199707101501.LAA25310@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o wrote: > > I think the main problem is one of terminology. > To quote the SPI text: > % 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. > > This statement, while technically correct (the last clause is > critical), is perhaps confusing to some in the case where a > datagram has both AH and ESP applied to it. Suppose host A > exchanges keying material with host B, and then uses said > keying material to protect datagrams using both AH and ESP > ---- how many security associations are there between > host A and host B? Are there one, or are there two? > > If you answer that there is only one security association, then the > first part of the above definition can be confusing --- because there > are two SPI's, one for AH and one for ESP. My answer is (and the historical intent has been): Let an IP session exist between nodes A and B. Let that session use both AH and ESP for protection. Then one has two separate IPsec Security Associations; one for AH and a different one for ESP. The combination of (SPI, Destination Address, {AH XOR ESP}) uniquely identifies an IPsec Security Association. Note that this does NOT preclude the operational practice of creating the AH and ESP SAs at the same time using a single KM process. It also does not mean that a particular implementation cannot choose to _internally_ handle those SAs as a pair. However, it also does not require that an implementation handle them as a pair or create them at the same time using a single KM process. > I believe this is the crux of Bill's compliant. Bill's terminology for "SA" and "SPI" as used in recent messages to this list appears to be unique to him. His terminology is not identical to the historical intent of the IPsec document author or with the formal definition of an IPsec Security Association in the existing RFCs (whose clarity is admittedly suboptimal due to historical factors). I beg to differ with Bill's assertion that he defined the semantics for the "SPI". For good or ill, the semantics were defined in the RFCs (1825-1827) -- Bill was neither author nor editor for those RFCs. Bill did suggest the term "SPI" -- to help with the sociological issue that some folks familiar with SP3/ISO-NLSP occasionally associated semantics unique to those protocols to ESP/AH. I have not seen any recent notes whose author appeared to be associating SP3/ISO-NLSP semantics with the IPsec protocols, though I think the term SPI should be retained for consistency. I believe that the current text on SAs and SPIs from Steve Kent is largely very reasonable (and generally an improvement on the original RFCs). I think it might be helpful for Steve's text to be slightly revised (1) to note the reasons why it matters that an implementation support separate SPI spaces for AH and ESP {a separate note from me this morning outlined the technical issues on that topic, but my words would benefit from editorial help from Steve Kent & Co}. Ted's suggestion (2) that the spec define the term "Security Association" in slightly more crisp language also seems sensible to me {Perhaps an informative sentence or two outlining the example situation that Ted outlines above would suffice}. Regards, Ran rja@inet.org From owner-ipsec Thu Jul 10 15:10:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03804 for ipsec-outgoing; Thu, 10 Jul 1997 15:10:23 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199707101501.LAA25310@dcl.MIT.EDU> References: Stephen Kent's message of Wed, 9 Jul 1997 18:57:29 -0400, Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 14:50:28 -0400 To: "Theodore Y. Ts'o" From: Stephen Kent Subject: Re: SPI orthogonality Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, The Architecture RFC (1825) was not clear on this point, and it might be interpreted to accommodate both AH and ESP use in a single SA. However, in section 1.5 of the most recently published architecture I-D (November, 1996) Ran answers the question clearly with the following text: "A single IPsec Security Association is a simplex (unidirectional) connection with which either AH or ESP (but not both) is employed. If both AH and ESP protection is to be applied to a traffic stream, then two (or more) security associations are created to control processing of the traffic stream." So, I have been working under the assumption that this was not an open question and thus the SPI text was not ambiguous. Steve From owner-ipsec Thu Jul 10 16:11:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04238 for ipsec-outgoing; Thu, 10 Jul 1997 16:09:53 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6224.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 16:11:40 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: ESP Introduction Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You continued, though belated, inputs to the document editing process are appreciated. However, gratituous assults on my competence with respect to network security are unsubstantiated, as well as unwarranted. >Unfortunately, Kent's lack of understanding lead to a significant >problem with the ESP terminology used throughout. > >For example, in the introduction, s/he writes: > > 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 > >Since the SPI is destination based, and does not imply a particular >sender (especially in a multicast environment) or Security Association, >"data origin authentication" is not provided by ESP. > >Technically, "data origin authentication" requires a long term key, >usually verified in the form of a signature. It is a term normally >reserved for applications such as email. ESP is defined for ephemeral >keys. Again, "data origin authentication" is not provided by ESP. Data origin authentication is an appropriate way to describe the service offered by AH or ESP, even in the multicast context. The difference is the granularity of the authentication provided. If an SA is bound to a specific IP address, protocol, and port, (or to a user ID on a host), then the granularity of authentication is rather fine grained. If traffic from multiple sources in a corporate network environment is muxed into a single SA then the authentication granularity is coarse, but authentication is still being provided. While it is true that a long term key often is involved as a basis for DOA, signatures are in no way needed, e.g., KDC-based systems like Kerberos provide DAO based on a long-term symmetric key, which is used to bootstrap to a TGT, etc. The fact that a key used with ESP may be ephemeral is irrelevant to the question of whether DOA is provided. The literature citations I provided earlier, as well as others, support this characterization >As I've noted before on this list, Internet Protocols do not provide >"connectionless" anything. Perhaps Kent meant to use the technical term >"datagram". Most of us would simply say "data integrity". > >In any case, the integrity can either be provided by the cipher or the >independent authenticator algorithms, and should not be listed as a >special "feature" of ESP. We argued this long ago. I remember a very >critical Rogaway draft. Indeed, after defining it as a separate ESP >feature, Kent consolidates it under "authentication" in the remainder of >the draft. Although integrity is technically a separate service from authentication, one is rarely provided absent the other. If one doesn't know the origin of a packet, but claims that it is integrity protected, this is a rather odd security guarantee in most circumstances. Similarly, to say that a packet is definately from some source, but to not know if it has been modified en route is not very useful. Thus we often use the terms integrity and authenticity in combination in describing the features offered by a given mechanism. Technically, the mechanisms used in AH or ESP provide integrity, and it is the management of the keys used in the computation that afford authenticity, at some granularity. An encryption algorithm, per se, does not provide a basis for determining the integrity (or authenticity) of received data. Only the inclusion of predictable, redundant information in the data allows for such determination. If one wants to be quite precise, an encryption process may provide support for a separate mechanism that determines the integrity of the received data. >The term "gateway" is incorrect (obsolete term for "router") or limiting >(as in application gateway). I retained the term "security gateway" in deference to Ran's use of the term in the RFCs and the arch I-Ds, but I'm quite willing to adopt other terminology if the WG deems it appropriate. Routers acting as firewalls are good candidates for IPSEC implementations, but then so are firewalls that are not acting as routers. Inline IPSEC devices, analogous tothe network security products produced by Semaphore and Motorola for several years, are not routers, nor are they firewalls with IPSEC-based VPN features added in. That's why I thought that Ran's use of the term "secruity gateway," when defined for this context, was an appropriately neutral term. >Inexplicably, the _useful_ RFC-1827 "Overview" is entirely missing. The >RFC-1827 "Requirements Terminology" is missing, and should be RFC-2116.The >>RFC-1827 "Key Management" information is missing, although some of >that belonged in the Architecture. The RFC-1827 "transform" language is >missing. The terminology discussion was removed from AH and ESP some time ago, and no complaints were received. A suitable glossary will appear as an appendix in the architecture document, as will the key management discussion. The term "transform" was retired when we moved from trivial base documents and a combinatorially expanding set of transform documents, to more comprehensive base documents accompanied by documents that describe how to employ an individual algorithm in the context of AH or ESP. The allowed combinations of algorithms are defined elsewhere, e.g., in terms of the ISAKMP negitiated attributes. **** Most egregious is that it is missing critical information **** **** from RFC-1827: the IP Next Header/Protocol number :-(. **** Well, Bill, you got me there! Somewhere along the way we dropped this important datam and you are the first person to point that out. We'll certainly amend the text to specify the protocol values for Ah and ESP, in the respecvtive documents. As for the remainder of your proposed text, we'll be working with the co-chairs to resolve any outstanding issues in producing the next rev of the documents, and I'll defer to their judgement. Steve From owner-ipsec Thu Jul 10 16:15:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04288 for ipsec-outgoing; Thu, 10 Jul 1997 16:15:23 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6223.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Jul 1997 16:22:49 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: Padding Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, >While I'm thinking about it, at least 4 WG members asked that the >default padding be changed to be well-known, and 2 asked that it be the >same Self-Describing-Padding that PPP is using. Yet, Kent's ESP text >does not reflect the requests. I'm currently discussing how to resolve the padding issue with those WG members who have expressed a desire for the default padding to be enumerated, vs. random, as a result of the recent, co-ordinated discussions among implementors lead by Bob Moskowitz. No ESP drafts have been produced since that suggestion was forwared to me, so your suggestion that I have refused to make such changes is unfounded. Moreover, you previously argued for no definition of a default padding, suggesting that every encryption algorithm document specify the padding. The WG has vascillated considerably about this topic. >I find Kent's text dense and difficult to understand, without such minor >editorial devices as a single topic per paragraph and transitional >sentences. Also, he misused the latin abbreviations "e.g." and "i.e.". >Why use them at all, when the spelled out versions are just as many >typed characters? This isn't calligraphy. Better yet, use the English. I reviewed the most recent ESP spec and could not find examples of misuse of "e.g." or "i.e." Please provide pointers to specific instances that you feel are incorrect. Steve From owner-ipsec Thu Jul 10 18:03:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04873 for ipsec-outgoing; Thu, 10 Jul 1997 18:02:54 -0400 (EDT) Date: Thu, 10 Jul 1997 15:10:02 -0700 (PDT) Message-Id: <199707102210.PAA25833@servo.qualcomm.com> From: Phil Karn To: cryptography@c2.org Cc: ipsec@tis.com, karn@Qualcomm.com Subject: Fast x86 DES for SSH Sender: owner-ipsec@ex.tis.com Precedence: bulk As I promised the other week, I have integrated my fast x86 asm DES code into the current version of freeware SSH (1.5-1.2.20). The code is for x86 processors only (386 or better), though the package should still compile successfully on other machines (it just won't run any faster). On the Pentium, file transfers in 3des mode now take about 40-50% less CPU time than before. There is still room for further improvement, particularly in the implementation of 3des cbc; see the notes in the readme file in the package. I'm releasing this stuff as a source patch kit. It's actually a shar archive that you extract onto a stock ssh-1.2.20 distribution once it has been extracted. The shar archive adds some files and replaces others. You then configure, make and install the package normally. I consider this alpha software. I've tested it on Pentiums running Linux 2.0.30 and BSD/OS 2.1 as well as on a Sun Ultrasparc running SunOS 5.5.1 (the latter just to make sure I didn't break the configuration script). Volunteers are hereby solicited for further testing. If you want this software, send me mail explicitly stating that you are a US citizen, US permanent resident or Canadian citizen physically in the US or Canada. Please don't forget this statement, otherwise I'll just bounce your request. Thanks, Phil From owner-ipsec Thu Jul 10 19:25:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05189 for ipsec-outgoing; Thu, 10 Jul 1997 19:24:22 -0400 (EDT) Message-Id: <199707102331.QAA01256@pita.cisco.com> To: Stephen Kent cc: ipsec@tis.com Subject: Re: Padding In-reply-to: Your message of "Thu, 10 Jul 1997 16:22:49 EDT." Date: Thu, 10 Jul 1997 16:31:59 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Unless the padding is random, I see little difference between padding with zero and padding with a monitonically incrementing constant. If there are cryptographic concerns, they're both equivalent, aren't they? While I understand the covert channel argument (being, in a past life, a VSA for a C2 and B1 TCSEC OS), that's not really one of our (unwritten) design criteria. Covert channel analysis is way beyond the charter of this working group. Unless there are strong cryptographic reasons for choosing pseudorandom pads, I would prefer to see it be zero. Derrell From owner-ipsec Thu Jul 10 19:31:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05223 for ipsec-outgoing; Thu, 10 Jul 1997 19:31:52 -0400 (EDT) To: Phil Karn cc: cryptography@c2.org, ipsec@tis.com Subject: Re: Fast x86 DES for SSH In-reply-to: Your message of "Thu, 10 Jul 1997 15:10:02 MST." <199707102210.PAA25833@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jul 1997 09:38:20 +1000 Message-ID: <23538.868577900@connect.com.au> From: George Michaelson Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric Youngs SSL-EAY includes optimized DES and layered transforms for a range of Architectures including RISC and non-Intel in particular. If somebody outside of the USA is going to work on optimal SSH, then abstracting its crypto code to use an ABI and coding to the SSLEAY ABI is the way to go. I did raise this on the SSL list but it sank like a stone, about 3 months ago. Eric is a bit busy earning a living, I think there is some confusion about where SSL and SSH collide in the space of session management and the 'right way' to do secured apps.. but that aside, his code is bitchin! -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From owner-ipsec Thu Jul 10 21:22:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05807 for ipsec-outgoing; Thu, 10 Jul 1997 21:21:52 -0400 (EDT) Date: Fri, 11 Jul 97 00:20:49 GMT From: "William Allen Simpson" Message-ID: <6234.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Security Association vis a vis Security Parameters Index Sender: owner-ipsec@ex.tis.com Precedence: bulk I was starting to send a nice private thank you to Atkinson for his well written earlier message, but then I read this one: > From: Randall Atkinson > My answer is (and the historical intent has been): > > Let an IP session exist between nodes A and B. > Let that session use both AH and ESP for protection. > > Then one has two separate IPsec Security Associations; > one for AH and a different one for ESP. The > combination of (SPI, Destination Address, {AH XOR ESP}) > uniquely identifies an IPsec Security Association. > Historical intent, my foot! I just went back and re-read the messages from March 20, 1995, where I proposed the term Security Parameters Index in a direct response to a Bellovin note. I also have a private message indicating that I spoke to Atkinson on the phone before proposing the term. I think that his memory of the historical intent is different from the historical record. The historical intent was to separate the "index" which is unidirectional and different per protocol, from the "association" which has the overall party trust relationship. According to more than one person, this was needed for MLS compartmentalization, where under a single "security association", the underlying parameters could "modulate", requiring multiple SPIs per SA (to paraphrase Andy Bayerl). As Perry wrote, "the index is not the map which is not the territory." > Note that this does NOT preclude the operational > practice of creating the AH and ESP SAs at the > same time using a single KM process. It also does > not mean that a particular implementation cannot choose > to _internally_ handle those SAs as a pair. However, > it also does not require that an implementation handle > them as a pair or create them at the same time using > a single KM process. > Yes, but only if you substitute SPI where you have written SA. > Bill's terminology for "SA" and "SPI" as used in recent > messages to this list appears to be unique to him. His > terminology is not identical to the historical intent > of the IPsec document author or with the formal definition > of an IPsec Security Association in the existing RFCs > (whose clarity is admittedly suboptimal due to historical > factors). > > I beg to differ with Bill's assertion that he defined > the semantics for the "SPI". For good or ill, the > semantics were defined in the RFCs (1825-1827) -- > Bill was neither author nor editor for those RFCs. > For good or ill, I proposed the term, wrote the list text, and the first internet-drafts. It's a matter of record. As noted by Atkinson, the final RFCs were suboptimal, but we all agreed to let them be published -- because the editor promised to clean up all the non-technical errors that we let slide, within the 6 month wait before going to Draft Standard. Well, that didn't happen in 6 months, and it didn't happen in a year, or even two years. Now we have another editor, and only one internet-draft in 6 months. Do we have to wait for another 2 years? So, to recapitulate, the intent of the Working Group (in 1994-1995) was that there exist two levels of information: Security Association A collection of parameters describing the security relationship between two nodes. These parameters include the identities of the parties, the transform (including algorithm and algorithm mode), the key(s) (such as a session-key, secret-key, or appropriate public/private key-pair), and possibly other infor- mation such as sensitivity labelling. Security Parameters Index A number that indicates a particular set of attributes in a Security Association. That number is relative to the IP Destination and Protocol. The term "attributes" was used by several folks (Hughes, Bayerl), on both the IPng and IPSec lists. If there is a number that identifies a Security Association between communicating parties, it is the pair of Cookies, not any single SPI. Once upon a time, we called all the KMPs "Security Association Management Protocols" (SAMP). Someone objected that the "Security Association" was too much of a meta-concept, that the "association" has to already exist before you execute the KMP, that you are really managing the particular attributes to be used for particular sessions. Nowadays, I've settled on "Session-Key Management Protocols". But there you have it, a little bit of history.... Oh, yeah, I'm reminded that Atkinson promised to buy me a dinner if he didn't deploy a Kerberos variant of Photuris within two years, after the changes I made at his request.... 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 Jul 10 21:22:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05797 for ipsec-outgoing; Thu, 10 Jul 1997 21:21:22 -0400 (EDT) Message-Id: <3.0.1.32.19970710212523.008ac990@pop3.pn.com> X-Sender: rodney@pop3.pn.com (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 10 Jul 1997 21:25:23 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: ELVIS? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk anyone know anything about Elvis? They haven't done a survey. -- Rodney Thayer Sable Technology Corporation 246 Walnut St Newton MA 02160 USA +1 617 332 7292 +1 617 332 7970(Fax) From owner-ipsec Fri Jul 11 01:40:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA06799 for ipsec-outgoing; Fri, 11 Jul 1997 01:38:51 -0400 (EDT) Message-Id: <199707110553.WAA23464@mailsun2.us.oracle.com> Date: 10 Jul 97 22:45:13 -0700 From: "PALAMBER.US.ORACLE.COM" To: wsimpson@greendragon.comx Subject: Re: Security Association vis a vis Security Parameters Index Cc: ipsec@tis.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:owner-ipsec@portal.ex.tis.com's message of 10-Jul-97 17:20 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_12262152_0_11919707102354170" Sender: owner-ipsec@ex.tis.com Precedence: bulk --=_ORCL_12262152_0_11919707102354170 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Bill, Why you are dwelling on the past: >I just went back and re-read the messages from March 20, >1995, where I proposed the term Security Parameters Index ... So ... >For good or ill, I proposed the term, wrote the list text, >and the first internet-drafts. It's a matter of record. Perhaps ... As best I remember, SPI was invented because SAID was already the common terminology for this mechanism and inventing a new term allowed the creation of a new definition without having to harmonize the usage with existing conventions. If we are looking for historical attribution, all of the concepts for SPIs or SAIDs were invented in the late 80's. I'd like to think that I was the first to propose the use of a recipient unique index for SAIDs/SPIs in 1987 (or was it 88), but who cares about attribution. I vaguely remember the meeting where the term Security Association was coined, I suspect it was by Mike White or Tom Markham. SAs were defined in exceeding fine detail by the SILS working group in IEEE. SWIPE and Photuris both stole many concepts from the ISO specification for NLSP. Much of the early groundwork was defined in the "dual versus single catenet" paper (Dave Golber) in 1983. Later work by Ruth Nelson (and others at GTE) helped replace the catenet models . >Once upon a time, we called all the KMPs "Security Association >Management Protocols" (SAMP). No ... in ipsec, we first called our placeholder for a key management specification the Internet Key Management Protocol (IKMP). SAMP was a specific complete proposal that was distributed to the working group. SAMP was rejected because it was written in an ISO style and used ASN.1. ISAKMP was partly derived from SAMP by replacing the ASN.1. SAMP was derived from the SDNS Key Management Protocol (KMP). What's that old adage about "building on the shoulders of others...". >But there you have it, a little bit of history.... Bill your retelling of history reminds me of the movie "Rashomon" (Akira Kurosawa, 1950). For those on the list that have not seen it, there is a detailed review at http://www.voyagerco.com/criterion/indepth.cgi?rashomon). We all have our own subjective view of history. The bandwidth of this mailing list would be better spend on constructive discussions that move us forward. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_12262152_0_11919707102354170 Content-Type:message/rfc822 Date: 10 Jul 97 17:20:49 From:"William Allen Simpson " To:ipsec@tis.com Subject:Security Association vis a vis Security Parameters Index Return-Path: Sender:owner-ipsec@ex.tis.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" I was starting to send a nice private thank you to Atkinson for his well written earlier message, but then I read this one: > From: Randall Atkinson > My answer is (and the historical intent has been): > > Let an IP session exist between nodes A and B. > Let that session use both AH and ESP for protection. > > Then one has two separate IPsec Security Associations; > one for AH and a different one for ESP. The > combination of (SPI, Destination Address, {AH XOR ESP}) > uniquely identifies an IPsec Security Association. > Historical intent, my foot! I just went back and re-read the messages from March 20, 1995, where I proposed the term Security Parameters Index in a direct response to a Bellovin note. I also have a private message indicating that I spoke to Atkinson on the phone before proposing the term. I think that his memory of the historical intent is different from the historical record. The historical intent was to separate the "index" which is unidirectional and different per protocol, from the "association" which has the overall party trust relationship. According to more than one person, this was needed for MLS compartmentalization, where under a single "security association", the underlying parameters could "modulate", requiring multiple SPIs per SA (to paraphrase Andy Bayerl). As Perry wrote, "the index is not the map which is not the territory." > Note that this does NOT preclude the operational > practice of creating the AH and ESP SAs at the > same time using a single KM process. It also does > not mean that a particular implementation cannot choose > to _internally_ handle those SAs as a pair. However, > it also does not require that an implementation handle > them as a pair or create them at the same time using > a single KM process. > Yes, but only if you substitute SPI where you have written SA. > Bill's terminology for "SA" and "SPI" as used in recent > messages to this list appears to be unique to him. His > terminology is not identical to the historical intent > of the IPsec document author or with the formal definition > of an IPsec Security Association in the existing RFCs > (whose clarity is admittedly suboptimal due to historical > factors). > > I beg to differ with Bill's assertion that he defined > the semantics for the "SPI". For good or ill, the > semantics were defined in the RFCs (1825-1827) -- > Bill was neither author nor editor for those RFCs. > For good or ill, I proposed the term, wrote the list text, and the first internet-drafts. It's a matter of record. As noted by Atkinson, the final RFCs were suboptimal, but we all agreed to let them be published -- because the editor promised to clean up all the non-technical errors that we let slide, within the 6 month wait before going to Draft Standard. Well, that didn't happen in 6 months, and it didn't happen in a year, or even two years. Now we have another editor, and only one internet-draft in 6 months. Do we have to wait for another 2 years? So, to recapitulate, the intent of the Working Group (in 1994-1995) was that there exist two levels of information: Security Association A collection of parameters describing the security relationship between two nodes. These parameters include the identities of the parties, the transform (including algorithm and algorithm mode), the key(s) (such as a session-key, secret-key, or appropriate public/private key-pair), and possibly other infor- mation such as sensitivity labelling. Security Parameters Index A number that indicates a particular set of attributes in a Security Association. That number is relative to the IP Destination and Protocol. The term "attributes" was used by several folks (Hughes, Bayerl), on both the IPng and IPSec lists. If there is a number that identifies a Security Association between communicating parties, it is the pair of Cookies, not any single SPI. Once upon a time, we called all the KMPs "Security Association Management Protocols" (SAMP). Someone objected that the "Security Association" was too much of a meta-concept, that the "association" has to already exist before you execute the KMP, that you are really managing the particular attributes to be used for particular sessions. Nowadays, I've settled on "Session-Key Management Protocols". But there you have it, a little bit of history.... Oh, yeah, I'm reminded that Atkinson promised to buy me a dinner if he didn't deploy a Kerberos variant of Photuris within two years, after the changes I made at his request.... 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 --=_ORCL_12262152_0_11919707102354170-- From owner-ipsec Fri Jul 11 03:49:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA07428 for ipsec-outgoing; Fri, 11 Jul 1997 03:48:23 -0400 (EDT) Message-ID: <01BC8D95.1F385400@BIGHUGE> From: Rob Adams To: "'Derrell Piper'" , Stephen Kent Cc: "ipsec@tis.com" Subject: RE: Padding Date: Fri, 11 Jul 1997 00:55:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The covert channel argument seems to me to be a bit over the top, in this context. I suppose if people are really worried about it, then we should cover, but personally, it isn't a sticking point with me. The wonderful thing about random was that receivers could simply strip it off and throw it away. If we specify that the padding must contain a specific value, we will imply that receivers have to test the padding for the "MUST be set" value. In this case, simply make it zero and dictate that all transforms MUST behave this way. If we have cryptographic reasons, then specify that it SHOULD be random and leave it up to the implementation to fill it in and allow receivers to ignore it. -Rob -----Original Message----- From: Derrell Piper [SMTP:piper@cisco.com] Sent: Thursday, July 10, 1997 4:32 PM To: Stephen Kent Cc: ipsec@tis.com Subject: Re: Padding Unless the padding is random, I see little difference between padding with zero and padding with a monitonically incrementing constant. If there are cryptographic concerns, they're both equivalent, aren't they? While I understand the covert channel argument (being, in a past life, a VSA for a C2 and B1 TCSEC OS), that's not really one of our (unwritten) design criteria. Covert channel analysis is way beyond the charter of this working group. Unless there are strong cryptographic reasons for choosing pseudorandom pads, I would prefer to see it be zero. Derrell From owner-ipsec Fri Jul 11 07:49:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA08734 for ipsec-outgoing; Fri, 11 Jul 1997 07:47:52 -0400 (EDT) Date: Fri, 11 Jul 97 10:53:57 GMT From: "William Allen Simpson" Message-ID: <6236.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Operational Considerations Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't know why I awoke so early thinking about IP Security, but before I go back to bed, a couple of semi-private notes I read yesterday from the ANX design team members remind me that my recent drafts contain important sections which should be in the main ESP draft, rather than duplicated in each transform. We've discussed these on this list before, but they have not yet shown up in the revised ESP. Make it so: Operational Considerations This specification provides only a few manually configurable parame- ters: SPI Manually configured SPIs are limited in range to aid operations. Automated SPIs are pseudo-randomly distributed throughout the remaining 2**32 values. Default: 0 (none). Range: 256 to 65,535. SPI LifeTime (SPILT) Manually configured LifeTimes are generally measured in days. Automated LifeTimes are specified in seconds. Default: 32 days (2,764,800 seconds). Maximum: 182 days (15,724,800 seconds). Replay Window Long term replay prevention requires automated configuration. Also, some earlier implementations used pseudo-random values. This check must only be used with those peers that have imple- mented this feature. Default: 0 (checking off). Range: 32 to 256. Pad Values New implementations use verifiable values. However, some earlier implementations used pseudo-random values. This check must only be used with those peers that have implemented this feature. Also, some operations desire additional padding to inhibit traffic analysis. Default: 0 (checking off). Range: 7 to 255. Encryption Each interface document will describe the keying material needed. Default: DES-CBC. Compression Default: none. Authentication Each interface document will describe the keying material needed. Default: none. 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. 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 Jul 11 10:49:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09890 for ipsec-outgoing; Fri, 11 Jul 1997 10:46:25 -0400 (EDT) Date: Fri, 11 Jul 97 13:58:28 GMT From: "William Allen Simpson" Message-ID: <6241.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: ESP Introduction Sender: owner-ipsec@ex.tis.com Precedence: bulk Notwithstanding the derogatory comments that prefixed his message, there remain a few substantive issues: > From: Stephen Kent > >Technically, "data origin authentication" requires a long term key, > >usually verified in the form of a signature. It is a term normally > >reserved for applications such as email. ESP is defined for ephemeral > >keys. Again, "data origin authentication" is not provided by ESP. > > While it is true that a long term key often is involved as a basis for DOA, > signatures are in no way needed, e.g., KDC-based systems like Kerberos > provide DAO based on a long-term symmetric key, which is used to bootstrap > to a TGT, etc. The fact that a key used with ESP may be ephemeral is > irrelevant to the question of whether DOA is provided. The literature > citations I provided earlier, as well as others, support this > characterization > How, exactly, does your adding the terms "data origin" and "connectionless" to our earlier agreed language (massaged by WG discussion in 1995) help write a protocol implementation? How, exactly, is "data origin" authentication provided when the same SPI is given to 20 folks to traverse a firewall? How, exactly, is my "usually" and "normally" different from your "often" and "in no way needed"? Are signatures never or rarely involved? What basis of evaluation are you using? Keep in mind, I am not at all interested in ISO specification language. If particular language is to be used here, writing a draft for us to review (and change) should have been your highest priority. You have already refused. Until then, I'll stick with "Applied Cryptography", which sits next to the keyboard and is extremely useful to implementors; and "Handbook of Applied Cryptography", which sits back in the library as it is much less useful to implementors. Also, your US DoD roots are showing. I remind folks that you were involved in Clipper/Fortezza/SkipJack review. Historically speaking, in this WG, there was a strong sentiment against using Clipper/SkipJack/Fortezza. There was an undercurrent desire rarely expressed in public that we didn't want any SPI to have "data origin" authentication, because we didn't want the SPI to be a subpoena relevant entity. We spent a lot of effort to try to ensure that the sender identity is hidden from outside parties. There, I've admitted it in writing. So, stop trying to put it back! > terminology if the WG deems it appropriate. Routers acting as firewalls > are good candidates for IPSEC implementations, but then so are firewalls > that are not acting as routers. Let us be perfectly clear, there are two and only two entities that apply to the Internet Protocol (the domain of this WG): 1) hosts (ISOese "end systems") 2) routers (ISOese "intermediate systems") If it passes IP packets between two interfaces, it is a router. At context levels above IP, such as transport, there are gateways. Please ensure that the text conforms to this long-standing Internet terminology. > The term "transform" was retired when we moved from trivial base documents > and a combinatorially expanding set of transform documents, The term transform has been resurrected for lack of a better term, and given a tighter definition. I was long opposed to combinatorial expansion, and am pleased that the WG has finally come around to earlier thinking. We have ciphers and authenticators. Each "transforms" their data. The ESP document needs to reflect this. I have submitted complete and expressive language. Use it. > **** Most egregious is that it is missing critical information **** > **** from RFC-1827: the IP Next Header/Protocol number :-(. **** > > Well, Bill, you got me there! Somewhere along the way we dropped this > important datam and you are the first person to point that out. We'll > certainly amend the text to specify the protocol values for Ah and ESP, in > the respecvtive documents. > I suggest that, perhaps, the documents were so dense that very few took the effort to read them.... It took me weeks. These comments are not being composed without considerable effort. 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 Jul 11 10:56:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09965 for ipsec-outgoing; Fri, 11 Jul 1997 10:55:55 -0400 (EDT) Date: Fri, 11 Jul 97 12:28:52 GMT From: "William Allen Simpson" Message-ID: <6238.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Sequence Number Sender: owner-ipsec@ex.tis.com Precedence: bulk Another set of common text in the recent drafts (and former RFCs) reflecting current deployment experience, that should be included in the main ESP draft: 2.2. Sequence Number The Sequence Number is a 32-bit (4 byte) unsigned counter. This field protects against replay attacks, and may also be used for syn- chronization by stream or block-chaining ciphers. When configured manually, the first value sent SHOULD be a random number. The limited anti-replay security of the sequence of data- grams depends upon the unpredictability of the values. When configured via an automated Security Association management pro- tocol, the first value sent is 1, unless otherwise negotiated. Thereafter, the value is monotonically increased for each datagram sent. A replacement SPI SHOULD be established before the value repeats. That is, no more than 2**32 datagrams SHOULD be sent with any single key. This field is mandatory and transparent. That is, the field is always present, and the value is not concealed by encryption. Although sending this field is mandatory, verification of the sequence of values is at the discretion of the receiver. When integrity checking is available, either through the optional Authen- ticator field or an external Authentication Header (AH), the imple- mentation SHOULD NOT accept duplicate values. This may be achieved by accepting only those datagrams that contain a different value than previously received, or by maintaining a small window of acceptable values. 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 Jul 11 10:56:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09966 for ipsec-outgoing; Fri, 11 Jul 1997 10:55:59 -0400 (EDT) Date: Fri, 11 Jul 97 12:38:22 GMT From: "William Allen Simpson" Message-ID: <6239.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Security Association vis a vis Security Parameters Index Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "PALAMBER.US.ORACLE.COM" > As best I remember, SPI was invented because SAID was already the common > terminology for this mechanism and inventing a new term allowed the creation > of a new definition without having to harmonize the usage with existing > conventions. > > If we are looking for historical attribution, As far as I know, we are not looking for history outside this WG. We are looking for _the_ definition that was defined in _this_ WG, which was (by your own admission) different from existing conventions. And this discussion started because the current document editor is trying to take us back to _old_ definitions, rather than the ones _we_ defined. We didn't approve the old definitions. We had good solid reasons for coming up with a new term and new definitions. > SAs were defined in exceeding fine detail by the SILS working > group in IEEE. So what? We didn't use IEEE. It was proposed, and rejected. > SWIPE and Photuris both stole many concepts from the ISO > specification for NLSP. Maybe I'm particularly cranky in the morning, but this is unutterable !@!@*!^%@!&%@&%!@!%@. NLSP was not mentioned in room 416 in San Diego (in 1992) when Karn sprawled across my bed and first drew out the packet formats that later became swIPe, nor in any of the lunch and dinner meetings that _I_ attended which launched the IPSec BOFs. And comparing the diagrams in the Proceedings (Nov 1993), I see that "I-NLSP" is not at all like the protocols we are currently using. Whereas, Karn's presentation and demonstration of working code at that same meeting in 1993 (and the swIPe internet-draft) have exactly the fields we are using, with the same "tunnel" versus "transport" modes, all spelled out in pretty pictures. NLSP was not mentioned in any of the design meetings for Photuris. Indeed, other than that single presentation in 1993, I've never seen any details. I'd be pretty surprised if there were any fields that matched. > >Once upon a time, we called all the KMPs "Security Association > >Management Protocols" (SAMP). > > No ... in ipsec, we first called our placeholder for a key management > specification the Internet Key Management Protocol (IKMP). SAMP was a > specific complete proposal that was distributed to the working group. Using the "royal we", I see. IKMP is what _you_ called things in meeting minutes, but you were rather out of touch with the words the rest of us were using in conversation. SAMP was probably the name of a proposal for the very reason that that is what the unwashed masses were calling the needed functionality. Hard to know, as we cannot read the mind of the presenter. Hard to know the details, either, as the presentation didn't make its way into the Proceedings. Only presentations that you "approved" show up in minutes and proceedings. It has been a real problem, that the new chairs have assured me they will not emulate.... 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 Jul 11 10:56:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09967 for ipsec-outgoing; Fri, 11 Jul 1997 10:55:59 -0400 (EDT) Date: Fri, 11 Jul 97 13:21:00 GMT From: "William Allen Simpson" Message-ID: <6240.wsimpson@greendragon.com> To: ipsec@tis.com Subject: on the nature of recent suggestions Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > You continued, though belated, inputs to the document editing process are > appreciated. "Belated"? I've posted previous suggestions to the mailing list. I've sent you private notes. Almost none of them has actually shown up in a document. I'm glad that these efforts are "appreciated", but a cynic might think, based on your current draft output, that is a euphemism for "ignored". I have seen several others contribute suggestions, both publically and semi-privately. I have reason to believe that there are more private suggestions to which I am not privy. I am not alone in my dissatisfication with the current state of the drafts. Worse, you have refused to add text that multiple folks have requested. You have refused to incorporate the results of an explicit straw poll of the WG conducted at the last meeting. None of your documents have been posted to internet-drafts in 4 months. Response to many other's suggestions in recent weeks have been answered that "current versions" of the drafts address the problems. Well, obviously the commenters are not privy to these "current versions". It's the drafts that are "belated"! > However, gratituous assults on my competence with respect to > network security are unsubstantiated, as well as unwarranted. > I am personally insulted that you have taken my carefully written and annotated suggestions as a "gratuitous assult". In the future, I ask that you refrain from these comments. You admitted in writing that you "don't understand". I merely quoted your own words. Is that too personal? Do people write documents, or are they handed down from a diety on high? Criticism of your use of obsolete and inapplicable terminology is not an assault on your "competence with respect to network security", they are a criticism of your writing. That is indeed warranted, since it is the writing for which you have taken responsibility. Moreover, since in 15 years of DoD ARPAnet affiliation including a long term on the Internet Activities Board, you did not manage to complete any network security for the Internet, I have nothing other than your recent writing on which to judge your competence. I don't know how you became annointed editor of these drafts. It was done in a secret smoke filled room, and not publically discussed in this Working Group. But until you relinquish the role, you can expect us to hold your feet to the fire. 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 Jul 11 11:54:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10410 for ipsec-outgoing; Fri, 11 Jul 1997 11:53:25 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6241.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Jul 1997 12:00:04 -0400 To: William Allen Simpson From: Stephen Kent Subject: Re: ESP Introduction Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Our continued bickering on the mailing list over these documents is a waste of everyone's time, not to mention bandwidth and storage. On that basis, I'm not going to respond to the points you have raised in your most recent messages. I am editing the documents to reflect WG concensus, which is not always equivalent to acting upon the material contained in public or private messages from you or from any other indvidual, in isolation. Since some of the points have been quite contentious and have not resulted in a clear concensus, I am defering to the WG co-chairs to resolve such issues and to direct me in this editing process. I will not be acting upon text you provide, unless the co-chairs agree that it represents WG concensus, or unless it represents explicit, obvious errors, such as the omission of the AH and ESP protocol values. Steve From owner-ipsec Fri Jul 11 12:01:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10494 for ipsec-outgoing; Fri, 11 Jul 1997 12:01:24 -0400 (EDT) Message-ID: <01BC8DD9.ECEEE4B0@BIGHUGE> From: Rob Adams To: "'William Allen Simpson'" , "ipsec@tis.com" Subject: RE: Sequence Number Date: Fri, 11 Jul 1997 09:05:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Here we go on the sequence number again... This is a particular hot button of mine because of the number of times we've gone over this... Anyway.... >-----Original Message----- >From: William Allen Simpson [SMTP:wsimpson@greendragon.com] >Sent: Friday, July 11, 1997 5:29 AM >To: ipsec@tis.com >Subject: Sequence Number > >2.2. Sequence Number > > When configured manually, the first value sent SHOULD be a random > number. The limited anti-replay security of the sequence of data- > grams depends upon the unpredictability of the values. > > When configured via an automated Security Association management pro- > tocol, the first value sent is 1, unless otherwise negotiated. When configured manually the value MUST start at 1 the same as it MUST start at 1 if a KMP is used. It's in the clear, it is monotonically increasing.. It is in a fixed spot in the packet... A random starting point adds no benefit and only complicates policy management and implementations. The statement about the limited value of the anti-replay security depending on the unpredictability adds no value to the document and can certainly be disputed. > Thereafter, the value is monotonically increased for each datagram > sent. A replacement SPI SHOULD be established before the value > repeats. That is, no more than 2**32 datagrams SHOULD be sent with > any single key. A replace SPI MUST be established before roll over. More than 2**32 datagrams MUST not be sent under a single key. We've always defined 0 as a replay condition. This goes back the 64 bit sequence number ... event ... Even if the receiver isn't checking the replay field, senders will know when they are going to send more than 2**32 and force a re-key. From owner-ipsec Fri Jul 11 12:57:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10716 for ipsec-outgoing; Fri, 11 Jul 1997 12:55:56 -0400 (EDT) Message-Id: <3.0.1.32.19970711125256.0090d270@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 11 Jul 1997 12:52:56 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Sequence Number for streaming ciphers? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Date: Fri, 11 Jul 97 12:28:52 GMT >From: "William Allen Simpson" >This > field protects against replay attacks, and may also be used for syn- > chronization by stream or block-chaining ciphers. What experience is being referenced about the sequence number being used for synchronization by stream ciphers? From owner-ipsec Fri Jul 11 13:08:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10794 for ipsec-outgoing; Fri, 11 Jul 1997 13:08:25 -0400 (EDT) Date: Fri, 11 Jul 1997 11:57:29 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: William Allen Simpson cc: ipsec@tis.com Subject: Re: Sequence Number In-Reply-To: <6238.wsimpson@greendragon.com> Message-Id: <97Jul11.115212edt.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 Fri, 11 Jul 1997, William Allen Simpson wrote: > The Sequence Number is a 32-bit (4 byte) unsigned counter. This > field protects against replay attacks, and may also be used for syn- > chronization by stream or block-chaining ciphers. Synchronizing stream ciphers requires a stream offset; synchronizing a block-chaining cipher requires an IV. 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 Fri Jul 11 14:16:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11200 for ipsec-outgoing; Fri, 11 Jul 1997 14:14:58 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'William Allen Simpson'" , "'Stephen Kent'" Subject: RE: on the nature of recent suggestions Date: Fri, 11 Jul 1997 14:25:10 -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 Excuse me for budding into your very personal attacks of each other on a public mailing list, but this line of conversation is wasting my time and I'm sure everyone else's as well. Please take your little "I was there when..." stories off the mailing list into personal email. I want to get IPSec product out the door THIS year. >---------- >From: William Allen Simpson[SMTP:wsimpson@greendragon.com] >Sent: Friday, July 11, 1997 9:21 AM >To: ipsec@tis.com >Subject: on the nature of recent suggestions > >> From: Stephen Kent >> You continued, though belated, inputs to the document editing process are >> appreciated. > >"Belated"? > >I've posted previous suggestions to the mailing list. I've sent you >private notes. Almost none of them has actually shown up in a document. > >I'm glad that these efforts are "appreciated", but a cynic might think, >based on your current draft output, that is a euphemism for "ignored". > >I have seen several others contribute suggestions, both publically and >semi-privately. I have reason to believe that there are more private >suggestions to which I am not privy. I am not alone in my >dissatisfication with the current state of the drafts. > >Worse, you have refused to add text that multiple folks have requested. >You have refused to incorporate the results of an explicit straw poll of >the WG conducted at the last meeting. > >None of your documents have been posted to internet-drafts in 4 months. >Response to many other's suggestions in recent weeks have been answered >that "current versions" of the drafts address the problems. Well, >obviously the commenters are not privy to these "current versions". >It's the drafts that are "belated"! > > >> However, gratituous assults on my competence with respect to >> network security are unsubstantiated, as well as unwarranted. >> >I am personally insulted that you have taken my carefully written and >annotated suggestions as a "gratuitous assult". In the future, I ask >that you refrain from these comments. > >You admitted in writing that you "don't understand". I merely quoted >your own words. Is that too personal? Do people write documents, or >are they handed down from a diety on high? > >Criticism of your use of obsolete and inapplicable terminology is not an >assault on your "competence with respect to network security", they are >a criticism of your writing. That is indeed warranted, since it is the >writing for which you have taken responsibility. > >Moreover, since in 15 years of DoD ARPAnet affiliation including a long >term on the Internet Activities Board, you did not manage to complete >any network security for the Internet, I have nothing other than your >recent writing on which to judge your competence. > >I don't know how you became annointed editor of these drafts. It was >done in a secret smoke filled room, and not publically discussed in this >Working Group. But until you relinquish the role, you can expect us to >hold your feet to the fire. > >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 Jul 11 14:19:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11226 for ipsec-outgoing; Fri, 11 Jul 1997 14:19:27 -0400 (EDT) Message-Id: <3.0.1.32.19970711142707.00ab09e0@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, 11 Jul 1997 14:27:07 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Comment cutoff! For now. Cc: Stephen Kent In-Reply-To: References: <199707101501.LAA25310@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk OK. enough is enough. There are some deep issues and opinions here, but we need to stop for a piece. Listen all. Steve, PLEASE work on getting the Architecture, ESP, and AH documents out. Take the comments we have sent you and take a cut. Get the IDs posted as soon as is practical. I suspect that they will be very close to done. EVERYONE else, please direct your attention to the roadmap, the cipher and auth drafts for the meantime. We have not received any comments on them. We do expect to have to make some changes on them as a result of ESP and AH discussions, so it would be nice to get a good set of comments so that changes can be made before ID cutoff date. We will NOT return to your regularly scheduled IPsec debate. Robert Moskowitz Chrysler Corporation (248) 758-8212 From owner-ipsec Fri Jul 11 15:36:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11692 for ipsec-outgoing; Fri, 11 Jul 1997 15:33:27 -0400 (EDT) Date: Fri, 11 Jul 97 19:24:50 GMT Daylight Time From: Ran Atkinson Subject: RE: Sequence Number To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <01BC8DD9.ECEEE4B0@BIGHUGE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Thereafter, the value is monotonically increased for each datagram > > sent. A replacement SPI SHOULD be established before the value > > repeats. That is, no more than 2**32 datagrams SHOULD be sent with > > any single key. > > A replace SPI MUST be established before roll over. More than 2**32 datagrams > MUST not be sent under a single key. We've always defined 0 as a replay > condition. This goes back the 64 bit sequence number ... event ... Even > if the receiver isn't checking the replay field, senders will know when they are > going to send more than 2**32 and force a re-key. I'd propose a more precise version of the above, perhaps something like: "A replacement IPsec Security Association MUST be established before the original IPsec Security Association rolls over its sequence number space or otherwise expires. More than 2**32 IP datagrams MUST NOT be sent using the same IPsec SA when anti-replay protection is in use. The replacement IPsec Security Association will, of course, have a different SPI than the original IPsec Security Association." I think perhaps the origin of the WG's confusion is the use of the term "rekey". The process of rekey does not retain an SA and merely change the keys. Rather, the rekey process creates an entire new SA to replace the original SA. Now it might commonly be the case that the new SA has nearly all of its attributes (not including SPI or crypto keys) the same as the original SA, but it is still a new SA. In general, SPIs are just 32-bit opaque numbers used in conjunction with the Destination Address to identify an SA. SPIs do not have sequence numbers, keys, or other stuff. By contrast, an SA does contain an SPI, identities, keys, sequence numbers, and other stuff. I hope this helps. On an unrelated note, I've been reading the bits about covert channels. My own take on this would be: - The specifications ought not preclude an implementation from providing covert channel protections. - The specifications ought not require that all implementations provide such protections. Ran rja@inet.org From owner-ipsec Fri Jul 11 20:46:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13451 for ipsec-outgoing; Fri, 11 Jul 1997 20:45:59 -0400 (EDT) Message-Id: <199707120051.UAA16963@raptor.research.att.com> To: Rodney Thayer cc: ipsec@tis.com Subject: Re: Sequence Number for streaming ciphers? Date: Fri, 11 Jul 1997 20:51:52 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk >Date: Fri, 11 Jul 97 12:28:52 GMT >From: "William Allen Simpson" >This > field protects against replay attacks, and may also be used for sy n- > chronization by stream or block-chaining ciphers. What experience is being referenced about the sequence number being used for synchronization by stream ciphers? The original SKIP proposal used the sequence number that way. From owner-ipsec Sun Jul 13 07:54:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22223 for ipsec-outgoing; Sun, 13 Jul 1997 07:48:57 -0400 (EDT) Message-ID: <01BC8F49.1A4BC890@BIGHUGE> From: Rob Adams To: "'Ran Atkinson'" , "ipsec@tis.com" Subject: RE: Sequence Number Date: Sun, 13 Jul 1997 04:48:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----Original Message----- From: Ran Atkinson [SMTP:rja@inet.org] Sent: Friday, July 11, 1997 12:25 PM To: ipsec@tis.com Subject: RE: Sequence Number > > Thereafter, the value is monotonically increased for each datagram > > sent. A replacement SPI SHOULD be established before the value > > repeats. That is, no more than 2**32 datagrams SHOULD be sent with > > any single key. > > A replace SPI MUST be established before roll over. More than 2**32 datagrams > MUST not be sent under a single key. We've always defined 0 as a replay > condition. This goes back the 64 bit sequence number ... event ... Even > if the receiver isn't checking the replay field, senders will know when they are > going to send more than 2**32 and force a re-key. > I'd propose a more precise version of the above, perhaps something like: > > "A replacement IPsec Security Association MUST be established before > the original IPsec Security Association rolls over its sequence > number space or otherwise expires. More than 2**32 IP datagrams > MUST NOT be sent using the same IPsec SA when anti-replay protection > is in use. The replacement IPsec Security Association will, of > course, have a different SPI than the original IPsec Security > Association." Well put. very well put. > On an unrelated note, I've been reading the bits about covert channels. > My own take on this would be: > - The specifications ought not preclude an implementation > from providing covert channel protections. > - The specifications ought not require that all implementations > provide such protections. Again, very well put. I agree with this completely. Unfortunately, the above statement could lead to the perception that we need to negotiate a pad value. I am strongly opposed to negotiating a pad value. That's added complexity we do not need. In the absence of a negotiated pad value, the only reasonable way to achieve the above is with a pad value of zero. Zero protects against covert channels. It is easy to set for senders who care and who don't. It is easy to test for receivers that care about covert channels, and just as easy to ignore as anything else for those receivers that don't. Requiring a pad value of zero fits Ran's statements above as well, with the only tiny caveat that senders who don't care about covert channels have to zero their pads. So, unless we find any cryptographic reasons for not using zero for the pad, I would suggest we require the pad MBZ. The pads length must be between zero and 255 octets to bring the packets length including the two required octets to a block ciphers block size. -Rob From owner-ipsec Sun Jul 13 11:40:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23076 for ipsec-outgoing; Sun, 13 Jul 1997 11:38:40 -0400 (EDT) Message-Id: <199707131549.SAA29938@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Sequence Number In-reply-to: Your message of "Sun, 13 Jul 1997 04:48:30 PDT." <01BC8F49.1A4BC890@BIGHUGE> Date: Sun, 13 Jul 1997 18:49:04 +0300 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Adams writes: Rob> Zero protects against covert channels. It is easy to set for Rob> senders who care and who don't. It is easy to test for Rob> receivers that care about covert channels, and just as easy Rob> to ignore as anything else for those receivers that don't. Frankly, I sort of like the self-describing padding, but I'm not picky. I realize that it is easier to just init the buffer to zeros (which is probably already done) overwrite, and insert pad length/payload. Rob> So, unless we find any cryptographic reasons for not using Rob> zero for the pad, I would suggest we require the pad MBZ. Well, it does increase the amount of known plaintext. This is one nice thing about the the self-describing padding is that it isn't the same. Also recall, that in CBC mode, the IV for the next packet likely comes from the ciphertext of the last block. In the case of payloads that are multiples of 64 bits (think v6), the last 8 bytes are: 0 0 0 0 0 0 7 [likely IPPROTO_TCP, UDP or IP] So, the IV for the next packet comes from the ciphertext of the previous block, the key and this known plaintext. Maybe this is a vulnerability, maybe not: I'm not a cryptographer. This isn't really an argument for self-describing padding, because in this special case we get: 1 2 3 4 5 6 7 Note, the amount of padding is itself a covert channel. ] The sun rarely sets on Helsinki | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM8j468mxxiPyUBAxAQFTbQMAnf+H8nlPJN8tUUeQF5E+cX3Qn6ukkN0w tESKzRxz++l2T2aoyHjm6kKUABXLdp91dQybnJO0lRjj4FfN+sIZnviu7UbPOYiN rrS+10iBj5VTv+nDiN35IFAY2EvEhF+D =j41H -----END PGP SIGNATURE----- From owner-ipsec Mon Jul 14 07:33:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27931 for ipsec-outgoing; Mon, 14 Jul 1997 07:31:21 -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-ciph-arcfour-00.txt Date: Mon, 07 Jul 1997 09:47:26 -0400 Message-ID: <9707070947.aa06754@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 ARCFOUR Algorithm Author(s) : R. Thayer Filename : draft-ietf-ipsec-ciph-arcfour-00.txt Pages : 4 Date : 07/03/1997 This draft describes the use of the ARCFOUR [Kaukonen] stream cipher algorithm 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-ciph-arcfour-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-arcfour-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-ciph-arcfour-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: <19970703131648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-arcfour-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-arcfour-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970703131648.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 14 07:33:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27975 for ipsec-outgoing; Mon, 14 Jul 1997 07:33:21 -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-ciph-desx-00.txt Date: Mon, 07 Jul 1997 09:47:37 -0400 Message-ID: <9707070947.aa06869@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 DES-XEX3-CBC Transform Author(s) : W. Simpson, R. Baldwin Filename : draft-ietf-ipsec-ciph-desx-00.txt Pages : 10 Date : 07/03/1997 This document describes the "DESX" DES-XEX3-CBC block cipher transform interface used with 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-ietf-ipsec-ciph-desx-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-desx-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-ciph-desx-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: <19970703145406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-desx-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-desx-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970703145406.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 14 07:33:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27957 for ipsec-outgoing; Mon, 14 Jul 1997 07:32:22 -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-ciph-des3-00.txt Date: Mon, 07 Jul 1997 09:47:35 -0400 Message-ID: <9707070947.aa06849@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 Triple DES Transform Author(s) : N. Doraswamy, P. Metzger, W. Simpson Filename : draft-ietf-ipsec-ciph-des3-00.txt Pages : 12 Date : 07/03/1997 This document describes the "Triple" DES-EDE3-CBC block cipher transform interface used with the IP Encapsulating Security Payload (ESP). It provides compatible migration from RFC-1851. 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-ciph-des3-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-des3-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-ciph-des3-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: <19970703145109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-des3-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-des3-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970703145109.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 14 07:33:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27937 for ipsec-outgoing; Mon, 14 Jul 1997 07:31:51 -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-cbc-00.txt Date: Mon, 07 Jul 1997 09:47:22 -0400 Message-ID: <9707070947.aa06717@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 : ESP with Cipher Block Chaining (CBC) Author(s) : W. Simpson Filename : draft-ietf-ipsec-cbc-00.txt Pages : 6 Date : 07/03/1997 This document describes the Cipher Block Chaining (CBC) mode, used by a number of Internet Encapsulating Security Payload (ESP) transforms. 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-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-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-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: <19970703115358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970703115358.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 14 07:33:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27966 for ipsec-outgoing; Mon, 14 Jul 1997 07:32:52 -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-ciph-des-derived-00.txt Date: Mon, 07 Jul 1997 09:47:33 -0400 Message-ID: <9707070947.aa06823@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 DES-CBC Transform Author(s) : P. Metzger, W. Simpson Filename : draft-ietf-ipsec-ciph-des-derived-00.txt Pages : 11 Date : 07/03/1997 This document describes the DES-CBC block cipher transform interface used with the IP Encapsulating Security Payload (ESP). It provides compatible migration from RFC-1829. 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-ciph-des-derived-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-des-derived-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-ciph-des-derived-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: <19970703144612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-des-derived-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-des-derived-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970703144612.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 14 07:34:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28018 for ipsec-outgoing; Mon, 14 Jul 1997 07:34:51 -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-ciph-cast128-cbc-00.txt Date: Mon, 07 Jul 1997 11:34:45 -0400 Message-ID: <9707071134.aa10036@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 CAST128-CBC Algorithm Author(s) : R. Pereira, G. Carter Filename : draft-ietf-ipsec-ciph-cast128-cbc-00.txt Pages : 6 Date : 07/03/1997 This document 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-ciph-cast128-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-cast128-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-ciph-cast128-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: <19970703102805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-cast128-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-cast128-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970703102805.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 14 07:35:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28033 for ipsec-outgoing; Mon, 14 Jul 1997 07:35:22 -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-doc-roadmap-00.txt (resend) Date: Mon, 07 Jul 1997 11:36:44 -0400 Message-ID: <9707071136.aa10095@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 : IP Security Document Roadmap Author(s) : R. Thayer, N. Doraswamy, R. Glenn Filename : draft-ietf-ipsec-doc-roadmap-00.txt Pages : 9 Date : 07/02/1997 The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Cipher and Authenticator documents are described. 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-doc-roadmap-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-doc-roadmap-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-doc-roadmap-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: <19970702152401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doc-roadmap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doc-roadmap-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970702152401.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 14 07:55:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28291 for ipsec-outgoing; Mon, 14 Jul 1997 07:51:51 -0400 (EDT) Date: Mon, 14 Jul 1997 07:51:51 -0400 (EDT) From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: Michael Richardson cc: ipsec@tis.com Subject: Re: Sequence Number In-Reply-To: <199707131549.SAA29938@morden.sandelman.ottawa.on.ca> Message-Id: <97Jul13.234332edt.11649@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Sun, 13 Jul 1997, Michael Richardson wrote: > Also recall, that in CBC mode, the IV for the next packet likely > comes from the ciphertext of the last block. This would make it impossible to decrypt packets received out of order. 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 Mon Jul 14 13:00:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00660 for ipsec-outgoing; Mon, 14 Jul 1997 12:56:31 -0400 (EDT) Message-Id: <3.0.1.32.19970714130023.007cd2a0@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 14 Jul 1997 13:00:23 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: Sequence Number Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It is recommended that the IV in each non-initial packet be set to the last encryption block of the previous packet. Since the IV travels with the packet, you can still decrypt even if there is packet loss. Nobody enforces this "use the last encryption block" scheme, it's a recommended thing. >Date: Mon, 14 Jul 1997 07:51:51 -0400 (EDT) >From: Norman Shulman >X-Sender: norm@rafael.tornd.securecomputing.com >To: Michael Richardson >cc: ipsec@tis.com >Subject: Re: Sequence Number >Sender: owner-ipsec@ex.tis.com > >On Sun, 13 Jul 1997, Michael Richardson wrote: > >> Also recall, that in CBC mode, the IV for the next packet likely >> comes from the ciphertext of the last block. > >This would make it impossible to decrypt packets received out of order. > >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 Mon Jul 14 19:53:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02764 for ipsec-outgoing; Mon, 14 Jul 1997 19:51:58 -0400 (EDT) Date: Mon, 14 Jul 1997 16:59:53 -0700 (PDT) Message-Id: <199707142359.QAA15610@servo.qualcomm.com> From: Phil Karn To: barney@databus.com CC: ipsec@tis.com In-reply-to: <33c2a4fe0.346c@databus.databus.com> (message from Barney Wolff on Tue, 8 Jul 1997 16:35 EDT) Subject: Re: ISAKMP performance Sender: owner-ipsec@ex.tis.com Precedence: bulk >The issue of ISAKMP performance has come up on the l2tp list, with >a claim that the Diffie-Hellman negotiation takes too long to be >viable when a box comes up after a failure. Does anyone have any >figures on this, or a URL? If DH performance is a problem (and I'm not saying it is), given Moore's Law and the speed of this working group, it certainly won't be by the time the spec comes out. Phil From owner-ipsec Mon Jul 14 20:28:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA02987 for ipsec-outgoing; Mon, 14 Jul 1997 20:27:58 -0400 (EDT) Message-Id: <199707150035.RAA29674@greatdane.cisco.com> To: Phil Karn cc: barney@databus.com, ipsec@tis.com Subject: Re: ISAKMP performance In-reply-to: Your message of "Mon, 14 Jul 1997 16:59:53 PDT." <199707142359.QAA15610@servo.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Jul 1997 17:35:57 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > >The issue of ISAKMP performance has come up on the l2tp list, with > >a claim that the Diffie-Hellman negotiation takes too long to be > >viable when a box comes up after a failure. Does anyone have any > >figures on this, or a URL? > > If DH performance is a problem (and I'm not saying it is), given > Moore's Law and the speed of this working group, it certainly won't > be by the time the spec comes out. Don't you mean an "implementable" spec? But I think I know the reason for the question. And if ISAKMP could statelessly cache peers' Diffie-Hellman public values even through failover it wouldn't be an issue. But, alas, it doesn't. sigh, Dan. From owner-ipsec Tue Jul 15 07:43:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06672 for ipsec-outgoing; Tue, 15 Jul 1997 07:42:00 -0400 (EDT) From: Barney Wolff To: ipsec@tis.com Date: Mon, 14 Jul 1997 21:37 EDT Subject: Re: ISAKMP performance Content-Type: text/plain Message-ID: <33cad5f50.552a@databus.databus.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Wanna bet there will still be TS vendors with 386-based products who will need to provide an IPSEC software upgrade? 486, for sure. Maybe they will allocate one modem's DSP to run it. Barney > Date: Mon, 14 Jul 1997 16:59:53 -0700 (PDT) > From: Phil Karn > > >The issue of ISAKMP performance has come up on the l2tp list, with > >a claim that the Diffie-Hellman negotiation takes too long to be > >viable when a box comes up after a failure. Does anyone have any > >figures on this, or a URL? > > If DH performance is a problem (and I'm not saying it is), given > Moore's Law and the speed of this working group, it certainly won't > be by the time the spec comes out. > > Phil > From owner-ipsec Tue Jul 15 10:19:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07960 for ipsec-outgoing; Tue, 15 Jul 1997 10:15:49 -0400 (EDT) Message-Id: <199707140646.JAA00212@morden.ssh.fi> To: ipsec@tis.com Subject: Re: ISAKMP Oakley resolution and ipsec doi document questions In-reply-to: Your message of "Mon, 16 Jun 1997 09:58:56 PDT." <01BC7A3B.E8662A40@baiju.jf.intel.com> Date: Mon, 14 Jul 1997 09:43:40 +0300 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Baiju" == Baiju Patel writes: Baiju> There are two specific scenarios using proxies for IPSEC. Let's be specific here: you mean doing proxy key management. I must admit that your second scenario doesn't make sense to me. The situation I understood for proxy ID's in Oakley is when two hosts behind two security gateways are supposed to get per-host keying. You say this in: Baiju> 1. A host wants to initiate a connection to another host, Baiju> and a proxy host in the middle handles IPSEC for it This is Baiju> the case addressed in your response. Typically, (but not Baiju> necessarily), this would be for accessing intranet over a Baiju> firewall by an host on the internet. I find the words "proxy host" to be far too overloaded, and would avoid them. Baiju> 2. A host (daemon) wants to accept connections from other Baiju> hosts and there is a proxy which needs to establish an Baiju> authenticated IPSEC connection to the host before it allows Baiju> traffic to/from it. Baiju> Here is an example. I have a web server www on the Baiju> intranet. For many pragmatic reasons, I do not want to put Baiju> this web server in the DMZ. This web server wants to Baiju> request the firewall that it be allowed to communicate with Baiju> any external host. The way firewall can ensure this (and This is just a tunnel. One end of the tunnel gets a filter of 0.0.0.0/0. I thought that networks with prefix lengths were one of the valid ID types... (I cleared those drafts from my notebook, so I can't quote paragraphs). ] The food on Finnair flights is quite good really | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM8nJp8mxxiPyUBAxAQE+YQMAmDuNQEXE37RBxlG+BPYFAP1RKyvP4s60 paatQBdKMxZB8mbd3xm4IWz26M6gfNhUXpz+OzUT8P46Uz1cUxsslgWQnCiKUh+8 ahYAmBm982S5EXCwrX4RkU3xjentGw3a =qPgv -----END PGP SIGNATURE----- From owner-ipsec Tue Jul 15 10:27:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08066 for ipsec-outgoing; Tue, 15 Jul 1997 10:27:20 -0400 (EDT) Message-Id: <199707151435.JAA19170@gungnir.fnal.gov> To: Daniel Harkins Cc: ipsec@tis.com From: "Matt Crawford" X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Date: Tue, 15 Jul 1997 09:35:12 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk > ... And if ISAKMP could > statelessly cache peers' Diffie-Hellman public values ... I'm trying real hard to think of a meaning for "statelessly cache." Maybe you mean what the routing geeks call "soft state?" From owner-ipsec Tue Jul 15 12:20:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08942 for ipsec-outgoing; Tue, 15 Jul 1997 12:18:54 -0400 (EDT) Message-Id: <199707151627.JAA15997@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Matt Crawford" Cc: ipsec@tis.com Subject: Re: ISAKMP performance In-Reply-To: Your message of "Tue, 15 Jul 1997 09:35:12 CDT." <199707151435.JAA19170@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jul 1997 09:27:01 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > > ... And if ISAKMP could > > statelessly cache peers' Diffie-Hellman public values ... > > I'm trying real hard to think of a meaning for "statelessly cache." > Maybe you mean what the routing geeks call "soft state?" No, state is state. I was trying to be sarcastic. I'd heard that question about ISAKMP D-H performance being too slow when a box comes up after some failure over-and-over during The Great Key Management Wars of 1996. Dan. From owner-ipsec Tue Jul 15 13:54:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09785 for ipsec-outgoing; Tue, 15 Jul 1997 13:53:20 -0400 (EDT) Message-ID: <33CBBA99.2C59@fet.com> Date: Tue, 15 Jul 1997 10:59:53 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: SA semantics References: <33cad5f50.552a@databus.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm new to the list and to ipsec issues in general. I've read RFC's 1825-27 and the latest corresponding drafts, but I'm still a bit confused when trying to walk through the steps a security gw would go through in handling both inbound and outbound packets in terms of SA establishment/lookup. It may be that I am confusing myself by trying to think about manual/static configuration of SA's. In any event, is there either a very clear written elucidation or an example implementation one could study? I know you folks are busy - just point me in the right direction if you can, and I will put in the time... Thanks, Scott From owner-ipsec Tue Jul 15 17:13:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA11190 for ipsec-outgoing; Tue, 15 Jul 1997 17:10:22 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Tue, 15 Jul 1997 13:00:06 -0500 Message-ID: <3CBEB3B0.3000@usr.com> To: Phil Karn , Daniel Harkins Cc: barney@databus.com, ipsec@tis.com Subject: Re[2]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.340200968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.340200968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Being the one who started all of this on the L2TP mailing list, I feel that I should quantify why I thought I had problems with DF performance. Using hardware acceleration, a security server will only be able to generate about 6 SAs/second (assume the DH exchange, the signing and the verification). Now certainly it is possible to add more hardware, but read below before we go on this thread. First an overview of the service. Imagine in the roaming world where a user dials into a local POP and is automatically tunneled to his/her corporate network. In this case, the number of Network Access Servers (NAS) are very large. In addition, the number of corporate networks which will support this service could be ever bigger. Keep in mind that some of the newer NAS' can support upwards to 1000 ports. The problem is this, when a user dials into a NAS, a security association must be established between the NAS and the Security Server at the corporate network (maybe the same box as the firewall). This SA is necessary since the L2TP protocol relies on IPSEC for security and most customers will not want to leave a hole in the firewall. So, since the next time the user will dial-in, chances are he will end up on a different NAS, the new NAS would have to setup the SA. Understandably an SA can have a long life, say based on time. Now certainly to initial boot-up where all the calls come in simultaneously is a problem (about 3 minutes), but let's look at a more serious problem. Say the average call lasts 1 hour, that means that over a 24 hour period a NAS would have to cache about 24000 enties. Assume that an SA takes up about 128 bytes (should be less, but it is easier on the math :) that would be 3Mb of cached SAs. Since we are dealing with embedded boxes, they do not have virtual memory available :( So the problem, in case you have not figured it out, is that the DH exchange is very CPU intensive and is not really a good fit for boxes which need to setup many SAs/second. Unfortunately L2TP, as many other WG, simply point to IPSEC for all security (which is a good thing, but what I have described above is a problem). I would appreciate any thoughts on how IPSEC can be used in the kind of scenario described above. PatC (Phil, I know you were joking with your response below, but some ISPs plan on offering these types of service by Q1 of next year) ______________________________ Reply Separator _________________________________ Subject: Re: ISAKMP performance Author: Daniel Harkins at Internet Date: 7/14/97 5:35 PM > >The issue of ISAKMP performance has come up on the l2tp list, with > >a claim that the Diffie-Hellman negotiation takes too long to be > >viable when a box comes up after a failure. Does anyone have any > >figures on this, or a URL? > > If DH performance is a problem (and I'm not saying it is), given > Moore's Law and the speed of this working group, it certainly won't > be by the time the spec comes out. Don't you mean an "implementable" spec? But I think I know the reason for the question. And if ISAKMP could statelessly cache peers' Diffie-Hellman public values even through failover it wouldn't be an issue. But, alas, it doesn't. sigh, Dan. --IMA.Boundary.340200968 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 3CACE330; Mon, 14 Jul 97 20:11:15 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id TAA12701; Mon, 14 Jul 1997 19:48:54 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA02987 for ipsec-outgoing; Mon, 14 Jul 1997 20:27:58 -0400 (EDT) Message-Id: <199707150035.RAA29674@greatdane.cisco.com> To: Phil Karn cc: barney@databus.com, ipsec@tis.com Subject: Re: ISAKMP performance In-reply-to: Your message of "Mon, 14 Jul 1997 16:59:53 PDT." <199707142359.QAA15610@servo.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Jul 1997 17:35:57 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.340200968-- From owner-ipsec Tue Jul 15 19:22:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11786 for ipsec-outgoing; Tue, 15 Jul 1997 19:21:51 -0400 (EDT) Message-ID: <33CC0789.B24@fet.com> Date: Tue, 15 Jul 1997 16:28:09 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: pcalhoun@usr.com CC: ipsec@tis.com Subject: Re: ISAKMP performance References: <3CBEB3B0.3000@usr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm pretty new here on ipsec, but I've been lurking on L2TP for months, so I'm jumping in. If the corporate firewall supports IPsec, the user has *no need* for l2tp. The user can run IPsec from his laptop to the firewall, with no regard for the PPP connection to the pop. The only thing making l2tp (or l2f, or pptp) attractive at this point is that IPsec isn't finished. Scott From owner-ipsec Wed Jul 16 07:31:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15587 for ipsec-outgoing; Wed, 16 Jul 1997 07:29:20 -0400 (EDT) Date: Tue, 15 Jul 1997 18:21:55 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: pcalhoun@usr.com cc: ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance In-Reply-To: <3CBEB3B0.3000@usr.com> Message-Id: <97Jul15.181623edt.11649@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 15 Jul 1997 pcalhoun@usr.com wrote: > Using hardware acceleration, a security server will only be able to > generate about 6 SAs/second (assume the DH exchange, the signing and > the verification). Now certainly it is possible to add more hardware, > but read below before we go on this thread. > > Keep in mind that some of the newer NAS' can support upwards to 1000 > ports. > > Understandably an SA can have a long life, say based on time. > > Now certainly to initial boot-up where all the calls come in > simultaneously is a problem (about 3 minutes), but let's look at a > more serious problem. Say the average call lasts 1 hour, that means > that over a 24 hour period a NAS would have to cache about 24000 > enties. Assume that an SA takes up about 128 bytes (should be less, > but it is easier on the math :) that would be 3Mb of cached SAs. Since > we are dealing with embedded boxes, they do not have virtual memory > available :( Having dynamic SAs time out after an idle period of say 4 hours would mean that even a fully loaded NAS would never have to cache more than 5,000 SAs, which only takes 625 KB. 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 Jul 16 09:27:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16635 for ipsec-outgoing; Wed, 16 Jul 1997 09:24:50 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Wed, 16 Jul 1997 08:13:16 -0500 Message-ID: <3CCCFE60.3000@usr.com> To: "Scott G. Kelly" Cc: ipsec@tis.com Subject: Re[2]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.285060968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.285060968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part No. L2TP provides you with address negotitation and multi-protocol, which are inherent to PPP. PatC ______________________________ Reply Separator _________________________________ Subject: Re: ISAKMP performance Author: "Scott G. Kelly" at Internet Date: 7/15/97 4:28 PM I'm pretty new here on ipsec, but I've been lurking on L2TP for months, so I'm jumping in. If the corporate firewall supports IPsec, the user has *no need* for l2tp. The user can run IPsec from his laptop to the firewall, with no regard for the PPP connection to the pop. The only thing making l2tp (or l2f, or pptp) attractive at this point is that IPsec isn't finished. Scott --IMA.Boundary.285060968 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 3CC0A9F0; Tue, 15 Jul 97 18:41:19 -0500 Received: from vogue.fet.com by usr.com (8.7.5/3.1.090690-US Robotics) id SAA29805; Tue, 15 Jul 1997 18:18:56 -0500 (CDT) Received: from vogue.fet.com (toro.fet.com [192.203.72.38]) by vogue.fet.com (8.6.12+2.5Wb7/3.4W202/15/96) with SMTP id QAA09775; Tue, 15 Jul 1997 16:29:34 -0700 Message-ID: <33CC0789.B24@fet.com> Date: Tue, 15 Jul 1997 16:28:09 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: pcalhoun@usr.com CC: ipsec@tis.com Subject: Re: ISAKMP performance References: <3CBEB3B0.3000@usr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --IMA.Boundary.285060968-- From owner-ipsec Wed Jul 16 10:13:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17066 for ipsec-outgoing; Wed, 16 Jul 1997 10:11:28 -0400 (EDT) Message-Id: <199707161423.RAA03259@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance In-reply-to: Your message of "Tue, 15 Jul 1997 18:21:55 EDT." <97Jul15.181623edt.11649@janus.tor.securecomputing.com> Date: Wed, 16 Jul 1997 17:23:41 +0300 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Tue, 15 Jul 1997 pcalhoun@usr.com wrote: >> Now certainly to initial boot-up where all the calls come in >> simultaneously is a problem (about 3 minutes), but let's look >> at a more serious problem. Say the average call lasts 1 hour, >> that means that over a 24 hour period a NAS would have to cache >> about 24000 enties. Assume that an SA takes up about 128 bytes >> (should be less, but it is easier on the math :) that would be >> 3Mb of cached SAs. Since we are dealing with embedded boxes, >> they do not have virtual memory available :( >>>>> "Norman" == Norman Shulman writes: Norman> Having dynamic SAs time out after an idle period of say 4 Norman> hours would mean that even a fully loaded NAS would never Norman> have to cache more than 5,000 SAs, which only takes 625 Norman> KB. Another way to solve this is to realize that the NAS doesn't store the user authentication database locally either. The long term SA (spi+keys) can be stored in the radius/tacacs server. This is desirable, since the user may login to different NAS servers each day. Clearly, the keys need to be protected in transit. IPsec between the NAS and authentication server should provide that (or a physically secure wire may be appropriate). Some might worry that the keys aren't well enough protected: however, if the user authentication packets are not breakable, then the bad guy can just impersonate the user logging into the NAS anyway. ] It isn't that sun never sets; rather dawn and dusk are united | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM8zZYMmxxiPyUBAxAQGw4QMArjH9gXj2zFhnoMiuXp9ilb+u757+dINe faynkCdEi7hHtCc7m1tyA36C5pwXdR+QgtmJH0LfzM1tVF4cD5Yn2SeJyVJrL1so f/umxFmbmmZi24d6CQeZ3FLjzafM4khJ =rvFV -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 16 10:14:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17106 for ipsec-outgoing; Wed, 16 Jul 1997 10:14:23 -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-mcdonald-pf-key-v2-03.txt Date: Wed, 16 Jul 1997 09:40:13 -0400 Message-ID: <9707160940.aa06770@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 : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, C. Metz, B Phan Filename : draft-mcdonald-pf-key-v2-03.txt Pages : 67 Date : 07/15/1997 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a,HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon). 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-mcdonald-pf-key-v2-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-03.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-mcdonald-pf-key-v2-03.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: <19970715153208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970715153208.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jul 16 10:34:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17323 for ipsec-outgoing; Wed, 16 Jul 1997 10:30:28 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199707161433.HAA17461@netcom13.netcom.com> Subject: Re: Re[2]: ISAKMP performance To: norm@tor.securecomputing.com (Norman Shulman) Date: Wed, 16 Jul 1997 07:33:03 -0700 (PDT) Cc: pcalhoun@usr.com, ipsec@tis.com In-Reply-To: <97Jul15.181623edt.11649@janus.tor.securecomputing.com> from "Norman Shulman" at Jul 15, 97 06:21:55 pm 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: 561 > > On Tue, 15 Jul 1997 pcalhoun@usr.com wrote: > > > Using hardware acceleration, a security server will only be able to > > generate about 6 SAs/second (assume the DH exchange, the signing and > > the verification). Now certainly it is possible to add more hardware, > > but read below before we go on this thread. > > 6 key setups per second is too slow. I believe about 1000/sec will be needed (in software). - Alex -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Wed Jul 16 11:35:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17696 for ipsec-outgoing; Wed, 16 Jul 1997 11:31:43 -0400 (EDT) Date: Wed, 16 Jul 1997 10:38:09 -0500 Message-Id: <199707161538.KAA09505@beavis.smallworks.com> From: Jim Thompson To: mcr@sandelman.ottawa.on.ca CC: ipsec@tis.com In-reply-to: <199707161423.RAA03259@morden.sandelman.ottawa.on.ca> (message from Michael Richardson on Wed, 16 Jul 1997 17:23:41 +0300) Subject: Re: ISAKMP performance Sender: owner-ipsec@ex.tis.com Precedence: bulk > Another way to solve this is to realize that the NAS doesn't store > the user authentication database locally either. The long term SA > (spi+keys) can be stored in the radius/tacacs server. This is > desirable, since the user may login to different NAS servers each > day. Clearly, the keys need to be protected in transit. IPsec between > the NAS and authentication server should provide that (or a physically > secure wire may be appropriate). I think its been shown that RADIUS, in particular, isn't anywhere near secure enough for this. -- Jim Thompson / Smallworks, Inc. / jim@smallworks.com 512 338 0619 phone / 512 338 0625 fax "Hiroshima '45, Chernobyl '86, Windows '95" From owner-ipsec Wed Jul 16 12:35:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18385 for ipsec-outgoing; Wed, 16 Jul 1997 12:33:27 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Wed, 16 Jul 1997 10:25:11 -0500 Message-ID: <3CCF77D0.3000@usr.com> To: Norman Shulman Cc: ipsec@tis.com Subject: Re[4]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.717070968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.717070968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Maybe you misunderstood my point. With the number of simultaneous calls that I have to take, DH is too much of a hit. Cache an entry for four hours is sort-of useless since the next time around the user will hit a different NAS anyways, which will need to negotiate an SA. My problem is the time it takes to do the DH exchange. PatC ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: ISAKMP performance Author: Norman Shulman at Internet Date: 7/15/97 6:21 PM On Tue, 15 Jul 1997 pcalhoun@usr.com wrote: > Using hardware acceleration, a security server will only be able to > generate about 6 SAs/second (assume the DH exchange, the signing and > the verification). Now certainly it is possible to add more hardware, > but read below before we go on this thread. > > Keep in mind that some of the newer NAS' can support upwards to 1000 > ports. > > Understandably an SA can have a long life, say based on time. > > Now certainly to initial boot-up where all the calls come in > simultaneously is a problem (about 3 minutes), but let's look at a > more serious problem. Say the average call lasts 1 hour, that means > that over a 24 hour period a NAS would have to cache about 24000 > enties. Assume that an SA takes up about 128 bytes (should be less, > but it is easier on the math :) that would be 3Mb of cached SAs. Since > we are dealing with embedded boxes, they do not have virtual memory > available :( Having dynamic SAs time out after an idle period of say 4 hours would mean that even a fully loaded NAS would never have to cache more than 5,000 SAs, which only takes 625 KB. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@tor.securecomputing.com Fax 1 416 813 2001 --IMA.Boundary.717070968 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 3CCCC680; Wed, 16 Jul 97 08:28:09 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id IAA20031; Wed, 16 Jul 1997 08:05:44 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15587 for ipsec-outgoing; Wed, 16 Jul 1997 07:29:20 -0400 (EDT) Date: Tue, 15 Jul 1997 18:21:55 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: pcalhoun@usr.com cc: ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance In-Reply-To: <3CBEB3B0.3000@usr.com> Message-Id: <97Jul15.181623edt.11649@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.717070968-- From owner-ipsec Wed Jul 16 14:06:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19278 for ipsec-outgoing; Wed, 16 Jul 1997 14:02:29 -0400 (EDT) Message-Id: <199707161738.KAA16981@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: andrade@netcom.com (Andrade Software Andrade Networking) Cc: norm@tor.securecomputing.com (Norman Shulman), pcalhoun@usr.com, ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance In-Reply-To: Your message of "Wed, 16 Jul 1997 07:33:03 PDT." <199707161433.HAA17461@netcom13.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Jul 1997 10:38:40 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten wrote: > > On Tue, 15 Jul 1997 pcalhoun@usr.com wrote: > > > > > Using hardware acceleration, a security server will only be able to > > > generate about 6 SAs/second (assume the DH exchange, the signing and > > > the verification). Now certainly it is possible to add more hardware, > > > but read below before we go on this thread. > > > > > 6 key setups per second is too slow. I believe about 1000/sec > will be needed (in software). Is your local service provider using a cray as his NAS? You're not gonna see a D-H exchanges with any realistic prime plus a digital sign and verify with any reasonably secure modulus in anything close to 1/1000 of a second! FAST, CHEAP, SECURE: pick any two. And this has _nothing_ to do with ISAKMP either; any scheme which authenticates a Diffie-Hellman with digital signatures-- like SKIP or Photuris-- would have similar performance. Dan. From owner-ipsec Wed Jul 16 19:01:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21325 for ipsec-outgoing; Wed, 16 Jul 1997 19:00:31 -0400 (EDT) Date: Wed, 16 Jul 1997 19:08:05 -0400 Message-Id: <199707162308.TAA29659@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Daniel Harkins Cc: andrade@netcom.com, norm@tor.securecomputing.com, pcalhoun@usr.com, ipsec@tis.com In-Reply-To: Daniel Harkins's message of Wed, 16 Jul 1997 10:38:40 -0700, <199707161738.KAA16981@dharkins-ss20> Subject: Re: Re[2]: ISAKMP performance Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 16 Jul 1997 10:38:40 -0700 From: Daniel Harkins Is your local service provider using a cray as his NAS? You're not gonna see a D-H exchanges with any realistic prime plus a digital sign and verify with any reasonably secure modulus in anything close to 1/1000 of a second! FAST, CHEAP, SECURE: pick any two. And this has _nothing_ to do with ISAKMP either; any scheme which authenticates a Diffie-Hellman with digital signatures-- like SKIP or Photuris-- would have similar performance. Dan's absolutely right. Your only other choice if you need that kind of authentication speed is to use a system based on secret-key technology, such as Kerberos. (Hint: there's a reason why Microsoft selected Kerberos as its authentication technology for intra-domain authentication for NT.) - Ted From owner-ipsec Wed Jul 16 23:00:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22544 for ipsec-outgoing; Wed, 16 Jul 1997 22:56:35 -0400 (EDT) Message-Id: <3.0.1.16.19970716230646.0aa75f70@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Wed, 16 Jul 1997 23:06:46 -0400 To: "Theodore Y. Ts'o" , Daniel Harkins From: David Jablon Subject: Re: Re[2]: ISAKMP performance Cc: andrade@netcom.com, norm@tor.securecomputing.com, pcalhoun@usr.com, ipsec@tis.com In-Reply-To: <199707162308.TAA29659@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Regarding the speed of strong authentication ... Daniel Harkins wrote: > Is your local service provider using a cray as his NAS? You're not gonna > see a D-H exchanges with any realistic prime plus a digital sign and verify > with any reasonably secure modulus in anything close to 1/1000 of a second! > > FAST, CHEAP, SECURE: pick any two. > > And this has _nothing_ to do with ISAKMP either; any scheme which > authenticates a Diffie-Hellman with digital signatures-- like SKIP or > Photuris-- would have similar performance. At 07:08 PM 7/16/97 -0400, Theodore Y. Ts'o replied: >Dan's absolutely right. >Your only other choice if you need that kind of authentication speed is >to use a system based on secret-key technology, such as Kerberos. Not quite. See below. >(Hint: there's a reason why Microsoft selected Kerberos as its >authentication technology for intra-domain authentication for NT.) But it's not necessarily a good reason. There are much stronger methods, such as password-authenticated Diffie-Hellman exchanges EKE, SPEKE, etc. Some of these have nice scalability characteristics, so that they can use a small DH modulus, and still be much more resistant to passive dictionary attack than Kerberos. The principle is that solving a small discrete log problem is at least a lot harder than computing a fast hash. Or, to paraphrase Dan ... FAST, CHEAP, at least a lot more SECURE: Why not pick all three? -- David ------------------------------------ David Jablon Integrity Sciences, Inc. tel: +1 508 898 9024 web: http://world.std.com/~dpj/ email: dpj@world.std.com From owner-ipsec Thu Jul 17 14:18:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27024 for ipsec-outgoing; Thu, 17 Jul 1997 14:14:16 -0400 (EDT) Message-Id: <3.0.32.19970717112006.009f7e00@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Jul 1997 11:20:06 -0700 To: piper@tgv.com, ipsec@tis.com From: John Burke Subject: format of name ID's in ISAKMP IP DOI Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Isn't there a need for clarification in the ISAKMP IP DOI document, about ID payloads whose content is a string? These questions: o May any blanks be present? o Any trailing terminator? o When this content gets hashed, how much of it is included? o Other possible variations which I forgot? The situation is aggravated considering the ID payload might have to be padded out (I don't remember a responsible party giving a clear indication what ISAKMP v-08 will say, nor do I remember consensus). Remember there is no inner definition of exactly how long a name string is. - John Burke Cylink, Sunnyvale, CA From owner-ipsec Thu Jul 17 14:18:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26929 for ipsec-outgoing; Thu, 17 Jul 1997 14:03:10 -0400 (EDT) Message-Id: <3.0.32.19970717110859.00955a30@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Jul 1997 11:09:00 -0700 To: ipsec@tis.com From: John Burke Subject: Re: Exchanging Certificate Chains Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:27 AM 7/16/97 -0400, Dave Mason wrote: >> But, nothing in isakmp-oakley-v.txt should be interpreted as >>forcing a certain order on payloads. You can send the nonce before the key > >I would have to differ with you here. The first paragraph of Section 4 >states that the order in which the payloads are processed is defined by >the specification and the sections that describe the exchanges generally >go like this: > > ..... Mode is defined as: > > HDR, A, B, C [ ... ] >I think that the MUST used here was meant more for the fact that ID >payloads for both of the endpoints must be sent so that the appropriate >security policy may be selected. [The order was already defined in >the exchange definition.] > >-dave and, At 10:12 AM 7/16/97 -0700, Daniel Harkins wrote: >Well since I wrote those words I think I know what I meant. Granted, > [ ... ] Hopefully isakmp-oakley-v4 will be more clear. The contributers to this subject seem to agree that one should be able to accept payloads in arbitrary order, with the possible exception of the Quick Mode Hashes 1 and 2; no one has screamed in objection. Probably most implementers, being Real Programmers, have written their receive code this way. But the current state of affairs is isakmp-oakley v-03 says or implies otherwise as Dave Mason points out. Dan H. makes a general statement that he doesn't mean it to be that way. So people are saying they think they know how it is; but we will keep needing to raise the question if we are not assured by the spec or by a definite statement about what's going into it. Can we hope that isakmp-oakley-v4 will confirm these points: o An exchange defines those payloads which are required in each message. In general each message description does not imply required order of payloads; any required ordering is explicitly noted in the particular exchange description. o In Quick Mode, the Hash 1 and Hash 2 payloads must appear immediately before that remaining part of the message which is to be hashed. [Expecting this would be the least objectionable tack; I expect at least some implementors have, reasonably enough, depended on this ordering, which is in fact explicit in isakmp-oakley v03, and I see no argument for a change at this point.] [The words about leaving out the pad added by encryption roundup I am presuming would stay the same.] I would also like to suggest some clarification in the isakmp-oakley discussion of the QM Hash 1 and 2. First it states clearly that the hash is over the message; but then it says that in other words the hashes are: HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) (and updated per Harkins mail Fri, 16 May 1997 accepted by the participants in the June Detroit interworking tests:) HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr | [ | KE ] [ | IDui | IDur ]) I think notation here is troublesome to the reader, because all those symbolics for payloads usually mean the content without the header, and in this case they mean including the header, which I think it confuses the issue. And in the new statement of Hash 2, the symbolic "Ni" means content only, while "Nr" means with header, so Dan Harkins assured me in response to private mail. Might it be done something like this: HASH(1) = prf(SKEYID_a, M-ID | ) HASH(2) = prf(SKEYID_a, M-ID | Ni | ) Where message body is all message bytes following the hash payload, through the last payload; these payloads must include: SA | Ni [ | KE ] [ | IDui | IDur ] As long as I'm asking for things, I'll also request something to this effect on QM first and second messages: o If the initiator of QM sends KE, an SA with PFS is being established, and the responder must return KE. Otherwise no KE's should appear. o If the initiator of QM sends [ IDui | IDur ], then the responder must include them in the response. Otherwise no ID's should appear. John Burke Cylink, Sunnyvale CA From owner-ipsec Thu Jul 17 14:31:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27102 for ipsec-outgoing; Thu, 17 Jul 1997 14:28:09 -0400 (EDT) Date: Thu, 17 Jul 1997 11:11:47 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: ipsec@tis.com Subject: draft-ietf-ipsec-ciph-des-derived-00 Message-Id: <97Jul17.110708edt.11649@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Page 4, 4.2, paragraph 2: Suggest adding the following sentence (copied from 4.3): "Alternatively, the least significant bit of each key byte is ignored, or locally set to parity by the DES implementation." Page 6, Pad Values, Range: Should be 1 to 255. 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 Thu Jul 17 17:04:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28251 for ipsec-outgoing; Thu, 17 Jul 1997 17:00:44 -0400 (EDT) Date: Thu, 17 Jul 1997 17:06:46 -0400 Message-Id: <199707172106.RAA03411@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: David Jablon Cc: "Theodore Y. Ts'o" , Daniel Harkins , andrade@netcom.com, norm@tor.securecomputing.com, pcalhoun@usr.com, ipsec@tis.com In-Reply-To: David Jablon's message of Wed, 16 Jul 1997 23:06:46 -0400, <3.0.1.16.19970716230646.0aa75f70@world.std.com> Subject: Re: Re[2]: ISAKMP performance Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 16 Jul 1997 23:06:46 -0400 From: David Jablon But it's not necessarily a good reason. There are much stronger methods, such as password-authenticated Diffie-Hellman exchanges EKE, SPEKE, etc. Small Diffie-Hellman moduli are easily broken. However, discussion of these topics aren't really germane to the ipsec working group, so I suggest we take this discussion elsewhere. Discussion of the possibility of designing some other key management protocol for ipsec is (barely) in order, although at this point if this discussion gets extensive Bob and I would probably recommend starting a separate working group to avoid bogging down existing efforts. - Ted From owner-ipsec Fri Jul 18 07:53:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02610 for ipsec-outgoing; Fri, 18 Jul 1997 07:47:43 -0400 (EDT) Message-Id: <3.0.1.32.19970718075120.00a029f0@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, 18 Jul 1997 07:51:20 -0400 To: "Theodore Y. Ts'o" , David Jablon From: Robert Moskowitz Subject: Re: Re[2]: ISAKMP performance Cc: "Theodore Y. Ts'o" , Daniel Harkins, andrade@netcom.com, norm@tor.securecomputing.com, pcalhoun@usr.com, ipsec@tis.com In-Reply-To: <199707172106.RAA03411@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:06 PM 7/17/97 -0400, Theodore Y. Ts'o wrote: > >Discussion of the possibility of designing some other key management >protocol for ipsec is (barely) in order, although at this point if this >discussion gets extensive Bob and I would probably recommend starting a >separate working group to avoid bogging down existing efforts. > AFTER we finish with the current work, considered proposals on things like replacing Diffie-Hellman moduli with eliptic curve groups (do I have that worded right :) will be collected to see if there is a basis for chartering a NEW workgroup. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Jul 18 09:46:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA03502 for ipsec-outgoing; Fri, 18 Jul 1997 09:45:41 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Fri, 18 Jul 1997 07:52:25 -0500 Message-ID: <3CF77EA0.3000@usr.com> To: "Theodore Y. Ts'o" , David Jablon , Robert Moskowitz Cc: Daniel Harkins, andrade@netcom.com, norm@tor.securecomputing.com, ipsec@tis.com Subject: Re[4]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.666432968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.666432968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Bob and Theo, Thanks for the input. However, I am faced with a bit of a problem. You see most WG blindly point to IPSEC for all security needs, not necessarily understanding whether it fits or not. I think that I have brought up a scenario where IPSEC (or rather DH exchange) does not scale very well. I would like the IPSEC WG to inform other WGs currently looking at using it about this possible scaleability problem. Otherwise, we will end up with protocols that really do not work very well in large networks. My main concern here is that L2TP will have a draft pushed for proposed standard by Munich with interoperability by mid-september. There are MANY customers which want to run this protocol to provide access to corporate networks. However, without a security infrastructure that scales well, they will be in for a surprise. Bob, due to your position (at Chrysler) I hope you understand my position (and Theo as well :). This is not meant as a direct attack at IPSEC. I like IPSEC, but I think that the WG needs to at least realize that the current protocol does have scaling problems. Thanks, PatC 3Com ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: ISAKMP performance Author: Robert Moskowitz at Internet Date: 7/18/97 7:51 AM At 05:06 PM 7/17/97 -0400, Theodore Y. Ts'o wrote: > >Discussion of the possibility of designing some other key management >protocol for ipsec is (barely) in order, although at this point if this >discussion gets extensive Bob and I would probably recommend starting a >separate working group to avoid bogging down existing efforts. > AFTER we finish with the current work, considered proposals on things like replacing Diffie-Hellman moduli with eliptic curve groups (do I have that worded right :) will be collected to see if there is a basis for chartering a NEW workgroup. Robert Moskowitz Chrysler Corporation (810) 758-8212 --IMA.Boundary.666432968 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 3CF5C6A0; Fri, 18 Jul 97 07:07:06 -0500 Received: from dilbert.is.chrysler.com by usr.com (8.7.5/3.1.090690-US Robotics) id GAA28530; Fri, 18 Jul 1997 06:44:42 -0500 (CDT) Received: by dilbert.is.chrysler.com; id HAA04184; Fri, 18 Jul 1997 07:53:31 -0400 (EDT) Received: from nsn1-gw5-xl1.netrex.com(206.253.228.11) by dilbert.is.chrysler.com via smap (3.2) id xma004180; Fri, 18 Jul 97 07:53:08 -0400 Message-Id: <3.0.1.32.19970718075120.00a029f0@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, 18 Jul 1997 07:51:20 -0400 To: "Theodore Y. Ts'o" , David Jablon From: Robert Moskowitz Subject: Re: Re[2]: ISAKMP performance Cc: "Theodore Y. Ts'o" , Daniel Harkins, andrade@netcom.com, norm@tor.securecomputing.com, pcalhoun@usr.com, ipsec@tis.com In-Reply-To: <199707172106.RAA03411@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" --IMA.Boundary.666432968-- From owner-ipsec Fri Jul 18 12:36:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04551 for ipsec-outgoing; Fri, 18 Jul 1997 12:35:42 -0400 (EDT) Date: Fri, 18 Jul 1997 12:43:33 -0400 Message-Id: <199707181643.MAA01996@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: pcalhoun@usr.com Cc: "Theodore Y. Ts'o" , David Jablon , Robert Moskowitz , Daniel Harkins, andrade@netcom.com, norm@tor.securecomputing.com, ipsec@tis.com In-Reply-To: pcalhoun@usr.com's message of Fri, 18 Jul 1997 07:52:25 -0500, <3CF77EA0.3000@usr.com> Subject: Re: Re[4]: ISAKMP performance Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 18 Jul 1997 07:52:25 -0500 From: pcalhoun@usr.com Thanks for the input. However, I am faced with a bit of a problem. You see most WG blindly point to IPSEC for all security needs, not necessarily understanding whether it fits or not. I think that I have brought up a scenario where IPSEC (or rather DH exchange) does not scale very well. I would like the IPSEC WG to inform other WGs currently looking at using it about this possible scaleability problem. Otherwise, we will end up with protocols that really do not work very well in large networks. The IPSEC working group (like other working groups :-) doesn't have a publicity arm which can use to do as you ask. It would be fair to ask some ISAKMP/Oakley implementors to post some benchmark numbers for their various implementations, though. It has always been the position of the Security Area Director and Security Area Directorate that it is not approrpiate for working groups to "blindly pointing to IPSEC for all their security needs". Like everything else, thought is required --- real analysis about how the application protocol will get used, by whom, etc., etc. Unfortunately, some combination of laziness and lack of security people in certain working groups has caused a number of working groups to adopt this attitude. Basically, they erect a "Sombody Else's Problem" field and then become surprised when they get fooed upon either at IETF Last Call or by the IESG. This is not a new problem, and I wish I had better answers for you. If anyone has any suggestions, feel free to send mail to secdir@mit.edu or saag@tis.com.... - Ted From owner-ipsec Fri Jul 18 14:07:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05208 for ipsec-outgoing; Fri, 18 Jul 1997 14:06:13 -0400 (EDT) Content-Type: Multipart/Mixed; Boundary="NextPart" 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-ciph-blowfish-cbc-00.txt Date: Fri, 18 Jul 1997 14:11:12 -0400 Message-ID: <9707181411.aa11333@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 Blowfish-CBC Algorithm Using an Explicit IV Author(s) : R. Adams Filename : draft-ietf-ipsec-ciph-blowfish-cbc-00.txt Pages : 6 Date : 07/17/1997 This draft describes the use of the Blowfish [Schneier] block cipher algorithm to be used with the IPSec Encapsulating Security Payload (ESP) [Kent97]. 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-ciph-blowfish-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-blowfish-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-ciph-blowfish-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: <19970718133832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-blowfish-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-blowfish-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970718133832.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 21 10:39:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23562 for ipsec-outgoing; Mon, 21 Jul 1997 10:32:46 -0400 (EDT) Date: Mon, 21 Jul 1997 10:39:37 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199707211439.KAA25601@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Theodore Y. Ts'o" > > Discussion of the possibility of designing some other key management > protocol for ipsec is (barely) in order, although at this point if this > discussion gets extensive Bob and I would probably recommend starting a > separate working group to avoid bogging down existing efforts. Before designing some other key management protocol, it would be worthwhile considering if the existing protocol can meet the performance requirements. ISAKMP was designed to use two phases precisely to allow the sort of performance tradeoffs being discussed. It seems to me that a NAS which required 1000 SA establishments per second, with, say, an average connection lifetime of 5 minutes (300 seconds), would be capable of supporting 300,000 simultaneous connections! I would expect such a mongo box to have enough non-volatile memory (disk or flash) to be able to cache enough phase 1 SAs to reduce the miss rate (the required rate of D-H calculations) to acceptably low levels. What size KDC would it take to support N NASes, each doing 1000 connections per second? From owner-ipsec Mon Jul 21 11:36:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24143 for ipsec-outgoing; Mon, 21 Jul 1997 11:35:15 -0400 (EDT) Message-Id: <97Jul21.113827edt.11650@janus.tor.securecomputing.com> To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance References: <199707211439.KAA25601@argon.ncsc.mil> In-reply-to: Your message of "Mon, 21 Jul 1997 10:39:37 -0400". <199707211439.KAA25601@argon.ncsc.mil> 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: Mon, 21 Jul 1997 11:43:11 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199707211439.KAA25601@argon.ncsc.mil>, David P. Kemp writes: > It seems to me that a NAS which > required 1000 SA establishments per second, with, say, an average > connection lifetime of 5 minutes (300 seconds), would be capable of > supporting 300,000 simultaneous connections! Not quite. The 1000/second refers to a reset or power outage, where you get slammed with (e.g.) 1000 simultaneous incoming calls. This is peak load; the average call-cycle load would be much lower (~200/minute, or merely 3.3/second :-). -- Harald Koch From owner-ipsec Mon Jul 21 12:21:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24611 for ipsec-outgoing; Mon, 21 Jul 1997 12:20:48 -0400 (EDT) Message-Id: <199707211628.JAA27480@relay.hp.com> To: "C. Harald Koch" Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance In-Reply-To: chk's message of Mon, 21 Jul 1997 11:43:11 -0400. <97Jul21.113827edt.11650@janus.tor.securecomputing.com> Date: Mon, 21 Jul 1997 12:28:38 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Not quite. The 1000/second refers to a reset or power outage, where you get > slammed with (e.g.) 1000 simultaneous incoming calls. This is peak load; the > average call-cycle load would be much lower (~200/minute, or merely > 3.3/second :-). If this is the case, it sounds like the original requirement was poorly stated. Is the *actual* requirement "must be able to withstand a burst of several thousand SA requests over several seconds without falling over"? If it gets the burst, and then takes a minute or two to chew through all of them (without dropping any), is that OK? - Bill From owner-ipsec Mon Jul 21 17:04:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26975 for ipsec-outgoing; Mon, 21 Jul 1997 17:02:32 -0400 (EDT) Message-Id: <01BC95F9.1ACA6B80@erussell-1.ftp.com> From: "Edward A. Russell" To: "'ipsec@tis.com'" Subject: FW: private use ISAKMP attributes Date: Mon, 21 Jul 1997 17:10:41 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins (dharkins@cisco.com) said on 7/21/97 at 4:51 PM > What would _your_ ISAKMP implementation do if I gave you the following >phase 1 offer? > > class value > ----- ----- > 1 1 (DES-CBC for encryption) > 2 2 (SHA for hash) > 3 1 (pre-shared key authentication) > 4 1 (default D-H group 1) > 11 65001 (life type of some private use value) > >Would you reject it because you don't know what a life type of 65001 is or >would you accept it because that life type means nothing to you and the >offer is, otherwise, acceptable? > >Would it make a difference if I also offered this along with the above? > > class value > ----- ----- > 12 (basic) 47 (life duration of 47 something-or-others) > >Similarly, what if I offered (as part of an otherwise acceptable offer) a >private use class: > > class value > ----- ----- > 65001 47 (?????) > >Acceptable or not? > > Dan. > > I have no choice but to reject it. If I accept it, I am promising to obey and perform what your private attribute says to do. It may be something superfluos like a special lifetype which if ignored, your side will timeout anyway. But I don't know that. It may be something real important that if I don't obey will either cause un-interoperability or may cause a security hole. I suggest you offer your proposal containing private parts and also offer a "standard" proposal. That way, if you are talking to someone who understands your privates, they will accept and obey, otherwise they'll pick your standard proposal. Of course with private attribute types, there can be conflict between two vendors who pick the same number for different things (hint: don't pick the first number in the private range). We need to be able to register a standard Private Scheme Attribute Class or something. Ultimately, it is left up to the user or administrator to configure proposals for specific systems knowing ahead of time which use the private schemes and which are strictly standard. Edward Russell erussell@ftp.com Edward Russell erussell@ftp.com From owner-ipsec Mon Jul 21 17:13:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27044 for ipsec-outgoing; Mon, 21 Jul 1997 17:13:02 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Mon, 21 Jul 1997 16:00:02 -0500 Message-ID: <3D3D3330.3000@usr.com> To: "C. Harald Koch" , Bill Sommerfeld Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re[4]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.971025968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.971025968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part THe problem is that if it does get this "burst", the PPP connections (which L2TP is carrying) will timeout. Effectively a denial of service. BTW, 1000/sec was not a realistic number. This is the number of ports that we will support today, but with densities going up we may need to support 3000 in a year. Supporting a total of, say, 6 a second is really too low. PatC ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: ISAKMP performance Author: Bill Sommerfeld at Internet Date: 7/21/97 12:28 PM > Not quite. The 1000/second refers to a reset or power outage, where you get > slammed with (e.g.) 1000 simultaneous incoming calls. This is peak load; the > average call-cycle load would be much lower (~200/minute, or merely > 3.3/second :-). If this is the case, it sounds like the original requirement was poorly stated. Is the *actual* requirement "must be able to withstand a burst of several thousand SA requests over several seconds without falling over"? If it gets the burst, and then takes a minute or two to chew through all of them (without dropping any), is that OK? - Bill --IMA.Boundary.971025968 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 3D397D20; Mon, 21 Jul 97 12:09:38 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id LAA13061; Mon, 21 Jul 1997 11:47:02 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24611 for ipsec-outgoing; Mon, 21 Jul 1997 12:20:48 -0400 (EDT) Message-Id: <199707211628.JAA27480@relay.hp.com> To: "C. Harald Koch" Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Re[2]: ISAKMP performance In-Reply-To: chk's message of Mon, 21 Jul 1997 11:43:11 -0400. <97Jul21.113827edt.11650@janus.tor.securecomputing.com> Date: Mon, 21 Jul 1997 12:28:38 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.971025968-- From owner-ipsec Mon Jul 21 17:16:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27072 for ipsec-outgoing; Mon, 21 Jul 1997 17:16:02 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707212123.OAA17442@kebe.eng.sun.com> Subject: "Default" cipher and authenticator To: ipsec@tis.com Date: Mon, 21 Jul 1997 14:23:30 -0700 (PDT) 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 Hello! What are the minimum default cipher algorithms and authenticator algorithms currently? From what I can tell: AUTHENTICATORS CIPHERS ============== ======= HMAC-MD5-96 DES-CBC (explicit IV) HMAC-SHA-1-96 And when I say "Authenticator" I mean an algorithm that works for both AH and ESP largely unmodified. So I use the exact HMAC-SHA-1-96 algorithm for both AH and combined ESP transforms. If any of my assumptions here are wrong, I'd appreciate a quick and timely correction, sent to the list as well, so we don't get confused. Thanks! -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Mon Jul 21 18:10:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27390 for ipsec-outgoing; Mon, 21 Jul 1997 18:09:33 -0400 (EDT) Message-Id: <3.0.1.32.19970721181204.007da320@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 21 Jul 1997 18:12:04 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: "Default" cipher and authenticator Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I didn't think we made SHA-1 part of the minimum default. I thought it was just HMAC MD5. I agree with the DES CBC Explicit IV. >From: Dan.McDonald@eng.sun.com (Dan McDonald) >Subject: "Default" cipher and authenticator >To: ipsec@tis.com >Date: Mon, 21 Jul 1997 14:23:30 -0700 (PDT) >Sender: owner-ipsec@ex.tis.com > >Hello! > >What are the minimum default cipher algorithms and authenticator algorithms >currently? From what I can tell: > >AUTHENTICATORS CIPHERS >============== ======= >HMAC-MD5-96 DES-CBC (explicit IV) >HMAC-SHA-1-96 > >And when I say "Authenticator" I mean an algorithm that works for both AH and >ESP largely unmodified. So I use the exact HMAC-SHA-1-96 algorithm for both >AH and combined ESP transforms. > >If any of my assumptions here are wrong, I'd appreciate a quick and timely >correction, sent to the list as well, so we don't get confused. > >Thanks! >-- >Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT >Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! >Phone: (415) 786-6815 |"rising falling at force ten >WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush > > From owner-ipsec Mon Jul 21 18:10:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27396 for ipsec-outgoing; Mon, 21 Jul 1997 18:10:07 -0400 (EDT) Date: Mon, 21 Jul 1997 18:15:48 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199707212215.SAA01233@earth.hpc.org> To: pcalhoun@usr.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199707212124.OAA10600@baskerville.CS.Arizona.EDU> Subject: Re: Re[4]: ISAKMP performance Sender: owner-ipsec@ex.tis.com Precedence: bulk Supporting a total of, say, 6 a second is really too low. One could get up to 20-50 per second commonly, perhaps, with elliptic curve groups for both the DH and signature, but there is definitely a penalty associated with the blessing of public key technology. However, there are ways to engineer this, aren't there? One could cache the keying security association on something non-volatile (even a trusted third party) and use it to derive new IPSEC SA's on restart, for example. It's a management of security issue that could be worked out in practice. Also note that SKIP in non-PFS mode does allow one to pre-compute all the expected DH keys and keep them somewhere safe (if there is such a place) to use on restart. Hilarie From owner-ipsec Mon Jul 21 18:47:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27582 for ipsec-outgoing; Mon, 21 Jul 1997 18:47:02 -0400 (EDT) Message-Id: <199707212254.PAA10567@pita.cisco.com> To: Rodney Thayer cc: ipsec@tis.com Subject: Re: "Default" cipher and authenticator In-reply-to: Your message of "Mon, 21 Jul 1997 18:12:04 EDT." <3.0.1.32.19970721181204.007da320@pop3.pn.com> Date: Mon, 21 Jul 1997 15:54:46 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk The DOI has always listed both SHA-1 and MD5 as MUST implement. Derrell From owner-ipsec Mon Jul 21 19:31:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA27822 for ipsec-outgoing; Mon, 21 Jul 1997 19:30:32 -0400 (EDT) Date: Mon, 21 Jul 97 16:31:32 PDT From: marc@mentat.com (Marc Hasson) Message-Id: <9707212331.AA01826@mentat.com> To: ipsec@tis.com Subject: Re: "Default" cipher and authenticator Sender: owner-ipsec@ex.tis.com Precedence: bulk (Apologies if this is a duplicate, I don't think my first try was accepted.) > I didn't think we made SHA-1 part of the minimum default. I thought it was > just HMAC MD5. I agree with the DES CBC Explicit IV. The last ESP & AH doc drafts I've seen (dated May 30) have the following text that confirm's Dan's original note quite clearly for SHA-1. But, the ESP draft seems to be implying that implicit IV with DES CBC is the way to go but elsewhere in the text there are references to explicit IVs so I think ESP was leaving it to the cipher algorithm to specify. ESP just described how you can have it either way. I didn't see any clarifications of this in the roadmap document either. I had also, like Dan, been assuming explicit IV is what will be mandated, now I'm not so sure... This needs to be stated more clearly in the next document revision, when it references an actual DES CBC implicit(?) IV draft. (ESP) 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 (AH) 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 > >From: Dan.McDonald@eng.sun.com (Dan McDonald) > >Subject: "Default" cipher and authenticator > >To: ipsec@tis.com > >Date: Mon, 21 Jul 1997 14:23:30 -0700 (PDT) > >Sender: owner-ipsec@ex.tis.com > > > >Hello! > > > >What are the minimum default cipher algorithms and authenticator algorithms > >currently? From what I can tell: > > > >AUTHENTICATORS CIPHERS > >============== ======= > >HMAC-MD5-96 DES-CBC (explicit IV) > >HMAC-SHA-1-96 -- Marc -- ----- End Included Message ----- From owner-ipsec Mon Jul 21 19:33:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA27871 for ipsec-outgoing; Mon, 21 Jul 1997 19:33:01 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707212341.QAA17890@kebe.eng.sun.com> Subject: Re: "Default" cipher and authenticator To: piper@cisco.com (Derrell Piper) Date: Mon, 21 Jul 1997 16:41:11 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199707212254.PAA10567@pita.cisco.com> from "Derrell Piper" at Jul 21, 97 03:54:46 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 > The DOI has always listed both SHA-1 and MD5 as MUST implement. I thought so. I presume it's the 96-bit truncated version of those, right? Dan From owner-ipsec Tue Jul 22 07:49:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02283 for ipsec-outgoing; Tue, 22 Jul 1997 07:45:29 -0400 (EDT) Message-Id: <199707212242.SAA29311@relay.hq.tis.com> Date: Mon, 21 Jul 97 18:33:50 EDT From: Karen Seo To: ipsec@tis.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 21 July 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 21 July 1997 Security Payload (ESP) Table of Contents 1. Introduction......................................................3 2. Encapsulating Security Payload Packet Format......................4 2.1 Security Parameters Index....................................5 2.2 Sequence Number .............................................5 2.3 Payload Data.................................................5 2.4 Padding (for Encryption).....................................6 2.5 Pad Length...................................................7 2.6 Next Header..................................................7 2.7 Authentication Data..........................................7 3. Encapsulating Security Protocol Processing........................7 3.1 ESP Header Location..........................................7 3.2 Outbound Packet Processing..................................10 3.2.1 Security Association Lookup............................10 3.2.2 Sequence Number Generation.............................10 3.2.3 Packet Encryption......................................10 3.2.3.1 Scope of Encryption................................10 3.2.3.2 Encryption Algorithms..............................11 3.2.4 Integrity Check Value Calculation......................11 3.2.4.1 Scope of Authentication Protection................11 3.2.4.2 Authentication Padding............................11 3.2.4.3 Authentication Algorithms.........................12 3.2.5 Fragmentation..........................................12 3.3 Inbound Packet Processing...................................12 3.3.1 Pre-ESP Processing Overview............................12 3.3.2 Security Association Lookup............................12 3.3.3 Sequence Number Verification...........................13 3.3.4 Integrity Check Value Verification.....................14 3.3.5 Packet Decryption......................................15 4. Auditing.........................................................15 5. Conformance Requirements.........................................16 6. Security Considerations..........................................16 7. Differences from RFC 1827........................................16 Acknowledgements....................................................17 References..........................................................17 Disclaimer..........................................................19 Author Information..................................................19 Kent, Atkinson [Page 2] Internet Draft IP Encapsulating 21 July 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 the Security Architecture document [KA97a]. 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. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]. 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 AH, the concept of Security Associations, the ways in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and Kent, Atkinson [Page 3] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) automated keying via Oakley/ISAKMP.) 2. Encapsulating Security Payload Packet Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 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) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * If included in the Payload field, cryptographic synchronization data, e.g., an IV, usually is not encrypted per se, although it often is referred to as being part of the ciphertext. 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. Kent, Atkinson [Page 4] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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. 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.2.2 for more details on how the Sequence Number is generated.) The transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32nd packet 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 Initialization Vector (IV), then this data MAY be carried explicitly Kent, Atkinson [Page 5] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this 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) Several factors require or motivate use of the Padding field. 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. Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above. 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 transmitter MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding. As a default, the Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.) Kent, Atkinson [Page 6] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a receiver MUST inform senders of how the receiver will handle the Padding field. 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 no Padding bytes are present. 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 (see Section 3.2.4.3) 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 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- Kent, Atkinson [Page 7] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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. or before any other IPsec headers that have already been inserted, e.g., AH. 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 8] Internet Draft IP Encapsulating 21 July 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 ESP, after ESP, 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 9] Internet Draft IP Encapsulating 21 July 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 in Section 2.2, the Sequence Number field is always included in ESP packets, even if the anti-replay service, or the authentication service, have not been enabled for the SA. The sender's counter is initialized to 0 when an SA is established. 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. Thus the first packet sent using a given SA will have a Sequence Number of 1. 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. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) 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 entire original IP datagram (plus the Padding, Pad Length, and Next Header). If authentication is selected, encryption is performed first, before Kent, Atkinson [Page 10] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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 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 [MS97]. 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 Kent, Atkinson [Page 11] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. 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 ESP 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 Authentication Data field should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable). Kent, Atkinson [Page 12] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. A window size of 64 or larger MAY be chosen by the receiver. If a larger window size is chosen, it MUST be a multiple of 32. If any window size other than the default of 64 is employed by the receiver, it MUST be reported to the transmitter during SA negotiation. 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 Kent, Atkinson [Page 13] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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 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 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 saved value. (For the mandatory-to-implement authentication algorithms, 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 may have different ICV lengths.) (If a digital signature and one-way hash are used for the ICV computation, the matching process is more complex and will Kent, Atkinson [Page 14] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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. 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 Kent, Atkinson [Page 15] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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 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 [MS97]. - 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 [ATK95] 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 Kent, Atkinson [Page 16] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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. 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, William Simpson and Nina Yuan. References [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1997. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996. [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 Kent, Atkinson [Page 17] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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: 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. [MS97] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", RFC-xxxx, August 1997. [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 Kent, Atkinson [Page 18] Internet Draft IP Encapsulating 21 July 1997 Security Payload (ESP) 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. 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 19] From owner-ipsec Tue Jul 22 07:49:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02277 for ipsec-outgoing; Tue, 22 Jul 1997 07:44:58 -0400 (EDT) Message-Id: <199707212241.SAA29303@relay.hq.tis.com> Date: Mon, 21 Jul 97 18:33:15 EDT From: Karen Seo To: ipsec@tis.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 July 21 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 21 July, 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......................................................5 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.......................9 3.2.3.1 Handling Mutable Fields............................9 3.2.3.1.1 ICV Computation for IPv4......................9 3.2.3.1.1.1 Base Header Fields........................9 3.2.3.1.1.2 Options..................................10 3.2.3.1.2 ICV Computation for IPv6.....................10 3.2.3.1.2.1 Base Header Fields.......................10 3.2.3.1.2.2 Extension Headers -- Options.............11 3.2.3.1.2.3 Extension Headers -- non-Options.........11 3.2.3.2 Padding...........................................11 3.2.3.2.1 Authentication Data Padding..................11 3.2.3.2.2 Implicit Packet Padding......................12 3.2.3.3 Authentication Algorithms.........................12 3.2.4 Fragmentation..........................................12 3.3 Inbound Packet Processing...................................13 3.3.1 Reassembly.............................................13 3.3.2 Security Association Lookup............................13 3.3.3 Sequence Number Verification...........................13 3.3.4 Integrity Check Value Verification.....................14 4. Auditing.........................................................15 5. Conformance Requirements.........................................15 6. Security Considerations..........................................16 7. Differences from RFC 1826........................................16 Acknowledgements....................................................17 Appendix A -- Mutability of IP Options/Extension Headers............18 1. IPv4 Options..................................................18 2. IPv6 Extension Headers........................................19 References..........................................................21 Disclaimer..........................................................22 Author Information..................................................22 Kent, Atkinson [Page 2] Internet Draft IP Authentication Header 21 July, 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 "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 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 the Security Architecture document [KA97a]. 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 ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via Oakley/ISAKMP.) Kent, Atkinson [Page 3] Internet Draft IP Authentication Header 21 July, 1997 2. Authentication Header Format The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 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.) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field, as there would be no corresponding Authentication Data field. Kent, Atkinson [Page 4] Internet Draft IP Authentication Header 21 July, 1997 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.) 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 sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.2.2 for more details on how the Sequence Number is generated.) The transmitted Sequence Number must never be allowed to cycle. Thus the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of 2^32nd packet 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 Kent, Atkinson [Page 5] Internet Draft IP Authentication Header 21 July, 1997 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. (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. or before any other IPsec headers that have already been inserted, e.g., ESP. 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 Kent, Atkinson [Page 6] Internet Draft IP Authentication Header 21 July, 1997 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 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. Kent, Atkinson [Page 7] Internet Draft IP Authentication Header 21 July, 1997 ------------------------------------------------ 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 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 sender's counter is initialized to 0 when an SA is established. 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. Thus the first packet sent using a given SA will have a Sequence Number of 1. 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. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) Kent, Atkinson [Page 8] Internet Draft IP Authentication Header 21 July, 1997 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 may be 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. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IPSEC implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPSEC implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) 3.2.3.1.1 ICV Computation for IPv4 3.2.3.1.1.1 Base Header Fields The IPv4 base header fields are classified as follows: Immutable Version Internet Header Length Total Length Identification Protocol Source Address Destination Address (without loose or strict source routing) Kent, Atkinson [Page 9] Internet Draft IP Authentication Header 21 July, 1997 Mutable but predictable Destination Address (with loose or strict source routing) Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum TOS -- This 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. Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. Fragment Offset -- 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). TTL -- This 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. Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. 3.2.3.1.1.2 Options For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 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. 3.2.3.1.2 ICV Computation for IPv6 3.2.3.1.2.1 Base Header Fields The IPv6 base header fields are classified as follows: Kent, Atkinson [Page 10] Internet Draft IP Authentication Header 21 July, 1997 Immutable Version Payload Length Next Header Source Address Destination Address (without Routing Extension Header) Mutable but predictable Destination Address (with Routing Extension Header) Mutable (zeroed prior to ICV calculation) Priority Flow Label Hop Limit 3.2.3.1.2.2 Extension Headers -- Options The IPv6 extension headers (that are options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. IPv6 options in the Hop-by-Hop and Destination Extension Headers 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. 3.2.3.1.2.3 Extension Headers -- non-Options The IPv6 extension headers (that are not options) are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. 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 version (v4 or v6) Kent, Atkinson [Page 11] Internet Draft IP Authentication Header 21 July, 1997 For example, if a default, 96-bit truncated (see Section 3.2.3.3) 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 padding 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 currently 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 Kent, Atkinson [Page 12] Internet Draft IP Authentication Header 21 July, 1997 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, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 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) 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 Kent, Atkinson [Page 13] Internet Draft IP Authentication Header 21 July, 1997 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.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. A window size of 64 or larger MAY be chosen by the receiver. If a larger window size is chosen, it MUST be a multiple of 32. If any window size other than the default of 64 is employed by the receiver, it MUST be reported to the transmitter during SA negotiation. 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 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. Kent, Atkinson [Page 14] Internet Draft IP Authentication Header 21 July, 1997 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 saved value. (For the mandatory-to- implement authentication algorithms, 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 may have different ICV lengths.) (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 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 Kent, Atkinson [Page 15] Internet Draft IP Authentication Header 21 July, 1997 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 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. Kent, Atkinson [Page 16] Internet Draft IP Authentication Header 21 July, 1997 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, William Simpson, and Nina Yuan. Kent, Atkinson [Page 17] Internet Draft IP Authentication Header 21 July, 1997 Appendix A -- Mutability of IP Options/Extension Headers 1. IPv4 Options This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). Opt. Copy Class # Name Reference ---- ----- --- ------------------------- --------- IMMUTABLE -- included in ICV calculation 0 0 0 End of Options List [RFC791] 0 0 1 No Operation [RFC791] 1 0 2 Security [RFC1108(historic but in use)] 1 0 5 Extended Security [RFC1108(historic but in use)] 1 0 6 Commercial Security [expired I-D, now US MIL STD] 1 0 20 Router Alert [RFC2113] 1 0 21 Sender Directed Multi- [RFC1770] Destination Delivery MUTABLE -- zeroed 1 0 3 Loose Source Route [RFC791] 0 2 4 Time Stamp [RFC791] 0 0 7 Record Route [RFC791] 1 0 9 Strict Source Route [RFC791] 0 2 18 Traceroute [RFC1393] EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 0 0 10 Experimental Measurement [ZSu] 1 2 13 Experimental Flow Control [Finn] 1 0 14 Experimental Access Ctl [Estrin] 0 0 15 ??? [VerSteeg] 1 0 16 IMI Traffic Descriptor [Lee] 1 0 19 Address Extension [Ullmann IPv7] NOTE: Use of the Router Alert option is potentially incompatible with use of IPSEC. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing. However, AH processing would require that each router along the path Kent, Atkinson [Page 18] Internet Draft IP Authentication Header 21 July, 1997 is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available. NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPSEC. 2. IPv6 Extension Headers This table shows how the IPv6 Extension Headers are classified with regard to "mutability". Option/Extension Name Reference ----------------------------------- --------- MUTABLE BUT PREDICTABLE -- included in ICV calculation Routing (Type 0) [RFC1883] BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883] NOT APPLICABLE Fragmentation [RFC1883] Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers 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 options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information. Routing (Type 0) -- 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 mutable but predictable. The transmitter must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. Fragmentation -- Fragmentation occurs after outbound IPSEC processing (section 3.2.4) and reassembly occurs before inbound IPSEC processing (section 3.3.1). So the Fragmentation Extension Kent, Atkinson [Page 19] Internet Draft IP Authentication Header 21 July, 1997 Header, if it exists, is not seen by IPSEC. Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Note that on the send side, the IP implementation could give the IPSEC code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. Kent, Atkinson [Page 20] Internet Draft IP Authentication Header 21 July, 1997 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. [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 Kent, Atkinson [Page 21] Internet Draft IP Authentication Header 21 July, 1997 [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 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 22] From owner-ipsec Tue Jul 22 07:49:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02289 for ipsec-outgoing; Tue, 22 Jul 1997 07:46:28 -0400 (EDT) Date: Mon, 21 Jul 1997 16:17:08 -0700 From: mark@mentat.com (Marc Hasson) Message-Id: <199707212317.QAA02944@feller.mentat.com> To: ipsec@tis.com Subject: Re: "Default" cipher and authenticator X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > I didn't think we made SHA-1 part of the minimum default. I thought it was > just HMAC MD5. I agree with the DES CBC Explicit IV. The last ESP & AH doc drafts I've seen (dated May 30) have the following text that confirm's Dan's original note quite clearly for SHA-1. But, the ESP draft seems to be implying that implicit IV with DES CBC is the way to go but elsewhere in the text there are references to explicit IVs so I think ESP was leaving it to the cipher algorithm to specify. ESP just described how you can have it either way. I didn't see any clarifications of this in the roadmap document either. I had also, like Dan, been assuming explicit IV is what will be mandated, now I'm not so sure... This needs to be stated more clearly in the next document revision, when it references an actual DES CBC implicit(?) IV draft. (ESP) 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 (AH) 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 > >From: Dan.McDonald@eng.sun.com (Dan McDonald) > >Subject: "Default" cipher and authenticator > >To: ipsec@tis.com > >Date: Mon, 21 Jul 1997 14:23:30 -0700 (PDT) > >Sender: owner-ipsec@ex.tis.com > > > >Hello! > > > >What are the minimum default cipher algorithms and authenticator algorithms > >currently? From what I can tell: > > > >AUTHENTICATORS CIPHERS > >============== ======= > >HMAC-MD5-96 DES-CBC (explicit IV) > >HMAC-SHA-1-96 -- Marc -- From owner-ipsec Tue Jul 22 09:54:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA03388 for ipsec-outgoing; Tue, 22 Jul 1997 09:45:29 -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-ciph-3des-expiv-00.txt Date: Tue, 22 Jul 1997 09:49:58 -0400 Message-ID: <9707220950.aa07131@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 3DES-CBC Algorithm Using an Explicit IV Author(s) : R. Pereira, R. Thayer Filename : draft-ietf-ipsec-ciph-3des-expiv-00.txt Pages : 7 Date : 07/21/1997 This document describes the "Triple" DES-EDE3-CBC block cipher algorithm used with the IP Encapsulating Security Payload (ESP). Use of an explicit IV is described. 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-ciph-3des-expiv-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-3des-expiv-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-ciph-3des-expiv-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: <19970721141221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-3des-expiv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-3des-expiv-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970721141221.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Jul 22 10:08:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03593 for ipsec-outgoing; Tue, 22 Jul 1997 10:07:04 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Tue, 22 Jul 1997 08:09:33 -0500 Message-ID: <3D4C3000.3000@usr.com> To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re[6]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.865185968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.865185968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Hilarie, Thanks for the input, but I believe that you may have missed the rest of the thread. Let me paint a picture of a real network where my product would typically sit. Imagine BigDarnServiceProvider which has 500 POPs around the U.S. Each POP has about 20 of my boxes (which has about 1000 incoming ports each). So that means about 20,000 ports per POP and so on. The service being offered (on top of straight Internet Access) is access to corporate networks using some well known Tunneling Protocol (in this case L2TP because it tunnels PPP traffic). This service provider has thousands of customers which have outsourced their dial service to this ISP. In addition, this service provider belongs to some Roaming corsortiums which means that users travelling to the US from abroad can use this service provider instead of having to do an international long distance for corporate access. So in this case the number of possible Firewalls to traverse are really in the thousands! So let's assume that user Joe@BigCorp dials in on NAS(a), an SA is established with BigCorp's Firewall. The SA could expire in a year. Once the user logs out, he logs back in and now connects to NAS(b), which needs to redo the SA from scratch. (will a hunt group, you have no idea which NAS you will hit, and in some installations you have no idea which city you will get connected to!). Now user Bob@BiggerCorp dials in and hits NAS(a), again the SA needs to be established and so on... Since I have 1000 ports, that means alot of SAs need to be cached. And even if the SA was to expire in a year, some of these embedded boxes with limited memory would have to trash the SA in order to preserve memory. So that means that the next day when Sally@BigCorp dials in and hits NAS(a), chances are an SA will have to be established again! Storing to non-volative memory is very difficult. Hard drives are not available in most routers (well, not in the ones that most ISPs are willing to run :). And flash memory is very limited. Now, storing the SA off to some third party is a VERY interesting idea. Presumably NAS(a) could send SA information to this third party, which would obviously be trusted. Do we know of any such thing being run today? I would assume that the keys being passed to this third party would be encrypted using a key encryption key which only NAS(a) could decrypt. How do most folk feel about this design? I would appreciate any input, PatC ______________________________ Reply Separator _________________________________ Subject: Re: Re[4]: ISAKMP performance Author: ho@earth.hpc.org (Hilarie Orman) at Internet Date: 7/21/97 6:15 PM Supporting a total of, say, 6 a second is really too low. One could get up to 20-50 per second commonly, perhaps, with elliptic curve groups for both the DH and signature, but there is definitely a penalty associated with the blessing of public key technology. However, there are ways to engineer this, aren't there? One could cache the keying security association on something non-volatile (even a trusted third party) and use it to derive new IPSEC SA's on restart, for example. It's a management of security issue that could be worked out in practice. Also note that SKIP in non-PFS mode does allow one to pre-compute all the expected DH keys and keep them somewhere safe (if there is such a place) to use on restart. Hilarie --IMA.Boundary.865185968 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 3D3E2DD0; Mon, 21 Jul 97 17:29:49 -0500 Received: from hpc.org by usr.com (8.7.5/3.1.090690-US Robotics) id RAA00166; Mon, 21 Jul 1997 17:07:15 -0500 (CDT) Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id SAA01479; Mon, 21 Jul 1997 18:26:14 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id SAA01233; Mon, 21 Jul 1997 18:15:48 -0400 Date: Mon, 21 Jul 1997 18:15:48 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199707212215.SAA01233@earth.hpc.org> To: pcalhoun@usr.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199707212124.OAA10600@baskerville.CS.Arizona.EDU> Subject: Re: Re[4]: ISAKMP performance --IMA.Boundary.865185968-- From owner-ipsec Tue Jul 22 10:15:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03681 for ipsec-outgoing; Tue, 22 Jul 1997 10:14:30 -0400 (EDT) Date: Tue, 22 Jul 1997 10:14:30 -0400 (EDT) From: owner-ipsec@ex.tis.com From: Roy Pereira To: "'ipsec@tis.com'" , "'Karen Seo'" Subject: RE: New draft -- IPSEC ESP Date: Tue, 22 Jul 1997 10:20:31 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Wasn't "draft-ietf-ipsec-esp-04.txt", released on May 30 as shown below? From: Karen Seo[SMTP:kseo@bbn.com] Sent: Friday, May 30, 1997 5:08 PM To: ipsec@tis.com Cc: kseo@bbn.com Subject: New draft -- IPSEC ESP Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-esp-04.txt 30 May 1997 >---------- >From: Karen Seo[SMTP:kseo@bbn.com] >Sent: Monday, July 21, 1997 6:33 PM >To: ipsec@tis.com >Subject: New draft -- IPSEC ESP > > > > >Network Working Group Stephen Kent, BBN Corp >Internet Draft Randall Atkinson, @Home Network >draft-ietf-ipsec-esp-04.txt 21 July 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 21 July 1997 > Security Payload (ESP) > > >Table of Contents > > 1. Introduction......................................................3 > 2. Encapsulating Security Payload Packet Format......................4 > 2.1 Security Parameters Index....................................5 > 2.2 Sequence Number .............................................5 > 2.3 Payload Data.................................................5 > 2.4 Padding (for Encryption).....................................6 > 2.5 Pad Length...................................................7 > 2.6 Next Header..................................................7 > 2.7 Authentication Data..........................................7 > 3. Encapsulating Security Protocol Processing........................7 > 3.1 ESP Header Location..........................................7 > 3.2 Outbound Packet Processing..................................10 > 3.2.1 Security Association Lookup............................10 > 3.2.2 Sequence Number Generation.............................10 > 3.2.3 Packet Encryption......................................10 > 3.2.3.1 Scope of Encryption................................10 > 3.2.3.2 Encryption Algorithms..............................11 > 3.2.4 Integrity Check Value Calculation......................11 > 3.2.4.1 Scope of Authentication Protection................11 > 3.2.4.2 Authentication Padding............................11 > 3.2.4.3 Authentication Algorithms.........................12 > 3.2.5 Fragmentation..........................................12 > 3.3 Inbound Packet Processing...................................12 > 3.3.1 Pre-ESP Processing Overview............................12 > 3.3.2 Security Association Lookup............................12 > 3.3.3 Sequence Number Verification...........................13 > 3.3.4 Integrity Check Value Verification.....................14 > 3.3.5 Packet Decryption......................................15 > 4. Auditing.........................................................15 > 5. Conformance Requirements.........................................16 > 6. Security Considerations..........................................16 > 7. Differences from RFC 1827........................................16 > Acknowledgements....................................................17 > References..........................................................17 > Disclaimer..........................................................19 > Author Information..................................................19 > > > > > > > > > > > >Kent, Atkinson [Page 2] > > >Internet Draft IP Encapsulating 21 July 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 "Security Architecture for the Internet Protocol" [KA97a], > hereafter referred to as the Security Architecture document). > 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 the Security Architecture > document [KA97a]. > > 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. However, use of confidentiality without > integrity/authentication (either in ESP or separately in AH) may > subject traffic to certain forms of active attacks that could > undermine the confidentiality service (see [Bel96]. 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 AH, the concept of Security Associations, the ways > in which ESP can be used in conjunction with the Authentication > Header (AH), and the different key management options available for > ESP and AH. (With regard to the last topic, the current key > management options required for both AH and ESP are manual keying and > > >Kent, Atkinson [Page 3] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > automated keying via Oakley/ISAKMP.) > >2. Encapsulating Security Payload Packet Format > > > The protocol header (IPv4, IPv6, or Extension) immediately preceding the > ESP header will contain the value 50 in its Protocol (IPv4) or Next > Header (IPv6, Extension) field [STD-2]. > > 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) | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > * If included in the Payload field, cryptographic synchronization > data, e.g., an IV, usually is not encrypted per se, although it > often is referred to as being part of the ciphertext. > > > > > 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. > > > > > >Kent, Atkinson [Page 4] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > >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. > >2.2 Sequence Number > > This unsigned 32-bit field contains a monotonically increasing > counter value (sequence number). The sender's counter and the > receiver's counter are initialized to 0 when an SA is established. > (The first packet sent using a given SA will have a Sequence Number > of 1; see Section 3.2.2 for more details on how the Sequence Number > is generated.) The transmitted Sequence Number must never be allowed > to cycle. Thus, the sender's counter and the receiver's counter MUST > be reset (by establishing a new SA and thus a new key) prior to the > transmission of 2^32nd packet 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 > Initialization Vector (IV), then this data MAY be carried explicitly > > >Kent, Atkinson [Page 5] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > in the Payload field. Any encryption algorithm that requires such > explicit, per-packet synchronization data MUST indicate the length, > any structure for such data, and the location of this 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) > > Several factors require or motivate use of the Padding field. > > > 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. > > Padding also may be required, irrespective of encryption > algorithm requirements, to ensure that the resulting ciphertext > terminates on a 4-byte boundary. Specifically, the Pad Length > and Next Header fields must be right aligned within a 4-byte > word, as illustrated in the ESP packet format figure above. > > 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 transmitter MAY add 0-255 bytes of padding. Inclusion of the > Padding field in an ESP packet is optional, but all implementations > MUST support generation and consumption of padding. > > As a default, the Padding bytes are initialized with a series of > (unsigned, 1-byte) integer values. The first padding byte appended > to the plaintext is numbered 1, with subsequent padding bytes making > up a monotonically increasing sequence: 1, 2, 3, ... When this > padding scheme is employed, the receiver SHOULD inspect the Padding > field. (This scheme was selected because of its relative simplicity, > ease of implementation in hardware, and because it offers limited > protection against certain forms of "cut and paste" attacks in the > absence of other integrity measures, if the receiver checks the > padding values upon decryption.) > > >Kent, Atkinson [Page 6] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > Any encryption algorithm that requires Padding other than the default > described above, MUST define the Padding contents (e.g., zeros or > random data) and any required receiver processing of these Padding > bytes in an RFC specifying how the algorithm is used with ESP. In > such circumstances, the content of the Padding field will be > determined by the encryption algorithm and mode selected and defined > in the corresponding algorithm RFC. The relevant algorithm RFC MAY > specify that a receiver MUST inspect the Padding field or that a > receiver MUST inform senders of how the receiver will handle the > Padding field. > >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 no Padding bytes are present. 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 (see Section 3.2.4.3) > 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 > 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- > > >Kent, Atkinson [Page 7] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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. or before any other > IPsec headers that have already been inserted, e.g., AH. 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 8] > > >Internet Draft IP Encapsulating 21 July 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 ESP, after ESP, 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 9] > > >Internet Draft IP Encapsulating 21 July 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 in Section 2.2, the Sequence Number field is always included > in ESP packets, even if the anti-replay service, or the > authentication service, have not been enabled for the SA. The > sender's counter is initialized to 0 when an SA is established. 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. Thus the first packet sent using a > given SA will have a Sequence Number of 1. 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. (Note that this approach to > Sequence Number management does not require use of modular > arithmetic.) > >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 entire original IP datagram (plus the > Padding, Pad Length, and Next Header). > > If authentication is selected, encryption is performed first, before > > >Kent, Atkinson [Page 10] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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 > 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 [MS97]. > > >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 > > >Kent, Atkinson [Page 11] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > blocksize (and hence the length of the padding) is specified by the > algorithm specification. This padding is not transmitted with the > packet. > >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 ESP 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 Authentication Data field should be present, and it will > specify the algorithms and keys to be employed for decryption and ICV > computations (if applicable). > > >Kent, Atkinson [Page 12] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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 > 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.) A MINIMUM window size of 32 MUST be supported; but a > window size of 64 is preferred and SHOULD be employed as the default. > A window size of 64 or larger MAY be chosen by the receiver. If a > larger window size is chosen, it MUST be a multiple of 32. If any > window size other than the default of 64 is employed by the receiver, > it MUST be reported to the transmitter during SA negotiation. > > 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 > > >Kent, Atkinson [Page 13] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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 > 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 > > 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 saved value. (For the mandatory-to-implement authentication > algorithms, 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 may have different ICV > lengths.) (If a digital signature and one-way hash are used for > the ICV computation, the matching process is more complex and will > > >Kent, Atkinson [Page 14] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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. > 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 > > >Kent, Atkinson [Page 15] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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 > 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 [MS97]. > > - 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 [ATK95] 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 > > >Kent, Atkinson [Page 16] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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. > > >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 Karen Seo for providing > extensive help in the review, editing, background research, and > coordination for this version of the specification. The authors > would also 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, William Simpson and Nina Yuan. > >References > > > [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC > 1827, August 1997. > > [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP > Protocol Suite", ACM Computer Communications Review, Vol. > 19, No. 2, March 1989. > > [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security > Protocols", Proceedings of the Sixth Usenix Unix Security > Symposium, July, 1996. > > [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 > > >Kent, Atkinson [Page 17] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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: > 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. > > [MS97] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", > RFC-xxxx, August 1997. > > [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 > > >Kent, Atkinson [Page 18] > > >Internet Draft IP Encapsulating 21 July 1997 > Security Payload (ESP) > > > 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. > > >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 19] > > > From owner-ipsec Tue Jul 22 10:43:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03912 for ipsec-outgoing; Tue, 22 Jul 1997 10:43:38 -0400 (EDT) Date: Tue, 22 Jul 1997 07:52:08 -0700 From: mark@mentat.com (Marc Hasson) Message-Id: <199707221452.HAA03334@feller.mentat.com> To: ipsec@tis.com Subject: Re: New draft -- IPSEC ESP X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I haven't read the entire draft yet (I will later today) but skipped straight to this reference due to yesterday's E-mail on the mandatory algorithms: > conjunction with SAs that are manually keyed. A compliant ESP > implementation MUST support the following mandatory-to-implement > algorithms (specified in [KBC97] and in [MS97]. > > - DES in CBC mode > - HMAC with MD5 > - HMAC with SHA-1 > > [MS97] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", > RFC-xxxx, August 1997. Is MS97 the (expected) RFC version of draft-ietf-ipsec-ciph-des-derived-00.txt? If so, the mandatory ESP DES_CBC will use an *implicit* IV, one constructed from the ESP sequence # in the packet ("SN || -SN"). And it will be optional for a key manager to negotiate some other "flavor" of either implicit IV (such as the earlier SPI & SN concatenation for automated key management) or an explicit IV. I'm not an ISAKMP person but I don't believe there is an implicit/explicit IV negotiation parameter there currently though I guess its easy to add more DES transform id variants for different IV handling, if someone thinks thats necessary. I'm *not* suggesting that its necessary, I'm just trying to confirm what I need to finish building so key management and the underlying auth/cipher code can do their jobs... Thanks for any confirmation of the above. -- Marc -- From owner-ipsec Tue Jul 22 10:55:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04126 for ipsec-outgoing; Tue, 22 Jul 1997 10:55:05 -0400 (EDT) Date: Tue, 22 Jul 97 14:46:19 GMT Daylight Time From: Ran Atkinson Subject: Re: FW: private use ISAKMP attributes To: "'ipsec@tis.com'" , "Edward A. Russell" X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <01BC95F9.1ACA6B80@erussell-1.ftp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 21 Jul 1997 17:10:41 -0400 "Edward A. Russell" wrote: > Of course with private attribute types, there can be conflict between two vendors > who pick the same number for different things (hint: don't pick the first number in > the private range). We need to be able to register a standard Private Scheme > Attribute Class or something. In historic IETF practice, there are usually two magic number spaces: - one that is standardised (or registered with IANA following some IETF process) and intended to be interoperable across multiple independent implementations - one that is for "private use among consenting parties" that is understood NOT to be interoperable but provides the ability to have proprietary or private-community extensions that are not appropriate for either standardisation OR for registration with IANA via some IETF process. SNMP has a third kind of number space, which is proprietary but allocated uniquely to a particular vendor. ISAKMP does not currently have that kind of number space (some of us don't view this as a problem). In the above context, I don't follow what "register a standard Private Scheme..." means for ISAKMP. In particular, its probably helpful for folks to identify now any KM attributes that they know they need but aren't currently documented. That way the group as a whole can have a chance to consider whether those ought to be standardised (even if they might be optional to implement). All IMHO. > Ultimately, it is left up to the user or administrator to configure proposals > for specific systems knowing ahead of time which use the private schemes and > which are strictly standard. It seems like a matter of local security policy to me. I imagine that each vendor will have their own method of specifying policy. If a vendor doesn't have some method for a local sysadmin to specify local policy, that vendor might be at a competitive disadvantage relative to other vendors. So goes capitalism. Later, Ran rja@inet.org From owner-ipsec Tue Jul 22 10:58:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04161 for ipsec-outgoing; Tue, 22 Jul 1997 10:58:05 -0400 (EDT) Date: Tue, 22 Jul 97 14:55:30 GMT Daylight Time From: Ran Atkinson Subject: Re: "Default" cipher and authenticator To: ipsec@tis.com, Rodney Thayer X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.1.32.19970721181204.007da320@pop3.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 21 Jul 1997 18:12:04 -0400 Rodney Thayer wrote: > I didn't think we made SHA-1 part of the minimum default. I thought it was > just HMAC MD5. I agree with the DES CBC Explicit IV. In 1996, the IESG objected to having two mandatory-to-implement authentication algorithms. At that time, I thought the result was that HMAC MD5 was mandatory-to-implement and standard while HMAC SHA-1 was optional-to-implement and standard. Things could easily be different now. I'd be interested in hearing a definitive answer on this question from the current co-chairs. Ran rja@inet.org From owner-ipsec Tue Jul 22 11:19:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04323 for ipsec-outgoing; Tue, 22 Jul 1997 11:19:06 -0400 (EDT) Message-Id: <199707221526.LAA29748@relay.rv.tis.com> Date: Tue, 22 Jul 97 11:17:36 EDT From: Karen Seo To: Roy Pereira cc: "'ipsec@tis.com'" , "'Karen Seo'" Subject: Re: New draft -- IPSEC ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Roy, Yes, the May ESP draft was xxx-04.txt. My apologies if this was wrong. I realize this is confusing, but I had the impression that I wasn't supposed to change that number, that the IETF secretariat changed it when they issued it as an internet draft. I believe the new ESP should be xxx-05.txt and the new AH should be xxx-06.txt. (Ted, Bob, should I re-issue the drafts with these number changes to the mailing list and the IETF secretariat?) Thanks, Karen From owner-ipsec Tue Jul 22 13:20:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05181 for ipsec-outgoing; Tue, 22 Jul 1997 13:16:10 -0400 (EDT) Message-Id: <199707221721.NAA13951@raptor.research.att.com> To: pcalhoun@usr.com cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re: Re[6]: ISAKMP performance Date: Tue, 22 Jul 1997 13:21:29 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Now, storing the SA off to some third party is a VERY interesting idea. Presumably NAS(a) could send SA information to this third party, which would obviously be trusted. Do we know of any such thing being run today? I would assume that the keys being passed to this third party would be encrypted using a key encryption key which only NAS(a) could decrypt. How do most folk feel about this design? It's quite attractive, and in fact the third party need not be trusted in the cryptographic sense. As you note, the information is encrypted (including an authenticity check) with a NAS(a)-only key, and hence is tamperproof. It could fail to respond, or it could respond with a damaged or fraudulent package, in which case the NAS simply establishes a new security association. In other words, this third party is a cache. But that all begs the question of whether or not it's worth doing. Well, it's probably worth doing in the business sense, but architecturally, if I'm running ipsec from my laptop to my firewall, I don't care whether or not the NAS-to-firewall L2TP traffic is protected or not. From owner-ipsec Tue Jul 22 14:00:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05511 for ipsec-outgoing; Tue, 22 Jul 1997 13:59:39 -0400 (EDT) Message-Id: <199707221807.LAA21278@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pcalhoun@usr.com Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re: Re[6]: ISAKMP performance In-Reply-To: Your message of "Tue, 22 Jul 1997 08:09:33 CDT." <3D4C3000.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jul 1997 11:07:34 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Pat, Although the lifetime of a SA might be a year, generally if the user logs off or the connection is dropped for whatever reason the SA is thrown away. Since joe@bigcorp doesn't know which NAS he dials into he wouldn't know which SA to use to talk to the NAS anyway (assuming he's also cacheing the SAs for the various NASs too). You're only going to keep active SAs, so if your box can support 1000 active connections that's 1000 SAs period. You're also just securing the NAS to LNS. joe@bigcorp's line to his NAS is in the clear. There are certain gov't agencies (not necessarily US either: imagine a Boeing executive in France these days) that I don't think have figured out how to use a sniffer but they have decades of experience tapping phone lines. If I was joe and my communications were sensitive enough to require encryption I'd want my whole thing encrypted. It seems pointless to leave in the clear the one point that would be easiest to attack. And since IPSec provides tunneling capabilities already why not just use them? (IMPORTANT NOTE: that's my opinion and not necessarily that of my employer). Also, there seems to be alot of concern about KM performance but if I was joe@bigcorp in your example packets for my telnet as they traverse through the ether would look like this if I'm not mistaken: IP | IPSec | UDP | L2TP | PPP | IP | TCP | which is a heckuva lot of overhead (IMPORTANT NOTE: that's my opinion and not necessarily that of my employer). I'd be pretty concerned about 1000 of those things too. If *I* was joe@bigcorp I wouldn't pay for BigDarnServiceProvider's secure tunneling service-- I'd just use IPSec in tunnel mode from my laptop or SOHO router or whatever. End-to-end security with less overhead. Dan. > Thanks for the input, but I believe that you may have missed the > rest of the thread. Let me paint a picture of a real network where my > product would typically sit. > > Imagine BigDarnServiceProvider which has 500 POPs around the U.S. > Each POP has about 20 of my boxes (which has about 1000 incoming ports > each). So that means about 20,000 ports per POP and so on. > > The service being offered (on top of straight Internet Access) is > access to corporate networks using some well known Tunneling Protocol > (in this case L2TP because it tunnels PPP traffic). This service > provider has thousands of customers which have outsourced their dial > service to this ISP. In addition, this service provider belongs to > some Roaming corsortiums which means that users travelling to the US > from abroad can use this service provider instead of having to do an > international long distance for corporate access. > > So in this case the number of possible Firewalls to traverse are > really in the thousands! > > So let's assume that user Joe@BigCorp dials in on NAS(a), an SA is > established with BigCorp's Firewall. The SA could expire in a year. > Once the user logs out, he logs back in and now connects to NAS(b), > which needs to redo the SA from scratch. (will a hunt group, you have > no idea which NAS you will hit, and in some installations you have no > idea which city you will get connected to!). > > Now user Bob@BiggerCorp dials in and hits NAS(a), again the SA > needs to be established and so on... Since I have 1000 ports, that > means alot of SAs need to be cached. And even if the SA was to expire > in a year, some of these embedded boxes with limited memory would have > to trash the SA in order to preserve memory. So that means that the > next day when Sally@BigCorp dials in and hits NAS(a), chances are an > SA will have to be established again! > > Storing to non-volative memory is very difficult. Hard drives are > not available in most routers (well, not in the ones that most ISPs > are willing to run :). And flash memory is very limited. > > Now, storing the SA off to some third party is a VERY interesting > idea. Presumably NAS(a) could send SA information to this third party, > which would obviously be trusted. Do we know of any such thing being > run today? I would assume that the keys being passed to this third > party would be encrypted using a key encryption key which only NAS(a) > could decrypt. How do most folk feel about this design? > > I would appreciate any input, > > PatC From owner-ipsec Tue Jul 22 14:32:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05836 for ipsec-outgoing; Tue, 22 Jul 1997 14:29:38 -0400 (EDT) Date: Tue, 22 Jul 1997 14:18:20 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: ipsec@tis.com Subject: draft-ietf-ipsec-ciph-arcfour-00.txt Message-Id: <97Jul22.141328edt.11653@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On page 3, section 4, there is no mention of the stream offset. 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 Tue Jul 22 14:32:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05844 for ipsec-outgoing; Tue, 22 Jul 1997 14:30:37 -0400 (EDT) Date: Tue, 22 Jul 1997 14:31:07 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: ipsec@tis.com Subject: draft-ietf-ipsec-cbc-00.txt Message-Id: <97Jul22.142615edt.11651@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Page 4, 5, Security Notes: I figure 7,200 bytes/sec is 26 MB/hour; 48 GB would take about 77 days to generate, so even the most long-winded should not have their conversations interrupted by a key refresh. 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 Tue Jul 22 14:38:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05905 for ipsec-outgoing; Tue, 22 Jul 1997 14:38:12 -0400 (EDT) Message-Id: <3.0.1.32.19970722144226.0080b140@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 22 Jul 1997 14:42:26 -0400 To: Derrell Piper From: Rodney Thayer Subject: Re: "Default" cipher and authenticator Cc: ipsec@tis.com In-Reply-To: <199707212254.PAA10567@pita.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk So it does. I was thinking about what's in the architecture document for guidelines in the 'must implement' department. Do we really have both documents dictating things? Should we? At 03:54 PM 7/21/97 -0700, you wrote: >The DOI has always listed both SHA-1 and MD5 as MUST implement. > >Derrell > > From owner-ipsec Tue Jul 22 15:06:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06164 for ipsec-outgoing; Tue, 22 Jul 1997 15:05:09 -0400 (EDT) Message-Id: <199707221913.PAA03993@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: pcalhoun@usr.com Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re: Re[6]: ISAKMP performance In-Reply-To: pcalhoun's message of Tue, 22 Jul 1997 08:09:33 -0500. <3D4C3000.3000@usr.com> Date: Tue, 22 Jul 1997 15:12:45 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Hmm. The scaling issues you're presenting seem to me to indicate more of a problem with your architecture, not with ipsec. I agree with Dan Harkins.. the correct place for ipsec in a mobile/dialup environment is in the dialup end system, not in the first-hop router (which is what the NAS effectively is). There may still be scaling issues on the security gateways/firewalls at the other end of the tunnel.. It's not clear what doing a secure tunnel from the NAS to the firewall buys me as an end user, as I can't trust the phone network to be secure. - Bill From owner-ipsec Tue Jul 22 15:54:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06610 for ipsec-outgoing; Tue, 22 Jul 1997 15:53:39 -0400 (EDT) Message-Id: <97Jul22.155703edt.11654@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Re: ISAKMP performance References: <199707221913.PAA03993@thunk.ch.apollo.hp.com> In-reply-to: sommerfeld's message of "Tue, 22 Jul 1997 15:12:45 -0400". <199707221913.PAA03993@thunk.ch.apollo.hp.com> From: "C. Harald Koch" Date: Tue, 22 Jul 1997 16:01:54 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > It's not clear what doing a secure tunnel from the NAS to the firewall > buys me as an end user, as I can't trust the phone network to be > secure. IPsec + IP Mobility only works for IP. The Internet doesn't carry WFW, or IPX, or AppleTalk on the backbone. To get around this, people are trying to create PPP connections directly from a client machine to a "home server", using PPTP, or L2F, or L2TP (all various forms of "get the PPP frames across the Internet" protocols, the third of which is an IETF WG). Note that the mandate is to do this *without* requiring changes on the client; i.e. it speaks 'standard' PPP with the NAS, and everything else is "magic". In order to gain approximately the same level of security one has in a direct connect with a tunnel over the Internet, one needs strong security between the NAS and the "home server". The L2TP group wants to mandate IPSEC for this purpose. Hence the ISAKMP performance discussion. Note that L2TP is not just a PPP over the Internet technology; it's designed to run over other "network" media, like Frame and ATM. IPsec is only being considered for L2TP over IP at this time. I am neither for nor against this technology. I recognize that it is an expedient solution to the problem of roaming users, VPNs, and non-IP protocols, but I'm not convinced that is is either the only or the best solution. Heck, with the proliferation of "Internet on the desktop" it may become entirely moot in a couple of years... -- Harald Koch From owner-ipsec Tue Jul 22 17:19:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07228 for ipsec-outgoing; Tue, 22 Jul 1997 17:18:39 -0400 (EDT) Date: Tue, 22 Jul 1997 17:26:58 -0400 Message-Id: <199707222126.RAA17919@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: mark@mentat.com Cc: ipsec@tis.com In-Reply-To: Marc Hasson's message of Tue, 22 Jul 1997 07:52:08 -0700, <199707221452.HAA03334@feller.mentat.com> Subject: Re: New draft -- IPSEC ESP Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Mark, My understanding is that the mandatory to implement cipher algorithm, based on what the vendors are implementing and what they tested at the ANX interoperability workshop, is represented by the I-D draft-ietf-ipsec-ciph-des-expiv-00.txt. In other words, DES CBC with an explicit IV. - Ted From owner-ipsec Tue Jul 22 17:21:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07262 for ipsec-outgoing; Tue, 22 Jul 1997 17:21:40 -0400 (EDT) Date: Tue, 22 Jul 1997 17:29:37 -0400 Message-Id: <199707222129.RAA17921@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Karen Seo Cc: Roy Pereira , "'ipsec@tis.com'" , "'Karen Seo'" In-Reply-To: Karen Seo's message of Tue, 22 Jul 97 11:17:36 EDT, <199707221526.LAA29748@relay.rv.tis.com> Subject: Re: New draft -- IPSEC ESP Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 22 Jul 97 11:17:36 EDT From: Karen Seo Yes, the May ESP draft was xxx-04.txt. My apologies if this was wrong. I realize this is confusing, but I had the impression that I wasn't supposed to change that number, that the IETF secretariat changed it when they issued it as an internet draft. I believe the new ESP should be xxx-05.txt and the new AH should be xxx-06.txt. (Ted, Bob, should I re-issue the drafts with these number changes to the mailing list and the IETF secretariat?) Well, it looks like the IETF secretariat has taken matters into their own hands and renamed the documents. (I'm not sure why; not that it matters.) Assuming that they actually get them published in the next day or two, I don't think it's worth bloating people's mailboxes to re-send the draft just with a slightly different header. Hopefully the esp-04 header won't confuse too many people, and once the I-D gets released, most people will probably be using the document found in the I-D directories anyway. - Ted From owner-ipsec Tue Jul 22 17:40:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07406 for ipsec-outgoing; Tue, 22 Jul 1997 17:40:40 -0400 (EDT) Date: Tue, 22 Jul 1997 17:48:55 -0400 Message-Id: <199707222148.RAA17929@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Rodney Thayer Cc: Derrell Piper , ipsec@tis.com In-Reply-To: Rodney Thayer's message of Tue, 22 Jul 1997 14:42:26 -0400, <3.0.1.32.19970722144226.0080b140@pop3.pn.com> Subject: Re: "Default" cipher and authenticator Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 22 Jul 1997 14:42:26 -0400 From: Rodney Thayer So it does. I was thinking about what's in the architecture document for guidelines in the 'must implement' department. Do we really have both documents dictating things? Should we? Rodney, The ESP and AH documents reference what certain algorithms as the "current default algorithms". This was done mainly to make certain issues (such as padding and alignment issues) more concrete and easier to understand. Steve and Karen has raised the question of whether or not these editorial comments caused problems or not. My reaction was that they made the text easier to understand, and so I supported leaving them in. It is true that doing so means that we will need to carefully proof the architecture document and the ESP and AH documents to make sure that they are coherent. However, I think this is a price that is worth paying. If there is a huge outcry against having that kind of non-normative text in the AH and ESP documents, we can have them taken out, of course. I view it as mainly a stylistic (and not technical) issue. Comments? - Ted From owner-ipsec Tue Jul 22 17:44:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07463 for ipsec-outgoing; Tue, 22 Jul 1997 17:44:14 -0400 (EDT) Date: Tue, 22 Jul 1997 14:52:53 -0700 From: mark@mentat.com (Marc Hasson) Message-Id: <199707222152.OAA03654@feller.mentat.com> To: tytso@MIT.EDU, kseo@bbn.com Subject: Re: New draft -- IPSEC ESP Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Mark, > My understanding is that the mandatory to implement cipher > algorithm, based on what the vendors are implementing and what they > tested at the ANX interoperability workshop, is represented by the I-D > draft-ietf-ipsec-ciph-des-expiv-00.txt. In other words, DES CBC with > an explicit IV. > > - Ted Fine, I really don't care which it is. Your statement is what I had *thought* we were doing too. Then I guess you're saying that the latest ESP draft has to get its mandatory to implement reference (MS97) fixed. Neither the authorship nor the title of that reference matches your "des-expiv" reference above, which is why I had asked if the *implicit" version is what the new ESP draft was truly referencing. draft-ietf-ipsec-ciph-des-derived-00.txt matches the MS97 reference for *both* authorship and title and is also a very recent draft. -- Marc -- From owner-ipsec Tue Jul 22 18:22:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07731 for ipsec-outgoing; Tue, 22 Jul 1997 18:21:45 -0400 (EDT) Date: Tue, 22 Jul 1997 18:29:40 -0400 Message-Id: <199707222229.SAA17948@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: mark@mentat.com Cc: kseo@bbn.com, ipsec@tis.com In-Reply-To: Marc Hasson's message of Tue, 22 Jul 1997 14:52:53 -0700, <199707222152.OAA03654@feller.mentat.com> Subject: Re: New draft -- IPSEC ESP Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Tue, 22 Jul 1997 14:52:53 -0700 From: mark@mentat.com (Marc Hasson) Then I guess you're saying that the latest ESP draft has to get its mandatory to implement reference (MS97) fixed. Neither the authorship nor the title of that reference matches your "des-expiv" reference above, which is why I had asked if the *implicit" version is what the new ESP draft was truly referencing. draft-ietf-ipsec-ciph-des-derived-00.txt matches the MS97 reference for *both* authorship and title and is also a very recent draft. Yes, this is correct. My apologies to Steve and Karen for not catching this when reading earlier versions of their text. See my previous message about needing to proof the ESP and AH drafts against the architecture document with respect to the current mandated algorithms. I believe it will make the document more understable in the end, but it does mean we have to do a bit more work to make sure the text in those documents match the text in the architecture document. - Ted From owner-ipsec Tue Jul 22 19:35:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08091 for ipsec-outgoing; Tue, 22 Jul 1997 19:34:13 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707222341.QAA08776@kebe.eng.sun.com> Subject: Auth algorithm measurement tools? To: ipsec@tis.com Date: Tue, 22 Jul 1997 16:41:39 -0700 (PDT) Cc: ho@earth.hpc.org 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 Hello! Apart from the obvious: get_time() /* Run test */ get_time_again() print_time_difference() are there any good test harnesses for measuring algorithms like SHA-1 and MD5 out there? Hilarie, I carboned you because I remember some time back you mentioning explicitly your very good MD5 numbers for a DEC Alpha. I've someone trying to get MD5 and SHA-1 running faster, and I'd like to keep him on the algorithms, rather than writing test harnesses. Obviously memory-access instead of file-access is good, etc. etc. etc. I may post this to sci.crypt, but I figure since we have a lot of implementors and experimenters here, I might get a sufficient answer here. Thanks a lot! Dan From owner-ipsec Tue Jul 22 19:42:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08135 for ipsec-outgoing; Tue, 22 Jul 1997 19:42:13 -0400 (EDT) Message-Id: <3.0.1.32.19970722194600.007db780@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 22 Jul 1997 19:46:00 -0400 To: "Theodore Y. Ts'o" From: Rodney Thayer Subject: Re: "Default" cipher and authenticator Cc: ipsec@tis.com In-Reply-To: <199707222148.RAA17929@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It seems to me then that we have: AH mandatories in AH and Arch and DOI ESP mandatories in ESP and Arch and DOI I think I'm convinced the information belongs in the AH and ESP documents, respectively. I think it's confusing to have it in multiple places. I think that the DOI should point you at the ESP/AH drafts for such information. I think the arch document should, too, but I suspect Steve&co have already done that. At 05:48 PM 7/22/97 -0400, you wrote: > Date: Tue, 22 Jul 1997 14:42:26 -0400 > From: Rodney Thayer > > So it does. I was thinking about what's in the architecture document for > guidelines in the 'must implement' department. > > Do we really have both documents dictating things? Should we? > >Rodney, > > The ESP and AH documents reference what certain algorithms as >the "current default algorithms". This was done mainly to make certain >issues (such as padding and alignment issues) more concrete and easier >to understand. > > Steve and Karen has raised the question of whether or not these >editorial comments caused problems or not. My reaction was that they >made the text easier to understand, and so I supported leaving them in. >It is true that doing so means that we will need to carefully proof the >architecture document and the ESP and AH documents to make sure that >they are coherent. However, I think this is a price that is worth >paying. > > If there is a huge outcry against having that kind of >non-normative text in the AH and ESP documents, we can have them taken >out, of course. I view it as mainly a stylistic (and not technical) >issue. > > Comments? > > - Ted > > From owner-ipsec Tue Jul 22 20:08:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA08290 for ipsec-outgoing; Tue, 22 Jul 1997 20:08:13 -0400 (EDT) From: touch@isi.edu Date: Tue, 22 Jul 1997 17:16:04 -0700 Posted-Date: Tue, 22 Jul 1997 17:16:04 -0700 Message-Id: <199707230016.RAA00559@rum.isi.edu> To: ipsec@tis.com, Dan.McDonald@eng.sun.com Subject: Re: Auth algorithm measurement tools? Cc: ho@earth.hpc.org X-Sun-Charset: US-ASCII X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Tue Jul 22 16:46:02 1997 > From: Dan.McDonald@eng.sun.com (Dan McDonald) > Subject: Auth algorithm measurement tools? > To: ipsec@tis.com > Date: Tue, 22 Jul 1997 16:41:39 -0700 (PDT) > Cc: ho@earth.hpc.org > > Hello! > > Apart from the obvious: > > get_time() > > /* Run test */ > > get_time_again() > > print_time_difference() > > are there any good test harnesses for measuring algorithms like SHA-1 and MD5 > out there? For measuring stand-alone performance, there's the MD5 optimized package, including a modified wrapper, in: ftp://ftp.isi.edu/pub/hpcc-papers/touch/md5-opt.tar.Z see also http://www.isi.edu/atomic2/md5-opts.html This includes: optimized source code (assembler is faster) unrolled code state variables forced to revisters avoid copies for little-endians 'optimized' byte-reordering source code the test 'wrapper' from the MD5 RFC, modified to: use getrusage(), rather than time() command-line variables for block size block repeat double-buffer blocks (to force cache misses) random block initialization (for data dependent algs) skip block initialization print bits/sec Note - some of the fastest measurements have been for in-cache blocks (on-chip cache), and drops of around 25% have been noted when data is not in-cache. Also, these kinds of 'wrapper' tests are not accurate predictors of actual in-situ performance in IPv4. Tests in IPv4 indicate that the packet processing can consume 2/3 of the processor capacity, i.e., resulting in 1/3 the 'stand-alone' throughput for some algorithms. FYI. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From owner-ipsec Wed Jul 23 06:37:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA11452 for ipsec-outgoing; Wed, 23 Jul 1997 06:35:13 -0400 (EDT) From: "Ahmod Bakr El-Sayed: -SC" Organization: Computer Systems Engineering, RMIT To: "C. Harald Koch" , owner-ipsec@ex.tis.com, ipsec@tis.com Date: Wed, 23 Jul 1997 20:43:54 +1000 Subject: Re: ISAKMP performance X-mailer: Pegasus Mail v3.40 Message-ID: <25227E0297@huntsman.cse.rmit.edu.au> Sender: owner-ipsec@ex.tis.com Precedence: bulk |Hi |This is burt from RMIT university Australia, |I hope i am not wasting your time, but this is realy important to my |research. I am researching the IPSEC and i was studying SKIP, |I am now thinking of studying ISAKMP implemenation for key management |since i found all the research intrest is directed to ISAKMP. | | 1- I would like to know why ISAKMP is different then SKIP? | 2- and if this means SKIP implementation will vanish soon? | 3- I would also like to know if there is any ISAKMP exported | version outside USA and work with Solaris? | |I would appreciate your reply | |Have a G'Day From owner-ipsec Wed Jul 23 07:32:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12004 for ipsec-outgoing; Wed, 23 Jul 1997 07:32:14 -0400 (EDT) Date: Tue, 22 Jul 1997 16:10:11 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: ipsec@tis.com Subject: draft-ietf-ipsec-ciph-3des-expiv-00.txt Message-Id: <97Jul22.160519edt.11654@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Page 4, 3.1, paragraph 3: Should begin: However, if the first two or last two independent 64-bit keys are equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the same as DES. 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 Jul 23 08:15:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12502 for ipsec-outgoing; Wed, 23 Jul 1997 08:14:46 -0400 (EDT) Date: Wed, 23 Jul 97 12:01:29 GMT From: "William Allen Simpson" Message-ID: <6312.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, it would be very helpful in the future that you would observe common courtesy, and use your Mail User Agent to excerpt only the relevant lines of the message to which you are replying. 1100 lines of quote for 5 lines of text is a rather bad ratio. The message should have bounced. Please do not do this again. > Date: Tue, 22 Jul 1997 10:14:30 -0400 (EDT) > From: owner-ipsec@ex.tis.com > X-UIDL: 99beb25939e0f5997cf2a7c8835b9b62 > > .com> > From: Roy Pereira > To: "'ipsec@tis.com'" , "'Karen Seo'" > Subject: RE: New draft -- IPSEC ESP > Date: Tue, 22 Jul 1997 10:20:31 -0400 > X-Mailer: Microsoft Exchange Server Internet Mail Connector Version > 4.0.995.52 > MIME-Version: 1.0 > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > Sender: owner-ipsec@portal.ex.tis.com > Precedence: bulk > > Wasn't "draft-ietf-ipsec-esp-04.txt", released on May 30 as shown below? > > From: Karen Seo[SMTP:kseo@bbn.com] > Sent: Friday, May 30, 1997 5:08 PM > To: ipsec@tis.com > Cc: kseo@bbn.com > Subject: New draft -- IPSEC ESP > > Network Working Group Stephen Kent, BBN > Corp > Internet Draft Randall Atkinson, @Home > Network > draft-ietf-ipsec-esp-04.txt 30 May > 1997 > > > > >---------- > >From: Karen Seo[SMTP:kseo@bbn.com] > >Sent: Monday, July 21, 1997 6:33 PM > >To: ipsec@tis.com > >Subject: New draft -- IPSEC ESP > > > > > > > > > >Network Working Group Stephen Kent, BBN Corp > >Internet Draft Randall Atkinson, @Home Network > >draft-ietf-ipsec-esp-04.txt 21 July 1997 > > [~1100 lines deleted] 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 Jul 23 08:15:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12504 for ipsec-outgoing; Wed, 23 Jul 1997 08:14:47 -0400 (EDT) Date: Wed, 23 Jul 97 11:36:33 GMT From: "William Allen Simpson" Message-ID: <6311.wsimpson@greendragon.com> To: Norman Shulman Cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-ciph-des-derived-00 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Norman Shulman > Page 4, 4.2, paragraph 2: Suggest adding the following sentence (copied from > 4.3): "Alternatively, the least significant bit of each key byte is ignored, > or locally set to parity by the DES implementation." > No, the purpose of the parity in manual keying is to detect configuration errors. It SHOULD be required. 4.3 is for automated keying. It MAY be required. SHOULD and MAY have very specific meanings. > Page 6, Pad Values, Range: Should be 1 to 255. > No, please read in context. The value is the _configured_ maximum amount of padding to generate and check. Zero (0) means no checking. For DES, when checking is enabled, the required value is 7, generating and checking 0-7 bytes of padding. More than 7 are allowed. Therefore, the configuration range is 7 to 255. This section was designed to complement the text that the WG asked to be added to the ESP draft. I will check the ESP draft to ensure that it includes the necessary explanation. 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 Jul 23 08:15:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12503 for ipsec-outgoing; Wed, 23 Jul 1997 08:14:47 -0400 (EDT) Date: Wed, 23 Jul 97 12:09:22 GMT From: "William Allen Simpson" Message-ID: <6313.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: FW: private use ISAKMP attributes Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Ran Atkinson > --- On Mon, 21 Jul 1997 17:10:41 -0400 "Edward A. Russell" wrote: > > Of course with private attribute types, there can be conflict between two vendors > > who pick the same number for different things (hint: don't pick the first number in > > the private range). We need to be able to register a standard Private Scheme > > Attribute Class or something. > > SNMP has a third kind of number space, which is proprietary but allocated > uniquely to a particular vendor. ISAKMP does not currently have that kind > of number space (some of us don't view this as a problem). > PPP and Photuris also have that "kind" of number space. It has been shown to be useful. I recommend adding it to ISAKMP. There is no shortage of numbers in ISAKMP. 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 Jul 23 08:46:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12701 for ipsec-outgoing; Wed, 23 Jul 1997 08:46:16 -0400 (EDT) Date: Wed, 23 Jul 97 12:22:51 GMT From: "William Allen Simpson" Message-ID: <6314.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Derived versus Explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted is somewhat confused. The mandatory to implement _manually_ configured algorithm is ciph-des-derived. 1) There are no vendors shipping anything else. 2) There is no technical rationale supporting a change to an explicit IV. 3) There is no increase in cryptographic strength with an explicit IV. 4) A change to explicit IV would "obsolete" thousands of fielded units, and create a user support nightmare. However, there was a "gentlemans' agreement" that ISAKMP could negotiate an explicit IV for single DES when it was so configured. And some vendors (but not all) at the ANX workshops tested such a configuration. To quote Moskowitz on another list, with respect to ISAKMP: Date: Thu, 03 Jul 1997 10:20:45 -0400 From: Robert Moskowitz As co-chair I state that we will give the workgroup a reasonable (end-of-july) time to determine a direction, if not, the market decides this one. Unfortunately, Bob forgot to tell the WG he had made this direction. Another "gentlemans' agreement" was that only 3des-derived would be published as output of this WG, since nobody had documented or tested explicit IV for 3DES, and at least 2 vendors had shipped derived IV based on RFC-1851. However, certain folks just violated that agreement. In response, I will be posting CAST et alia with derived IVs. > From: "Theodore Y. Ts'o" > My understanding is that the mandatory to implement cipher > algorithm, based on what the vendors are implementing and what they > tested at the ANX interoperability workshop, is represented by the I-D > draft-ietf-ipsec-ciph-des-expiv-00.txt. In other words, DES CBC with > an explicit IV. > 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 Jul 23 10:24:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13403 for ipsec-outgoing; Wed, 23 Jul 1997 10:18:49 -0400 (EDT) Date: Wed, 23 Jul 1997 10:24:13 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199707231424.KAA13041@earth.hpc.org> To: Dan.McDonald@eng.sun.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199707222347.QAA20185@baskerville.CS.Arizona.EDU> Subject: Re: Auth algorithm measurement tools? Sender: owner-ipsec@ex.tis.com Precedence: bulk Joe Touch does have a good test harness, I recommend using it. His comments about optimized byte ordering and cache effects should be heeded. My informal survey of test harnesses for crypto software a few years ago revealed that results between any two harnesses were almost always incomparable, and precious few were predictive of actual performance (all errors on the side of optimism). Byte access is the major limitation on speed; this led me to look for a 64-bits-at-a-chunk algorithm that would run at memory speed on the DEC Alpha. What I ended up with was fast enough but very probably not strong enough (sort of MD5-- or MD5-=5 :-) ). Fast algorithms with more parallelism, perhaps using a tree structure, might be possible with FPGA's in the future. Hilarie From owner-ipsec Wed Jul 23 10:26:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13483 for ipsec-outgoing; Wed, 23 Jul 1997 10:26:44 -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-auth-header-01.txt Date: Wed, 23 Jul 1997 09:38:49 -0400 Message-ID: <9707230938.aa07519@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised 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 : IP Authentication Header Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-auth-header-01.txt Pages : 22 Date : 07/22/1997 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. 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-auth-header-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-header-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-ietf-ipsec-auth-header-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: <19970722114752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-header-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-header-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970722114752.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jul 23 10:27:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13497 for ipsec-outgoing; Wed, 23 Jul 1997 10:27:14 -0400 (EDT) Content-Type: Multipart/Mixed; Boundary="NextPart" 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-ciph-idea-cbc-00.txt Date: Wed, 23 Jul 1997 09:38:41 -0400 Message-ID: <9707230938.aa07462@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 IDEA-CBC Algorithm Using Explicit IV Author(s) : R. Adams Filename : draft-ietf-ipsec-ciph-idea-cbc-00.txt Pages : 7 Date : 07/22/1997 This draft describes the use of the IDEA [Schneier] block cipher algorithm in CBC mode with the IPSec Encapsulating Security Payload (ESP) [Kent97]. 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-ciph-idea-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-idea-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-ciph-idea-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: <19970722105509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-idea-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-idea-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970722105509.I-D@ietf.org> --OtherAccess-- --NextPart-- To: Internet-Drafts Subject: I-D REVIEW:draft-ietf-ipsec-ciph-idea-cbc-00.txt ---------- ------Included Message--- Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce cc: ipsec@tis.com Dcc: all-ietf@ietf.org From: Internet-Drafts@ietf.org Bcc: Internet-Drafts Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-idea-cbc-00.txt --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 IDEA-CBC Algorithm Using Explicit IV Author(s) : R. Adams Filename : draft-ietf-ipsec-ciph-idea-cbc-00.txt Pages : 7 Date : 07/22/1997 This draft describes the use of the IDEA [Schneier] block cipher algorithm in CBC mode with the IPSec Encapsulating Security Payload (ESP) [Kent97]. 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-ciph-idea-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ciph-idea-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-ciph-idea-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: <19970722105509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-idea-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-idea-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970722105509.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jul 23 10:27:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13510 for ipsec-outgoing; Wed, 23 Jul 1997 10:27:44 -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-v2-00.txt Date: Wed, 23 Jul 1997 09:38:51 -0400 Message-ID: <9707230938.aa07537@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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent, R. Atkinson Filename : draft-ietf-ipsec-esp-v2-00.txt Pages : 19 Date : 07/22/1997 The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. 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-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-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-ietf-ipsec-esp-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: <19970722115137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970722115137.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jul 23 10:29:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13546 for ipsec-outgoing; Wed, 23 Jul 1997 10:29:14 -0400 (EDT) Date: Wed, 23 Jul 1997 10:31:12 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: William Allen Simpson cc: ipsec@tis.com Subject: Re: draft-ietf-ipsec-ciph-des-derived-00 In-Reply-To: <6311.wsimpson@greendragon.com> Message-Id: <97Jul23.102628edt.11654@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, 23 Jul 1997, William Allen Simpson wrote: > > Page 6, Pad Values, Range: Should be 1 to 255. > > > No, please read in context. The value is the _configured_ maximum > amount of padding to generate and check. Zero (0) means no checking. > For DES, when checking is enabled, the required value is 7, generating > and checking 0-7 bytes of padding. More than 7 are allowed. Therefore, > the configuration range is 7 to 255. > > This section was designed to complement the text that the WG asked to be > added to the ESP draft. I will check the ESP draft to ensure that it > includes the necessary explanation. Since there are really two independent attributes here, I propose replacing this parameter with the following two: Pad Checking New implementations use verifiable values. However, some earlier implementations used pseudo-random values. This check must only be used with those peers that have implemented this feature. Default: 0 (checking off). Range: 0 to 1 (checking on). Maximum Pad Length Some operations desire additional padding to inhibit traffic analysis. Default: 7. Range: 7 to 255. 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 Jul 23 10:36:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13658 for ipsec-outgoing; Wed, 23 Jul 1997 10:36:44 -0400 (EDT) Message-Id: <97Jul23.103947edt.11655@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Re: Derived versus Explicit IV References: <6314.wsimpson@greendragon.com> In-reply-to: Your message of "Wed, 23 Jul 1997 08:22:51 -0400". <6314.wsimpson@greendragon.com> From: "C. Harald Koch" Date: Wed, 23 Jul 1997 10:44:43 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > 4) A change to explicit IV would "obsolete" thousands of fielded units, > and create a user support nightmare. Yes. The draft ESP spec, combined with the ciph-des-derived spec, is compatible with the 32-bit-IV option in RFC 1827+1829, which in turn is the most commonly implemented transform. The ciph-des-expiv is *not* compatible with old implementations, due to the addition of the mandatory sequence number field in the ESP header. If the new ESP plus new mandatory to implement transforms are *not* backwards compatible *ON THE WIRE*, then a new IP protocol value for ESP will be required. -- Harald Koch From owner-ipsec Wed Jul 23 11:06:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13865 for ipsec-outgoing; Wed, 23 Jul 1997 11:05:44 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" Subject: RE: Derived versus Explicit IV Date: Wed, 23 Jul 1997 11:15:51 -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 > >If the new ESP plus new mandatory to implement transforms are *not* >backwards compatible *ON THE WIRE*, then a new IP protocol value for ESP >will be required. > RFC1827 (ESP) only specifies a 32 bit number to represent the SPI. The rest of the ESP payload was dependent on the actual transform. RFC1829 added an IV, data, padding, pad length, and the next protocol fields. Thus the new ESP is compatible with the old ESP? From owner-ipsec Wed Jul 23 11:24:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14031 for ipsec-outgoing; Wed, 23 Jul 1997 11:23:45 -0400 (EDT) Message-Id: <3.0.1.32.19970723112603.007db640@pop3.pn.com> X-Pgp-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 23 Jul 1997 11:26:03 -0400 To: "C. Harald Koch" From: Rodney Thayer Subject: Re: Derived versus Explicit IV Cc: ipsec@tis.com In-Reply-To: <97Jul23.103947edt.11655@janus.tor.securecomputing.com> References: <6314.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Why? No new number was demanded for the HMAC variants of AH and that's not wire-compatible with 1827. It was my understanding that it was considered a *feature* that you couldn't tell what protocol it was by looking at the protocol number. Not that I liked that, but I was told that was what people wanted. At 10:44 AM 7/23/97 -0400, you wrote: >If the new ESP plus new mandatory to implement transforms are *not* >backwards compatible *ON THE WIRE*, then a new IP protocol value for ESP >will be required. From owner-ipsec Wed Jul 23 11:28:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14074 for ipsec-outgoing; Wed, 23 Jul 1997 11:28:15 -0400 (EDT) From: andrade@netcom.com (Andrade Software Andrade Networking) Message-Id: <199707231536.IAA27622@netcom13.netcom.com> Subject: Re: Re[6]: ISAKMP performance To: pcalhoun@usr.com Date: Wed, 23 Jul 1997 08:36:27 -0700 (PDT) Cc: ho@earth.hpc.org, ipsec@tis.com In-Reply-To: <3D4C3000.3000@usr.com> from "pcalhoun@usr.com" at Jul 22, 97 08:09:33 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: 521 PatC's scenario sounds like either each box (with 1000 connections) handles the key setup or each server would (with 20 boxes each). In the former (per box setup) you would probably need to handle peak loads in the 10-100/sec range. In the latter (per server setup) you would probably need to handle in the 100-1000/sec range. Public Key can't scale up easily to these rates even using hardware boosts. - Alex -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-ipsec Wed Jul 23 11:34:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14138 for ipsec-outgoing; Wed, 23 Jul 1997 11:34:15 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" Subject: RE: Derived versus Explicit IV Date: Wed, 23 Jul 1997 11:46: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 >Ted is somewhat confused. > >The mandatory to implement _manually_ configured algorithm is >ciph-des-derived. No, Bill, you are confused. The mandatory cipher algorithm mentioned is a relic from the days when we only had one DES transform. Now that we have different flavours of DES transforms (thanks to you), the mandatory cipher algorithm needs to be more clearly defined. This is why the point was raised in the first place. > 1) There are no vendors shipping anything else. RFC1829 allows for both a derived IV and an explicit IV. But are you saying that these vendors who have already shipped RFC1829 compliant products do not wish to upgrade their product to the newer IPSec standard? > > 2) There is no technical rationale supporting a change to an explicit IV. Why are we changing to explicit IV when we have been there all along? Through all of the changes that have taken place for ESP and AH, I don't remember not having explicit IV in my code. The 32-bit IV derived to 64-bits was a hack for the sake of alignment. > 3) There is no increase in cryptographic strength with an explicit IV. So why should we change to derived IV then? > 4) A change to explicit IV would "obsolete" thousands of fielded units, > and create a user support nightmare. We had made the decision to obsolete RFC1829 a long time ago. >However, there was a "gentlemans' agreement" that ISAKMP could negotiate >an explicit IV for single DES when it was so configured. And some >vendors (but not all) at the ANX workshops tested such a configuration. At the last ANX bakeoff, no one tested such an attribute, since your DERIVED IV ESP algorithms did not yet exist. >To quote Moskowitz on another list, with respect to ISAKMP: > Date: Thu, 03 Jul 1997 10:20:45 -0400 > From: Robert Moskowitz > As co-chair I state that we will give the workgroup a reasonable > (end-of-july) time to determine a direction, if not, the market decides > this one. What planet are you on? All of the developers that spoke up clearly stated that they did not wish to implement yet another useless negotiation attribute. >Unfortunately, Bob forgot to tell the WG he had made this direction. > >Another "gentlemans' agreement" was that only 3des-derived would be >published as output of this WG, since nobody had documented or tested >explicit IV for 3DES, and at least 2 vendors had shipped derived IV >based on RFC-1851. RFC1851 states that it can have either an explicit IV or a derived IV. draft-ietf-ipsec-esp-3des-md5 uses an EXPLICIT IV or a CONSTANT IV. In fact after going through all of the ESP transform/algorithm drafts that I could find, I found that all of them could handle EXPLICIT IV (except your new drafts). Some also handled a CONSTANT IV, while the older ones also handled a DERIVED IV. Vendor's who released implementations on draft documents or on RFCs that have been obsoleted obviously realized that the protocol would change and they would have to upgrade their IPSec implementation. DERIVED IV is something that you brought back from the dead after your lengthy absence from the IPSec wg. All of the ESP drafts had already moved on and evolved. Why are you trying to de-evolve the IPSec protocols back to 1996 ? From owner-ipsec Wed Jul 23 11:52:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14338 for ipsec-outgoing; Wed, 23 Jul 1997 11:52:18 -0400 (EDT) Message-Id: <97Jul23.115532edt.11654@janus.tor.securecomputing.com> To: Roy Pereira cc: "'ipsec@tis.com'" Subject: Re: Derived versus Explicit IV References: In-reply-to: Your message of "Wed, 23 Jul 1997 11:15:51 -0400". 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: Wed, 23 Jul 1997 12:00:28 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Thus the new ESP is compatible with the old ESP? To answer both of your messages, here's what we're talking about: Old ESP+DES (with 32-bit IV): NEW ESP + ciph-des-derived: 32bits SPI 32bits SPI 32bits IV 32bits Sequence number ciphertext ciphertext pad pad 8bits padlen 8bits padlen 8bits nextheader 8bits nextheader Looks like the same packet to me, especially when the "IV derived from Sequence Number" algorithm is the same as the old RFC1829 "convert 32-bit IV to 64 bit IV" algorithm. Therefore, ciph-des-derived MUST be mandatory-to-implement, in order that new products retain backwards compatability with old products. > But are you saying that these vendors who have already shipped RFC1829 > compliant products do not wish to upgrade their product to the newer > IPSec standard? Yes, but we can't require that customers upgrade their deployed equipment (especially with a "flag day" due to incompatabilities). > Vendor's who released implementations on draft documents or on RFCs that > have been obsoleted obviously realized that the protocol would change > and they would have to upgrade their IPSec implementation. RFC 1827/1829 are both IETF Proposed Standards. Like it or not, they're out in the field, and have been for almost TWO YEARS. This is the price this working group pays for its glacial progress. -- Harald From owner-ipsec Wed Jul 23 11:55:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14362 for ipsec-outgoing; Wed, 23 Jul 1997 11:55:45 -0400 (EDT) Message-Id: <97Jul23.115900edt.11655@janus.tor.securecomputing.com> To: Rodney Thayer cc: ipsec@tis.com Subject: Re: Derived versus Explicit IV References: <3.0.1.32.19970723112603.007db640@pop3.pn.com> In-reply-to: rodney's message of "Wed, 23 Jul 1997 11:26:03 -0400". <3.0.1.32.19970723112603.007db640@pop3.pn.com> From: "C. Harald Koch" Date: Wed, 23 Jul 1997 12:03:55 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk > Why? No new number was demanded for the HMAC variants of AH and that's not > wire-compatible with 1827. It was my understanding that it was considered > a *feature* that you couldn't tell what protocol it was by looking at the > protocol number. Oops; you're right; I was over-reacting.... -- Harald From owner-ipsec Wed Jul 23 12:09:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14489 for ipsec-outgoing; Wed, 23 Jul 1997 12:08:45 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Wed, 23 Jul 1997 06:40:07 -0500 Message-ID: <3D630B30.3000@usr.com> To: Steven Bellovin Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re[8]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.781576968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.781576968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part The idea here is not necessarily to protect the data within the L2TP data stream, but to protect the L2TP peers (the NAS and the firewall) given that the L2TP protocol is insecure and requires underlying security. PatC ______________________________ Reply Separator _________________________________ Subject: Re: Re[6]: ISAKMP performance Author: Steven Bellovin at Internet Date: 7/22/97 1:21 PM Now, storing the SA off to some third party is a VERY interesting idea. Presumably NAS(a) could send SA information to this third party, which would obviously be trusted. Do we know of any such thing being run today? I would assume that the keys being passed to this third party would be encrypted using a key encryption key which only NAS(a) could decrypt. How do most folk feel about this design? It's quite attractive, and in fact the third party need not be trusted in the cryptographic sense. As you note, the information is encrypted (including an authenticity check) with a NAS(a)-only key, and hence is tamperproof. It could fail to respond, or it could respond with a damaged or fraudulent package, in which case the NAS simply establishes a new security association. In other words, this third party is a cache. But that all begs the question of whether or not it's worth doing. Well, it's probably worth doing in the business sense, but architecturally, if I'm running ipsec from my laptop to my firewall, I don't care whether or not the NAS-to-firewall L2TP traffic is protected or not. --IMA.Boundary.781576968 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 3D4EF670; Tue, 22 Jul 97 12:35:35 -0500 Received: from ns.research.att.com by usr.com (8.7.5/3.1.090690-US Robotics) id MAA09300; Tue, 22 Jul 1997 12:12:59 -0500 (CDT) Received: from research.att.com ([135.205.32.20]) by ns; Tue Jul 22 13:23:03 EDT 1997 Received: from raptor.research.att.com ([135.207.23.32]) by research; Tue Jul 22 13:21:30 EDT 1997 Received: from research.att.com (raptor.research.att.com [135.207.23.32]) by raptor.research.att.com (8.8.5/8.7) with ESMTP id NAA13951; Tue, 22 Jul 1997 13:21:30 -0400 (EDT) Message-Id: <199707221721.NAA13951@raptor.research.att.com> To: pcalhoun@usr.com cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re: Re[6]: ISAKMP performance Date: Tue, 22 Jul 1997 13:21:29 -0400 From: Steven Bellovin --IMA.Boundary.781576968-- From owner-ipsec Wed Jul 23 12:09:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14504 for ipsec-outgoing; Wed, 23 Jul 1997 12:09:15 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Wed, 23 Jul 1997 06:44:49 -0500 Message-ID: <3D630B60.3000@usr.com> To: Daniel Harkins Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re[8]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.091576968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.091576968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Dan, L2TP provides some features that IPSEC cannot provide. They sort-of look at ISDN call signalling messages over an ethernet. Imagine the phone rings, the NAS looks up DNIS/ANI and sends a tunnel request message to the tunnel terminator. If the response is successful, then the NAS answers the phone and tunnels all data. This cannot possibly be done with IPSEC. BTW, L2TP also offers outbound call features, where the NAS acts as a modem pool. PatC ______________________________ Reply Separator _________________________________ Subject: Re: Re[6]: ISAKMP performance Author: Daniel Harkins at Internet Date: 7/22/97 11:07 AM Pat, Although the lifetime of a SA might be a year, generally if the user logs off or the connection is dropped for whatever reason the SA is thrown away. Since joe@bigcorp doesn't know which NAS he dials into he wouldn't know which SA to use to talk to the NAS anyway (assuming he's also cacheing the SAs for the various NASs too). You're only going to keep active SAs, so if your box can support 1000 active connections that's 1000 SAs period. You're also just securing the NAS to LNS. joe@bigcorp's line to his NAS is in the clear. There are certain gov't agencies (not necessarily US either: imagine a Boeing executive in France these days) that I don't think have figured out how to use a sniffer but they have decades of experience tapping phone lines. If I was joe and my communications were sensitive enough to require encryption I'd want my whole thing encrypted. It seems pointless to leave in the clear the one point that would be easiest to attack. And since IPSec provides tunneling capabilities already why not just use them? (IMPORTANT NOTE: that's my opinion and not necessarily that of my employer). Also, there seems to be alot of concern about KM performance but if I was joe@bigcorp in your example packets for my telnet as they traverse through the ether would look like this if I'm not mistaken: IP | IPSec | UDP | L2TP | PPP | IP | TCP | which is a heckuva lot of overhead (IMPORTANT NOTE: that's my opinion and not necessarily that of my employer). I'd be pretty concerned about 1000 of those things too. If *I* was joe@bigcorp I wouldn't pay for BigDarnServiceProvider's secure tunneling service-- I'd just use IPSec in tunnel mode from my laptop or SOHO router or whatever. End-to-end security with less overhead. Dan. > Thanks for the input, but I believe that you may have missed the > rest of the thread. Let me paint a picture of a real network where my > product would typically sit. > > Imagine BigDarnServiceProvider which has 500 POPs around the U.S. > Each POP has about 20 of my boxes (which has about 1000 incoming ports > each). So that means about 20,000 ports per POP and so on. > > The service being offered (on top of straight Internet Access) is > access to corporate networks using some well known Tunneling Protocol > (in this case L2TP because it tunnels PPP traffic). This service > provider has thousands of customers which have outsourced their dial > service to this ISP. In addition, this service provider belongs to > some Roaming corsortiums which means that users travelling to the US > from abroad can use this service provider instead of having to do an > international long distance for corporate access. > > So in this case the number of possible Firewalls to traverse are > really in the thousands! > > So let's assume that user Joe@BigCorp dials in on NAS(a), an SA is > established with BigCorp's Firewall. The SA could expire in a year. > Once the user logs out, he logs back in and now connects to NAS(b), > which needs to redo the SA from scratch. (will a hunt group, you have > no idea which NAS you will hit, and in some installations you have no > idea which city you will get connected to!). > > Now user Bob@BiggerCorp dials in and hits NAS(a), again the SA > needs to be established and so on... Since I have 1000 ports, that > means alot of SAs need to be cached. And even if the SA was to expire > in a year, some of these embedded boxes with limited memory would have > to trash the SA in order to preserve memory. So that means that the > next day when Sally@BigCorp dials in and hits NAS(a), chances are an > SA will have to be established again! > > Storing to non-volative memory is very difficult. Hard drives are > not available in most routers (well, not in the ones that most ISPs > are willing to run :). And flash memory is very limited. > > Now, storing the SA off to some third party is a VERY interesting > idea. Presumably NAS(a) could send SA information to this third party, > which would obviously be trusted. Do we know of any such thing being > run today? I would assume that the keys being passed to this third > party would be encrypted using a key encryption key which only NAS(a) > could decrypt. How do most folk feel about this design? > > I would appreciate any input, > > PatC --IMA.Boundary.091576968 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 3D4F9D00; Tue, 22 Jul 97 13:20:00 -0500 Received: from rhodes.cisco.com by usr.com (8.7.5/3.1.090690-US Robotics) id MAA11802; Tue, 22 Jul 1997 12:57:20 -0500 (CDT) Received: from dharkins-ss20 (dharkins-ss20.cisco.com [171.69.56.149]) by rhodes.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id LAA27565; Tue, 22 Jul 1997 11:07:35 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by dharkins-ss20 (8.6.8+c/CISCO.WS.1.1) with SMTP id LAA21278; Tue, 22 Jul 1997 11:07:34 -0700 Message-Id: <199707221807.LAA21278@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pcalhoun@usr.com Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re: Re[6]: ISAKMP performance In-Reply-To: Your message of "Tue, 22 Jul 1997 08:09:33 CDT." <3D4C3000.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jul 1997 11:07:34 -0700 From: Daniel Harkins --IMA.Boundary.091576968-- From owner-ipsec Wed Jul 23 12:12:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14557 for ipsec-outgoing; Wed, 23 Jul 1997 12:12:45 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Wed, 23 Jul 1997 09:07:32 -0500 Message-ID: <3D630BE0.3000@usr.com> To: Bill Sommerfeld Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re[8]: ISAKMP performance Content-Type: multipart/mixed; boundary="IMA.Boundary.791576968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.791576968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Bill, In this application, it is implied that end to end security is used (hopefully using IPSEC). Againk, as I have repeted many times, I am not attempting to encrypt the users' data, merely trying to get around all of the security holes in the L2TP protocol by using IPSEC underneath it. In this case, authentication of each L2TP peer is done using IPSEC. This will ensure that no malicious user inserts data into a tunnel data stream. There seems to be this misunderstanding that I am trying to encrypt the users' data, which is obviously wrong. There is no trust between the NAS and the firewall! I am simply trying to get around the L2TP deficiencies. Again, this gets back to the fact that most WG are simply pointing to the IPSEC group for all of their security needs. I think this is WRONG and more thought need to be put into it before a WG decides to do this, but unfortunately this WG is called IP Security. It gets very difficult to argue NOT using IP Security if a protocol runs over IP (just because of the name implies that it makes ALL IP traffic secure, does not mention scaling problems). As I mentioned earlier, I think that the IPSEC needs to advertise the target applications which it is trying to address in order to ensure that we do not have too many of these WGs blindly point to IPSEC for all underlying security and key management. PatC ______________________________ Reply Separator _________________________________ Subject: Re: Re[6]: ISAKMP performance Author: Bill Sommerfeld at Internet Date: 7/22/97 3:12 PM Hmm. The scaling issues you're presenting seem to me to indicate more of a problem with your architecture, not with ipsec. I agree with Dan Harkins.. the correct place for ipsec in a mobile/dialup environment is in the dialup end system, not in the first-hop router (which is what the NAS effectively is). There may still be scaling issues on the security gateways/firewalls at the other end of the tunnel.. It's not clear what doing a secure tunnel from the NAS to the firewall buys me as an end user, as I can't trust the phone network to be secure. - Bill --IMA.Boundary.791576968 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 3D509100; Tue, 22 Jul 97 14:25:04 -0500 Received: from capone.ch.apollo.hp.com by usr.com (8.7.5/3.1.090690-US Robotics) id OAA14871; Tue, 22 Jul 1997 14:02:31 -0500 (CDT) Received: from thunk.ch.apollo.hp.com by capone.ch.apollo.hp.com id ; Tue, 22 Jul 1997 15:13:09 -0400 Received: from thunk ([[UNIX: localhost]]) by thunk.ch.apollo.hp.com (8.8.5/8.6.12) with ESMTP id PAA03993; Tue, 22 Jul 1997 15:13:05 -0400 (EDT) Message-Id: <199707221913.PAA03993@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: pcalhoun@usr.com Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re: Re[6]: ISAKMP performance In-Reply-To: pcalhoun's message of Tue, 22 Jul 1997 08:09:33 -0500. <3D4C3000.3000@usr.com> Date: Tue, 22 Jul 1997 15:12:45 -0400 From: Bill Sommerfeld --IMA.Boundary.791576968-- From owner-ipsec Wed Jul 23 13:07:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14938 for ipsec-outgoing; Wed, 23 Jul 1997 13:06:13 -0400 (EDT) Date: Wed, 23 Jul 1997 13:02:02 -0400 (EDT) From: John Shriver Message-Id: <199707231702.NAA15492@shiva-dev.shiva.com> To: pcalhoun@usr.com CC: chk@tor.securecomputing.com, sommerfeld@apollo.hp.com, dpkemp@missi.ncsc.mil, ipsec@tis.com In-reply-to: <3D3D3330.3000@usr.com> (pcalhoun@usr.com) Subject: ISAKMP performance & phone switch capacity Sender: owner-ipsec@ex.tis.com Precedence: bulk Pat, I think you're missing part of the equation. What is the call setup rate of a Lucent 5ESS? Yes, it's more than 6/second. But can it really setup 3000 calls per second? I doubt it, particularly in the configurations (number of CPU's) that a telco would be likely to deploy. Lucent doesn't appear to put detailed specifications on their WWW site, and I don't really feel like calling their sales office... From owner-ipsec Wed Jul 23 13:15:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15031 for ipsec-outgoing; Wed, 23 Jul 1997 13:15:13 -0400 (EDT) Message-ID: <01BC9752.5BD1CD80@BIGHUGE> From: Rob Adams To: "'Roy Pereira'" , "'ipsec@tis.com'" Subject: RE: Derived versus Explicit IV Date: Wed, 23 Jul 1997 10:22:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Roy completely here. We've had a directive from the chair to obsolete 1829. Bob indicated quite clearly that he saw no need for backwards compatibility. And as stated in this thread earlier, "whether you like it or not," being compatible with 1829 is not a goal for this group or our documents. >From the same July 03 mail from Bob that Simpson quotes: >Thus as an educated consumer, I reject all concerns about backwards >compatibility. As co-chair of a protocol group, I seriously question the >value of backwards compatibility in this case, other than a foot-note and >some accommodation. "Some accommodation" does not indicate mandatory implementation of obsolete features even in the manually configured case. Roy states my opinions on the rest of this thread so well that I don't feel any need to add any more.. %) Thanks Roy. This thread boarders on the waste'o'bandwith. If we're going to talk about what should be mandatory, we must focus on what we as a group feel comfortable putting forward within the constraints laid down by the chair. In this setting, it seems clear that des-cbc-expliciv for ESP and hmac-md5 for AH are the choices. -----Original Message----- From: Roy Pereira [SMTP:rpereira@TimeStep.com] Sent: Wednesday, July 23, 1997 8:47 AM To: 'ipsec@tis.com' Subject: RE: Derived versus Explicit IV >Ted is somewhat confused. > >The mandatory to implement _manually_ configured algorithm is >ciph-des-derived. No, Bill, you are confused. The mandatory cipher algorithm mentioned is a relic from the days when we only had one DES transform. Now that we have different flavours of DES transforms (thanks to you), the mandatory cipher algorithm needs to be more clearly defined. This is why the point was raised in the first place. . . . From owner-ipsec Wed Jul 23 13:57:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15262 for ipsec-outgoing; Wed, 23 Jul 1997 13:57:14 -0400 (EDT) Message-Id: <97Jul23.140044edt.11659@janus.tor.securecomputing.com> To: Rob Adams cc: "'ipsec@tis.com'" Subject: Re: Derived versus Explicit IV References: <01BC9752.5BD1CD80@BIGHUGE> In-reply-to: Your message of "Wed, 23 Jul 1997 13:22:26 -0400". <01BC9752.5BD1CD80@BIGHUGE> From: "C. Harald Koch" Date: Wed, 23 Jul 1997 14:05:39 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <01BC9752.5BD1CD80@BIGHUGE>, Rob Adams writes: > I agree with Roy completely here. We've had a directive from the chair to > obsolete 1829. Since when? I missed that directive. Where is it written down? Or did it perhaps occur on a mailing list not affilated with the IPsec WG? > From the same July 03 mail from Bob that Simpson quotes: > > >Thus as an educated consumer, I reject all concerns about backwards > >compatibility. As co-chair of a protocol group, I seriously question the > >value of backwards compatibility in this case, other than a foot-note and > >some accommodation. > > "Some accommodation" does not indicate mandatory implementation of obsolete > features even in the manually configured case. This message was not part of the WG discussion. Bob was not acting in any capacity as WG chair. I reject your analysis. There is no reason *not* to support backwards compatablity, given an easy option to do so. Compatability is *always* a good thing. Frankly, I don't understand why this is even an issue, except for the fact that Bill Simpson raised it. -- Harald From owner-ipsec Wed Jul 23 14:20:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15441 for ipsec-outgoing; Wed, 23 Jul 1997 14:19:44 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Wed, 23 Jul 1997 12:47:00 -0500 Message-ID: <3D64EEA0.3000@usr.com> To: John Shriver Cc: chk@tor.securecomputing.com, sommerfeld@apollo.hp.com, dpkemp@missi.ncsc.mil, ipsec@tis.com Subject: Re: ISAKMP performance & phone switch capacity Content-Type: multipart/mixed; boundary="IMA.Boundary.229286968" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.229286968 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part John, I thought I had made this clear. The worst case scenario (being the reboot case) I was not overly worried about (unfortunately that is how my QA dept tests our products, being the worst case :(. However, receiving 50 calls almost simultaneously actually exists today in my customer's networks. And this really is a problem is public key technology. PatC ______________________________ Reply Separator _________________________________ Subject: ISAKMP performance & phone switch capacity Author: John Shriver at Internet Date: 7/23/97 1:02 PM Pat, I think you're missing part of the equation. What is the call setup rate of a Lucent 5ESS? Yes, it's more than 6/second. But can it really setup 3000 calls per second? I doubt it, particularly in the configurations (number of CPU's) that a telco would be likely to deploy. Lucent doesn't appear to put detailed specifications on their WWW site, and I don't really feel like calling their sales office... --IMA.Boundary.229286968 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 3D63C7E0; Wed, 23 Jul 97 12:16:46 -0500 Received: from shiva-dev.shiva.com by usr.com (8.7.5/3.1.090690-US Robotics) id LAA29381; Wed, 23 Jul 1997 11:54:14 -0500 (CDT) Received: (jas@localhost) by shiva-dev.shiva.com (8.7.6/8.6.4) id NAA15492; Wed, 23 Jul 1997 13:02:02 -0400 (EDT) Date: Wed, 23 Jul 1997 13:02:02 -0400 (EDT) From: John Shriver Message-Id: <199707231702.NAA15492@shiva-dev.shiva.com> To: pcalhoun@usr.com CC: chk@tor.securecomputing.com, sommerfeld@apollo.hp.com, dpkemp@missi.ncsc.mil, ipsec@tis.com In-reply-to: <3D3D3330.3000@usr.com> (pcalhoun@usr.com) Subject: ISAKMP performance & phone switch capacity --IMA.Boundary.229286968-- From owner-ipsec Wed Jul 23 15:09:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15788 for ipsec-outgoing; Wed, 23 Jul 1997 15:09:13 -0400 (EDT) Message-ID: <01BC9761.E0ED20F0@Tastid.cisco.com> From: Rob Adams To: "'C. Harald Koch'" Cc: "'ipsec@tis.com'" Subject: RE: Derived versus Explicit IV Date: Wed, 23 Jul 1997 12:13:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >-----Original Message----- >From: C. Harald Koch [SMTP:chk@utcc.utoronto.ca] >Sent: Wednesday, July 23, 1997 11:06 AM >To: Rob Adams >Cc: 'ipsec@tis.com' >Subject: Re: Derived versus Explicit IV > >In message <01BC9752.5BD1CD80@BIGHUGE>, Rob Adams writes: >> I agree with Roy completely here. We've had a directive from the chair to >> obsolete 1829. > >Since when? I missed that directive. Where is it written down? Or did it >perhaps occur on a mailing list not affilated with the IPsec WG? > >> From the same July 03 mail from Bob that Simpson quotes: >> >> >Thus as an educated consumer, I reject all concerns about backwards >> >compatibility. As co-chair of a protocol group, I seriously question the >> >value of backwards compatibility in this case, other than a foot-note and >> >some accommodation. >> >> "Some accommodation" does not indicate mandatory implementation of obsolete >> features even in the manually configured case. > >This message was not part of the WG discussion. Bob was not acting in any >capacity as WG chair. I reject your analysis. Hmm.. Seemed to me like it was part of the working group discussion. Also, I think that the line "As co-chair of a protocol group" states pretty strongly that he was speaking as chair. You can reject my analysis. That's your option. However, I stand by my analysis. Why don't we let Bob be the definitive voice here. Bob? > >There is no reason *not* to support backwards compatablity, given an easy >option to do so. Compatability is *always* a good thing. > Simply because something is easy for you does not mean it is easy for me or even the right thing to do. I don't know of any of my customers asking for this. I don't know if it worth supporting for me or my customer base. Currently, my believe is that it isn't worth it. >Frankly, I don't understand why this is even an issue, except for the fact >that Bill Simpson raised it. It is an issue because I haven't heard any compelling reason to support it. I don't have any hard numbers on what implementations are in the field. I have seen no study on the impact of not supporting it. I do not have it already and I don't have any customers, that I know of, asking for it. If I see some hard numbers other than just guesses, I'll reconsider my opinion. If I have customers asking for it, I'll reconsider my opinion. This is all beside the fact the co-chair stated a very strong opinion to obsolete it. Bill Simpson has nothing to do with it. I would have my opinion regardless of who raised the point. The suggestion is a bit silly. Although his style may not be to some peoples liking, he sometimes has good points, sometimes not. Just like all the rest of us. I personally don't understand why this is an issue since we decided quite some time ago. In 10 years this working group will be fondly looked back upon as the "flogging the dead horse" group. From owner-ipsec Wed Jul 23 15:28:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16025 for ipsec-outgoing; Wed, 23 Jul 1997 15:27:14 -0400 (EDT) Message-Id: <97Jul23.152749edt.11655@janus.tor.securecomputing.com> X-Mailer: exmh version 2.0delta 6/3/97 To: Rob Adams cc: "'C. Harald Koch'" , "'ipsec@tis.com'" , oz@tor.securecomputing.com Subject: Re: Derived versus Explicit IV Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 15:32:45 -0400 From: "ozan s. yigit" Sender: owner-ipsec@ex.tis.com Precedence: bulk > I don't know of any of my customers asking for this. do you have a product to which this issue is relevant? > ... This is all beside the fact the co-chair stated a very > strong opinion to obsolete it. it is my understanding that these issues are decided with rough consensus which i doubt chairman's opinions necessarily reflect. if i am mistaken someone should say so. oz --- Always ... always remember: Less is less. More is more. More is better. And twice as much is good too. Not enough is bad. And too much is never enough except when it's just about right. -- The Tick. From owner-ipsec Wed Jul 23 16:00:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16229 for ipsec-outgoing; Wed, 23 Jul 1997 15:59:45 -0400 (EDT) Date: Wed, 23 Jul 1997 13:06:44 -0700 Message-Id: <199707232006.NAA14407@gump.eng.ascend.com> From: Karl Fox To: "ozan s. yigit" Cc: Rob Adams , "'C. Harald Koch'" , "'ipsec@tis.com'" Subject: Re: Derived versus Explicit IV In-Reply-To: <97Jul23.152749edt.11655@janus.tor.securecomputing.com> References: <97Jul23.152749edt.11655@janus.tor.securecomputing.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk ozan s. yigit writes: > it is my understanding that these issues are decided with rough consensus > which i doubt chairman's opinions necessarily reflect. if i am mistaken > someone should say so. Being myself a WG chair, I quite agree, but I'd also like to point out that achieving consensus has been very difficult in this group (and, he said ducking, apparently historically not a priority). For what it's worth, I cast my votestraw ballot on the side of backward compatibility. I've been shipping 1829 for two weeks shy of two years now. -- 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 Wed Jul 23 17:15:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16791 for ipsec-outgoing; Wed, 23 Jul 1997 17:14:16 -0400 (EDT) Date: Wed, 23 Jul 1997 17:22:45 -0400 Message-Id: <199707232122.RAA18514@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "C. Harald Koch" Cc: ipsec@tis.com In-Reply-To: C. Harald Koch's message of Wed, 23 Jul 1997 10:44:43 -0400, <97Jul23.103947edt.11655@janus.tor.securecomputing.com> Subject: Re: Derived versus Explicit IV Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk References: <6314.wsimpson@greendragon.com> From: "C. Harald Koch" The draft ESP spec, combined with the ciph-des-derived spec, is compatible with the 32-bit-IV option in RFC 1827+1829, which in turn is the most commonly implemented transform. This is not strictly true. It's true *only* if the authenticator is not present (which opens you to the active attacks pointed out by Steve Bellovin), and if you assume the RFC-1829 implementation uses a counter initialized to zero for the 32-bit IV. Given that support for the authenticator is required, an old RFC-1829 implementation won't be compliant anyway. In my judgement, this limited interoperability isn't particularly useful, all things considered. If you're going to be implementing something which is compatible with the old RFC1827-1829, you can simply use those old RFC's; they're not going away. If you're going to be supporting the new key management stuff, it's not that hard to support the new cipher algorithms, and there are very good security reasons for doing so. Finally, if you need to support both the old manual keying way of doing things and the new key-management way of doing things, the extra code to support a new cipher algorithm is minimal; the size of your DES, MD5, SHA, et. al. implementation will completely dwarf the extra code you need to support the new way of handling the sequence number and IV (which is after all, simply byte juggling). - Ted From owner-ipsec Wed Jul 23 18:08:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17117 for ipsec-outgoing; Wed, 23 Jul 1997 18:08:17 -0400 (EDT) Date: Wed, 23 Jul 1997 18:15:04 -0400 Message-Id: <199707232215.SAA18535@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: pcalhoun@usr.com Cc: Bill Sommerfeld , ho@earth.hpc.org, ipsec@tis.com In-Reply-To: pcalhoun@usr.com's message of Wed, 23 Jul 1997 09:07:32 -0500, <3D630BE0.3000@usr.com> Subject: Re: Re[8]: ISAKMP performance Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: pcalhoun@usr.com Date: Wed, 23 Jul 1997 09:07:32 -0500 In this application, it is implied that end to end security is used (hopefully using IPSEC). Againk, as I have repeted many times, I am not attempting to encrypt the users' data, merely trying to get around all of the security holes in the L2TP protocol by using IPSEC underneath it. In this case, authentication of each L2TP peer is done using IPSEC. This will ensure that no malicious user inserts data into a tunnel data stream. I haven't had a chance to study the L2TP protocol yet, but from what I've heard on this list, it's really not clear a pure IPSEC solution is the right one. You might be better off using the GSSAPI (with some kind of private-key crypto mechanism) to do the initial authentication connection, and then perhaps using GSSAPI to send over a key which is used at the ESP layer, for example. Again, this gets back to the fact that most WG are simply pointing to the IPSEC group for all of their security needs. I think this is WRONG and more thought need to be put into it before a WG decides to do this, but unfortunately this WG is called IP Security. It gets very difficult to argue NOT using IP Security if a protocol runs over IP (just because of the name implies that it makes ALL IP traffic secure, does not mention scaling problems). Well, it should be obvious that ipsec is but one working group among many in the IETF Security Area, and we didn't shut them all down just because we were working on IPSEC. There are different places where different security approaches need to be used. I know you've asked us to "speak out", but many people have in the Security Area have do so in the past, and people haven't listened. (They generally prefer to believe what will result in the least amount of work for themselves :-). This perhaps wouldn't be as much of an issue if working groups were actually putting implementations together coincident with generating the spec, since presumably then people would notice the disconnects earlier. But I don't know that this is necessarily a IPSEC working group issue. I can certainly talk to my peers in the Security Area, and the Security Area Director can talk to the other A-D's, but I'm afraid we've done this before; heck, just a few months ago the IAB sponsored a workshop on Security. The question is how do we get all of the people in the various working groups to listen.... - Ted From owner-ipsec Wed Jul 23 23:23:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA18701 for ipsec-outgoing; Wed, 23 Jul 1997 23:22:16 -0400 (EDT) Date: Wed, 23 Jul 1997 23:29:57 -0400 Message-Id: <199707240329.XAA18613@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Norman Shulman Cc: "Theodore Y. Ts'o" , "C. Harald Koch" , ipsec@tis.com In-Reply-To: Norman Shulman's message of Wed, 23 Jul 1997 23:11:09 -0400, <97Jul23.230615edt.11656@janus.tor.securecomputing.com> Subject: Re: Derived versus Explicit IV Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 23 Jul 1997 23:11:09 -0400 From: Norman Shulman Authentication can be provided by a separate AH header. For interoperability, it doesn't matter how the 32-bit IV is generated. RFC-1829 implementations won't be compliant, but at least they will be compatible. That's simply not true. RFC-1829 implementations are allowed to pick random IV's --- it doesn't specify how the IV's are picked at all. If they do so, they won't be complaint with the latest ESP, because that field is where the sequence number goes, which must be a sequentially incrementing field starting at zero. Therefore, RFC-1829 implementations can not be counted upon to be compatible with the new ESP, no matter whether you use an explicit or derived IV. > Finally, if you need to support both the old manual keying way of doing > things and the new key-management way of doing things, the extra code to > support a new cipher algorithm is minimal; the size of your DES, MD5, > SHA, et. al. implementation will completely dwarf the extra code you > need to support the new way of handling the sequence number and IV > (which is after all, simply byte juggling). Why add unnecessary complexity? We made changes to the ESP protocol --- by adding a sequence number field, and adding an authenticator --- to improve ESP's security. The old ESP was flawed; we fixed it. Sometimes such fixes imply incompatible changes. Life's rough sometimes. - Ted From owner-ipsec Wed Jul 23 23:30:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA18718 for ipsec-outgoing; Wed, 23 Jul 1997 23:30:15 -0400 (EDT) Message-Id: <199707240336.XAA11111@coredump.cis.upenn.edu> To: "Theodore Y. Ts'o" cc: Norman Shulman , "C. Harald Koch" , ipsec@tis.com Subject: Re: Derived versus Explicit IV In-reply-to: Your message of "Wed, 23 Jul 1997 23:29:57 EDT." <199707240329.XAA18613@dcl.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29439.869715412.1@dsl.cis.upenn.edu> Date: Wed, 23 Jul 1997 23:36:52 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199707240329.XAA18613@dcl.MIT.EDU>, "Theodore Y. Ts'o" writes: > >That's simply not true. RFC-1829 implementations are allowed to pick >random IV's --- it doesn't specify how the IV's are picked at all. If >they do so, they won't be complaint with the latest ESP, because that >field is where the sequence number goes, which must be a sequentially >incrementing field starting at zero. > >Therefore, RFC-1829 implementations can not be counted upon to be >compatible with the new ESP, no matter whether you use an explicit or >derived IV. It can be simulated however by having the key management daemon tell the kernel not to check the replay counter, *and* to use the replay counter as a half-IV. This is useful if you want your code to be able to talk to the old implementations but don't like duplicated code. How key mgmt specifies that is, of course, implementation and protocol dependent. -Angelos From owner-ipsec Thu Jul 24 07:46:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21449 for ipsec-outgoing; Thu, 24 Jul 1997 07:45:44 -0400 (EDT) Date: Thu, 24 Jul 1997 07:45:44 -0400 (EDT) From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: "Theodore Y. Ts'o" cc: "C. Harald Koch" , ipsec@tis.com Subject: Re: Derived versus Explicit IV In-Reply-To: <199707232122.RAA18514@dcl.MIT.EDU> Message-Id: <97Jul23.230615edt.11656@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, 23 Jul 1997, Theodore Y. Ts'o wrote: > References: <6314.wsimpson@greendragon.com> > From: "C. Harald Koch" > > The draft ESP spec, combined with the ciph-des-derived spec, is compatible > with the 32-bit-IV option in RFC 1827+1829, which in turn is the most > commonly implemented transform. > > This is not strictly true. It's true *only* if the authenticator is not > present (which opens you to the active attacks pointed out by Steve > Bellovin), and if you assume the RFC-1829 implementation uses a counter > initialized to zero for the 32-bit IV. Given that support for the > authenticator is required, an old RFC-1829 implementation won't be > compliant anyway. Authentication can be provided by a separate AH header. For interoperability, it doesn't matter how the 32-bit IV is generated. RFC-1829 implementations won't be compliant, but at least they will be compatible. > In my judgement, this limited interoperability isn't particularly > useful, all things considered. If you're going to be implementing > something which is compatible with the old RFC1827-1829, you can simply > use those old RFC's; they're not going away. Don't forget there is an RFC-1829 installed base out there. > If you're going to be supporting the new key management stuff, it's not > that hard to support the new cipher algorithms, and there are very good > security reasons for doing so. > > Finally, if you need to support both the old manual keying way of doing > things and the new key-management way of doing things, the extra code to > support a new cipher algorithm is minimal; the size of your DES, MD5, > SHA, et. al. implementation will completely dwarf the extra code you > need to support the new way of handling the sequence number and IV > (which is after all, simply byte juggling). Why add unnecessary complexity? 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 Thu Jul 24 09:50:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22423 for ipsec-outgoing; Thu, 24 Jul 1997 09:49:24 -0400 (EDT) Date: Thu, 24 Jul 97 13:11:26 GMT From: "William Allen Simpson" Message-ID: <6319.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Derived versus Explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Theodore Y. Ts'o" > .... RFC-1829 implementations are allowed to pick > random IV's --- it doesn't specify how the IV's are picked at all. If > they do so, they won't be complaint with the latest ESP, because that > field is where the sequence number goes, which must be a sequentially > incrementing field starting at zero. > That latter analysis is not correct. For manual keys, the sequence number starts at a random number. There is no anti-replay requirement, but the random start provides a small degree of protection through unpredicatability. For automated keys, the sequence number starts at one (not zero). Historically, RFC-1829 was based on swIPe, which had a sequence number. The extra 64-bit explicit IV was mandated by the current WG chair. It ruined word alignment for IPv6. It was not requested by any person in the WG. The authors were not happy about this, but agreed to add the option to get the publication out the door. You can draw your own conclusions as to the motivation of that WG chair. The stated rationale was that it was needed for backward compatibility with existing hardware manufacturers. A straw poll on the list found no such existing implementations. A survey of actual vendors at SWAN and ANX workshops have found no such vendors. QED. Thus, in the olden days, we "bent over backwards" to assist backwards compatibility. Doing that has lead to persons claiming that because we had an explicit IV as an option, the new drafts need an explicit IV as well. Give them an inch, they take a yard. Yet, the proposed explicit IV is _not_ backward compatible with deployed RFC-1829, as noted by several on this list. So, those advocating an explicit IV are contradicting themselves. Suddenly, we need no backward compatibility. I do not find the argument of those arguing against backward compatibility compelling. > We made changes to the ESP protocol --- by adding a sequence number > field, and adding an authenticator --- to improve ESP's security. The > old ESP was flawed; we fixed it. Sometimes such fixes imply > incompatible changes. Life's rough sometimes. > As noted many times before, all we did was move around existing fields in their documents. The sequence number was there in swIPe, and it was there in RFC-1829 and RFC-1851, and it has been moved (as a common field) back into the main ESP base. There was no "fix". The only change is removing an unneeded explicit IV. Removing unnecessary options is a common practice when proceeding from Proposed to Draft Standard. As noted many times before, we already can provide authentication via AH. The Bellovin splicing attack was duly referenced in RFC-1829, which noted the need for authentication/integrity in _certain_ scenarios. The authenticator does not improve security over AH. The only reason for adding the authenticator field is to save 8 bytes of AH header. Adding an explicit IV wastes those 8 bytes. I conclude that there are no vendors needing this capability for any technical reason. I perceive that those persons asking for this capability are vendors that have no deployed product, and can only conclude that they are trying to use the WG consensus process to "level the playing field" and give their new products an equal opportunity against other vendors. I reject the claims of such vendors. 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 Jul 24 10:24:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22712 for ipsec-outgoing; Thu, 24 Jul 1997 10:21:50 -0400 (EDT) Message-Id: <199707241426.KAA18564@raptor.research.att.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: Derived versus Explicit IV Date: Thu, 24 Jul 1997 10:26:29 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Theodore Y. Ts'o" > .... RFC-1829 implementations are allowed to pick > random IV's --- it doesn't specify how the IV's are picked at all. If > they do so, they won't be complaint with the latest ESP, because tha t > field is where the sequence number goes, which must be a sequentiall y > incrementing field starting at zero. > That latter analysis is not correct. For manual keys, the sequence number starts at a random number. There is no anti-replay requirement, but the random start provides a small degree of protection through unpredicatability. For automated keys, the sequence number starts at one (not zero). Historically, RFC-1829 was based on swIPe, which had a sequence number. 1829 does not have sequence numbers. The text explicitly states that IV selection is implementation-dependent, though use of a counter is described as meeting the requirements. A number of people -- including me -- objected to the swIPe sequence number. At the time, the cryptographic importance was not understood. I had many discussions with Karn and Blaze on the subject; the only rationale offered then was that perhaps higher-level protocols couldn't cope well with packet replay in a hostile world. They felt that the long-standing requirement for such an ability was designed to deal with non-malicious failures, and that an opponent might be able to do evil things by re-injecting packets. They were overruled; most people (again, including me) felt that the older policy was sufficient. (And if we hadn't pulled the sequence number ourselves, we likely would have been attacked by non-security folks in the IETF, for a layering violation. Indeed, I believe I deflected just such an attack last night, from a very well-respected member of the community.) We put sequence numbers back in when cryptographic problems were found. For those who haven't read my paper, an enemy with a login on the same machine can bind to the same port after the target has finished using it, and replay the packets. The decryptor module will happily translate them back to plaintext, thus gutting the privacy protection. The new sequence number, though syntactically the same as the original swIPe version, has a totally different purpose. From owner-ipsec Thu Jul 24 10:34:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22826 for ipsec-outgoing; Thu, 24 Jul 1997 10:34:22 -0400 (EDT) Date: Thu, 24 Jul 97 13:58:57 GMT From: "William Allen Simpson" Message-ID: <6320.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Manual Key support required Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Theodore Y. Ts'o" > In my judgement, this limited interoperability isn't particularly > useful, all things considered. If you're going to be implementing > something which is compatible with the old RFC1827-1829, you can simply > use those old RFC's; they're not going away. > While I am pleased to see this statement (the previous chair proposed moving them to Historic), the tone of your message leads me to think that manual key management is somehow "old". Every implementation is required to support manual key management. Support for an automated key manager is optional. > Finally, if you need to support both the old manual keying way of doing > things and the new key-management way of doing things, the extra code to > support a new cipher algorithm is minimal; the size of your DES, MD5, > SHA, et. al. implementation will completely dwarf the extra code you > need to support the new way of handling the sequence number and IV > (which is after all, simply byte juggling). > A new definition of "minimal". I think you meant "small". The "minimal" effort proposed here is "none". But that argument, taken on its face, means that every possible method of handling every possible option is "small". I think that many vendors find the prospect of many "small" differences to be undesirable. 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 Jul 24 10:34:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22825 for ipsec-outgoing; Thu, 24 Jul 1997 10:34:22 -0400 (EDT) Date: Thu, 24 Jul 97 14:06:32 GMT From: "William Allen Simpson" Message-ID: <6321.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Derived versus Explicit technical rationale Sender: owner-ipsec@ex.tis.com Precedence: bulk The technical rationale seems to be forgotten in the debate. Please remember: there is no technical advantage to Explicit. Explicit is _NOT_ more cryptographically secure than Derived. Also, Explicit wastes bytes. An Explicit IV allow undetectable modification of the first block. A single bit change produces a single bit change in the deciphered plaintext. Any multiple bit changes are independent. It has a cryptographic strength of "2**0" -- no bits of protection. A Derived IV is stronger. Any single bit change produces multiple bits of change to the first plaintext block. Any multiple bit changes are related. The strength will vary depending on the derivation algorithm. Several algorithms have been proposed. See draft-simpson-ipsec- enhancement-01.txt. The method used in RFC-1829 has a strength of at least order "2**7". This is the work factor of finding an IV that affects the underlying text in an undetectable fashion, given the normal TCP, UDP, IP checksum. However, given that the derivation is from a sequence number providing anti-replay protection, this provides _mutual_ protection between the sequence number and the first block (birthday attacks no longer apply), and a strength based on the size of the field: "2**32". It has been argued that adding AH or an Authenticator field brings that Explicit IV the same level of protection. But this protection is in _addition_ to the protection afforded by the underlying construct. Implicit is still cryptographically and practically stronger. Even had analysis shown that Explicit and Implicit were equal, that gives no technical rationale for using an Explicit IV. Given that an Explicit IV has not been proven to be STRONGER, and that it takes 8 extra bytes, I know of no technical argument for having an Explicit IV in _ANY_ of the drafts. I ask for WG support for removing the Explicit IV from drafts for Blowfish, CAST, RC5, et alia. 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 Jul 24 12:42:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23765 for ipsec-outgoing; Thu, 24 Jul 1997 12:39:21 -0400 (EDT) Message-Id: <199707241645.MAA15375@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Re[8]: ISAKMP performance In-reply-to: Your message of "Wed, 23 Jul 1997 09:07:32 CDT." <3D630BE0.3000@usr.com> Date: Thu, 24 Jul 1997 12:45:01 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "pcalhoun" == pcalhoun writes: pcalhoun> In this application, it is implied that end to pcalhoun> end security is used (hopefully using IPSEC). Againk, as pcalhoun> I have repeted many times, I am not attempting to pcalhoun> encrypt the users' data, merely trying to get around all Okay, so don't encrypt the user's data. pcalhoun> of the security holes in the L2TP protocol by using pcalhoun> IPSEC underneath it. In this case, authentication of pcalhoun> each L2TP peer is done using IPSEC. This will ensure pcalhoun> that no malicious user inserts data into a tunnel data pcalhoun> stream. Here you say that you *are* trying to protect the user's data stream. Integrity and origin authentication is a form of protection. Same difference really from the ISAKMP point of view. pcalhoun> There seems to be this misunderstanding that I pcalhoun> am trying to encrypt the users' data, which is obviously pcalhoun> wrong. There is no trust between the NAS and the pcalhoun> firewall! I am simply trying to get around the L2TP pcalhoun> deficiencies. So the firewall does the authentication of the user. Okay. Thus, the NAS and the firewall need only share a *single* SA for all users. pcalhoun> protocol runs over IP (just because of the name implies pcalhoun> that it makes ALL IP traffic secure, does not mention pcalhoun> scaling problems). At least three different suggestions have been made on scaling: 1. move security to the user's end. NAS not involved (this isn't L2TP) 2. cache the NAS<->firewall SAs on the authentication server, or some other place instead of NVRAM. 3. do ISAKMP on another machine (or machines). pcalhoun> As I mentioned earlier, I think that the IPSEC pcalhoun> needs to advertise the target applications which it is pcalhoun> trying to address in order to ensure that we do not have pcalhoun> too many of these WGs blindly point to IPSEC for all pcalhoun> underlying security and key management. In that IPsec is a producer of security services, and L2TP, MobileIP, and ?? are consumers of security services, I agree: producer and consumer must agree on what is being "sold"/"bought". Unfortunately, that involves both parties. That means that the consumers must brief the producers on their requirements, and also means that the producers must understand what the consumers are doing. IETF meetings are ideal for this kind of thing: a similar thing happened last year between mobileip and ipsec. Bill> It's not clear what doing a secure tunnel from the NAS Bill> to the firewall buys me as an end user, as I can't trust Bill> the phone network to be secure. So, forget about ISDN caller id. That's a joke. :!mcr!: | Network security programming, currently Michael Richardson | on contract 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 iQB1AwUBM9eGhaZpLyXYhL+BAQExiQMAtyPMkqgAycMB4QYX5BqTnj9ABFXuzFwW HcDRb2vg6c58ZGeg2pjdfjOQSGo6s2BHiX2UDlVd7cb3c6qG4AZYBYMbn2Ems2WL Qdtzzj1X+5+7xw4mjp2mNSbssYKLeklP =FBI2 -----END PGP SIGNATURE----- From owner-ipsec Thu Jul 24 15:02:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24744 for ipsec-outgoing; Thu, 24 Jul 1997 15:01:23 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" Subject: RE: Derived versus Explicit technical rationale Date: Thu, 24 Jul 1997 15:16:56 -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 >---------- >From: William Allen Simpson[SMTP:wsimpson@greendragon.com] > >I ask for WG support for removing the Explicit IV from drafts for >Blowfish, CAST, RC5, et alia. Excuse Bill, but you are not the only one in this working group. Where do you come accross as having the authority of making a statement like that. Settle down and try to work WITH everyone else in this working group. From owner-ipsec Thu Jul 24 15:03:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24771 for ipsec-outgoing; Thu, 24 Jul 1997 15:03:23 -0400 (EDT) Message-Id: <199707241908.PAA15857@raptor.research.att.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: Derived versus Explicit technical rationale Date: Thu, 24 Jul 1997 15:08:44 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk The technical rationale seems to be forgotten in the debate. Please remember: there is no technical advantage to Explicit. Explicit is _NOT_ more cryptographically secure than Derived. Also, Explicit wastes bytes. An Explicit IV allow undetectable modification of the first block. A single bit change produces a single bit change in the deciphered plaintext. Any multiple bit changes are independent. It has a cryptographic strength of "2**0" -- no bits of protection. A Derived IV is stronger. Any single bit change produces multiple bits of change to the first plaintext block. Any multiple bit changes are related. The strength will vary depending on the derivation algorithm. Several algorithms have been proposed. See draft-simpson-ipsec- enhancement-01.txt. I did. As the text notes, it's a very old RFC that was (for whatever reason) not published promptly. It's now seriously out of date, and should be revised to take into account authenticators and sequence numbers in ESP. Many of the suggested mechanisms, such as using pseudo-random number generators or cryptographic hash functions, seemed to be quite expensive in comparison to the benefits provided. The method used in RFC-1829 has a strength of at least order "2**7". This is the work factor of finding an IV that affects the underlying text in an undetectable fashion, given the normal TCP, UDP, IP checksum. However, given that the derivation is from a sequence number providing anti-replay protection, this provides _mutual_ protection between the sequence number and the first block (birthday attacks no longer apply), and a strength based on the size of the field: "2**32". It has been argued that adding AH or an Authenticator field brings that Explicit IV the same level of protection. But this protection is in _addition_ to the protection afforded by the underlying construct. Implicit is still cryptographically and practically stronger. If playing games with the IV can defeat our cryptographic authentication, we're in very deep yogurt indeed. Implicit may be stronger, but by an infinitesimal amount. Even had analysis shown that Explicit and Implicit were equal, that gives no technical rationale for using an Explicit IV. I'm no longer quite certain how you want to implement your derived IV. As a strawman, I'll assume that it's the sequence number replicated or in some other way expanded to 64 bits. Now consider the design of a hardware assist board for ipsec -- modern hardware, with a 64-bit bus. The board first reads the SPI and sequence number, in one operation. The expanded sequence number now has to go back out to the bus, to be fed into the decrypt engine. At the same time, it has to go to the sequence-checking unit. With an explicit IV, the decryption unit just slurps up 64-bit chunks from the input buffer. The IV is simply set to zero by the context initialization function; there's no need for an explicit output cycle. I *think* this is faster; I'm fairly certain it's simpler. Given that an Explicit IV has not been proven to be STRONGER, and that it takes 8 extra bytes, I know of no technical argument for having an Explicit IV in _ANY_ of the drafts. A few weeks ago, I sent the following note to a few folks; Bill, you were on the 'cc' list: The only choice I'd be unhappy with is one that mandated implicit IVs. That would rule out ciphers that required an explicit IV for some reason. (Bear in mind that "IV" need not be "the stuff you XOR with the first block of plaintext in CBC mode". The LEAF is one example of a more complex IV; we could all concoct other artificial examples quite easily, I'm sure.) I do have a preference for explicit IVs. Ted's note gives some of the size calculations; I've done other, more detailed ones, to the same effect. In other words, I don't care very much about explicit vs. implicit IVs for DES. I don't think it makes any difference at all. It may matter for other ciphers. I ask for WG support for removing the Explicit IV from drafts for Blowfish, CAST, RC5, et alia. Why? The strength difference is irrelevant, we know that some ciphers (such as Skipjack) require explicit IVs, and there may be hardware implementations that really want their own, or are faster with explicit IVs. The size difference, though measurable, is quite small. If people want to change it, at this date, feel free -- *if* we can get the !@#$%^& drafts *done* without further delay. My line in the sand is if someone wants to mandate implicit IVs for all encryption algorithms. From owner-ipsec Thu Jul 24 15:17:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24892 for ipsec-outgoing; Thu, 24 Jul 1997 15:16:56 -0400 (EDT) Message-Id: <199707241911.PAA13610@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: Derived versus Explicit technical rationale In-Reply-To: wsimpson's message of Thu, 24 Jul 1997 14:06:32 +0000. <6321.wsimpson@greendragon.com> Date: Thu, 24 Jul 1997 15:11:27 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Encryption by itself does not provide integrity protection. For instance, any XOR-based stream cipher will allow an attacker to make predictable changes to the plaintext. The difference between derived vs. explicit IV does not affect the ability of the protocol to provide confidentiality. If you require integrity, you need to add a MAC either in ESP or by using AH.. - Bill From owner-ipsec Thu Jul 24 15:32:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24988 for ipsec-outgoing; Thu, 24 Jul 1997 15:31:54 -0400 (EDT) Message-Id: <97Jul24.153423edt.11654@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Re: Derived versus Explicit IV References: <199707241426.KAA18564@raptor.research.att.com> In-reply-to: smb's message of "Thu, 24 Jul 1997 10:26:29 -0400". <199707241426.KAA18564@raptor.research.att.com> From: "C. Harald Koch" Date: Thu, 24 Jul 1997 15:39:20 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk I withdraw any and all compatability objections that I may or may not have made. I think it's free, but apparently concensus is against it. So, you guys go do whatever you want with the drafts; when you're finished, I'll go write code. -- Harald Koch From owner-ipsec Thu Jul 24 15:38:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25063 for ipsec-outgoing; Thu, 24 Jul 1997 15:38:26 -0400 (EDT) Message-Id: <199707241946.MAA06282@pita.cisco.com> To: Steven Bellovin cc: "William Allen Simpson" , ipsec@tis.com Subject: Re: Derived versus Explicit technical rationale In-reply-to: Your message of "Thu, 24 Jul 1997 15:08:44 EDT." <199707241908.PAA15857@raptor.research.att.com> Date: Thu, 24 Jul 1997 12:46:23 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk I disagree with Simpson and believe that there is more support for explicit IV's, for reasons such as Steve Bellovin and Steve Kent have pointed out over the last two years. I see no reason to continue with the implicit IV drafts. Derrell From owner-ipsec Thu Jul 24 16:31:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25959 for ipsec-outgoing; Thu, 24 Jul 1997 16:30:00 -0400 (EDT) Date: Thu, 24 Jul 97 20:06:10 GMT From: "William Allen Simpson" Message-ID: <6323.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Derived versus Explicit technical rationale Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Roy Pereira > >From: William Allen Simpson[SMTP:wsimpson@greendragon.com] > > > >I ask for WG support for removing the Explicit IV from drafts for > >Blowfish, CAST, RC5, et alia. > > Excuse Bill, but you are not the only one in this working group. Where > do you come accross as having the authority of making a statement like > that. Settle down and try to work WITH everyone else in this working > group. > Perhaps you should settle down and re-read your own sentences here. You have a self-contradiction. If I was the "only one" in the working group, then I wouldn't need to ask for WG support, would I? Someone has to have "authority" to ask for WG support? Is this an Autocracy? Gosh, you'd think I put a gun to his head! Folks, the temper of some of the participants is showing again. I'm really tired of it. It would really help if we could have a technical discourse and reach a consensus based on rationale arguments. Maybe that's impossible in this WG. As to working "WITH" some of the others, the agreements we made on dividing the effort seems to have fallen apart, and I have seen opposing drafts appearing this week. I'll note that several folks suggested changes to the AH and ESP drafts, criticizing my cipher drafts for having too much duplicated material. The duplicated material was there because of the lack of material in RFCs 1825-27 and the BBN revisions. Yet, the long awaited BBN drafts do not have any of the requested text, or anything that looks like the requested text. Some others just don't want to work with anyone else. I don't know about you, but I don't need no stinkin' autocratic "authorities".... 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 Jul 24 17:06:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26179 for ipsec-outgoing; Thu, 24 Jul 1997 17:06:01 -0400 (EDT) Message-ID: <01BC983B.72D70D80@Tastid.cisco.com> From: Rob Adams To: "'William Allen Simpson'" , "ipsec@tis.com" Subject: RE: Derived versus Explicit technical rationale Date: Thu, 24 Jul 1997 14:11:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Waste'o'bandwidth. Bill, before you complain about other people's tempers, perhaps you should look at some of your own remarks, such as "oppose till my dying breath." I can imagine statements like these will raise a few tempers. Please take further discussions of this ilk, off the list. We're all aware of how disfunctional this group is. Lementing preceived broken agreements and peoples personalities, including mine, doesn't get us anywhere closer to publishing documents. I include my own past iniquities. -Rob -----Original Message----- From: William Allen Simpson [SMTP:wsimpson@greendragon.com] Sent: Thursday, July 24, 1997 1:06 PM To: ipsec@tis.com Subject: Re: Derived versus Explicit technical rationale > From: Roy Pereira > >From: William Allen Simpson[SMTP:wsimpson@greendragon.com] > > > >I ask for WG support for removing the Explicit IV from drafts for > >Blowfish, CAST, RC5, et alia. > > Excuse Bill, but you are not the only one in this working group. Where > do you come accross as having the authority of making a statement like > that. Settle down and try to work WITH everyone else in this working > group. > Perhaps you should settle down and re-read your own sentences here. You have a self-contradiction. ... From owner-ipsec Thu Jul 24 17:33:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26324 for ipsec-outgoing; Thu, 24 Jul 1997 17:32:30 -0400 (EDT) Date: Thu, 24 Jul 1997 17:40:38 -0400 Message-Id: <199707242140.RAA18896@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: HMAC-MD5 test vectors? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Has anyone else tried implementing HMAC-MD5 and used the test vectors specified in RFC 2104 to verify their implementation? I'm tearing my hair out, because I'm consistently getting 6372bd727c8a3c98f2850e7766e4148a as the MAC for first test vector, but RFC 2104 says that the correct MAC should be: 9294727a3638bb1c13f48ef8158bfc9d I've even tried using the sample implementation found in RFC-2104, and I'm getting the same results. (Note that it's missing a semi-colon or two. :-) I'm using a version of MD5 from PGP (written by Colin Plumb) which has passed the MD5 validation suite, so it doesn't look like an MD5 problem. I'm left with the conclusion that the test vectors might be wrong, although it's hard to believe no one had double checked them before publishing the RFC. It's possible I made a mistake in my test driver code, but I have single-stepped it through a debugger and looks fine. Also, the second and third vectors work just fine, either using my implementation or the sample implementation from RFC-2104; it's only the first test vector where I'm losing. If someone else has an implementation which passes all three test vectors, could they please let me know? Many thanks... - Ted Test #1 digest is 6372bd727c8a3c98f2850e7766e4148a Test #1 failed! Should have been: 9294727a3638bb1c13f48ef8158bfc9d Test #2 digest is 750c783e6ab0b503eaa86e310a5db738 Test #3 digest is 56be34521d144c88dbb8c733f0e8b3f6 HMAC-MD5 time trial. MAC'ing 100000 1024-byte blocks ... Time = 11 seconds Speed = 9309090 bytes/second From owner-ipsec Thu Jul 24 18:00:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26448 for ipsec-outgoing; Thu, 24 Jul 1997 18:00:30 -0400 (EDT) Message-Id: <199707242207.SAA04005@habanero.bbn.com> To: "Theodore Y. Ts'o" cc: ipsec@tis.com Subject: Re: HMAC-MD5 test vectors? In-reply-to: Your message of "Thu, 24 Jul 1997 17:40:38 EDT." <199707242140.RAA18896@dcl.MIT.EDU> Date: Thu, 24 Jul 1997 18:07:03 -0400 From: Nina Yuan Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, > Has anyone else tried implementing HMAC-MD5 and used the test vectors > specified in RFC 2104 to verify their implementation? > > I'm tearing my hair out, because I'm consistently getting > > 6372bd727c8a3c98f2850e7766e4148a > > as the MAC for first test vector, but RFC 2104 says that the correct MAC > should be: > > 9294727a3638bb1c13f48ef8158bfc9d I just checked and I do get the correct MAC (as specified in the RFC) for tests #1 and #2. I'm using the reference implementation from the RFC atop the NSA Cryptoki 1.0 implementation, which in turn uses RSAREF to do MD5. Interesting that you're getting the correct MACs for tests 2 and 3 though! Silly question, but are you sure you're giving it the right key and key length? -Nina ------------------------------------------------------------------------------- Nina H. Yuan 70 Fawcett Street; Cambridge, MA 02138 Network Security Department (617) 873-1878; FAX (617) 873-4086 BBN Technologies, GTE Corp. nyuan@bbn.com ------------------------------------------------------------------------------- From owner-ipsec Thu Jul 24 18:36:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26717 for ipsec-outgoing; Thu, 24 Jul 1997 18:36:02 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199707222229.SAA17948@dcl.MIT.EDU> References: Marc Hasson's message of Tue, 22 Jul 1997 14:52:53 -0700, <199707222152.OAA03654@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Jul 1997 18:43:51 -0400 To: "Theodore Y. Ts'o" From: Stephen Kent Subject: Re: New draft -- IPSEC ESP Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, The reference to the implicit IV DES CBC mode as THE required encryption algoroithm is merely a carry forward from previous drafts, updated to refer to Bill's current I-D. Nobody objected to this reference in previous drafts (March 27 and May 30), but it certainly can be changed. I hate to jump into this argument but ... If authentication is employed with this encryption mode, as is the required default for ESP, then I personally prefer an explicit (pseudo) random IV, of 64 bits. As Steve Bellovin has pointed out, such authentication is adequate protection against the ability to modify the first block of the plaintext, and the entropy provide by the 64 bit explicit IV (which may have some implications for confidentiality) is consistent with DES FIPS guidelines. I believe FIPS 81 actually calls for integrity protecting a 64-bit (pseudo) random IV (through the use of ECB mode encryption) for CBC mode, but that is obviated by our use of a strong authentication mechanism of the sort we require (as a default). Also note that use of a smaller effectuve IV motivates rekeying an SA sooner than might otherwise be needed (compared to a 64-bit IV in which all bits were independent). So, from a pure confidentiality perspective, I think one might argue that an explicit, 64 bit, (pseudo) random IV is preferable. We address authentication/integrity concerns separately with the MAC, or with use of AH, so I would not bring such concerns into this discussion. I view implicit IV approaches as motivated primarily by a desire to save space in the header, and I don't challenge that motivation. The WG must decide on a default, MUST implement encryption algorithm and mode and that decision will weight space efficiency, confidentiality effectiveness, rekey frequency, and existing implementations in some fashion. This is a fairly complex set of factors to consider, so I don't assume it will be an easily objectifiable (did I really type that word?) decision. Steve From owner-ipsec Thu Jul 24 18:39:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26744 for ipsec-outgoing; Thu, 24 Jul 1997 18:39:03 -0400 (EDT) Date: Thu, 24 Jul 1997 18:47:19 -0400 Message-Id: <199707242247.SAA18939@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Theodore Y. Ts'o" Cc: ipsec@tis.com In-Reply-To: Theodore Y. Ts'o's message of Thu, 24 Jul 1997 17:40:38 -0400, <199707242140.RAA18896@dcl.MIT.EDU> Subject: Re: HMAC-MD5 test vectors? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks to all of you who answered. As some of you may have guessed, it was something really stupid. I had entered the data for the test case as "Hi there", instead of "Hi There" --- and guess what? It makes a difference. :-) (Time to feel really stupid now; I was staring at this for a long time late last night, and I kept on missing it.....) - Ted From owner-ipsec Thu Jul 24 21:54:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA27719 for ipsec-outgoing; Thu, 24 Jul 1997 21:52:59 -0400 (EDT) Date: Thu, 24 Jul 1997 22:01:22 -0400 Message-Id: <199707250201.WAA18991@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "William Allen Simpson" Cc: ipsec@tis.com In-Reply-To: William Allen Simpson's message of Thu, 24 Jul 97 13:11:26 GMT, <6319.wsimpson@greendragon.com> Subject: Re: Derived versus Explicit IV Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 24 Jul 97 13:11:26 GMT From: "William Allen Simpson" The extra 64-bit explicit IV was mandated by the current WG chair. It ruined word alignment for IPv6. For the record, there is no problem with IPv6 alignment with the current version of ESP with the 64-bit explicit IV. Check the the current I-D's for yourself and see. - Ted From owner-ipsec Fri Jul 25 00:12:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA28340 for ipsec-outgoing; Fri, 25 Jul 1997 00:11:34 -0400 (EDT) Date: Fri, 25 Jul 97 02:34:37 GMT From: "William Allen Simpson" Message-ID: <6325.wsimpson@greendragon.com> To: ipsec@tis.com Subject: replay and insecure security implementations Sender: owner-ipsec@ex.tis.com Precedence: bulk And now, the other part of the message, slightly reordered: > From: Steven Bellovin > We put sequence numbers back in when cryptographic problems were found. >... > The new > sequence number, though syntactically the same as the original swIPe > version, has a totally different purpose. > As much as it pains me, I have to disagree. Here is the text from the swIPe internet-draft in 1993: Packet sequence number (32 bits) This field protects against replay attacks and may also be used for synchronization by a stream cipher. It is unique within the context of an endpoint pair (common source/destination address and Policy identifier). It is incremented by one with every packet sent, and initialized whenever the hosts re-negotiate keys and/or policies. The hosts MUST renegotiate crypto variables before the packet sequence number wraps around. A host MUST NOT accept duplicate packets; this may be achieved by only accepting packets which increment the sequence number, or maintaining a small window of acceptable packet numbers. > For those who haven't read my paper, an enemy with a login on the same > machine can bind to the same port after the target has finished using > it, and replay the packets. The decryptor module will happily translate > them back to plaintext, thus gutting the privacy protection. Now, this would be quite a problem, if it represented a real attack. But, in my opinion, this attack is unrealistic in any properly designed and implemented operating system with security. Any implementor that claimed to have a secure system, and had implemented IP Security Protocols, should have protected against this attack. Indeed, there has been plenty of warning in the literature. But should warnings in the literature not be enough, there was also plenty of guidance in the WG drafts and RFCs. Here's what Metzger wrote in early 1995 (RFCs 1829 and 1851, with Karn and me): The cut and paste attack described by [Bell95] exploits the nature of all Cipher Block Chaining algorithms. When a block is damaged in transmission, on decryption both it and the following block will be garbled by the decryption process, but all subsequent 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) transport checksum can detect this attack, but on its own is not considered cryptographically strong. In this situation, user or connection oriented integrity checking is needed. And here's what Karn wrote in 1994 and 1995 (for Photuris, with me): Many security breaches in cryptographic systems have been facilitated by designs that generate traffic-encrypting keys (or their equivalents) well before they are needed, and then keep them around longer than necessary. This creates many opportunities for compromise, especially by insiders. A carefully designed public-key system can avoid this problem. ... Internet Security protects against threats that come from the external network, not from mutually hostile users of the nodes themselves. Any secure multi-user operating system MUST be able to protect its resources from hostile users, and protect one hostile user from damaging the resources controlled by another hostile user. Each secure multi-user operating system MUST be capable of separately maintaining multiple Identification Exchange SPI values for each Value Exchange calculated shared-secret. ... Successful use of user-oriented keying requires a significant level of operating system support. If the operating system has a security vulnerability, then there is no basis for separate user- oriented keying. Use of multi-user segregated exchanges likely requires added functionality in the transport API of the implementation operating system. Such a mechanism is outside the scope of this document. 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 Jul 25 00:12:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA28341 for ipsec-outgoing; Fri, 25 Jul 1997 00:11:34 -0400 (EDT) Date: Fri, 25 Jul 97 02:33:46 GMT From: "William Allen Simpson" Message-ID: <6324.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Derived versus Explicit technical rationale Sender: owner-ipsec@ex.tis.com Precedence: bulk I was pretty enervated at Roy's message, so I after writing this, I left it to percolate for review some hours later, to avoid a caustic tone. This is as neutral as I am ever likely to become: > From: Steven Bellovin > Historically, RFC-1829 was based on swIPe, which had a sequence number. > > 1829 does not have sequence numbers. The text explicitly states that > IV selection is implementation-dependent, though use of a counter is > described as meeting the requirements. > As I wrote this document, I would hope that I have some knowledge about what it actually does and does not have in it. Drafts leading to RFC-1829 started with a field in that position called "Sequence". There were some doubts expressed that it was unnecessary. There was also some desire expressed for no IV field at all. And there were the IPv6 folks that wanted a 96-bit field to align their payloads. All of these were present in the draft at one time. This is the process called "compromise" and "consensus building". I once thought that I was pretty good at those processes. Obviously, in retrospect, compromise was a mistake, but one of the co-authors thought that it would be best at the time, and convinced the others. Perhaps you can understand why I am more resistant to compromise on the second go around.... Then, once the WG had explored all the options, the discussion baked out the explicit IVs, leaving only the 32-bit sequence number, and with the understanding given Karn that 0 could be a negotiable option for Photuris. We were ordered to put the 64-bit explicit IV back in. This was done. But the language for sequence numbers still remains, and is in fact what most folks have implemented. I was very careful to use words such as "acceptable", "sufficiently robust", "most common", to hint that this was the best way to implement. I took a lot of heat for that at the time. > A number of people -- including me -- objected to the swIPe sequence > number. At the time, the cryptographic importance was not understood. Yes, I remember that. I remember even farther back when swIPe had no sequence number field, as the IP Identification field was used for the same facility. In those early days, the argument was whether 16-bits was enough to detect replay, and whether the IP field was consistently implemented. Field testing showed that it was not. But, sequence numbers of one form or another, both to protect against replay and to use as an IV for DES, were always present from the very first Karn diagrams that I saw in '92. And as noted, I have a very old draft that has been delayed politically for a couple of years describing enhancements for AH and ESP with replay protection. That old draft was extracted from an even older draft. I've been advocating replay detection for at least 4 years. (Sound of hand patting back.) Glad other folks are catching up. > Implicit may be stronger, but by an infinitesimal amount. >... > The size difference, though measurable, is quite small. >... > I do have a preference for explicit IVs. > OK, here we have a non-technical qualitative judgement. I have given very explicit technical numbers. One of us judges them significant, the other "infinitesimal" and "small". Now, what I do not understand, given that _any_ measurable quantitative difference exists, why someone would _not_ prefer the strongest and smallest? > The only choice I'd be unhappy with is one that mandated implicit IVs. > That would rule out ciphers that required an explicit IV for some reason. > > In other words, I don't care very much about explicit vs. implicit IVs > for DES. I don't think it makes any difference at all. It may matter > for other ciphers. >... > If people want to change it, at this date, feel free -- *if* we can get > the !@#$%^& drafts *done* without further delay. My line in the sand > is if someone wants to mandate implicit IVs for all encryption algorithms. > We agree. I have long advocated having the IV description in each cipher document, rather than one global requirement. I have no desire to mandate one way for _all_ ciphers. I do wish that those ciphers that can be done with in smallest and strongest fashion use that method. That includes all of the block cipher drafts posted to date. I once was willing to compromise that some would have explicit and others would have derived, and the choice would be made by the designer. However, the "other side" has abandoned the compromise. Should I alone continue to honor the agreement? 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 Jul 25 08:03:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00953 for ipsec-outgoing; Fri, 25 Jul 1997 08:02:01 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6325.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Jul 1997 08:09:09 -0400 To: ipsec@tis.com From: Stephen Kent Subject: Sequence numbers and IVs Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, One more thought on the issue of using the ESP sequence number field as an IV. I note that Bill's I-D calls for the sequence number field to be initialized differently depending on whether key management is manual or automated. In the former case the initial value is random, while in the latter case it is zero. Although not explicitly stated, I assume the difference is motivated by a desire to not trivially reuse the same IV space with the same key, even though such reuse may well occur anyway if the manual key is not changed frequently or if the traffic volume is siginficant. This difference also requires the sequence number wrap around logic to differ for each case (although one could maintain a zero-initialized, shadow counter in the random IV case to avoid the need to do modular arithmetic comparisons to detect overflow). Still, this is an example of increased system design complexity that results from reusing the sequence number field for an IV. I'm not saying that this ought to be considered a show stopper per se, but many have argued on this list for avoiding just this sort of added complexity, e.g., in deciding not to support an authentication-only mode for ESP. Steve From owner-ipsec Fri Jul 25 09:58:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01524 for ipsec-outgoing; Fri, 25 Jul 1997 09:57:09 -0400 (EDT) Message-ID: <33D8B205.4A6A@pa.net> Date: Fri, 25 Jul 1997 10:02:45 -0400 From: Bill Negley Reply-To: billn@pa.net X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: Lotus Notes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi guys, Does anyone have experience with tunneling notes clients through the internet and through a firewall proxy. We're having problems finding the *right* solution. Thanks in advance for any help. I'd be willing to share what we've already found but only in a direct email type fashion. Bill From owner-ipsec Fri Jul 25 10:19:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01698 for ipsec-outgoing; Fri, 25 Jul 1997 10:18:15 -0400 (EDT) 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-photuris-15.txt Date: Fri, 25 Jul 1997 09:44:55 -0400 Message-ID: <9707250944.aa08815@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 : Photuris: Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-simpson-photuris-15.txt Pages : 74 Date : 07/24/1997 Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms. 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-photuris-15.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-15.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-photuris-15.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: <19970724113803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-photuris-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-photuris-15.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970724113803.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jul 25 10:20:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01725 for ipsec-outgoing; Fri, 25 Jul 1997 10:19:11 -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-photuris-schemes-03.txt Date: Fri, 25 Jul 1997 09:44:48 -0400 Message-ID: <9707250944.aa08797@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 : Photuris: Extended Schemes and Attributes Author(s) : P. Karn, W. Simpson Filename : draft-simpson-photuris-schemes-03.txt Pages : 15 Date : 07/24/1997 Photuris is a session-key management protocol. Extensible Exchange-Schemes are provided to enable future implementation changes without affecting the basic protocol. Additional authentication attributes are included for use with the IP Authentication Header (AH). Additional confidentiality attributes are included for use with the IP Encapsulating Security Protocol (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-photuris-schemes-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-schemes-03.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-photuris-schemes-03.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: <19970724113158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-photuris-schemes-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-photuris-schemes-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970724113158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jul 25 10:20:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01726 for ipsec-outgoing; Fri, 25 Jul 1997 10:19:11 -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-ipsec-cbcs-00.txt Date: Fri, 25 Jul 1997 09:43:02 -0400 Message-ID: <9707250943.aa08626@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 : ESP with Cipher Block CheckSums (CBCS) Author(s) : W. Simpson Filename : draft-simpson-ipsec-cbcs-00.txt Pages : 9 Date : 07/24/1997 This document describes the Cipher Block Chaining mode with additional single or double parallel CheckSums for integrity, used with a number of Internet Encapsulating Security Payload (ESP) transforms. This version is described in terms of 64-bit block ciphers, but can be expanded to other block sizes. 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-ipsec-cbcs-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-ipsec-cbcs-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-ipsec-cbcs-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: <19970724173911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-ipsec-cbcs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipsec-cbcs-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970724173911.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jul 25 13:41:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03078 for ipsec-outgoing; Fri, 25 Jul 1997 13:36:42 -0400 (EDT) Message-Id: <199707251741.NAA02556@raptor.research.att.com> To: "William Allen Simpson" cc: ipsec@tis.com Subject: Re: replay and insecure security implementations Date: Fri, 25 Jul 1997 13:41:47 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk And now, the other part of the message, slightly reordered: > From: Steven Bellovin > We put sequence numbers back in when cryptographic problems were fou nd. >... > The new > sequence number, though syntactically the same as the original swIPe > version, has a totally different purpose. > As much as it pains me, I have to disagree. Here is the text from the swIPe internet-draft in 1993: Packet sequence number (32 bits) This field protects against replay attacks and may also be us ed for synchronization by a stream cipher. It is unique within the context of an endpoint pair (common source/destination address and Policy identifier). It is incremented by one wit h every packet sent, and initialized whenever the hosts re-negotiate keys and/or policies. The hosts MUST renegotiate crypto variables before the packet sequence number wraps around. A host MUST NOT accept duplicat e packets; this may be achieved by only accepting packets which increment the sequence number, or maintaining a small window of acceptable packet numbers. This doesn't at all contradict what I said. If you're doing any sort of replay prevention in a security context, it's to deter replay attacks. Naturally, you need to deal with wrap-arounds -- replays are replays. The question is what sort of attacks, and to what end. My statement was based on discussions with Blaze and Karn. No one mentioned the sorts of attacks I discussed in my papers. > For those who haven't read my paper, an enemy with a login on the sa me > machine can bind to the same port after the target has finished usin g > it, and replay the packets. The decryptor module will happily trans late > them back to plaintext, thus gutting the privacy protection. Now, this would be quite a problem, if it represented a real attack. But, in my opinion, this attack is unrealistic in any properly designed and implemented operating system with security. Any implementor that claimed to have a secure system, and had implemented IP Security Protocols, should have protected against this attack. Indeed, there has been plenty of warning in the literature. But should warnings in the literature not be enough, there was also plenty of guidance in the WG drafts and RFCs. Here's what Metzger wrote in early 1995 (RFCs 1829 and 1851, with Karn and me): The cut and paste attack described by [Bell95] exploits the nature of all Cipher Block Chaining algorithms. When a block is damaged in transmission, on decryption both it and the following block will be garbled by the decryption process, but all subsequent blocks will b e 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) transport checksum can detect this attack, but on its own is not considered cryptographically strong. In this situation, user or connection oriented integrity checking is needed. User- or connection-oriented keying are excellent defenses against this attack. They're not always practical, especially if outboard (router-based or bump-in-the-cord) encryption is used. And here's what Karn wrote in 1994 and 1995 (for Photuris, with me): Many security breaches in cryptographic systems have been facilitat ed by designs that generate traffic-encrypting keys (or their equivalents) well before they are needed, and then keep them around longer than necessary. This creates many opportunities for compromise, especially by insiders. A carefully designed public-ke y system can avoid this problem. ... Internet Security protects against threats that come from the external network, not from mutually hostile users of the nodes themselves. Any secure multi-user operating system MUST be able to protect its resources from hostile users, and protect one hostile user from damaging the resources controlled by another hostile user . Each secure multi-user operating system MUST be capable of separate ly maintaining multiple Identification Exchange SPI values for each Value Exchange calculated shared-secret. ... Successful use of user-oriented keying requires a significant level of operating system support. If the operating system has a security vulnerability, then there is no basis for separate user - oriented keying. Use of multi-user segregated exchanges likely requires added functionality in the transport API of the implementation operati ng system. Such a mechanism is outside the scope of this document. Yes. So what? Segregating keys -- and my Danvers presentation was intended to justify precisely that policy -- is a defense. Sequence numbers are another defense that in some contexts work better. From owner-ipsec Fri Jul 25 14:47:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03540 for ipsec-outgoing; Fri, 25 Jul 1997 14:47:14 -0400 (EDT) Date: Fri, 25 Jul 97 18:16:00 GMT From: "William Allen Simpson" Message-ID: <6338.wsimpson@greendragon.com> To: Steven Bellovin cc: ipsec@tis.com Subject: Re: replay and insecure security implementations Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Steven Bellovin > > The new > > sequence number, though syntactically the same as the original swIPe > > version, has a totally different purpose. > > > As much as it pains me, I have to disagree. Here is the text from > the swIPe internet-draft in 1993: > > This doesn't at all contradict what I said. If you're doing any sort > of replay prevention in a security context, it's to deter replay attacks. > Yes, then we agree -- swIPe had a sequence number and its purpose was replay prevention. I thought that you were saying that it did not. The purpose of the ESP Sequence Number is also for replay prevention. I don't see how that is in any way different from swIPe? > The question is what sort of attacks, and to what end. My statement > was based on discussions with Blaze and Karn. No one mentioned > the sorts of attacks I discussed in my papers. > Pardon? Why would we be concerned with "sorts of attacks"? If someone developed a cipher, and made it resistant to differential cryptanalysis, and 20 years later someone came out with linear cryptanalysis, but the old cipher is also very resistant to linear using the exact same mechanisms, would the original designer think the original mechanisms were a failure? Or that the cipher suddenly had a whole different purpose? The purpose of the sequence number is to prevent replay, whether that replay is from an outsider with no legitimate access to the keys, or an insider with illegitimate access to the keys. Maybe the reason nobody mentioned the sorts of attacks that you mentioned in your paper is because they had already decided that any "good" security implementation would not be subject to that attack? We had already written that the keys must be segregated and that sequence numbers be generated. There was a loud complaint against segregating keys from certain vendors, and vigorous argument about needing sequence numbers from others. But, that didn't make us any less correct in the long run.... Do all possible attacks need to be known before any design can begin? There is a certain IRTF group that took that approach, but IMnsHO that isn't good engineering practice. > User- or connection-oriented keying are excellent defenses against this > attack. They're not always practical, especially if outboard (router-based > or bump-in-the-cord) encryption is used. >... > Yes. So what? Segregating keys -- and my Danvers presentation was > intended to justify precisely that policy -- is a defense. Sequence > numbers are another defense that in some contexts work better. At this point, I'd say we should take this off-list, as I cannot figure out why we are disagreeing or even whether we _are_ disagreeing. Also, I see no relevance of these semantic discussions to the protocol specifications or 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 Jul 25 15:13:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03747 for ipsec-outgoing; Fri, 25 Jul 1997 15:13:45 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" 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-isakmp-oakley-04.txt (re-sent) Date: Fri, 25 Jul 1997 14:51:06 -0400 Message-ID: <9707251451.aa02642@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised 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. Note: This revision reflects comments received during the last call period. Title : The resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-04.txt Pages : 30 Date : 07/16/1997 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). [Kra96] (SKEME) describes a versatile key exchange technique which provides anonymity, repudiability, and quick key refreshment. This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. 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-isakmp-oakley-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-04.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-isakmp-oakley-04.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: <19970725144951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970725144951.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jul 25 15:39:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03854 for ipsec-outgoing; Fri, 25 Jul 1997 15:39:16 -0400 (EDT) From: pau@watson.ibm.com Date: Fri, 25 Jul 1997 15:55:08 -0400 Message-Id: <9707251955.AA24064@secpwr.watson.ibm.com> To: dharkins@cisco.com Subject: ISAKMP-OAKLEY v4 draft Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: 05FqFnAubiiqLx7LT9PoeQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, on page 13, : KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] SPI | Ni | Nr) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] SPI | Ni | Nr) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] SPI | Ni | Nr) etc. Should "protocol" be included in deriving K1, K2, ..., i.e.; KEYMAT = K1 | K2 | K3 | ... where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni | Nr) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni | Nr) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni | Nr) etc. Pau-Chen From owner-ipsec Sat Jul 26 23:12:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA11874 for ipsec-outgoing; Sat, 26 Jul 1997 23:05:57 -0400 (EDT) Date: Sat, 26 Jul 97 23:16:05 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9707270316.AA02728@dolphin.ncsc.mil> To: ipsec@tis.com Subject: ISAKMP - New Version (v8) Content-Type: X-sun-attachment Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 33 All, A new version of the ISAKMP Internet Draft has been sent to press. It should be available in the near future. In the meantime, the attached document explains the changes made from version 7. Most of these changes were made based on comments from the IPSEC list and those received via personal e-mail. Special thanks to: John Burke, Cylink Dave Mason, Trusted Information Systems Jim Ryder, IBM Tom Markham, Secure Computing Corp. Greg Carter, Entrust Technologies Michael Richardson, Independent Security Consultant Angelos Keromytis, Univ. of Pennsylvania Roy Pereira, TimeStep Baiju Patel, Intel Norman Shulman, Secure Computing Corp. Harald Koch, Secure Computing Corp. Ben Rogers, Ascend Matt Thomas, AltaVista Edward Russell, FTP Software Luis Sanchez, BBN Richard Waterhouse, GTE Dan Harkins, Cisco Ruth Taylor, NSA for their detailed review of version 7 of the protocol specification and the comments they provided. Doug Maughan ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: ISAKMP_v7_changes.txt X-Sun-Content-Lines: 60 ISAKMP - Changes made from 07 to 08 ----------------------------------- Section 2 --------- 2.3 Changes to text about negotiation phases 2.4 Clarification of SPI size - variable instead of fixed 2.4 Clarification of SPI in relation to Proposal and Protocol 2.4 Clarification of processing multiple Proposals - "ownership and control" of SA establishment 2.5 Clarification of cookie for SA Notify and SA Delete - no longer required - Notify and Delete under protection of existing ISAKMP SA 2.5 Clarification of procedure for sending Notify and Delete payloads Section 3 --------- 3 Changed text so that ISAKMP messages MUST be aligned on 4-byte alignment instead of ISAKMP payloads on 4-byte boundaries 3 References to several figures corrected 3.1 Clarification of ISAKMP Header Commit Bit and relationship to the Notify payload 3.6 Clarification of ordering of fields in Transform payload 3.9 Added SPKI Certificate Type for Certificate payload 3.14 Clarification of procedure for sending Notify and Delete payloads 3.14.1 Notify Message Types - changed RESERVED and FUTURE USE numbers to be more "binary friendly" Section 4 --------- 4.1.1 Clarification of SA examples - inclusion of SPI size field in SA establishment examples 4.3 Clarification of exchanges and the provision of anti-clogging Section 5 --------- 5 Minor edits and clarifications to several payload processing sections 5.12/13 Added detailed descriptions for handling Notify and Delete payloads Appendix A ---------- A.2.2 Supported Security Protocols - changed IANA, FUTURE, and PRIVATE USE numbers to be more "binary friendly" From owner-ipsec Mon Jul 28 05:19:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA19220 for ipsec-outgoing; Mon, 28 Jul 1997 05:08:23 -0400 (EDT) From: Kun-Yu Li Message-Id: <199707280918.RAA02978@telstar.netrd.iii.org.tw> To: Subject: beginner's questions Date: Mon, 28 Jul 1997 17:14:35 +0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=BIG5 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I just started reading documents about ipsec these days. Some questions occurred to me today. Pardon me if these questions are somewhat stupid. In rfc 1825-1829, it is said AH is for providing integrity and authentication. ESP is for providing integrity and confidentiality. Furthermore, AH using Keyed MD5 and ESP using DES-CBC transform are the basic algorithms. I just wondering, (1) Keyed MD5 is for "integrity" only, so how does "AH using Keyed MD5" provide "authentication"?? (2) DES-CBC is for "confidentiality" only, so how does "ESP using DES-CBC transform" provide "integrity"?? If there're any mistakes of my understanding, Please correct me. Thank you in advance. lky@telstar.netrd.iii.org.tw 7/28 From owner-ipsec Mon Jul 28 09:12:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA20958 for ipsec-outgoing; Mon, 28 Jul 1997 09:06:52 -0400 (EDT) Message-Id: <199707281316.JAA29407@relay.hq.tis.com> Date: Mon, 28 Jul 97 09:11:49 EDT From: "Steve Klein (254-5623)" To: ipsec@tis.com Subject: Sequence Number field for manually configured SAs Sender: owner-ipsec@ex.tis.com Precedence: bulk I am confused on how the Sequence Number field for ESP should be handled for manually configured SAs, especially with respect to implicit IVs. The latest ESP draft, draft-ietf-ipsec-esp-v2-00.txt (dated 21 July 1997), contains the following two passages: 2.2 Sequence Number . . . 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). 5. Conformance Requirements ...................... 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. Based on these passages, one could assume that for manual SAs you should send the Sequence Number field in the ESP but do not increment any counters (to avoid the rollover of the field). The latest ESP DES-CBC transform draft, draft-ietf-ipsec-ciph-des-derived-00.txt (dated July 1997), contains the following passage: 5.1. ESP Sequence Number The Sequence Number is a 32-bit (4 byte) unsigned counter. This field protects against replay attacks, and may also be used for syn- chronization by stream or block-chaining ciphers. When configured manually, the first value sent SHOULD be a random number. The limited anti-replay security of the sequence of data- grams depends upon the unpredictability of the values. This passage leads me to believe that for manually configured ESP SAs, one should initialize the Sequence Number field to a random number, increment the field for each subsequent packet, and not worry about the rollover of the field. Which interpretation is correct? I assume the same interpretation would also apply to the handling of the Sequence Number field in the manually configured AH SAs. Steve Klein From owner-ipsec Mon Jul 28 11:15:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21882 for ipsec-outgoing; Mon, 28 Jul 1997 11:14:32 -0400 (EDT) Date: Mon, 28 Jul 1997 18:22:09 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199707281522.SAA27062@ee.technion.ac.il> To: ipsec@tis.com Subject: RE: Derived versus Explicit technical rationale Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Somebody asked me, in a private message, to comment on the issue of derived vs explicit IV. I'll share my response with you (all of the arguments below have already been presented in this list in the past - as everything else, I guess) Forwarded Message: I haven't followed closely the group discussion. In general, it is best to have an IV which is unpredictable and, if possible, secret. This can be achieved by computing a secret function (e.g. depending on a shared key) on a sequence number or any other strictly changing field transmitted with the packet. In any case, the method of draft-ietf-ipsec-ciph-des-derived-00.txt: By default, the 64-bit IV is generated from the 32-bit ESP Sequence Number field followed by (concatenated with) the bit-wise complement of the same 32-bit value: SN || -SN does not achieve any of the two desired properties, namely, it is both predictable and exposed. Secrecy of IV can help avoiding collection of plaintext-ciphertext pairs through the first block which may be easier to predict by an attacker than subsequent blocks. (Notice that if the secret IV is derived from a known quantity using the same key used to encrypt the rest of the message then not much is gained as for avoiding plaintext-ciphertext pairs). Unpredictability of IVs was "praised" in the ipasec list several times (I remember messages on this by Prennel, Roe, Rogaway and others). Attached is a recent note of myself to ipsec on this recurrent subject. Date: 7 January 1997, 10:31:29 EST From: HUGO at WATSON To: bhoward at TimeStep.com, chk at border.com, URI at WATSON cc: ipsec at tis.com Subject: pf_key comments (predictable IVs) Sender: owner-ipsec@ex.tis.com Precedence: bulk The traditional motivation for IVs is to cause two encryptions of the same plaintext to result in two different cipheretexts. For such a use just different (even if predicatable) IVs are enough. However, there is more functionality built into IVs. They are intended to randomize plaintext before encryption for a variety of other reasons. Especially, against chosen message attacks. Consider, for example, an attacker that builds a table with encryptions of the all-zero message under the 2^56 DES keys. How does the guy gets an encryption of zero under the victim's key? If the attcker can mount a chosen plaintext attack it could ask for the encryption of the zero message. But if the encryptor chooses an IV before encrypting then the attacker gets DES(K,IV) rather than DES(K,0). On the other hand, if the IV is known to the attacker before hand (e.g., the IV is an incrementing counter or the last block of ciphertext from the *previous* message) then the task for the attacker is easy. He just chooses the message to encrypt to be equal to the next IV. The ciphertext he will see is DES(K, IV XOR IV) = DES(K,0) ! If instead, the IV is chosen *after* the plaintext is fixed (in a way which is unpredictable to the attacker) then the attacker has little to do to get DES(K,0). I hope this helps in clarifying the issue of predictable vs unpredictable IVs. In particular, IVs known *before* choosing/fixing the message to be encrypted or *after*. Another example from Phil Rogaway (draft-rogaway-ipsec-comments-00.txt): "...suppose the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000001 is recognizably distinct from a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000000. Clearly this violates violates the notion of a secure encryption sketched in Section 2." [You can find the full Rogaway's draft in http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/list.html A related one in the same page is: draft-rogaway-cbc-encrypt-00.txt (April 27, 1995)] Hugo From owner-ipsec Mon Jul 28 12:36:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22558 for ipsec-outgoing; Mon, 28 Jul 1997 12:34:25 -0400 (EDT) Date: Mon, 28 Jul 97 15:56:30 GMT From: "William Allen Simpson" Message-ID: <6347.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Sequence Number field for manually configured SAs Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree that the current ESP draft text is confusing. > From: "Steve Klein (254-5623)" > I am confused on how the Sequence Number field for ESP should be handled > for manually configured SAs, especially with respect to implicit IVs. >... > Based on these passages, one could assume that for manual SAs you should > send the Sequence Number field in the ESP but do not increment any > counters (to avoid the rollover of the field). > I did not make the same interpretation. I understood the text to mean the Sequence Number is always present and advanced, but that manually keyed implementations not check the field, and must be aware that it might roll over. The Kent ESP text is manifestly unclear. >(quoted) > compliant implementation SHOULD NOT provide this service in > conjunction with SAs that are manually keyed. > I disagree with the SHOULD NOT. Indeed, a manual implementation SHOULD ignore two consecutive packets with the same sequence -- simple packet duplication replay protection. If the initial manual sequence number is chosen randomly, there is at least a small window where the receiver is protected against replay -- the bandwidth-delay time. The receiver is not protected against an evesdropper recording a long sequence and replay at a much later time, however. > Which interpretation is correct? I assume the same interpretation would > also apply to the handling of the Sequence Number field in the manually > configured AH SAs. > Well, mine of course! If you start at a random number, and increment, and the receiver ignores it entirely, you have the same effect as Kent's ESP text. And you may note: Replay Window Default: 0 (checking off). Range: 32 to 256. So, you can expect all peers to ignore the field, unless and until they have been configured to do so. Interoperability is maintained with all previous 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 Mon Jul 28 12:36:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22568 for ipsec-outgoing; Mon, 28 Jul 1997 12:34:55 -0400 (EDT) Date: Mon, 28 Jul 97 16:09:04 GMT From: "William Allen Simpson" Message-ID: <6348.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Derived versus Explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Thu, 24 Jul 1997 22:01:22 -0400 > From: "Theodore Y. Ts'o" > > Date: Thu, 24 Jul 97 13:11:26 GMT > From: "William Allen Simpson" > > The extra 64-bit explicit IV was mandated by the current WG chair. It > ruined word alignment for IPv6. > > For the record, there is no problem with IPv6 alignment with the current > version of ESP with the 64-bit explicit IV. Check the the current I-D's > for yourself and see. > For the record, I have corresponded with Ted, and he admits that he mis-interpreted my quoted text. His admonishment was out of order. The quote was taken out of context. The quote did not concern the (now) current I-D's, nor the (now) current WG chairs. The quote, in context: Historically, RFC-1829 was based on swIPe, which had a sequence number. The extra 64-bit explicit IV was mandated by the current WG chair. It ruined word alignment for IPv6. It was not requested by any person in the WG. The authors were not happy about this, but agreed to add the option to get the publication out the door. ... You will note that the verb tense everywhere in these paragraphs is "past" -- was, had, ruined, was not, were not, agreed. That section concludes with "Thus, in the olden days, ....". Later sections use present tense. I thought them reasonably well distinguished. I had nice consistent terms, and transitional sentences. In the recent drafts, everyone will note that _BOTH_ derived and explicit IVs align appropriately for IPv6. It is not an issue with the (now) current drafts. My main point still stands, however, that the previous explicit IV is not conformant nor interoperable with the current group of transforms. That an explicit IV was mandated by an earlier WG chair is not a good reason why the (now) current chairs should mandate one. On the contrary, one might expect great hesitation to repeat the same mistake. 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 Jul 28 12:36:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22577 for ipsec-outgoing; Mon, 28 Jul 1997 12:35:25 -0400 (EDT) Message-Id: <3.0.2.32.19970728115408.007d5100@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Mon, 28 Jul 1997 11:54:08 -0400 To: "Steve Klein (254-5623)" From: Rodney Thayer Subject: Re: Sequence Number field for manually configured SAs Cc: ipsec@tis.com In-Reply-To: <199707281316.JAA29407@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In manually configured SA's it is impossible for the receiver to use the sequence number field for packet sequence checking. Therefore, you can get away with putting whatever you want in it at the transmitter. I believe what's going on here is that the main ESP document is saying you can't do sequence number checking, and the derived-IV DES document is saying you should put a random number in the field. At 09:11 AM 7/28/97 EDT, you wrote: >I am confused on how the Sequence Number field for ESP should be handled >for manually configured SAs, especially with respect to implicit IVs. >The latest ESP draft, draft-ietf-ipsec-esp-v2-00.txt (dated 21 July 1997), >contains the following two passages: > > 2.2 Sequence Number > . > . > . > 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). > > > 5. Conformance Requirements > > ...................... 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. > > >Based on these passages, one could assume that for manual SAs you should >send the Sequence Number field in the ESP but do not increment any >counters (to avoid the rollover of the field). > >The latest ESP DES-CBC transform draft, draft-ietf-ipsec-ciph-des-derived-00.txt >(dated July 1997), contains the following passage: > > 5.1. ESP Sequence Number > > The Sequence Number is a 32-bit (4 byte) unsigned counter. This > field protects against replay attacks, and may also be used for syn- > chronization by stream or block-chaining ciphers. > > When configured manually, the first value sent SHOULD be a random > number. The limited anti-replay security of the sequence of data- > grams depends upon the unpredictability of the values. > > >This passage leads me to believe that for manually configured ESP SAs, >one should initialize the Sequence Number field to a random number, >increment the field for each subsequent packet, and not worry about >the rollover of the field. > >Which interpretation is correct? I assume the same interpretation would >also apply to the handling of the Sequence Number field in the manually >configured AH SAs. > >Steve Klein > > From owner-ipsec Mon Jul 28 13:37:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23172 for ipsec-outgoing; Mon, 28 Jul 1997 13:36:29 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707281744.KAA07853@kebe.eng.sun.com> Subject: Re: Sequence Number field for manually configured SAs To: steveklein@vnet.ibm.com (Steve Klein) Date: Mon, 28 Jul 1997 10:44:19 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199707281316.JAA29407@relay.hq.tis.com> from "Steve Klein" at Jul 28, 97 09:11:49 am 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 these passages, one could assume that for manual SAs you should > send the Sequence Number field in the ESP but do not increment any > counters (to avoid the rollover of the field). You could. Note the SHOULD NOT. The reason it says SHOULD NOT is a "cover the *ss" move. It's possible to run out of sequence space before rekeying. In manual keying situations, rekeying is.... hard. OTOH there's nothing stopping you from doing this anyway. > When configured manually, the first value sent SHOULD be a random > number. The limited anti-replay security of the sequence of data- > grams depends upon the unpredictability of the values. Again, it's SHOULD, not MUST. I believe (and Bill, correct me here if I'm wrong) that he thinks it should be set to random initially so that an adversary cannot replay a packet with a subsequent sequence number. But without authentication, is the counter useful? This brings up an interesting point. Without authentication (either encryption-only ESP + AH or an ESP with both authentication and encryption), sequence numbers are less than useless. Bellovin's paper from '96 points this out, and it's why (without thinking to explicitly require AH) ESP with both authentication and encryption came about. And with authentication, does the value of the replay counter matter? Quite honestly, I don't why a random starting point would help when you have some sort of authentication (AH or an ESP with two algorithms) working for you. Sure, the adversary knows what the number is, but w/o the authentication key, he/she cannot inject bogus packets. And if your implementation follows the spec correctly, you only accept the packet's sequence number as taken if it successfully passes authentication and (for ESP) encryption. If an adversary can make it pass those, you've a lot bigger problem than replay attacks. :-( > Which interpretation is correct? Yes! :) > I assume the same interpretation would also apply to the handling of the > Sequence Number field in the manually configured AH SAs. It could, but see my above argument. Why bother? The sequence number is part of the auth calculation. If your adversary can make that pass, he/she has the key, and you're in Big Trouble (TM). -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (415) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Mon Jul 28 14:46:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23649 for ipsec-outgoing; Mon, 28 Jul 1997 14:33:57 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199707280918.RAA02978@telstar.netrd.iii.org.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jul 1997 14:37:59 -0400 To: Kun-Yu Li From: Stephen Kent Subject: Re: beginner's questions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk DES-CBC mode provides confidentiality, but it does not provide integrity per se. Still, it can support an integrity service when used in conjunction with the right integrity algorithm. However, it's better to think of the encryption algorithm as providing just confidentiality. The answer to your second question is a bit more subtle. In a narrow sense, use of a keyed hash function (e.g., HMAC) provides integrity for the data on which the function is computed. Specifically, it provides assurance that the packet has not been modified after the hash was computed and before the hash was verified. However, we need to know who holds the key used to compute the hash, otherwise the integrity guarantee is rather meaningless. So, to the extent that we know who holds that key, we have some level of authentication as well, i.e., we know who sent the packet AND that the packet was not modified after it was sent. Depending on the granularity of the key menagement employed, we may have very fine grained authentication, or rather course authentication. For example, we may know that a specific user on a specific computer sent the packet, or we may know only that some host (among a set) at a site sent the packet. Steve From owner-ipsec Mon Jul 28 14:46:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23643 for ipsec-outgoing; Mon, 28 Jul 1997 14:32:57 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199707281316.JAA29407@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jul 1997 14:25:32 -0400 To: "Steve Klein (254-5623)" From: Stephen Kent Subject: Re: Sequence Number field for manually configured SAs Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, As you noted, the ESP I-D and the Metzger-Simpson I-D (DES-CBC with derived IV) are not consistent, although the ESP and AH I-Ds are internally consistent. When we cited the M-S I-D as the specification for the default encryption algorithm, we did so very quickly, to get the ESP I-D out, and we failed to look closely enough at the old RFC and the new I-D to note this problem. Several messages have recently been exchanged about the pros and cons of using the sequence number as an IV. The ESP text is clear on what to do, and sender and receiver, and the requirements and motivations are explained. All of this is based on the assumption that the sequence number is just a sequence number. However, when one uses the sequence number as the basis for an IV, a new set of possible requirements arise, and that results in the disparity between the ESP I-D and the M-S I-D, and the suggestion to manage the sequence number space differently (for manual vs. automated key management). The WG has yet to resolve this issue. Stay tuned. Steve From owner-ipsec Mon Jul 28 17:00:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24627 for ipsec-outgoing; Mon, 28 Jul 1997 16:54:00 -0400 (EDT) Date: Mon, 28 Jul 1997 17:02:17 -0400 Message-Id: <199707282102.RAA27553@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Munich preparations Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk The Munich IETF meeting is fast approaching, and so I have two things to ask of the working group. 1) Bob and I are preparing the agenda for the Munich IPSEC aggenda. If you have specific presentations that you would like to make at that meeting, please let us know ASAP. (Sara Bitan and Rodney Thayer, we have your previosly submitted requests already.) 2) Document editors, the deadline for getting internet-drafts submitted before the Munich meeting is this Wednesday (July 30 at 1700 EDT). If you have any pending changes, please get them to the IETF Secretariat before then, so that we can all be discussing the most recent versions of your documents. Even if the changes are relatively minor, go ahead and submit a new I-D --- I-D's are cheap! If you can't get the changes done before the deadline, unless the draft is in a really horrible state, it's probably better to publish what you have so far, and send a quick note to the working group listing what changes are pending, but not yet in the I-D. In any case, sending a note to the list describing the changes that have been made since the last draft is greatly appreciated. (Thanks to all of the document editors who have been doing essentially this already!) Many thanks for all of the hard work that you all have put into IPSEC. See you in Munich! - Ted From owner-ipsec Wed Jul 30 07:22:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12471 for ipsec-outgoing; Wed, 30 Jul 1997 07:17:38 -0400 (EDT) From: Ly Loi Date: Tue, 29 Jul 1997 13:56:41 -0700 (PDT) Message-Id: <199707292056.NAA25784@snow.NSD.3Com.COM> To: ipsec@tis.com Subject: payload length change suggestion Sender: owner-ipsec@ex.tis.com Precedence: bulk According to the July AH draft, due to backward compatibility, one must subtract 2 from the actual payload length and put the resulting value in the "payload length" field. I find the resulting value misleading since the field is called "payload length" but we're putting there an inaccurate payload length value. May I suggest that we calculate the correct payload length field (e.g. subtract 3) and turn a bit (or some bits) of the RESERVED field into a VERSION field to indicate which version of AH one is running? The current value in the RESERVED field is 0. 0 could be used to imply that the old AH version was version 0. I realize that with this suggestion, there'll still be a backward compatibility problem. For example, A_oldAH <------- B_newAH pkts given box A running the old AH and box B running the new AH, box A will drop AH pkts coming from box B because the pkts' reserved field is non-zero. However, even with the current draft proposal, there's a backward compatibility problem. If box A receives a pkt from box B, box A will think the authentication data starts at an offset which actually contains the sequence number field. So box A will still end up dropping the pkts. Since neither the current draft proposal nor my proposal offers a perfect backward compatibility solution, we may as well calculate an accurate payload length. Otherwise, may be we should rename the payload length field to another name. - Ly From owner-ipsec Wed Jul 30 08:29:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12901 for ipsec-outgoing; Wed, 30 Jul 1997 08:28:40 -0400 (EDT) Date: Wed, 30 Jul 1997 13:31:39 From: plipp To: ipsec@tis.com, cat-ietf@MIT.EDU, ietf-pkix%tandem.comietf-pgp-mime@imc.org, ietf-smime@imc.org, spki@c2.net, ietf-tls@consensus.com, wg-sec@terena.nl, ICE-TEL public list Subject: CFP: SEC '98 Message-Id: <19970730133249.NTM2901@iaik.tu-graz.ac.at> X-Mailer: NTXMail B.01.50.344 (Intel 32-bit) (Apr 30 1997 15:26:03 0000-000-NUL0000000-00000) Mime-Version: 1.0 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 IAA12898 Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry if you get multiple copies....... ----------------------------------------------------------------------- SEC '98: IFIP TC11 14th International Information Security Conference August 31 - September 4 in Vienna and Budapest, Austria and Hungary Sponsors: IFIP TC11 Austrian Ministry of Science and Research SEC '98 covers a wide range of security related topics. It comprises both emphasis in technical as well as commercial aspects of information security. The conference is held within the framework of the the IFIP World Computer Congress. Important dates - Deadline for submission of papers: January 16, 1998 - Notification on acceptance: March 27, 1998 - Deadline for the final version: May 8, 1998 More Information: http://www.ifip.tu-graz.ac.at/TC11/SEC98/index.html Contact: Prof. Dr. Reinhard Posch IAIK Klosterwiesgasse 32/I A-8010 Graz, AUSTRIA Tel: +43 316 8735510 Fax: +43 316 873520 e-mail: rposch@iaik.tu-graz.ac.at Dr. György Papp Prime Minister's Office Republic of Hungary Kossuth ter 4 Budapest HUNGARY Tel: +36 1 269 4826 Fax: +36 1 269 0314 e-mail: papp@gmc400.x400gw.itb.hu Dr. Peter Lipp, IAIK, University of Technology, Graz Institute for Applied Information Processing and Communications Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513 ________________________________________________________________________ Was nützt die beste Erziehung, die Kinder machen uns ja doch alles nach. From owner-ipsec Wed Jul 30 09:02:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13100 for ipsec-outgoing; Wed, 30 Jul 1997 09:02:39 -0400 (EDT) Message-Id: <199707301312.JAA14084@relay.hq.tis.com> Date: Wed, 30 Jul 97 9:09:47 EDT From: Charles Lynn To: Ly Loi cc: ipsec@tis.com Subject: Re: payload length change suggestion Sender: owner-ipsec@ex.tis.com Precedence: bulk Ly, You may not be familiar with IPv6 (RFC 1883), but ALL extension headers encode the "Hdr Ext Len" field by first subtracting 8 octets from the payload length. While IPv6 then divides by 8 for all extension headers except AH, I do not see any good reason for yet more variations. Charlie From owner-ipsec Wed Jul 30 09:06:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13139 for ipsec-outgoing; Wed, 30 Jul 1997 09:06:08 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" 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-isakmp-08.txt, .ps Date: Tue, 29 Jul 1997 16:24:22 -0400 Message-ID: <9707291624.aa18192@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised 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. Note: This revision reflects comments received during the last call period. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-08.txt, .ps Pages : 83 Date : 07/29/1997 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. 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-isakmp-08.txt". Or "get draft-ietf-ipsec-isakmp-08.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-08.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-isakmp-08.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-08.ps". 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: <19970729162312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729162312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jul 30 09:07:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA13161 for ipsec-outgoing; Wed, 30 Jul 1997 09:07:08 -0400 (EDT) Date: Wed, 30 Jul 1997 09:07:08 -0400 (EDT) Message-Id: <199707301307.JAA13161@portal.ex.tis.com> From: Ly Loi NAA25784 for ipsec@tis.com; Tue, 29 Jul 1997 13:56:41 -0700 (PDT) Date: Tue, 29 Jul 1997 13:56:41 -0700 (PDT) Message-Id: <199707292056.NAA25784@snow.NSD.3Com.COM> To: ipsec@tis.com Subject: payload length change suggestion Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk According to the July AH draft, due to backward compatibility, one must subtract 2 from the actual payload length and put the resulting value in the "payload length" field. I find the resulting value misleading since the field is called "payload length" but we're putting there an inaccurate payload length value. May I suggest that we calculate the correct payload length field (e.g. subtract 3) and turn a bit (or some bits) of the RESERVED field into a VERSION field to indicate which version of AH one is running? The current value in the RESERVED field is 0. 0 could be used to imply that the old AH version was version 0. I realize that with this suggestion, there'll still be a backward compatibility problem. For example, A_oldAH <------- B_newAH pkts given box A running the old AH and box B running the new AH, box A will drop AH pkts coming from box B because the pkts' reserved field is non-zero. However, even with the current draft proposal, there's a backward compatibility problem. If box A receives a pkt from box B, box A will think the authentication data starts at an offset which actually contains the sequence number field. So box A will still end up dropping the pkts. Since neither the current draft proposal nor my proposal offers a perfect backward compatibility solution, we may as well calculate an accurate payload length. Otherwise, may be we should rename the payload length field to another name. - Ly From owner-ipsec Wed Jul 30 10:11:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13609 for ipsec-outgoing; Wed, 30 Jul 1997 10:10:39 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" 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-isakmp-08.txt, .ps Date: Wed, 30 Jul 1997 09:39:38 -0400 Message-ID: <9707300939.aa08347@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised 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. Note: This revision reflects comments received during the last call period. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-08.txt, .ps Pages : 83 Date : 07/29/1997 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. 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-isakmp-08.txt". Or "get draft-ietf-ipsec-isakmp-08.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-08.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-isakmp-08.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-08.ps". 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: <19970730092716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970730092716.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jul 30 13:01:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14645 for ipsec-outgoing; Wed, 30 Jul 1997 12:59:08 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707301707.KAA19831@kebe.eng.sun.com> Subject: Re: payload length change suggestion To: ipsec@tis.com Date: Wed, 30 Jul 1997 10:07:33 -0700 (PDT) Cc: lll@3com.com, clynn@bbn.com In-Reply-To: <199707301312.JAA14084@relay.hq.tis.com> from "Charles Lynn" at Jul 30, 97 09:09:47 am 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 I totally agree with Charlie on this one. The _reason_ AH is the way it is was because of: 1.) It started off like _any other_ IPv6 header. 2.) To make it a bit more IPv4-friendly, the multiple of 8 was trimmed to a multiple of 4. I also see no good reason to change this. Dan From owner-ipsec Wed Jul 30 14:27:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15472 for ipsec-outgoing; Wed, 30 Jul 1997 14:27:12 -0400 (EDT) Message-ID: <01BC9CDC.CD30D900.baiju@mailbox.jf.intel.com> From: "Baiju V. Patel" Reply-To: "baiju@mailbox.jf.intel.com" To: "'internet-drafts@ietf.org'" Cc: "'ipsec'" , "'dhcp'" Subject: Internet draft submission Date: Wed, 30 Jul 1997 11:36:11 -0700 Organization: Intel X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Sender: owner-ipsec@ex.tis.com Precedence: bulk Included is a draft for submission to DHCP working group (please direct any comments to myself or DHCP working group). DHCP working Group Baiju V. Patel INTERNET DRAFT Intel Corporation July 11, 1997 Expires in 6 months Securing DHCP Status of this Memo This document is a submission to the IETF Dynamic Host Configuration Protocol (dhc) Working Group. Comments are solicited and should be addressed to the working group mailing list (dhcp-v4@bucknell.edu) or to the editor. 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 six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``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), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This proposal describes methods of securing DHCP based on IETF DHCP and IPSEC protocols. This protocol achieves security goals for DHCP client and servers without having to define a new security protocol. Instead, it first bootstraps the DHCP client in un-trusted mode using existing DHCP protocol and then proceeds to secure configuration of the client using existing DHCP and IP protocol features. 1. Introduction In this draft, we present a method of securing DHCP protocol Patel [Page 1] INTERNET DRAFT Securing DHCP 07/30/97 and use notation DHCPSEC for the proposed method. The servers and clients that implement the proposed method are denoted by DHCPSEC servers and clients, respactively. The objective behind securing DHCP is to securely configure a DHCP client with an IP address(es) and configuration parameters. The DHCPSEC does not protect against an unauthorized client from arbitrarily selecting an address and using it. Instead, if a client obtains IP address(es) and configuration parameters using DHCPSEC protocol, it is assured that the IP address and configurations obtained using DHCPSEC are the ones provided by an authenticated DHCPSEC server and the integrity of the parameters is not compromised by an adversary in the network. The subsequent renewal of the lease, and acquiring of the additional configuration parameters, as well as release of the lease of an address(es) is authenticated as well. Thus, the protocol protects the client from an adversary who may release the lease of its IP address. The DHCPSEC server also authenticates the DHCPSEC clients. This allows an DHCPSEC server to determine if a client should be allocated an address at all, and to help determine configuration parameters for the client. Moreover, it prevents an adversary from renewing or releasing an address assigned to an authorized client. 2. Securing DHCP Protocol The DHCPSEC is comprised of several phases: 1) start-up phase, 2) trusted configuration phase, 3) trusted renew, and 4) trusted release phase. 2.1. Start-up phase In start-up phase, the DHCPSEC client brings up an un- trusted configuration using the DHCP protocol defined in [1]. The configuration supplied by the DHCP server in this phase is the minimal configuration required to execute subsequent phases of the protocol. The server MUST supply an IP address, and optionally, provide default gateway and DNS server information. If the DHCP server is not on the same subnet as the client, the default gateway information MUST be provided. The lease time (configurable) for the IP address should be relatively small for the efficient use of the addresses. The recommended duration of the lease is hundreds of milliseconds. In many environments, there may be a concern that an adversary may be able to launch a denial of service attack by quickly requesting too many addresses (short lease in this case) and thus denying a legitimate client an IP address. There are several alternatives that may be deployed to protect against some forms of such denial of attacks. For example, if the DHCPSEC server is on the same subnet as the Patel [Page 2] INTERNET DRAFT Securing DHCP 07/30/97 client, it may allocate a non-routable temporary address to a DHCP client. Since the non-routable address space is large, an authorized client is likely to get an address even when this type of attack is in progress (it may result in a fairly large short lived state in the server). Broadband cable network environment may use such configuration by deploying DHCPSEC server at the head-end. In a switch based network, the monitors may be deployed in the hubs to detect both unauthorized use of IP addresses and denial of service attacks. If the attack in progress is detected, the ports may be deactivated. This is by no means a complete list of protection mechanisms against denial of service attack and the implementers must take appropriate actions to protect against such attacks. Note that the proposed method does not attempt to protect against denial of service attack. 2.2. Trusted configuration phase In this phase, the DHCPSEC client proceeds with establishing a secure communication channel (as defined in section 2.4) between itself and a known DHCPSEC server (the address of the server is known after the start-up phase). If the DHCPSEC client fails to establish a secure channel with the DHCPSEC server, the DHCPSEC fails and MUST be terminated with appropriate messages. Naturally, the process may be repeated again as often as desired. Once the trusted channel is established, the DHCPSEC client proceeds to renew the IP address using DHCP renew message. The communication for DHCP renew phase MUST be based on the unicast messages over the secured communication channel between the DHCPSEC client and server. If the renew completes successfully, the IP address allocated to the DHCPSEC client is authenticated. Note: As suggested earlier, if the temporary address is not same as the address assigned in the trusted configuration phase, then the DHCP protocol may have to be modified so that instead of sending a NACK for the renew message, the server can ACK with an alternate address. The other approach is to modify the protocol so that instead of issuing a DHCP renew, the client can do a DHCP discover and, instead of sending a discover message as a broadcast, it is sent as a unicast message over the trusted communication channel. If the new trusted address is not identical to the un-trusted address assigned to a client, the DHCPSEC server SHOULD not automatically reclaim address before the duration of the temporary lease (it could lead to some race conditions). The client may issue an un-trusted release for the temporary address is no longer needed. 2.3. Trusted Renew and Release The DHCPSEC server MUST ignore any renew or release request over clear channel for securely allocated IP address. Lease of a securely allocated IP address may be renewed or Patel [Page 3] INTERNET DRAFT Securing DHCP 07/30/97 released only over a secure channel between the DHCPSEC server and client to whom the address was allocated in the trusted configuration phase of the DHCPSEC protocol. The identity of the client is verified by the secure channel protocol. In summary, the trusted release phase is essentially same as the trusted configuration phase. 2.4. Authenticated Secure Channel The DHCPSEC compliant servers and clients MUST implement the secure channel based on IPSEC AH [2] and ISAKMP/OAKLEY [3,4,5]. IPSEC ESP [6] MAY be used when the situation warrants. DHCPSEC clients and servers must conform to the interoperability requirements of IPSEC protocol suit (including ISAKMP/OAKLEY, IPSEC AH, and IPSEC ESP). In future other secure communication channels may be defined. The IPSEC security association is used by the DHCPSEC protocol during the trusted configuration phase. Therefore, at the end of this phase, the security association SHOULD be discarded by both the DHCPSEC client and servers. In some cases (e.g., when the temporary address is same as the securely assigned address), the same security association MAY be used for further communication between the two systems. 3. Security Considerations The proposed protocol does not address security requirements for tftp function that is part of the bootp protocol. It is assumed that the integrity of the files tftp'd will be verified using means external to this protocol. An example of such means would be to use signed files for software download using tftp so that the client would be able to authenticate and verify integrity of the copied software. The server may enforce licensing requirements on the software by external means such as a license servers. 4. Acknowledgments The author would like to thank Thomas Narten, Ralph Droms, Peter Ford, Eric Dittert, Dave Chouinard, Charlie Perkins, and Throop Wilder, Munil Shah and many others for helping improve this draft. 5. References [1] Droms, R, "Dynamic Host Configuration Protocol", RFC 1531. Bucknell University, 1993. [2] Atkinson, R., "IP Authentication Header", RFC 1826. Patel [Page 4] INTERNET DRAFT Securing DHCP 07/30/97 [3] Maughan, D., Schrtler, M. Schneider, M., and Truner, J., "Internet Security Association and Key Management Protocol (ISAKMP)". [4] Piper, D., The Internet IP Security Domain of Interpretations, Internet Draft. [5] Carel, D., Harkins, D., "The Resolution of ISAKMP with Oakley". [6] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827. 6. Authors' Address Baiju V. Patel Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR, USA 97124 +1(503)264-2422 baiju@mailbox.jf.intel.com Patel [Page 5] From owner-ipsec Wed Jul 30 15:12:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15790 for ipsec-outgoing; Wed, 30 Jul 1997 15:11:09 -0400 (EDT) Date: Wed, 30 Jul 1997 15:19:21 -0400 Message-Id: <199707301919.PAA11981@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: internet-drafts@ietf.org, ipsec@tis.com Subject: [Karen Seo: multiple AH/ESP drafts] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk IETF Secretariat, could you please delete draft-ietf-ipsec-new-auth-00.txt and draft-ietf-ipsec-new-esp-00.txt from the I-D directory, as they have since been obsoleted by draft-ietf-ipsec-auth-header-01.txt and draft-ietf-ipsec-esp-v2-00.txt. We're not sure why they were given new names by the Secretariat, but as long the older I-D's are removed, it really doesn't matter. IPSEC working group, please be sure to pick up the right version of the I-D's. - Ted P.S. Karen, sending out notes like this is not something which is restricted only to WG chars; so yes, you could have done this yourself. But since I had your message in front of me, it was easier simply to forward you note to the right places. ------- Forwarded Message Date: Wed, 30 Jul 97 13:44:00 EDT From: Karen Seo To: tytso@MIT.EDU, rgm3@chrysler.com Cc: skent@BBN.COM, kseo@BBN.COM Subject: multiple AH/ESP drafts Hello Bob, Ted, Sorry to bother you with this, but just in case... When the IETF secreriat installed the latest versions of the AH and ESP drafts, they didn't remove the March drafts. So there are multiple version in the Internet Directory: AH 03/28/1997 draft-ietf-ipsec-new-auth-00.txt 07/22/1997 draft-ietf-ipsec-auth-header-01.txt ESP 03/28/1997 draft-ietf-ipsec-new-esp-00.txt 07/22/1997 draft-ietf-ipsec-esp-v2-00.txt Would you like for me to send a message to the mailing list warning people to pick up the July versions? And/or tell the secretariat that the July drafts superceded the March ones and asking them to remove the March ones? (Or is this something the WG chairs do?) Thanks, Karen ------- End Forwarded Message From owner-ipsec Wed Jul 30 17:14:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16702 for ipsec-outgoing; Wed, 30 Jul 1997 17:10:41 -0400 (EDT) Date: Wed, 30 Jul 1997 13:31:39 From: plipp To: ipsec@tis.com, cat-ietf@MIT.EDU, ietf-pkix%tandem.comietf-pgp-mime@imc.org, ietf-smime@imc.org, spki@c2.net, ietf-tls@consensus.com, wg-sec@terena.nl, ICE-TEL public list Subject: CFP: SEC '98 Message-Id: <19970730133249.NTM2901@iaik.tu-graz.ac.at> X-Mailer: NTXMail B.01.50.344 (Intel 32-bit) (Apr 30 1997 15:26:03 0000-000-NUL0000000-00000) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id IAA15105 X-Mime-Autoconverted: from 8bit to quoted-printable by pad-thai.cam.ov.com id IAB15107 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id RAA16699 Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry if you get multiple copies....... ----------------------------------------------------------------------- SEC '98: IFIP TC11 14th International Information Security Conference August 31 - September 4 in Vienna and Budapest, Austria and Hungary Sponsors: IFIP TC11 Austrian Ministry of Science and Research SEC '98 covers a wide range of security related topics. It comprises both emphasis in technical as well as commercial aspects of information security. The conference is held within the framework of the the IFIP World Computer Congress. Important dates - Deadline for submission of papers: January 16, 1998 - Notification on acceptance: March 27, 1998 - Deadline for the final version: May 8, 1998 More Information: http://www.ifip.tu-graz.ac.at/TC11/SEC98/index.html Contact: Prof. Dr. Reinhard Posch IAIK Klosterwiesgasse 32/I A-8010 Graz, AUSTRIA Tel: +43 316 8735510 Fax: +43 316 873520 e-mail: rposch@iaik.tu-graz.ac.at Dr. György Papp Prime Minister's Office Republic of Hungary Kossuth ter 4 Budapest HUNGARY Tel: +36 1 269 4826 Fax: +36 1 269 0314 e-mail: papp@gmc400.x400gw.itb.hu Dr. Peter Lipp, IAIK, University of Technology, Graz Institute for Applied Information Processing and Communications Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513 ________________________________________________________________________ Was nützt die beste Erziehung, die Kinder machen uns ja doch alles nach. From owner-ipsec Thu Jul 31 09:11:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22086 for ipsec-outgoing; Thu, 31 Jul 1997 09:09:40 -0400 (EDT) Message-Id: <199707311309.JAA22086@portal.ex.tis.com> Date: Wed, 30 Jul 97 17:17:07 EDT From: Karen Seo To: internet-drafts@ietf.org cc: ipsec@tis.com, tytso@MIT.EDU, rgm3@chrysler.com, skent@bbn.com, kseo@bbn.com Subject: Internet Draft -- IPsec Architecture Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Stephen Kent, BBN Corp Internet Draft Randall Atkinson, @Home Network draft-ietf-ipsec-arch-sec-01.txt 30 July 1997 Security Architecture for the Internet Protocol 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". 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 IP Security (IPsec) working group. It is intended that a future version of this draft be submitted to the IESG for publication as a Draft Standard RFC. Comments about this draft may be sent to the authors or to the IPsec WG mailing list . Distribution of this document is unlimited. Kent, Atkinson [Page 1] Internet Draft Security Architecture for IP 30 July 1997 Table of Contents 1. Introduction............................................................4 1.1 Summary of Contents of Document.....................................4 1.2 Audience -- assumptions about background knowledge..................4 1.3 Related Documents...................................................4 2. Design Objectives (how this system fits into the IP environment)........5 2.1 Goals/Objectives/Requirements/Problem Description...................5 2.2 Caveats and Assumptions.............................................5 3. System Overview ........................................................5 3.1 What IPSEC Does.....................................................6 3.2 How IPSEC Works.....................................................6 3.3 Where IPSEC May Be Implemented......................................7 4. Security Associations...................................................8 4.1 Definition and Scope................................................8 4.2 Security Association Functionality..................................9 4.3 Combining Security Associations....................................10 4.4 Security Association Processing....................................11 4.4.1 The Security Policy Database (SPD)............................11 4.4.2 Security Association Outbound Processing......................12 4.4.3 Selectors.....................................................13 4.4.4 Security Association Database (SAD)...........................14 4.5 Basic Combinations of Security Associations........................15 4.6 SA Establishment...................................................17 4.6.1 Manual Techniques.............................................17 4.6.2 Automatic Techniques -- Key Mgt Protocol Requirements.........18 4.6.3 Locating a security gateway...................................18 4.7 Security Associations and Multicast................................20 5. Processing IPSEC Traffic............................................... 5.1 Processing Outbound IPsec Traffic.................................. 5.1.1 Mapping to an SA or a bundle of SAs........................... 5.1.2 Header construction for tunnel mode........................... 5.1.2.1 IPv4 -- Header construction for tunnel mode.............. 5.1.2.2 IPv6 -- Header construction for tunnel mode.............. 5.2 Processing Inbound IPsec Traffic................................... 6. ICMP processing (relevant to IPsec).................................... 6.1 PMTU/DF processing................................................. 6.1.1 DF bit........................................................ 6.1.2 Path MTU Discovery (PMTU)..................................... 6.1.2.1 Propagation of PMTU...................................... 6.1.2.2 Calculation of PMTU...................................... 6.1.2.3 Granularity of PMTU processing........................... 6.1.2.4 PMTU Aging............................................... 7. Algorithm Descriptions................................................. 8. Usage Scenarios........................................................ 9. Auditing............................................................... 10. Use in systems supporting information flow security................... 11. Performance Issues.................................................... 12. Conformance Requirements.............................................. 13. Security Considerations............................................... 14. Differences from RFC 1825............................................. Kent, Atkinson [Page 2] Internet Draft Security Architecture for IP 30 July 1997 Acknowledgements.......................................................... Appendix A -- Glossary.................................................... A.1. Relevant Network Security Terminology............................. A.2 Requirements Terminology........................................... Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues......... B.1 DF bit............................................................. B.2 Fragmentation...................................................... B.3 Path MTU Discovery................................................. B.3.1 Identifying the Originating Host(s)........................... B.3.2 Calculation of PMTU........................................... B.3.3 Granularity of Maintaining PMTU Data.......................... B.3.4 Per Socket Maintenance of PMTU Data........................... B.3.5 Delivery of PMTU Data to the Transport Layer.................. B.3.6 Aging of PMTU Data............................................ Appendix C - Sequence Space Window Code Example........................... References................................................................ Disclaimer................................................................ Author Information........................................................ Kent, Atkinson [Page 3] Internet Draft Security Architecture for IP 30 July 1997 1. Introduction 1.1 Summary of Contents of Document This memo specifies the architecture of a system aimed at providing security for traffic at the IP layer, both IPv4 and IPv6. This document describes the goals of the system, its components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be used in the IP environment. The following fundamental components of IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d). a. Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP) b. Security Associations -- what they are and how they work, how they are managed, associated processing c. Key Management -- manual and automatic (Oakley/ISAKMP) d. Algorithms for authentication and encryption This document is not an overall Security Architecture for the Internet; it addresses security only at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms. [This version of the document is a VERY ROUGH DRAFT and requires considerable additional work.] 1.2 Audience The target audience for this document includes implementers of this IP security technology and others interested in gaining a general background understanding of this system. In particular, prospective users of this technology (end users or system administrators) are part of the target audience. A glossary is provided as an appendix to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general security terms and concepts. 1.3 Related Documents As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their inter-relationship. They include RFCs on the following topics: a. "IP Security Document Roadmap" -- a document providing guidelines for specifications describing encryption and authentication algorithms used in this system. b. security protocols -- RFCs describing the Authentication Kent, Atkinson [Page 4] Internet Draft Security Architecture for IP 30 July 1997 Header (AH) and Encapsulating Security Payload (ESP) protocols. c. algorithms for authentication and encryption -- a separate RFC for each algorithm d. automatic key management, e.g., an RFC on Oakley/ISAKMP 2. Design Objectives 2.1 Goals/Objectives/Requirements/Problem Description IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols. These objectives are met through the use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations When these mechanisms correctly implemented and deployed, they ought not adversely affect users, hosts, and other Internet components that do not employ these security mechanisms for protection of their traffic. These mechanisms also are designed to be algorithm- independent. This modularity permits selection of different sets of algorithms without affecting the other parts of the implementation. For example, different user communities may select different sets of algorithms (creating cliques) if required. A standard set of default algorithms is specified to facilitate interoperability in the global Internet. The use of these algorithms, in conjunction with IPsec traffic protection and key management protocols, is intended to permit system and application developers to deploy high quality, Internet layer, cryptographic security technology. 2.2 Caveats and Assumptions [To be supplied] 3. System Overview This section provides a high level description of how IPsec works, the components of the system, and how they fit together to provide Kent, Atkinson [Page 5] Internet Draft Security Architecture for IP 30 July 1997 the security services noted above. The goal of this description is to enable the reader to "picture" the overall process/system, see how it fits into the IP environment, and to provide context for later sections of this document, which describe each of the components in more detail. 3.1 What IPSEC Does IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect paths between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.) The set of security services that IPsec can provide includes access control connectionless integrity, data origin authentication, protection against replays (providing a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc. NOTE: When encryption is employed within IPsec, it prevents effective compression by lower protocol layers. However, IPsec does not provide its own compression services. Such services may be provided by existing higher layer protocols, or, in the future, in IP itself. The IETF working group, "IP Payload Compression Protocol (ippcp)" has the charter to "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." 3.2 How IPSEC Works IPsec uses two protocols to provide traffic security -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in more detail below in Section 5 ("Security Protocols") and in complete detail in their respective RFCs [KA97a, KA97b]. o The IP Authentication Header (AH) [KA97a] provides connectionless integrity, data origin authentication, and an optional anti-replay service (a form of partial sequence integrity). o The Encapsulating Security Payload (ESP) header/protocol provides confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless Kent, Atkinson [Page 6] Internet Draft Security Architecture for IP 30 July 1997 integrity, data origin authentication, an optional anti-replay service (a form of partial sequence integrity). o Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols. These protocols may be applied alone or in combination with the each other to provide desired sets of security services in IPv4 and IPv6. They support two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to a tunneled IP packet. The differences between the two modes are discussed in Section 4. IPsec allows the user (or system administrator) to control the granularity at which a service is offered. For example, one can create a single encrypted tunnel to carry all traffic between two security gateways or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec management incorporates facilities for specifying: o which security services to use and in what combinations o the granularity at which a given security protection should be applied o the algorithms used to effect cryptographic-based security Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place. (The keys are used for authentication and for encryption services.) This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (Oakley/ISAKMP [Reference???]) for automatic key management, but other automated key distribution techniques could be used. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed. 3.3 Where IPSEC May Be Implemented There are several ways in which IPsec may be implemented in hosts or in conjunction with routers or firewalls (to create a security gateway). Several common examples are provided below: a. Integration of IPSEC into the native IP implementation. This requires access to the IP source code and is applicable to both hosts and security gateways. b. "Bump-in-the-stack" (BITS) implementations, where IPSEC is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local Kent, Atkinson [Page 7] Internet Draft Security Architecture for IP 30 July 1997 network drivers. Source code access for stack is not required in this context, making it appropriate for use with legacy systems. This is generally assumed to be implemented in hosts. c. The use of an outboard crypto processor is a common design feature of network security systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "Bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway (or both). Usually the device is IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but in supporting a router or firewall, it is more like a security gateway. 4. Security Associations This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of Oakley/ISAKMP is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques. 4.1 Definition and Scope A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or of ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts (or between two security gateways), two Security Associations (one in each direction) are required. The combination of a Security Parameter Index (SPI), a Destination Address, and the security protocol identifier uniquely identifies a Security Association. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well. As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between Kent, Atkinson [Page 8] Internet Draft Security Architecture for IP 30 July 1997 two hosts. The security protocol header appears immediately after the IP header (and any options or extensions), and before any higher layer protocols (e.g., TCP or UDP). In the case of ESP, a tunnel mode SA provides security services only for these higher layer protocols, not for the IP header. In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA97b]. A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. So, an SA between two security gateways is always a tunel mode SA, as is an SA between a host and a security gateway. Two hosts MAY establish a tunnel mode SA between them. An SA involving a security gateway must be a tunnel SA to avoid potential problems with regard to fragmentation and reassembly, and in circumstances where multiple paths (e.g., via different routers or firewalls) exist to the same destination (behind the security gateway). For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header. 4.2 Security Association Functionality The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and on the election of optional services within the protocol. For example, AH provides data origin authentication and connectionless integrity for IP datagrams (hereafter referred to as just "authentication"). The "precision" of the authentication service is a function of the granularity of the security association with which AH is employed, as discussed in Section 4.??. AH also offers an anti-replay (partial sequence integrity) service at the discretion of the receiver, to counter denial of service attacks. AH is an appropriate protocol to employ when confidentiality is not required (or is not permitted, e.g , due to government restrictions on encryption). AH also provides authentication for selected portions of the IP header, which may be necessary in some contexts. For example, if the integrity of an IP option or IPv6 extended header must be protected en route between sender and receiver, AH can provide this service. Kent, Atkinson [Page 9] Internet Draft Security Architecture for IP 30 July 1997 ESP always provides confidentiality for traffic. It also may optionally provide authentication (as defined above). If authentication is negotiated for an ESP SA, the receiver also may elect to enforce an anti-replay service with the same features as the AH anti-replay service. The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header "below" the ESP header is not protected. If only the upper layer protocols need to be authenticated, then ESP is an appropriate choice and is more space efficient than nested use of AH. An ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination. Moreover, ESP payload padding also can be invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). 4.3 Combining Security Associations The IP datagrams transmitted over an individual security association are afforded protection by exactly one security protocol, either AH or ESP. Sometimes a security policy may call for a combination of services and service sitings for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. (Note that the SAs that comprise a bundle need may terminate at different endpoints.) Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling. Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the processing is performed at one IPsec instance the (ultimate) destination. Iterated tunneling refers to the application of multiple layers of security protocols effected through tunneling. This approach allows for multiple levels of nesting, since each tunnel can terminate at a different IPsec site along the path. These two approaches also can be combined, i.e., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and (parts of) the IP header. Thus if AH is used in a transport mode, in Kent, Atkinson [Page 10] Internet Draft Security Architecture for IP 30 July 1997 conjunction with ESP, AH should appear as the first header after IP, then ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. 4.4 Security Association Databases Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized, to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to security associations, in support of these interoperability and functionality goals. 4.4.1 The Security Policy Database (SPD) Ultimately, a security association is a management construct used to enforce a security policy in the IPsec environment. Thus an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section does specify certain minimum management functionality that must be provided, to allow a user or system administrator to control how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. For any (outbound) datagram three processing choices are possible: discard, bypass, protect. The first choice refers to traffic that is not allowed to exit the host or traverse the security gateway, at all. The second choice refers to traffic that is allowed to pass without IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security services to be provided, protocols to be employed, algorithms to be used, etc. For every IPsec implementation, there MUST be some form of administrative interface that allows a user or system administrator to manage the SPD. The form of the management interface is not specified by this document and may differ for hosts vs. security gateways, and within hosts the interface may differ for socket-based vs. BITS implementations. However, this document does specify a standard set of SPD elements that all IPsec implementations MUST support. The SPD contains an ordered list of policy entries that define the security services, protocols, and algorithms that will be employed Kent, Atkinson [Page 11] Internet Draft Security Architecture for IP 30 July 1997 for IP traffic that processed by the IPsec implementation. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry. The selectors are the sort of information that could be used to create a socket in a host. These define the granularity of SAs. Each entry also includes an indication of whether traffic matching this policy will be bypassed, discarded, or subject to IPsec processing. Finally, the entry includes an SA (or SA bundle) specification, listing the IPsec protocols, modes, and algorithms to be employed, including nesting requirements. For example, an entry may call for all matching traffic to be protected by ESP in transport mode using 3DES-CBC with explicit IV, nested inside of AH in tunnel mode using HMAC/SHA-1. As described below in Section 4.4.3, selectors may include "wildcard" entries and hence the selectors for two entries may overlap. Thus, to ensure consistent, predictable processing, SPD entries must be ordered. Note that the SPD does not map traffic to specific SAs or SA bundles. Instead, it can be thought of as the reference database for security policy, to be consulted when no existing SA or SA bundle matches the requirements for traffic. In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket was created, to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket. The SPD also will be consulted when any IPsec implementation is the target of an SA establishment request from another IPsec implementation, e.g., using Oakley/ISAKMP. An IPsec implementation in a security gateway, BITW or BITS context, it usually will be necessary to examine every outbound packet to determine what, Ipsec processing, if any, is needed. In these instances, a second database is required. The Security Association Map is the database that maps selectors to existing SAs (or SA bundles) and will be consulted on a per-packet basis (for outbound traffic). Section 4.4.2 defines the requirements for this database 4.4.2 Security Association Map (SAM) The Security Association Map (SAM) is a nominal database used to map outbound traffic IP to a security association (or to an SA bundle) when the IPsec implementation does not make use of a socket-based interface. This likely to be the sort of interface encountered for most security gateways, BITW and BITS IPsec implementations. This document does not specify a required form for the database nor an interface. It provides an illustration of database entries and entry contents as a guide for implementors. Like the SPD, this is an ordered database in which each entry is keyed by one or more selectors that define the granularity of SAs (or SA bundles). Unlike the SPD, entries in the SAM refer to existing Kent, Atkinson [Page 12] Internet Draft Security Architecture for IP 30 July 1997 SAs, or define traffic that is to be bypassed or discarded. Thus each entry that calls for IPsec processing points to an ordered list of SAs (to support SA bundles) that will be applied to the traffic. When SAs are created, an entry is made in the SAM, and when SAs expire or are otherwise explicitly terminated, entries in the SAM are deleted. The selectors used in the SAM are the same as those used in the SPD, and are defined below in Section 4.4.3. 4.4.3 Selectors An SA (or SA bundle) may be fine-grained or coarse-grained, depending on the selectors used to define the set of (outbound) traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Protocol and Port fields), with different security services offered for different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported for SA management to facilitate control of SA granularity: - Destination IP Address(es): this may be a single IP address (unicast or multicast group), an enumerated list of addresses, or a wildcard (mask) address. The last two are required to support more than one destination system sharing the same SA (behind a security gateway). [REQUIRED for all implementations] - Source IP Address(es): this may be a single IP address, an enumerated list of addresses, or a wildcard (mask) address. The last two are required to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations] - UserID: a user identifier from the operating system. (The use of a User ID as a SA selector is sometimes referred to as "user-oriented keying.") [REQUIRED for host implementations, unless the layering of the implementation precludes access to this information, e.g., a BITS implementation need not support this selector.] - Data sensitivity level: (IPSO/CIPSO labels) [REQUIRED for all systems providing label-based security, OPTIONAL for all other systems] - Transport Layer Protocol (formerly Next Protocol): Both the IPv4 "Protocol" and the IPv6 "Next Header" fields may not contain the Transport Protocol due to the presence of IP extension headers. Kent, Atkinson [Page 13] Internet Draft Security Architecture for IP 30 July 1997 These fields could contain a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. To address the question of which Protocol/Next-Header to use when there is more than one, this selector has been defined to be the Transport Layer Protocol selector. This is based on the assumption that it is not necessary to allow use (as selectors) of Protocol or Next Header fields other than the one containing the Transport Protocol field. It is assumed to be unlikely that a policy administrator might want to map a security association to a communication association using a Protocol or Next Header field with an extension header value. This means, for example, it will not be possible to specify that "Any packet with a routing header (which defines a source route) must be authenticated so that the destination can tell whether or not to accept the packet." [REQUIRED for all implementations] NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Next Protocol" field until it encounters either one it recognizes as a transport protocol or until it reaches one that isn't on its list of extension headers. - Source and Destination (TCP/UDP) Ports: These may be individual UPD or TCP port values, an enumerated list of ports, or a wildcard (mask) port. (The use of the Next Protocol field and the Source and/or Destination Port fields (in conjunction with the Source and/or Destination Address fields), as an SA selector is sometimes referred to as "session-oriented keying.") [REQUIRED for all implementations] - IPv6 Priority (from IP header): This may be expressed as ??? [REQUIRED for all systems that implement IPv6] - IPv6 Flow Label (from IP header): This may be expressed as ???. The IPv6 spec (RFC 1883) calls for all datagrams for a given IPv6 Flow Label to have the same Source Address, Destination Address, Hop-by-hop Options header, and Routing Header. The Flow Label may be assigned on a per socket basis. It would then be correlated with the Source/Destination and could be used to provide finer granularity selection of security association(s). [REQUIRED for all systems that implement IPv6] 4.4.4 Security Association Database (SAD) In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each entry in the SAD is indexed by a destination IP address,IPsec protocol type, and SPI, for use in inbound IPsec packet processing. For outbound processing, entries are pointed to by entries in the SAM. The following parameters are associated with Kent, Atkinson [Page 14] Internet Draft Security Architecture for IP 30 July 1997 each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation. - Destination IP address: the IPv4 or IPv6 address used as an index for SA lookup in this database. [REQUIRED for all implementations] - IPsec Protocol: AH or ESP. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] - SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] - IPsec protocol mode: tunnel or transport. Indicates which mode of AH or ESP is applied to traffic on this SA. [REQUIRED for all implementations] - Replay Protection: selection/non-selection by receiver and window size. [REQUIRED for all implementations] - AH Authentication algorithm. [REQUIRED for AH implementations] - ESP Encryption algorithm and mode. [REQUIRED for ESP implementations] - ESP authentication algorithm. If the authentication service is not selected, this field will be null. [REQUIRED for ESP implementations] - Lifetime of this Security Association: a time interval after which an SA must be rekeyed or terminated, plus an indication of which of these actions should occur. [REQUIRED for all implementations] 4.5 Basic Combinations of Security Associations There are 4 obvious examples of combinations of security associations. Support for each of these is required. Note that there may be other uses of IPSEC; but these appear to be the most critical ones, ones that all compliant (host/security gateway) implementations are required to support. The diagrams and text below describe the basic cases. The legend for the diagrams is: Kent, Atkinson [Page 15] Internet Draft Security Architecture for IP 30 July 1997 ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) Hx = host x SGx = security gateway x X* = X supports IPSEC NOTE: The security associations below can be either AH or ESP. The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel. For host-to-gateway SAs and gateway-to-gateway SAs the mode can ONLY be tunnel. Section 5.4, "Required Support for AH and ESP Combinations", provides additional detail on the required support for different combinations of IPsec protocols and modes. Case 1. The case of providing end-to-end security between 2 hosts across the Internet (or an Intranet). ==================================== | | H1* ------ (Inter/Intranet) ------ H2* Case 2. This case includes creating virtual private networks. =========================== | | ---------------------|---- ---|----------------------- | | | | | | | H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Case 3. This case takes case 2 and adds end-to-end security between the sending and receiving hosts =============================================================== | | | ========================= | | | | | ---|-----------------|---- ---|-------------------|--- | | | | | | | | | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | | Intranet) | | Intranet) | -------------------------- --------------------------- admin. boundary admin. boundary Kent, Atkinson [Page 16] Internet Draft Security Architecture for IP 30 July 1997 Case 4. This covers the situation where a remote host (H1) is using the Internet to reach an organization's firewall (SG1) and to then gain access to some server or other machine (H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall (SG1), etc. The details of support for this case, (how H1 locates SG1, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.4.3, "Locating a Security Gateway". ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG1* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server 4.6 SA Establishment 4.6.1 Manual Techniques The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are quite practical in small, static environments but they do not scale well. It is not a viable medium-term or long-term approach, but might be appropriate and useful in some environments in the near-term. For example, a company could create a Virtual Private Internet (VPI) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not encrypting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization, for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist. Kent, Atkinson [Page 17] Internet Draft Security Architecture for IP 30 July 1997 4.6.2 Automatic Techniques -- Key Mgt Protocol Requirements Widespread deployment and use of IP security requires an Internet- standard, scalable, key management protocol. This protocol should not be limited to supporting IP security. This protocol should be compatible with the IETF's DNS Security work and should include the ability to obtain bootstrapping information (e.g. keys, addresses) from the Secure DNS as a mandatory-to-implement feature. Signed host keys to the Domain Name System [EK96] The DNS keys enable the originating party to authenticate key management messages with the other key management party using an asymmetric algorithm. A standards-track key management protocol for use with IP Security MUST provide the property of "Perfect Forward Secrecy" as a mandatory-to- implement feature. Further, any standards-track key management protocol MUST permit the secure negotiation or secure identification of the Security Association attributes to all parties of that Security Association. 4.6.3 Locating a Security Gateway This section discusses the issues relating to how a host learns about the existence of relevant security gateways and once a host has contacted these security gateways, how it knows that these are the correct security gateways. [NOTE: This topic is still under discussion so the text below describes the problem and some proposed approaches rather than a final agreed-upon solution.] Suppose you have a remote host (H1) which is using the Internet to gain access to a server or other machine (H2) and there is a primary security gateway (SG1), e.g., a firewall, through which the H1's traffic must pass. Suppose also that there is a secondary security gateway (SG2) available as a backup path. An example of this situation would be a mobile host (Road Warrior) dialing up to a local PPP/ARA server on the Internet and then crossing the Internet to the home organization's firewall (SG1), etc. The following discussion also applies to the situation where the remote entity setting up the security associations to SG1 (or SG2) is H1's security gateway (SG3) acting on behalf of H1. To support this kind of situation, H1 MUST be able to create a communication association to H2 that makes use of two SAs -- a tunnel mode SA from H1 to to SG1 and a transport mode SA from H1 to H2. The diagram below illustrates this. The legend for the diagram is: ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) Hx = host x SGx = security gateway x X* = X supports IPSEC Kent, Atkinson [Page 18] Internet Draft Security Architecture for IP 30 July 1997 ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------|-SG1* ---- (Local ----- H2* | ^ | | Intranet) | | | | | | | -----------|-SG2* --------- | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server This situation raises several questions: 1. How does H1 know/learn about the existence of the security gateway SG1? 2. How does it authenticate SG1, and once it has authenticated SG1, how does it confirm that SG1 has the "right" to represent H2? 3. How does SG1 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know to use SG2 as an alternate path to H2 when something disrupts connectivity via SG1? There are appear to be 2 main instances where this situation would arise. 1. H1 is the system of an individual associated with the organization administering SG1/SG2/H2, e.g., an employee. H1 might be remotely accessing a home system H2 through the firewall SG1 and the H1 to SG1 connection could be part of a Virtual Private Network. In this case, it is reasonable for H1 to be pre-configured with the requisite information about SG1, SG2, and H2. To do this, H1 MUST have an administrative interface that allows the user/administrator to specify: o the SAs to use for a communication association to H2 -- a tunnel mode SA from H1 to SG1 and a transport mode SA from H1 to H2. o the SAs to use if the path to H2 via SG1 fails -- a tunnel mode SA from H1 to SG2 and a transport mode SA from H1 to H2. o the requisite information for locating, authenticating, and verifying the authorization of SG1 and SG2. 2. H1 is the system of a person who's been told about system H2 at the organization administering SG1/H2, but who's otherwise Kent, Atkinson [Page 19] Internet Draft Security Architecture for IP 30 July 1997 unconnected to that organization. When H1 tries to contact H2, several things will need to happen to dynamically provide H1 with the requisite information: a) H1 needs to find out about SG1. b) H1 must have a mechanism that allows it to authenticate SG1 and verify that SG1 is authorized to represent H2. c) SG1 has to have a mechanism to authenticate H1 and verify that H1 is authorized to contact H2. d) If the path via SG1 is unusable for some reason, (SG1 is down, source routing, etc.), then H1 must know to use SG2 and then (b), (c), and (d) apply to SG2. To address this situation, an approach has been proposed that uses a new "key exchange" record (KX) in the Secure Domain Name System (DNS) as a mechanism to allow a host/gateway to determine the set "of authorised remote key exchanger systems" for a given destination. (See Randall Atkinson's Internet Draft, "Key Exchange Delegation Record for the DNS" for details.) In both cases: 1. H1 MUST be able to use SG1's public key certificate to authenticate that the connection is to the real SG1. The same applies to H1 authenticating SG2. 2. SG1 MUST be able to use H1's public key certificate to authenticate H1. The same applies to SG2 authenticating H1. 3. SG1 and SG2 MUST be able to check H1's authorization to contact H2. NOTE: If H2 were outside the firewall/security gateway perimeter, it might be possible to handle this situation by use of SSL [need reference]. 4.7 Security Associations and Multicast The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations that conflict with automatically configured (e.g. via a key management protocol) Security Associations. For multicast traffic, there are multiple destination systems but a single destination multicast group, so some system or person will need to select SPIs on behalf of that multicast group and then communicate the information to all of the legitimate members of that multicast group via mechanisms not defined here. Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to Kent, Atkinson [Page 20] Internet Draft Security Architecture for IP 30 July 1997 that group when a symmetric cryptographic algorithm is in use. In that case, the receiver only knows that the message came from a system knowing the security association data for that multicast group. A receiver cannot generally authenticate which system sent the multicast traffic when symmetric algorithms (e.g. DES, IDEA) are in use. Multicast senders SHOULD use a separate Security Association for each sender to the multicast group when an asymmetric cryptographic algorithm is in use. In this last case, the receiver can know the specific system that originated the message. Multicast key distribution was an active research area in the published literature at the time this specification was published. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. 5. IPSEC Traffic Processing 5.1 Outbound IPsec Traffic Processing 5.1.1 Selecting an SA or SA Bundle - socket-based host implementations - SAM-based mapping - sequential application of SAs to traffic - fragmentation 5.1.2 Header construction for tunnel mode [There are a variety of unresolved issues here. The text below is included as a starting place for further discussion. For example, RFC 1853 may be an appropriate basis for this discussion, for outbound processing] This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. This description is based on the situation below with H1 sending IP traffic to H2 and an IPsec tunnel between SG1 and SG2. ==== = security association (AH or ESP, tunnel) ---- = connectivity Hx = host x Gx = gateway x SGx = security gateway x X* = X supports IPSEC =========================== | | | | Kent, Atkinson [Page 21] Internet Draft Security Architecture for IP 30 July 1997 H1 -- G1 -- G2 - SG1* -- G3 -- G4 -- G5--- SG2* -- G6 -- G7 -- H2 This processing is a function of: a) which stage of processing is occurring: - outbound (the sender at the beginning of the tunnel) - inbound (the receiver at the end of the tunnel) b) IP version c) header/option fields d) security policy The tables in the following sub-sections show the handling for the different header/option fields using the following "actions": constructed-indep = the value in the outer field is constructed independently of the value in the inner field. constructed-calc = for outbound packets, the value in the outer field is computed from the inner field and possibly some other information. For inbound packets, the value in the inner field is computed from the outer field and possibly some other information. configured = the derivation of the value in the field is "configurable" by the administrator to one of several choices, e.g., outer header's TOS can be (a) "copied" from the inner field, (b) hardwired by the configuration to a particular value, (c) "filtered", i.e., the administrator defines a range such that within (or outside of) the range, the value in the inner field is used; and outside (or within) the range, a configuration-defined value is used. copied = the value in the outer field is always copied as is from the inner field. never copied = the value in the inner field is never copied to the outer field. consumed = the outer field is ignored/discarded. nc = no change. 5.1.2.1 IPv4 -- Header construction for tunnel mode Kent, Atkinson [Page 22] Internet Draft Security Architecture for IP 30 July 1997 <-------- How Outer Hdr Relates to Inner Hdr ---------> Outbound Inbound ------------------------------ -------------------- IPv4 Outer hdr Inner hdr Outer header Inner Header fields version constructed-indep(11) nc consumed nc header length constructed-calc nc consumed nc TOS configured (6) nc consumed nc total length constructed-calc nc consumed nc ID constructed-indep nc consumed nc flags (DF,MF) constructed-calc (8) nc consumed nc fragmt offset constructed-calc nc consumed nc TTL configured (7) nc consumed conf (5) protocol AH, ESP, routing hdr nc consumed nc checksum constructed-calc nc consumed constr-calc src address constructed-calc (9) nc consumed nc dest address constructed-calc (9) nc consumed nc Options sec option copied nc consumed nc loose src route configured (1) nc consumed conf (1) strict src route configured (1) nc consumed conf (1) record route configured (10) nc consumed cnstr-calc(10) timestamp copied nc consumed cnstr-calc (2) end constructed-calc (3) nc consumed nc nop constructed-calc (4) nc consumed nc (1) loose and strict source routing for IPv4 raise several issues: a) Should source routing information from the inner IP header be copied to the outer header? b) If yes, how does SG1 figure out how to construct the outer IP header, i.e., what part of the source route comes before SG2 and should be copied to the outer header? c) If yes, should SG2 copy the recorded route information from the outer header to the inner header? For IPv4, SG1 can be configured with: a) 2 choices for outbound processing: o outer header is constructed from remaining hops in inner routing header with SG2 as the last destination. If part of the source route is "beyond" SG2, then SG1 needs to construct an outer header containing just the part of the source route that extends up to SG2, inserting SG2 as the last hop (destination). [Need to specify how SG1 figures out how much of the source route belongs in the outer header, e.g., use an ICMP message from Kent, Atkinson [Page 23] Internet Draft Security Architecture for IP 30 July 1997 SG2] o outer routing header is constructed based on security policy specification for the tunnel. b) 3 choices for the inbound processing: o inner routing header is updated to know to skip over "used" hops in outer header but the recorded route information is not copied over and the corresponding information for the "used" hops is zero'd in the inner header. o inner routing header is updated to know to skip over "used" hops in outer header and the recorded route information is copied over to the inner header. o inner routing header is constructed based on security policy specification for the tunnel. For IPv6, SG1 can be configured with: a) 2 choices for outbound processing: o outer (version 0) routing header is constructed from remaining hops in inner routing header. o outer (version 0) routing header is constructed based on security policy specification for the tunnel. b) 3 choices for the inbound processing: o inner routing header is updated to know to skip over "used" hops in outer header but the recorded route information is not copied over and the locations where the recorded route information would normally be placed for the "used" hops is zero'd in the inner header. o inner routing header is updated to know to skip over "used" hops in outer header and the recorded route information is copied over to the inner header. o inner routing header is constructed based on security policy specification for the tunnel. (2) copy the inner fields to the outer fields. At the tunnel destination, the inner fields MUST be updated with any additional information recorded on outside header. (3) for outside field, this is inserted if needed based on whatever else was copied. At the tunnel destination, it is not changed as any changes made to the inner option fields cannot change the length of an option. (4) constructed, based on alignment and options copied (5) [needs to be coordinated between src endpoint and dst endpoint] The following steps assume that IPSEC does the decapsulating of the packet and then passes it to the IP forwarding code where the decrementing of TTL occurs. Accordingly no decrementing is done in IPSEC. (a) if the outer TTL was a configured number, leave inner TTL as is. Kent, Atkinson [Page 24] Internet Draft Security Architecture for IP 30 July 1997 (b) if inner TTL was copied to outer field, replace inner TTL with outer TTL. (6) [needs to be coordinated between src endpoint and dst endpoint] Choices = copy from inner header, use configured value, "filter" (administrator defines a range such that within (outside of) the range, the inner IP header value is used; and outside (inside) the range, a configuration-defined value is used.) (7) choices = copy from inner header, use configured value. MUST be consistent with (5). (8) see Section Y on PMTU/DF. (9) src and dst addresses depend on the SA, which is used to determine the dst address which in turn determines which src address (net interface) is used to forward the packet. (10) whether to copy the inner fields to outer fields is "configurable"; but "always" update the inner fields with the hops (if any) recorded in the outer fields. (11) the IP version in the encapsulating header can be different from the value in the inner header. 5.1.2.2 IPv6 -- Header construction for tunnel mode <-------- How Outer Hdr Relates to Inner Hdr ---------> Outbound Inbound ------------------------------ -------------------- IPv6 Outer hdr Inner hdr Outer header Inner Header fields version constr.-indep (11) nc consumed nc priority configured (6) nc consumed nc flow id configured (6) nc consumed nc len constructed-calc nc consumed nc next header AH,ESP,routing hdr nc consumed nc hop count configured (7) nc consumed conf (5) src address constructed-calc(9) nc consumed nc dest address constructed-calc(9) nc consumed nc Extension headers destination options pad 1 constructed-calc(4) nc consumed nc pad N constructed-calc(4) nc consumed nc EID never copied nc consumed nc hop by hop options pad 1 constructed-calc(4) nc consumed nc pad N constructed-calc(4) nc consumed nc jumbogram copied but adjusted nc consumed nc fragmentation never copied (12) nc consumed (12) nc routing configured (1) nc consumed conf (1) AH/ESP constr.-indep(13) nc consumed nc (1), (4)-(7), (9), (11) see table notes from Section 4.3.1.4.1, "IPv4 -- Header construction for tunnel mode" Kent, Atkinson [Page 25] Internet Draft Security Architecture for IP 30 July 1997 (12) in tunnelling, the new packet can be fragmented. At the tunnel end, the outer header should have been removed by re-assembly. (13) the outer header is constructed for the tunnel and is not derived from any inner header AH/ESP In IPv6 source routing, the system routes the packet (reading the IPv6 header) until the current router = the destination in the IPv6 header, then the current router processes the next header. At each router, the next hop in the routing header's chain of source routes is swapped with the IPv6 destination field; the Segments Left field is decremented by 1. The system routes the packet onward (goes no further up the stack) until the Segments Left field is 0. Any headers that are after the RH are processed only when Segments Left field is 0. Suppose, you have the sample headers/options below RH = routing header version 0 (processed by routers listed in RH): A B ---- ---- IPv6 IPv6 RH AH/ESP AH/ESP RH TCP TCP In case A, the AH/ESP header gets processed only after the packet reaches the final destination (RH Segments Left = 0). This is the typical case for end-to-end AH/ESP. In case B, the AH/ESP header will get processed at every router listed in the RH (they get copied to the IPv6 header). In a typical case, the AH/ESP header is validated and replaced with a different SA(s) at each hop listed in the source route. 5.2 Processing Inbound IPsec Traffic Processing of inbound IPsec traffic generally is easier that processing of outbound processing. This is because each inbound IP datagram to which IPsec processing will be applied is identified by the appearance of the AH or ESP values in the IP Next Protocol field (or of AH or ESP as an extension header in the IPv6 context). Moreover, mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. - mapping packets to a SAD entry - iterative processing for nested SAs - reassembly 6. ICMP processing (relevant to IPsec) - anything other than PMTU issues? Kent, Atkinson [Page 26] Internet Draft Security Architecture for IP 30 July 1997 6.1 PMTU/DF processing 6.1.1 DF bit In cases where a system (host or gateway) adds an encapsulating header (ESP or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.) 6.1.2 Path MTU Discovery (PMTU) [This section assumes PMTU processing based on inputs from possibly untrusted intermediate routers. We must consider whether such processing is optionally supported, with the alternative of processing based only on information from trusted routers (see Richardson I-D on this topic).] This section discusses IPsec handling for Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for: IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled "unused" in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message 6.1.2.1 Propagation of PMTU The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix B for more detailed discussion of this topic.) o PMTU message with 64 bits of IPSEC header -- If the ICMP PMTU message contains only 64 bits of the IPSEC header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis: a. if the originating host(s) can be determined, send the PMTU information to all the possible originating hosts. Kent, Atkinson [Page 27] Internet Draft Security Architecture for IP 30 July 1997 b. if the originating host(s) cannot be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If the packet(s) are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host(s). Retain the PMTU information for any message that might arrive subsequently (until ???) o PMTU message with >64 bits of IPSEC header -- If the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with a 5-selector pointer for storing/updating the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. o Distributing the PMTU to the Transport Layer -- The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). 6.1.2.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPSEC header -- ESP or AH transport, or ESP or AH tunnel. (See Appendix B for discussion of implementation issues.) 6.1.2.3 Granularity of PMTU processing In hosts, the granularity with which ICMP PMTU processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix B for detailed discussion of this issue): a. Integration of IPSEC into the native IP implementation b. Bump-in-the-stack implementations, where IPSEC is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPSEC implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and Kent, Atkinson [Page 28] Internet Draft Security Architecture for IP 30 July 1997 destination IP addresses, and each communication association may have a different amount of IPSEC header overhead (e.g., due to use of different transforms or different algorithms). Implementation of the calculation of PMTU and support for PTMUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPSEC in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPSEC header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. 6.1.2.4 PMTU Aging In all systems (host or gateway) implementing IPSEC and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. 7. Algorithm Descriptions [To be supplied -- refers to separate algorithm documents] 8. Usage Scenarios [To be supplied. including s subsection on special processing in an information flow security environment, e.g., MLS hosts and networks.] 9. Auditing Not all systems that implement IPsec will implement auditing. However, if a system supports auditing, then the IPsec implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for IPsec. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications 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 29] Internet Draft Security Architecture for IP 30 July 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. 10. Use in systems supporting information flow security [To be supplied] 11. Performance Issues The use of IPsec imposes computational performance costs on the hosts or security gateways that implement these protocols. These costs are associated with the computation of integrity check values, encryption and decryption,and added per-packet handling. These per-packet computational costs will be manifested by increased latency and, possibly, reduced throughout. Use of security association management protocols, especially ones that employ public key cryptography, also adds computational performance costs to use of IPsec. These per- association computational costs will be manifested in terms of increased latency in association establishment. For many hosts, it is anticipated that software-based cryptography will not appreciably reduce throughput, but hardware may be required for security gateways (since they represent aggregation points), and for some hosts. The use of IPsec also imposes bandwidth utilization costs on transmission, switching, and routing components of the Internet infrastructure, components not implementing IPsec. This is due to the increase in the packet size resulting from the addition of AH and/or ESP headers, ESP tunneling (which adds a second IP header), and the increased packet traffic associated with key management protocols. It is anticipated that, in most instances, this increased bandwidth demand will not noticeably affect the Internet infrastructure. However, in some instances, the effects may be significant, e.g., transmission of ESP encrypted traffic over a dialup link that otherwise would have compressed the traffic. Note: As discussed above, compression can still employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "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 IPsec protocols. 12. Conformance Requirements [Will be a summary] Kent, Atkinson [Page 30] Internet Draft Security Architecture for IP 30 July 1997 13. Security Considerations [To be supplied] 14. Differences from RFC 1825 [To be supplied] 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, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security. 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 Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also 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, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, William Simpson, Harry Varnis, and Nina Yuan. Kent, Atkinson [Page 31] Internet Draft Security Architecture for IP 30 July 1997 Appendix A -- Glossary A.1. Relevant Network Security Terminology This section provides definitions for several key terms that are employed in this document. Other documents provide additional definitions and background information relevant to this technology, e.g., [VK83, HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms. Access Control Access control is a security service that prevents unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. In the IPsec context, the resource to which access is being controlled often is a network interface on a host security gateway. Anti-replay [See "Integrity" below] Authentication This term is used informally to refer to the combination of two nominally distinct security services, data origin authentication and connectionless integrity. See the definitions below for each of these services. Availability Availability, when viewed as a security service, addresses the security concerns engendered by attacks against networks that deny or degrade service. For example, in the IPsec context, the use of anti-replay mechanisms in AH and ESP support availability. Confidentiality Confidentiality is the security service that protects data from unauthorized disclosure. The primary confidentiality concern in most instances is unauthorized disclosure of application level data, but disclosure of the external characteristics of communication also can be a concern in some circumstances. Traffic flow confidentiality is the service addresses this latter concern by concealing source and destination addresses, message length, or frequency of communication. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality. (See also traffic analysis, below.) Encryption Encryption is a security mechanism used to transform data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is designated "decryption." Oftimes the term "encryption" is used to generically refer to both processes. Kent, Atkinson [Page 32] Internet Draft Security Architecture for IP 30 July 1997 Data Origin Authentication Data origin authentication is a security service that verifies the identity of the claimed source of data. This service is usually bundled with the connectionless integrity service. Integrity Integrity is a security service that ensures that modifications to data are detectable. Integrity comes in various flavors, to match application requirements. IPsec supports two forms of integrity: connectionless and a form of partial sequence integrity. Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic. The form of partial sequence integrity offered in IPsec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). This is in contrast to connection-oriented integrity, which imposes more stringent sequencing requirements on traffic, e.g., to be able to detect lost messages. Although authentication and integrity services often are cited separately, in practice they are intimately connected and almost always offered in tandem. Security Association (SA) A simplex (uni-directional) logical connection, created for security purposes. All traffic traversing an SA is provided the same security processing. In IPsec, an SA is an internet layer abstraction enforced through the use of AH or ESP. Security Gateway A security gateway is an intermediate system that acts as the communications interface between two networks. The set of hosts (and nets) on the external side of the security gateway is viewed as untrusted (or less trusted), while the networks and hosts and on the internal side are viewed as trusted (or more trusted). The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. (See "Trusted Subnetwork" below.) In the IPsec context, a security gateway is a point at which AH and/or ESP is implemented in order to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also employing IPsec (either directly or via another security gateway). SPI Acronym for "Security Parameters Index." The combination of an SPI, a destination address, and a security protocol uniquely identifies a security association (SA, see above). The SPI is carried in AH and ESP protocols to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally Kent, Atkinson [Page 33] Internet Draft Security Architecture for IP 30 July 1997 viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. Traffic Analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, flow Identifiers, etc. [Sch94] Trusted Subnetwork A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. There also is an assumption that the underlying communications channel (e.g., a LAN or CAN) isn't being attacked by other means. A.2. Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalized. These words are: MUST This word or the adjective "REQUIRED" means that implementation of the item is an absolute requirement of the specification. SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to not implement this item, but the full implications should be understood and the case carefully weighed before taking a different course. MAY This word or the adjective "OPTIONAL" means that this item is truly optional to implement. For example, one vendor might choose to include the item because a particular marketplace requires it or because it enhances the product; another vendor might omit the same item. Kent, Atkinson [Page 34] Internet Draft Security Architecture for IP 30 July 1997 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues B.1 DF bit In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header? Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. B.2 Fragmentation Fragmentation MUST be done after outbound IPSEC processing. Reassembly MUST be done before inbound IPSEC processing. The general reasoning is shown below (delimited by the *******'s). NOTE: IPSEC always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPSEC and is intrinsic to the definition of IPSEC. Therefore any IPSEC implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (IP2): o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer **************************************************************************** Overall, the fragmentation/reassembly approach described above works for all cases examined. Kent, Atkinson [Page 35] Internet Draft Security Architecture for IP 30 July 1997 AH Xport AH Tunnel ESP Xport ESP Tunnel Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y S. Gwy (integr w/ IP stack) Y Y Y Y Outboard crypto processor * * If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPSEC processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers. The following analysis assumes that: 1. There is only one IPSEC module in a given system's stack. There isn't an IPSEC module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPSEC module B. 2. There are several places where IPSEC could be implemented (as shown in the table above). a. Hosts with integration of IPSEC into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPSEC is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPSEC code to be incorporated into the system. c. Security gateways and outboard crypto processors with integration of IPSEC into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible. For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4). Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.) Kent, Atkinson [Page 36] Internet Draft Security Architecture for IP 30 July 1997 IP/Transport Interface IPv4 IPv6 (RFC 1122 -- Sec 3.4) ---- ---- ---------------------- Version = 4 Version = 6 Header Len *TOS Prty,Flow Lbl TOS Packet Len Payload Len Len ID ID (optional) *Flags DF *Offset *TTL *Hop Limit TTL Protocol Next Header *Checksum Src Address Src Address Src Address Dst Address Dst Address Dst Address Options? Options? Opt ? = AH covers Option-Type and Option-Length, but not Option-Data. The results for each of the 24 cases is shown below ("works" = will work if system fragments after outbound IPSEC processing, reassembles before inbound IPSEC processing). Notes indicate implementation issues. a. Hosts (integrated into IP stack) o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works b. Hosts (Bump-in-the-stack) -- put IPSEC between IP layer and network drivers. In this case, the IPSEC module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel is to the ultimate destination, this is fine. But in AH or ESP tunnel modes where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal Kent, Atkinson [Page 37] Internet Draft Security Architecture for IP 30 July 1997 routing because the IPSEC module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPSEC would need to know the LAN interface and the next-hop gateway for the tunnel end. (Note: The tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall.) OR - pass the IPSEC'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPSEC module would have to check and let IPSEC'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header At the network layer, the IPSEC module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPSEC has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works c. Security gateways -- integrate IPSEC into the IP stack NOTE: The IPSEC module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> Kent, Atkinson [Page 38] Internet Draft Security Architecture for IP 30 July 1997 SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works **************************************************************************** B.3 Path MTU Discovery As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery. The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) is: ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) .... = ICMP message (hereafter referred to as ICMP PMTU) for IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Hx = host x Rx = router x SGx = security gateway x X* = X supports IPSEC B.3.1 Identifying the Originating Host(s) The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security Kent, Atkinson [Page 39] Internet Draft Security Architecture for IP 30 July 1997 associations, originating hosts, etc. for use in further propagating the PMTU information. In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted. Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)... H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. And suppose H0 sends a data packet to H5 which causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message. Kent, Atkinson [Page 40] Internet Draft Security Architecture for IP 30 July 1997 original after IPSEC ICMP packet processing packet -------- ----------- ------ IP-3 header (S = R1, D = SG1) ICMP header (includes PMTU) IP-2 header IP-2 header (S = SG1, D = SG2) ESP header minimum of 64 bits of ESP hdr (*) IP-1 header IP-1 header TCP header TCP header TCP data TCP data ESP trailer (*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), unknown (32 bits) -- could be the optional Replay counter but one can't be sure. - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits) This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPSEC header (minimum for IPv4), then the 5 original IPSEC selectors will have been lost -- Source and Destination addresses, Next Protocol, Source and Destination ports. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association. The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could: a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one host. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a). Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with a 5-selector Kent, Atkinson [Page 41] Internet Draft Security Architecture for IP 30 July 1997 pointer for storing/updating the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. B.3.2 Calculation of PMTU The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPSEC header by H1 -- ESP or AH transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. The diagram below illustrates several possible combinations of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx = transport mode) Socket 1 ----------------------------------------------- I | n Socket 2 (ESPt/SPI-A) ------------------------------- | t \| e Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r / n Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e t In order to figure out the PMTU for each socket that maps to SPI-E, it will be necessary to have backpointers from SPI-E to each of the 4 paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H. B.3.3 Granularity of Maintaining PMTU Data In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues: a. Integration of IPSEC into the native IP implementation b. Bump-in-the-stack implementations, where IPSEC is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPSEC implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination Kent, Atkinson [Page 42] Internet Draft Security Architecture for IP 30 July 1997 IP addresses, and each communication association may have a different amount of IPSEC header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this. In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them. ================================== | | H1* --- R1 ----- R2 ---- R3 ---- H2* ^ | |.......| If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPSEC implementation in H1 can store/update the PMTU for the associated socket. In case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly ToS, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/ToS will be the subtraction of the largest amount of IPSEC header used for any communication association between a given source and destination. In case (c), there has to be a security gateway to have any IPSEC processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them. ================ | | H1 ---- SG1* --- R --- SG2* ---- H2 ^ | |.......| As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly ToS. So the result may be sub-optimal, since the PMTU for a given SRC/DST/ToS will be the subtraction of the largest amount of IPSEC header used for any communication association between a given source and destination. B.3.4 Per Socket Maintenance of PMTU Data Implementation of the calculation of PMTU (Section B.2.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.2.3) is a local matter. However, a socket- Kent, Atkinson [Page 43] Internet Draft Security Architecture for IP 30 July 1997 based implementation of IPSEC in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPSEC header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. B.3.5 Delivery of PMTU Data to the Transport Layer The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). B.3.6 Aging of PMTU Data In all systems (host or gateway) implementing IPSEC and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) has to be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be Configurable. Kent, Atkinson [Page 44] Internet Draft Security Architecture for IP 30 July 1997 Appendix C - Sequence Space Window Code Example This appendix contains a routine that implements a bitmask check for a 32 packet window. It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) and is intended as an implementation example. Note that this code both checks for a replay and updates the window. Thus the algorithm, as shown, should only be called AFTER the packet has been authenticated. Implementers might wish to consider splitting the code to do the check for replays before computing the ICV. If the packet is not a replay, the code would then compute the ICV, (discard any bad packets), and if the packet is OK, update the window. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap <<= diff; while (diff > 1) bitmap &= ~(1 << --diff); bitmap |= 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1 << diff)) return 0; /* this packet already seen */ bitmap |= (1 << diff); /* mark as seen */ return 1; /* out of order but good */ } char string_buffer[512]; #define STRING_BUFFER_SIZE sizeof(string_buffer) Kent, Atkinson [Page 45] Internet Draft Security Architecture for IP 30 July 1997 int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):0); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu0, bitmap, lastSeq); printf("Input value to test (current):0); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu0, bitmap, lastSeq); } return 0; } Kent, Atkinson [Page 46] Internet Draft Security Architecture for IP 30 July 1997 References [BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, DDN Network Information Center, June 1994. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [Bel95] Steven M. Bellovin, Presentation at IP Security Working Group Meeting, Proceedings of the 32nd Internet Engineering Task Force, March 1995, Internet Engineering Task Force, Danvers, MA. [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996. [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74- 244, The MITRE Corporation, Bedford, MA, May 1973. [CERT95] CA-95:01 [CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & Internet Security, Addison-Wesley, Reading, MA, 1994. [CG96] Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with Replay Prevention", Internet Draft, 1 May 1996. [DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation Specification", Technical Report DDS-2600- 6243-87. [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985. [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987. [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, No. 6, November 1976, pp. 644-654. [DH95] Steve Deering & Bob Hinden, Internet Protocol version 6 Kent, Atkinson [Page 47] Internet Draft Security Architecture for IP 30 July 1997 (IPv6) Specification, RFC-1883, December 1995. [EK96] D. Eastlake III & C. Kaufman, "Domain Name System Protocol Security Extensions", Internet Draft, 30 January 1996. [GM93] J. Galvin & K. McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC- 1446, DDN Network Information Center, April 1993. [HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704, DDN Network Information Center, October 1994. [Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay Prevention Security Transform", Internet Draft, June 1996. [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio [KA97a] Steve Kent, Randall Atkinson, "IP Authentication Header", Internet Draft, ?? 1997. [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft, ?? 1997. [Ken91] Steve Kent, US DoD Security Options for the Internet Protocol, RFC-1108, DDN Network Information Center, November 1991. [Ken93] Steve Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, RFC-1422, DDN Network Information Center, 10 February 1993. [KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication Service (V5), RFC-1510, DDN Network Information Center, 10 September 1993. [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999. Kent, Atkinson [Page 48] Internet Draft Security Architecture for IP 30 July 1997 [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited", ACM Operating Systems Review, Vol. 21, No. 1., 1981. [OG96] Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", Internet Draft, 1 May 1996. [OTA94] US Congress, Office of Technology Assessment, "Information Security & Privacy in Network Environments", OTA-TCT-606, Government Printing Office, Washington, DC, September 1994. [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994. [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, March 1996. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and Zappala, D., "RSVP: A New Resource ReSerVation Protocol", IEEE Network magazine, September 1993. Disclaimer The views and specification expressed in this document 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 design. Kent, Atkinson [Page 49] Internet Draft Security Architecture for IP 30 July 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 50] From owner-ipsec Thu Jul 31 12:44:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23777 for ipsec-outgoing; Thu, 31 Jul 1997 12:43:11 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' 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-doc-roadmap-01.txt Date: Thu, 31 Jul 1997 09:57:30 -0400 Message-ID: <9707310957.aa09300@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 : IP Security Document Roadmap Author(s) : Rodney Thayer and Naganand Doraswamy and R. Glenn Filename : draft-ietf-ipsec-doc-roadmap-01.txt Pages : 10 Date : 1997-07-30 The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and Authentication Algorithm documents are described. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-ipsec-doc-roadmap-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-doc-roadmap-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-doc-roadmap-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: <19970730174124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doc-roadmap-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-ipsec-doc-roadmap-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970730174124.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jul 31 16:47:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25496 for ipsec-outgoing; Thu, 31 Jul 1997 16:44:32 -0400 (EDT) Message-Id: <199707312045.FAA23588@bimota.imada.math.human.nagoya-u.ac.jp> To: ipsec@tis.com Subject: IPv6 Destination options extension header position. From: Koji Imada - je4owb/2 X-Mailer: Mew version 1.54 on Emacs 19.28.3, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 01 Aug 1997 05:43:21 +0900 Sender: owner-ipsec@ex.tis.com Precedence: bulk I have some question about position of IPv6 Destination options extension header. In draft-ietf-ipsec-{auth-header-01,esp-v2-00}.txt, IPv6 Destination options extension header may appear before ah/esp, after ah/esp or both position. When it appears before ah/esp, it's position is after hop-by-hop, routing and fragment header. But in rfc1883 or draft-ietf-ipngwg-ipv6-spec-v2-00.txt, destination option can appear between hop-by-hop option and routing header or after ah/esp. What is the right description? In both document, Destination options header can appear after ah/esp header. This is not ambiguous. But how about position before ah/esp? If there is not routing/fragment header, it has almost same meaning. it will be processed by final destination only. But if there is routing header, it is different. According to rfc1883 or draft-ietf-ipngwg-ipv6-spec-v2-00.txt, destination options header before routing header must be processed by nodes which appear IPv6 destination address field(each node which appear in routing header). In the other hand, destination options header before ah/esp and after hop-by-hop options, (destination options, )routing header and fragment header(in draft-ietf-ipsec-*.txt) will be processed by final destination only. I think both are reasonable(destination options header may be appear 3 times). Because ah/esp related options must be processed before ah/esp processing and only by node which must process ah/esp(final destination for common cases). So it should be noted in both draft or rfc. Any comments? -- Koji Imada - je4owb/2 koji@math.human.nagoya-u.ac.jp From owner-ipsec Thu Jul 31 17:48:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25869 for ipsec-outgoing; Thu, 31 Jul 1997 17:45:13 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707312153.OAA11807@kebe.eng.sun.com> Subject: Re: IPv6 Destination options extension header position. To: koji@math.human.nagoya-u.ac.jp (Koji Imada - je4owb/2) Date: Thu, 31 Jul 1997 14:53:39 -0700 (PDT) Cc: ipsec@tis.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199707312045.FAA23588@bimota.imada.math.human.nagoya-u.ac.jp> from "Koji Imada - je4owb/2" at Aug 1, 97 05:43:21 am 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 > What is the right description? The IPv6 RFC (1883) is the right description. I remember now having a small exchange with someone else about this. I decided not to pursue it because I figured the drawing in the AH draft was intended to show possibilities, not real positioning. Apparently the AH draft is confusing at least one person, and therefore needs to be clarified. > Any comments? "Destination" options (as opposed to hop-by-hop options) appear in TWO places: 1.) Before the routing header, which affects "per-source-route-hop" semantics. 2.) After AH, which affects "receiver-only" semantics. I'm also sending this to the ipng to make sure I'm not forgetting something. I'll show the original picture in the new AH draft, followed by my proposal for a clearer illustration. Here's the original one. Note the slight inaccuracy in destination options placement... > 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 Here's my proposed replacement drawing: AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, frag. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both The above replacment text better illustrates (IMHO) AH placement in an IPv6 datagram than does the current text. Dan From owner-ipsec Thu Jul 31 19:05:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA26362 for ipsec-outgoing; Thu, 31 Jul 1997 19:05:14 -0400 (EDT) Message-Id: <199707312305.TAA26362@portal.ex.tis.com> To: ipsec@tis.com cc: internet-drafts@ietf.org Subject: ID: draft-ietf-ipsec-ipsec-doi-03.txt Date: Thu, 31 Jul 1997 15:25:17 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Network Working Group Derrell Piper INTERNET-DRAFT cisco Systems draft-ietf-ipsec-ipsec-doi-03.txt July 31, 1997 The Internet IP Security Domain of Interpretation for ISAKMP 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 working groups. Note that other groups may also distribute working 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 inappropriate to use Internet Drafts as reference material or to cite them other than as ``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), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. This draft will expire six months from date of issue. 1. Abstract The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. For a description of how the IPSEC DOI fits into the overall IP Security Documentation framework, please see [ROADMAP]. Piper Expires in 6 months [Page 1] INTERNET DRAFT IPSEC DOI July 31, 1997 2. Introduction Within ISAKMP, a Domain of Interpretation is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. They also share a common interpretation of DOI-specific payload data content, including the Security Association and Identification payloads. Overall, ISAKMP places the following requirements on a DOI definition: o define the naming scheme for DOI-specific protocol identifiers o define the interpretation for the Situation field o define the set of applicable security policies o define the syntax for DOI-specific SA Attributes (phase II) o define the syntax for DOI-specific payload contents o define additional mappings or Key Exchange types, if needed The remainder of this document details the instantiation of these requirements for using the IP Security (IPSEC) protocols to provide authentication, integrity, and/or confidentiality for IP packets sent between cooperating host systems and/or firewalls. 3. Terms and Definitions 3.1 Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalized. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY This word or the adjective "OPTIONAL" means that this item is Piper Expires in 6 months [Page 2] INTERNET DRAFT IPSEC DOI July 31, 1997 truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. Piper Expires in 6 months [Page 3] INTERNET DRAFT IPSEC DOI July 31, 1997 4.1 IPSEC Naming Scheme Within ISAKMP, all DOI's must be registered with the IANA in the ``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the Internet IP Security DOI is one (1). Within the IPSEC DOI, all well-known identifiers MUST be registered with the IANA under the Internet IP Security DOI. Unless otherwise noted, all tables within this document refer to IANA Assigned Numbers for the IPSEC DOI. All multi-octet binary values are stored in network byte order. 4.2 IPSEC Situation Definition Within ISAKMP, the Situation provides information that can be used by the responder to make a policy determination about how to process the incoming Security Association request. For the IPSEC DOI, the Situation field is a four (4) octet bitmask with the following values. Situation Value --------- ----- SIT_IDENTITY_ONLY 0x01 SIT_SECRECY 0x02 SIT_INTEGRITY 0x04 All other values are reserved to IANA. 4.2.1 SIT_IDENTITY_ONLY The SIT_IDENTITY_ONLY type specifies that the security association will be identified by source identity information present in an associated Identification Payload. See Section 4.6.2 for a complete description of the various Identification types. All IPSEC DOI implementations MUST support SIT_IDENTITY_ONLY by including an Identification Payload in at least one of the phase I Oakley exchanges ([IO], Section 5) and MUST abort any association setup that does not include an Identification Payload. If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the situation consists only of the 4 octet situation bitmap and does not include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) or any subsequent label information. Conversely, if the initiator supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain Identifier MUST be included in the situation payload. 4.2.2 SIT_SECRECY The SIT_SECRECY type specifies that the security association is being Piper Expires in 6 months [Page 4] INTERNET DRAFT IPSEC DOI July 31, 1997 negotiated in an environment that requires labeled secrecy. If SIT_SECRECY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes a sensitivity level and compartment bitmask. See Section 4.6.1 for a complete description of the Security Association Payload format. If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be set in the Situation bitmap and no secrecy level or category bitmaps shall be included. If a responder does not support SIT_SECRECY, a SITUATION-NOT- SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted. 4.2.3 SIT_INTEGRITY The SIT_INTEGRITY type specifies that the security association is being negotiated in an environment that requires labeled integrity. If SIT_INTEGRITY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes an integrity level and compartment bitmask. If SIT_SECRECY is also in use for the association, the integrity information immediately follows the variable-length secrecy level and categories. See section 4.6.1 for a complete description of the Security Association Payload format. If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST NOT be set in the Situation bitmap and no integrity level or category bitmaps shall be included. If a responder does not support SIT_INTEGRITY, a SITUATION-NOT- SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted. 4.3 IPSEC Security Policy Requirement The IPSEC DOI does not impose specific security policy requirements on any implementation. Host system policy issues are outside of the scope of this document. However, the following sections touch on some of the issues that must be considered when designing an IPSEC DOI host implementation. This section should be considered only informational in nature. 4.3.1 Key Management Issues It is expected that many systems choosing to implement ISAKMP will strive to provide a protected domain of execution for a combined Piper Expires in 6 months [Page 5] INTERNET DRAFT IPSEC DOI July 31, 1997 ISAKMP/Oakley key management daemon. On protected-mode multiuser operating systems, this key management daemon will likely exist as a separate privileged process. In such an environment, a formalized API to introduce keying material into the TCP/IP kernel may be desirable. The PF_KEY API [PFKEY] is an example of one such API that provides an abstracted key management interface. The IP Security architecture does not place any requirements for structure or flow between a host TCP/IP kernel and its key management provider. 4.3.2 Static Keying Issues Host systems that implement static keys, either for use directly by IPSEC, or for authentication purposes (see [IO] Section 5.3), should take steps to protect the static keying material when it is not residing in a protected memory domain or actively in use by the TCP/IP kernel. For example, on a laptop, one might choose to store the static keys in a configuration store that is, itself, encrypted under a private password. Depending on the operating system and utility software installed, it may not be possible to protect the static keys once they've been loaded into the TCP/IP kernel, however they should not be trivially recoverable on initial system startup without having to satisfy some additional form of authentication. 4.3.3 Host Policy Issues It is not realistic to assume that the transition to IPSEC will occur overnight. Host systems must be prepared to implement flexible policy lists that describe which systems they desire to speak securely with and which systems they require speak securely to them. Some notion of proxy firewall addresses may also be required. A minimal approach is probably a static list of IP addresses, network masks, and a security required flag or flags. A more flexible implementation might consist of a list of wildcard DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional firewall address. The wildcard DNS name would be used to match incoming or outgoing IP addresses, the in/out bitmask would be used to determine whether or not security was to be applied and in which direction, and the optional firewall address would be used to indicate whether or not tunnel mode would be needed to talk to the target system though an intermediate firewall. Piper Expires in 6 months [Page 6] INTERNET DRAFT IPSEC DOI July 31, 1997 4.3.4 Certificate Management Host systems implementing a certificate-based authentication scheme will need a mechanism for obtaining and managing a database of certificates. Secure DNS is to be one certificate distribution mechanism, however the pervasive availability of secure DNS zones, in the short term, is doubtful for many reasons. What's far more likely is that hosts will need an ability to import certificates that they acquire through secure, out-of-band mechanisms, as well as an ability to export their own certificates for use by other systems. However, manual certificate management should not be done so as to preclude the ability to introduce dynamic certificate discovery mechanisms and/or protocols as they become available. When an ISAKMP/Oakley exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange. 4.4 IPSEC Assigned Numbers The following sections list the Assigned Numbers for the IPSEC DOI Security Protocol Identifiers, Transform Identifiers, and Security Association Attribute Types. 4.4.1 IPSEC Security Protocol Identifiers The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple security protocol suites within a single negotiation. As a result, the protocol suites listed below form the set of protocols that can be negotiated at the same time. It is a host policy decision as to what protocol suites might be negotiated together. The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC DOI. Protocol ID Value ----------- ----- RESERVED 0 PROTO_ISAKMP 1 PROTO_IPSEC_AH 2 PROTO_IPSEC_ESP 3 PROTO_IPCOMP 4 Piper Expires in 6 months [Page 7] INTERNET DRAFT IPSEC DOI July 31, 1997 The size of this field is one octet. The values 5-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.1.1 PROTO_ISAKMP The PROTO_ISAKMP type specifies message protection required during Phase I of the ISAKMP protocol. The specific protection mechanism used for the IPSEC DOI is described in [IO]. All implementations within the IPSEC DOI MUST support PROTO_ISAKMP. NB: ISAKMP reserves the value one (1) across all DOI definitions. 4.4.1.2 PROTO_IPSEC_AH The PROTO_IPSEC_AH type specifies IP packet authentication. The default AH transform provides data origin authentication, integrity protection, and replay prevention. For export control considerations, confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform. 4.4.1.3 PROTO_IPSEC_ESP The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Authentication, if required, must be provided as part of the ESP transform. The default ESP transform includes data origin authentication, integrity protection, replay prevention, and confidentiality. 4.4.1.4 PROTO_IPCOMP The PROTO_IPCOMP type specifies IP packet compression. 4.4.2 IPSEC ISAKMP Transform Values As part of an ISAKMP Phase I negotiation, the initiator's choice of Key Exchange offerings is made using some host system policy description. The actual selection of Key Exchange mechanism is made using the standard ISAKMP Proposal Payload. The following table lists the defined ISAKMP Phase I Transform Identifiers for the Proposal Payload for the IPSEC DOI. Transform Value --------- ----- RESERVED 0 KEY_OAKLEY 1 KEY_MANUAL 2 KEY_KDC 3 Piper Expires in 6 months [Page 8] INTERNET DRAFT IPSEC DOI July 31, 1997 The size of this field is one octet. The values 4-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.2.1 KEY_OAKLEY The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman key exchange as defined in the [IO] document. All implementations within the IPSEC DOI MUST support KEY_OAKLEY. 4.4.2.2 KEY_MANUAL The KEY_MANUAL type specifies that a shared secret key mechanism is to be used in lieu of a dynamic key mechanism. Specific details of a static key establishment protocol will be described in a future document. 4.4.2.3 KEY_KDC The KEY_KDC type specifies that a secret-key based Key Distribution Center will be used to provide dynamic key exchange through a Kerberos-like ticket protocol. Specific details of a KDC-based key establishment protocol will be described in a future document. 4.4.3 IPSEC AH Transform Values The Authentication Header Protocol (AH) defines one mandatory and several optional transforms used to provide authentication, integrity, and replay detection. The following table lists the defined AH Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 AH_MD5_KPDK 1 AH_MD5 2 AH_SHA 3 The size of this field is one octet. The values 4-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.3.1 AH_MD5_KPDK The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key) described in RFC-1826. This mode MAY be negotiated for compatibility with older implementations. Implementations are not required to support this mode. Piper Expires in 6 months [Page 9] INTERNET DRAFT IPSEC DOI July 31, 1997 4.4.3.2 AH_MD5 The AH_MD5 type specifies a generic AH transform using MD5. The actual protection suite is determined in concert with an associated SA attribute list. A generic MD5 transform is currently undefined. All implementations within the IPSEC DOI MUST support AH_MD5 along with the HMAC(MD5) attribute. This suite is defined as the HMAC- MD5-96 transform described in [HMACMD5]. 4.4.3.3 AH_SHA The AH_SHA type specifies a generic AH transform using SHA-1. The actual protection suite is determined in concert with an associated SA attribute list. A generic SHA transform is currently undefined. All implementations within the IPSEC DOI are strongly encouraged to support AH_SHA along with the HMAC(SHA) attribute. This suite is defined as the HMAC-SHA-1-96 transform described in [HMACSHA]. 4.4.4 IPSEC ESP Transform Identifiers The Encapsulating Security Payload (ESP) defines one mandatory and many 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_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 The size of this field is one octet. The values 10-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.4.1 ESP_DES_IV64 The ESP_DES_IV64 type specifies the DES-CBC transform defined in RFC-1827 and RFC-1829 using a 64-bit IV. This mode MAY be negotiated for compatibility with older implementations. Implementations are Piper Expires in 6 months [Page 10] INTERNET DRAFT IPSEC DOI July 31, 1997 not required to support this mode. 4.4.4.2 ESP_DES The ESP_DES type specifies a generic DES transform using DES-CBC. The actual protection suite is determined in concert with an associated SA attribute list. A generic transform is currently undefined. All implementations within the IPSEC DOI MUST support ESP_DES along with the HMAC(MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5. 4.4.4.3 ESP_3DES The ESP_3DES type specifies a generic triple-DES transform. The actual protection suite is determined in concert with an associated SA attribute list. The generic transform is currently undefined. All implementations within the IPSEC DOI are strongly encourage to support ESP_3DES along with the HMAC(MD5) attribute. This suite is defined as the [3DES] transform, with authentication and integrity provided by HMAC MD5. 4.4.4.4 ESP_RC5 The ESP_RC5 type specifies the RC5 transform defined in [RC5]. 4.4.4.5 ESP_IDEA The ESP_IDEA type specifies the IDEA transform defined in [IDEA]. 4.4.4.6 ESP_CAST The ESP_CAST type specifies the CAST transform defined in [CAST]. 4.4.4.7 ESP_BLOWFISH The ESP_BLOWFISH type specifies the BLOWFISH transform defined in [BLOW]. 4.4.4.8 ESP_3IDEA The ESP_3IDEA type is reserved for triple-IDEA. 4.4.4.9 ESP_DES_IV32 The ESP_DES_IV32 type specifies the DES-CBC transform defined in Piper Expires in 6 months [Page 11] INTERNET DRAFT IPSEC DOI July 31, 1997 RFC-1827 and RFC-1829 using a 32-bit IV. This mode MAY be negotiated for compatibility with older implementations. Implementations are not required to support this mode. 4.4.5 IPSEC IPCOMP Transform Identifiers The IP Compression (IPCOMP) transforms define optional compression algorithms that can be negotiated to provide for IP compression before ESP encryption. The following table lists the defined IPCOMP Transform Identifiers for the ISAKMP Proposal Payload within the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLAT 2 IPCOMP_LZS 3 IPCOMP_V42BIS 4 The size of this field is one octet. The values 5-248 are reserved to IANA. Values 249-255 are reserved for private use. 4.4.5.1 IPCOMP_OUI The IPCOMP_OUI type specifies a proprietary compression transform. The IPCOMP_OUI type must be accompanied by an attribute which further identifies the specific vendor algorithm. 4.4.5.2 IPCOMP_DEFLATE The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate algorithm. 4.4.5.3 IPCOMP_LZS The IPCOMP_LZS type specifies the use of the Stac Electronics LZS algorithm. 4.4.5.4 IPCOMP_V42BIS The IPCOMP_V42BIS type specifies the use of V42bis compression. 4.5 IPSEC Security Association Attributes The following SA attribute definitions are used in phase II of an ISAKMP/Oakley negotiation. Attribute types can be either Basic (B) or Variable-Length (V). Encoding of these attributes is defined in Piper Expires in 6 months [Page 12] INTERNET DRAFT IPSEC DOI July 31, 1997 the base ISAKMP specification. Attribute Types class value type ------------------------------------------------- SA Life Type 1 B SA Life Duration 2 B/V Group Description 3 B Encapsulation Mode 4 B HMAC Algorithm 5 B Key Length 6 B Key Rounds 7 B Compress Dictionary Size 8 B Compress Private Algorithm 9 B/V The size of this field is two octets, with the high bit reserved for the ISAKMP B/V encoding. The values 10-32000 are reserved to IANA. Values 32001-32767 are for experimental use. Class Values 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. The life type values are: RESERVED 0 seconds 1 kilobytes 2 Values 3-61439 are reserved to IANA. Values 61440-65535 are for experimental use. For a given Life Type, the value of the Life Duration attribute defines the actual length of the component lifetime -- either a number of seconds, or a number of Kbytes that can be protected. When the initiator and responder offer different SA life times, the shortest duration offered MUST be chosen. If unspecified, the default value shall be assumed to be 28800 seconds (8 hours). Group Description RESERVED 0 Piper Expires in 6 months [Page 13] INTERNET DRAFT IPSEC DOI July 31, 1997 default group 1 Values 2-61439 are reserved to IANA. Values 61440-65535 are for private use among mutually consenting parties. This attribute is used for PFS Phase II negotiations. If unspecified, the default value shall be assumed to be the default Oakley group ([IO], Section 5.7.1). Encapsulation Mode RESERVED 0 Tunnel 1 Transport 2 Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use among mutually consenting parties. If unspecified, the default value shall be assumed to be unspecified (host-dependent). HMAC Algorithm RESERVED 0 MD5 1 SHA-1 2 Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use among mutually consenting parties. There is no default value for HMAC Algorithm, as it must be specified to correctly identify the applicable AH or ESP transform. Key Length RESERVED 0 There is no default value for Key Length, as it must be specified for transforms using ciphers with variable key lengths. Key Rounds RESERVED 0 There is no default value for Key Rounds, as it must be specified for transforms using ciphers with varying numbers of rounds. Compression Dictionary Size Piper Expires in 6 months [Page 14] INTERNET DRAFT IPSEC DOI July 31, 1997 RESERVED 0 Specifies the log2 maximum size of the dictionary. There is no default value for dictionary size. Compression Private Algorithm Specifies a private vendor compression algorithm. The first three (3) octets must be an IEEE assigned company_id (OUI). The next octet may be a vendor specific compression subtype, followed by zero or more octets of vendor data. 4.5.1 Required Attribute Support To ensure basic interoperability, all implementations MUST be prepared to negotiate all of the following attributes. SA Life Type SA Duration HMAC Algorithm 4.5.2 Attribute List Parsing Requirement To allow for flexible semantics, the IPSEC DOI requires that a conforming ISAKMP implementation MUST correctly parse an attribute list that contains multiple instances of the same attribute class, so long as the different attribute entries do not conflict with one another. To see why this is important, the following example shows the binary encoding of a four entry attribute list that specifies an Encryption Key Lifetime of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a complete description of the attribute encoding format.) Attribute #1: 0x80030001 (AF = 1, type = Enc Key Life Type, value = seconds) Attribute #2: 0x00040004 (AF = 0, type = Enc Key Duration, length = 4 bytes) 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) Attribute #3: 0x80030002 (AF = 1, type = Enc Key Life Type, value = KB) Attribute #4: 0x00040004 (AF = 0, type = Enc Key Duration, length = 4 bytes) Piper Expires in 6 months [Page 15] INTERNET DRAFT IPSEC DOI July 31, 1997 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted. 4.5.3 Attribute Negotiation If an implementation receives a defined IPSEC DOI attribute (or attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted, unless the attribute value is in the reserved range. If an implementation receives an attribute value in the reserved range, an implementation MAY chose to continue based on local policy. 4.6 IPSEC Payload Content The following sections describe those ISAKMP payloads whose data representations are dependent on the applicable DOI. 4.6.1 Security Association Payload The following diagram illustrates the content of the Security Association Payload for the IPSEC DOI. See Section 4.2 for a description of the Situation bitmap. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (IPSEC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation (bitmap) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Labeled Domain Identifier ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Secrecy Length (in octets) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Secrecy Level ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Secrecy Cat. Length (in bits) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Secrecy Category Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Integrity Length (in octets) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Level ~ Piper Expires in 6 months [Page 16] INTERNET DRAFT IPSEC DOI July 31, 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Integ. Cat. Length (in bits) ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Category Bitmap ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Security Association Payload Format The Security Association Payload is defined as follows: o Next Payload (2 octets) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0). o RESERVED (1 octet) - Unused, must be zero (0). o Payload Length (2 octets) - Length, in octets, of the current payload, including the generic header. o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, which has been assigned the value one (1). o Situation (4 octets) - Bitmask used to interpret the remainder of the Security Association Payload. See Section 4.2 for a complete list of values. o Labeled Domain Identifier (4 octets) - IANA Assigned Number used to interpret the Secrecy and Integrity information. o Secrecy Length (2 octets) - Specifies the length, in octets, of the secrecy level identifier. o RESERVED (2 octets) - Unused, must be zero (0). o Secrecy Category Length (2 octets) - Specifies the length, in bits, of the secrecy category (compartment) bitmap, excluding pad bits. o RESERVED (2 octets) - Unused, must be zero (0). o Secrecy Category Bitmap (variable length) - A bitmap used to designate secrecy categories (compartments) that are required. The bitmap MUST be padded with zero (0) to the next 32-bit boundry. o Integrity Length (2 octets) - Specifies the length, in octets, of the integrity level identifier. Piper Expires in 6 months [Page 17] INTERNET DRAFT IPSEC DOI July 31, 1997 o RESERVED (2 octets) - Unused, must be zero (0). o Integrity Category Length (2 octets) - Specifies the length, in bits, of the integrity category (compartment) bitmap, excluding pad bits. o RESERVED (2 octets) - Unused, must be zero (0). o Integrity Category Bitmap (variable length) - A bitmap used to designate integrity categories (compartments) that are required. The bitmap MUST be padded with zero (0) to the next 32-bit boundry. 4.6.1.1 Labeled Domain Identifier Values The following table lists the assigned values for the Labeled Domain Identifier field contained in the Situation field of the Security Association Payload. Domain Value ------- ----- RESERVED 0 The values 1-0x7fffffff are reserved to IANA. Values 0x8000000- 0xffffffff are reserved for private use. 4.6.2 Identification Payload Content The Identification Payload is used to identify the initiator of the Security Association. The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association. For example, a host might choose to require authentication and integrity without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (ESP) from another range of IP addresses. The Identification Payload provides information that can be used by the responder to make this decision. The following diagram illustrates the content of the Identification Payload. 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ Piper Expires in 6 months [Page 18] INTERNET DRAFT IPSEC DOI July 31, 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Identification Payload Format The Identification Payload fields are defined as follows: o Next Payload (2 octets) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0). o RESERVED (1 octet) - Unused, must be zero (0). o Payload Length (2 octets) - Length, in octets, of the identification data, including the generic header. o Identification Type (1 octet) - Value describing the identity information found in the Identification Data field. o Protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g. UDP/TCP). A value of zero means that the Protocol ID field should be ignored. o Port (2 octets) - Value specifying an associated port. A value of zero means that the Port field should be ignored. o Identification Data (variable length) - Value, as indicated by the Identification Type. 4.6.2.1 Identification Type Values The following table lists the assigned values for the Identification Type field found in the Identification Payload. ID Type Value ------- ----- RESERVED 0 ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 The size of this field is one octet. The values 11-248 are reserved Piper Expires in 6 months [Page 19] INTERNET DRAFT IPSEC DOI July 31, 1997 to IANA. Values 249-255 are reserved for private use. For types where the ID entity is variable length, the size of the ID entity is computed from size in the ID payload header. 4.6.2.2 ID_IPV4_ADDR The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 4.6.2.3 ID_FQDN The ID_FQDN type specifies a fully-qualified domain name string. An example of a ID_FQDN is, "foo.bar.com". The string should not contain any terminators. 4.6.2.4 ID_USER_FQDN The ID_USER_FQDN type specifies a fully-qualified username string, An example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should not contain any terminators. 4.6.2.5 ID_IPV4_ADDR_SUBNET The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. 4.6.2.6 ID_IPV6_ADDR The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address. 4.6.2.7 ID_IPV6_ADDR_SUBNET The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is an IPv6 address. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit. 4.6.2.8 ID_IPV4_ADDR_RANGE The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two Piper Expires in 6 months [Page 20] INTERNET DRAFT IPSEC DOI July 31, 1997 specified addresses are considered to be within the list. 4.6.2.9 ID_IPV6_ADDR_RANGE The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 4.6.2.10 ID_DER_ASN1_DN The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501] of the principal whose certificates are being exchanged to establish the SA. 4.6.2.11 ID_DER_ASN1_GN The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 X.500 GeneralName [X.509] of the principal whose certificates are being exchanged to establish the SA. 4.7 IPSEC Key Exchange Requirements The IPSEC DOI introduces no additional Key Exchange types. 5. Security Considerations This entire draft pertains to a negotiated key management protocol, combining Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), which negotiates and derives keying material for security associations in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references. Acknowledgements This document is derived, in part, from previous works by Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, and Dave Carrel. Matt Thomas, Roy Pereira, and Greg Carter also contributed suggestions and, in many cases, text. References [AH] Kent, S., Atkinson, R., "IP Authentication Header," draft-ietf- ipsec-auth-05.txt. [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload Piper Expires in 6 months [Page 21] INTERNET DRAFT IPSEC DOI July 31, 1997 (ESP)," draft-ietf-ipsec-esp-04.txt. [BLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an Explicit IV," draft-ietf-ipsec-ciph-blowfish-cbc-00.txt. [CAST] Pereira, R., Carter, G., "The ESP CAST128-CBC Algorithm," draft-ietf-ipsec-ciph-cast128-cbc-00.txt. [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-00.txt. [3DES] Pereira, R., Thayer, R., "The ESP 3DES-CBC Algorithm Using an Explicit IV," draft-ietf-ipsec-ciph-3des-expiv-00.txt. [HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5-96 IP Authentication with Replay Prevention," draft-ietf-ipsec-ah-hmac-md5-96-00.txt. [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA-1-96 IP Authentication with Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt. [IDEA] Adams, R., "The ESP IDEA-CBC Algorithm Using Explicit IV," draft-ietf-ipsec-ciph-idea-cbc-00.txt. [IO] Harkins, D., Carrel, D., "The Resolution of ISAKMP with Oakley," draft-ietf-ipsec-isakmp-oakley-04.txt. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-07.{ps,txt}. [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-ietf-ipsec-oakley-01.txt. [ROADMAP] Thayer, R., Doraswamy, N., Glenn, R., "IP Security Documentation Roadmap," draft-ietf-ipsec-doc-roadmap-00.txt. [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key Management API, Version 2", draft-mcdonald-pf-key-v2-03.txt. [RC5] Pereira, R., Baldwin, R., "The ESP RC5-CBC Transform," draft- ietf-ipsec-ciph-rc5-cbc-00.txt. [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993. [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", Piper Expires in 6 months [Page 22] INTERNET DRAFT IPSEC DOI July 31, 1997 CCITT/ITU Recommendation X.509, 1993. Author's Address: Derrell Piper cisco Systems 101 Cooper St. Santa Cruz, California, 95060 United States of America +1 408 457-5384 Piper Expires in 6 months [Page 23]