From owner-ipsec Sun Dec 1 19:41:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA20441 for ipsec-outgoing; Sun, 1 Dec 1996 19:34:34 -0500 (EST) Message-Id: <199612020037.QAA07179@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pau@watson.ibm.com Cc: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: Your message of "Wed, 27 Nov 1996 15:53:29 EST." <9611272053.AA22380@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 16:37:41 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen wrote: > I have a question triggered by the discussion : > > If two firewalls (gateways), IDii and IDir, did a successful ISAKMP > phase-II proxy negotiation for IDui and IDur. Then, which one is the > right usage of the SA resulting from the negotiation : > > 1. The SA is shared between IDii and IDir (the gateways), and IDii > IDir are performing IPSEC protection on traffic between IDui and > IDur. In this case, IDui and IDur are unware of the IPSEC > protection. > > 2. The SA is shared between IDui and IDur and IDui and IDur perform > IPSEC by themselves. IDii and IDir (the gateways) become more or less > (IPSEC) transparent. Number one is the correct usage. Dan. From owner-ipsec Mon Dec 2 07:00:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA20881 for ipsec-outgoing; Mon, 2 Dec 1996 06:58:37 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199611271802.NAA29680@carp.morningstar.com> References: <96Nov26.191251est.30786-1@janus.border.com> <9610258489.AA848977264@netx.nei.com> <199611261929.OAA01715@thunk.orchard.medford.ma.us> <199611262230.RAA27739@carp.morningstar.com> <96Nov26.191251est.30786-1@janus.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 1 Dec 1996 20:46:43 -0500 To: ipsec@tis.com From: Stephen Kent Subject: Re: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, A general problem arises with the use of AH at gateways. AH is nominally a "transport" mode security protocol, using the terminlogy adopted for ESP in the IPSEC context. In this mode, AH cannot be used unambiguously by a pair of firewalls, because it conflicts with possible use of AH by subscriber hosts served by these firewalls. Since the choice of SPIs is totrally within the purview of the receiving systems, the firewalls have no way to control which SPIs are selected by hosts served by them. So, irrespective of the other points argued by contributors to this debate, the fundamental problem here is the potential conflict between end systems and intermediate system use of the same header and SPIs. One can address this problem by tunneling between the firewalls, and using AH in the exterior IP header. There is a very, very brief note on such tunneling in the AH spec that Ran published a while ago. It is mostly a cautionary note aimed at other concerns, so it does not really alert the reader to this aspect of the problem. One also can achieve a similar (though not identical) capability by using ESP in tunnel mode, but NOT electing to perform encryption. Since ESP is being revised to be general enough to NOT requre encryption, this would address the export or import concerns cited earlier. Also, I agree with several of the observations about source address filtering. This too is an area where we need agreement of what a compliant implementation supports. I tend to favor a receiving host or gateways checking the source IP address against the (possibly singleton) set of addresses that are associated with the SA. As we define different granularities for selecting traffoc to map to a single SA selector, it seems appropriate to be able to verify that the received traffic is consistent with the definitions established during SA establishment. If this technlogy is widely used, it will not be appropriate to claim that any source with which one establishes an IPSEC-secured connection will be "trusted." They will merely be well identified in most cases. This has been a useful discussion threat and it points out the need to define required, and permitted, configurations for AH and ESP in hosts and security gatewayas, as well as other processing requirements for compliant implementations. I don't think we included this detail in the recent revisions of the RFCs that have been completed, so we will need to go back and add this. I look forward to a discussion of this topic of appropriate combinations of AH and ESP atunneling in San Jose. Steve From owner-ipsec Mon Dec 2 07:53:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20954 for ipsec-outgoing; Mon, 2 Dec 1996 07:52:36 -0500 (EST) Date: Thu, 28 Nov 96 15:31:05 GMT From: "William Allen Simpson" Message-ID: <5515.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "C. Harald Koch" > AH_1828 1 > AH_HMAC_MD5_REPLAY 2 > AH_MHAC_SHA_REPLAY 3 > > I object to the use of RFC numbers in the name of the transform; it's > either meaningless or obscure, depending on who you ask. AH_MD5 would be > better than AH_1828. > Personally, I was using AH_MD5_KP, that is, keyed with padding. For a more explict set of letters, I would suggest AH_MD5_KPDK, for Key_Pad_Data_Key. Could we agree to reverse the others to AH_MD5_HMAC_REPLAY and AH_SHA1_HMAC_REPLAY, as more descriptive and intuitive, and matching the term ordering of ESP_DES_CBC_HMAC_REPLAY? > The "AH_HMAC_MD5" transform is missing from the list. While this transform > never became an RFC, it is in use by several vendors, and so needs an > identifier for proper interoperability. (Yes, it's a proper subset of > AH_HMAC_MD5_REPLAY, But to support historical implementations, I think it > needs to be kept separate. I'm willing to negotiate on this one :-) > I agree. Identifiers should be assigned as needed, to distinguish even past and future proprietary transforms. > RESERVED 0 > ESP_1829_TRANSPORT 1 > ESP_1829_TUNNEL 2 > ESP_DES_CBC_HMAC_REPLAY 3 > > Again, I object to the use of RFC numbers in the name; IMHO, these should be > "ESP_DES_CBC_TRANSPORT" and "ESP_DES_CBC_TUNNEL". (And I though the > "transport" v.s. "tunnel" distinction was an RFC 1827 thing; if so, > shouldn't we be consistent here?) > > ESP_3DES_CBC is missing (RFC 1851). Again, there are vendors using this > already; an ID and number are required for interoperability. > Again, I agree. However, I'd suggest ESP_1DES_CBC_TRANSPORT, etc., to more easily distinguish it from 3DES in the eyes of the operator. These things have a tendency to show up in the configuration menus. ;-) 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 Dec 2 08:20:22 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA21249 for ipsec-outgoing; Mon, 2 Dec 1996 08:19:35 -0500 (EST) Message-Id: <199612021319.IAA21249@portal.ex.tis.com> From: Kurt Stammberger To: "'cat-ietf@mit.edu'" , "'e-payment@bellcore.com'" , "'firewalls@greatcircle.com'" , "'ids@uow.edu.au'" , "'ietf-otp@bellcore.com'" , "'ietf-pkix@tandem.com'" To: "'ietf-tls@w3.org'" , "'ietf@cnri.reston.va.us'" , "'ipsec@ans.net'" , "'pem-dev@tis.com'" , "'psrg@isi.edu'" , "'sndss-authors@isi.edu'" To: "'sndss-chairs@tis.com'" , "'spki@c2.net'" , "'virus-l@lehigh.edu'" , "'www-buyinfo@allegra.att.com'" , "'www-security@ns2.rutgers.edu'" , "'David M. Balenson'" Subject: ANNOUNCEMENT: 1997 RSA Data Security Conference Date: Sun, 1 Dec 1996 18:38:08 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk 28-31 January, 1997 NOB HILL, SAN FRANCISCO 1997 marks RSA's fifteenth anniversary and our sixth annual conference. Two days of general sessions and two days of classes will provide over 100 different classes to choose from, with separate tracks for mathematicians and cryptographers, developers, industry analysts and business people. We invite you to join us. Find out more information, view the class syllabi and register online at http://www.rsa.com Thanks Kurt Stammberger RSADSI > From owner-ipsec Mon Dec 2 10:04:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22062 for ipsec-outgoing; Mon, 2 Dec 1996 09:59:44 -0500 (EST) Date: Mon, 2 Dec 1996 10:01:42 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199612021501.KAA18888@earth.hpc.org> To: kent@bbn.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199612021214.FAA13018@baskerville.CS.Arizona.EDU> Subject: Re: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk > So, irrespective of the other points argued by contributors to this > debate, the fundamental problem here is the potential conflict between end > systems and intermediate system use of the same header and SPIs. But this potential conflict is not necessarily fatal, is it? Assuming cooperating firewalls, the conflict can exist and be irrelevant. The firewalls unwrap outer headers according to their notions of the SA mappings, and the end hosts unwrap inner headers according to their notions. Conflicts are invisible as long as the firewalls are in place. BTW, does anyone run multiple firewalls and try to keep the databases in synch? Hilarie From owner-ipsec Mon Dec 2 10:49:00 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22209 for ipsec-outgoing; Mon, 2 Dec 1996 10:48:47 -0500 (EST) Date: Mon, 02 Dec 1996 09:49:52 -0600 From: Matt Crawford Subject: Re: ANNOUNCEMENT: 1997 RSA Data Security Conference In-reply-to: "01 Dec 1996 18:38:08 PST." To: ipsec@tis.com Message-id: <199612021549.JAA21385@gungnir.fnal.gov> Content-transfer-encoding: 7BIT 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{ 28-31 January, 1997 NOB HILL, SAN FRANCISCO > 1997 marks RSA's fifteenth anniversary ... The seventeenth anniversary will be much more significant. From owner-ipsec Mon Dec 2 11:23:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22243 for ipsec-outgoing; Mon, 2 Dec 1996 11:21:15 -0500 (EST) Date: Mon, 02 Dec 96 09:55:58 EST From: "Whelan, Bill" Message-Id: <9611028495.AA849549400@netx.nei.com> To: ipsec@tis.com, Stephen Kent Subject: Re[2]: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, >AH is >nominally a "transport" mode security protocol, using the terminlogy >adopted for ESP in the IPSEC context. In this mode, AH cannot be >used unambiguously by a pair of firewalls, because it conflicts with >possible use of AH by subscriber hosts served by these firewalls. Thanks, this ambiguity is the heart of my original question. >One can address this problem by tunneling between the firewalls, >and using AH in the exterior IP header. I agree - AH with ESP on a secure gateway seems pretty unambiguous. >One also can achieve a similar (though not identical) capability by >using ESP in tunnel mode, but NOT electing to perform encryption. Since >ESP is being revised to be general enough to NOT requre encryption, this >would address the export or import concerns cited earlier. Hmm, this might be a solution, but it seems somewhat expensive. Would all host systems providing AH need to provide ESP to handle the possibility they are communicating through a gateway? >Steve Bill From owner-ipsec Mon Dec 2 11:56:23 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22303 for ipsec-outgoing; Mon, 2 Dec 1996 11:55:44 -0500 (EST) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9612021657.AA01437@katahdin.columbia.sparta.com> Subject: IPSEC mtgs at IETF? To: ipsec@tis.com Date: Mon, 2 Dec 1996 11:57:50 -0500 (EST) Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I just checked the latest IETF draft agenda (as of 11/27) and I only see one IPSEC session scheduled (Tue 12/10 @ 1530). Is this really the case? Howie -- ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| From owner-ipsec Mon Dec 2 13:35:12 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22463 for ipsec-outgoing; Mon, 2 Dec 1996 13:32:59 -0500 (EST) Message-Id: <199612021829.KAA09616@mailsun3-fddi.us.oracle.com> Date: 02 Dec 96 10:23:21 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Agenda MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.25) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk There will be two IPSEC sessions at the December IETF meeting. The first session will cover Key Management and the second will cover the ESP, AH and Architecture documents. I'd like to post a detailed agenda tommorrow. If you are planning to present, or would like to present please send me (palamber@us.oracle.com) a note asap. Include your name, subject, requested length of presentation and the name of any related Internet Drafts. Be sure to include "IPSEC Agenda" in the subject line. As always, preference for presentations will be given to editors of working documents. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Mon Dec 2 14:00:02 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22520 for ipsec-outgoing; Mon, 2 Dec 1996 13:59:32 -0500 (EST) Date: Mon, 02 Dec 96 12:43:17 EST From: "Whelan, Bill" Message-Id: <9611028495.AA849563882@netx.nei.com> To: kent@bbn.com, ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re[2]: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk . . . >But this potential conflict is not necessarily fatal, is it? Assuming >cooperating firewalls, the conflict can exist and be irrelevant. The >firewalls unwrap outer headers according to their notions of the SA >mappings, and the end hosts unwrap inner headers according to their >notions. Conflicts are invisible as long as the firewalls are in >place. Outer headers and inner headers? Per RFC1826, the Authentication Header sits between the IP header and the upper layer protocol. It appears the same whether it's inserted by the host system or the gateway. >Hilarie Bill From owner-ipsec Mon Dec 2 16:25:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22706 for ipsec-outgoing; Mon, 2 Dec 1996 16:21:41 -0500 (EST) Message-Id: <199612022123.QAA00683@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "Whelan, Bill" Cc: kent@bbn.com, ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com Subject: Re: Re[2]: AH (without ESP) on a secure gateway In-Reply-To: bwhelan's message of Mon, 02 Dec 1996 12:43:17 -0500. <9611028495.AA849563882@netx.nei.com> Date: Mon, 02 Dec 1996 16:23:37 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > >But this potential conflict is not necessarily fatal, is it? Assuming > >cooperating firewalls, the conflict can exist and be irrelevant. The > >firewalls unwrap outer headers according to their notions of the SA > >mappings, and the end hosts unwrap inner headers according to their > >notions. Conflicts are invisible as long as the firewalls are in > >place. > > Outer headers and inner headers? Per RFC1826, the Authentication Header > sits between the IP header and the upper layer protocol. It appears the > same whether it's inserted by the host system or the gateway. Hmm. Which "protocol tower" are we talking about, anyhow? IP[H1->H2],AH[R1->R2],... or IP[R1->R2],AH[R1->R2],IP[H1->H2],... (R1,R2 are routers, H1,H2 are hosts; the problem is only interesting if we assume H2 != R2). The latter case has "outer headers" and "inner headers". I can see ways of making the former case "work" when H2 doesn't do AH, but if H2 does, you have to worry about SPI collisions between the ones assigned by H2 and the ones assigned by R2.. - Bill From owner-ipsec Mon Dec 2 17:32:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22802 for ipsec-outgoing; Mon, 2 Dec 1996 17:29:15 -0500 (EST) Date: Mon, 02 Dec 96 17:27:43 EST From: "Whelan, Bill" Message-Id: <9611028495.AA849576552@netx.nei.com> To: Bill Sommerfeld Cc: kent@bbn.com, ho@earth.hpc.org, ipsec@tis.com Subject: Re[4]: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk >Hmm. Which "protocol tower" are we talking about, anyhow? > IP[H1->H2],AH[R1->R2],... >or > IP[R1->R2],AH[R1->R2],IP[H1->H2],... >(R1,R2 are routers, H1,H2 are hosts; the problem is only interesting >if we assume H2 != R2). Well I'm not sure I understand the notation (AH defined in RFC 1826 doesn't have source/destination addresses), but I was thinking of the former case. OOPS, I just noticed there is an internet draft more recent than RFC 1826. I'll go over this to see if I need to take anything back(:-(). >The latter case has "outer headers" and "inner headers". Unless I'm really confused, the latter case is not even provided for in the specifications... Or are you saying that security gateways which provide AH MUST implement some type of IP (ESP or other) tunneling? I don't see that required by the documents. >I can see ways of making the former case "work" when H2 doesn't do >AH, but if H2 does, you have to worry about SPI collisions between >the ones assigned by H2 and the ones assigned by R2.. > - Bill Bill W. From owner-ipsec Mon Dec 2 18:08:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA22859 for ipsec-outgoing; Mon, 2 Dec 1996 18:08:19 -0500 (EST) Message-Id: <199612022310.SAA00742@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "Whelan, Bill" Cc: kent@bbn.com, ho@earth.hpc.org, ipsec@tis.com Subject: Re: Re[4]: AH (without ESP) on a secure gateway In-Reply-To: bwhelan's message of Mon, 02 Dec 1996 17:27:43 -0500. <9611028495.AA849576552@netx.nei.com> Date: Mon, 02 Dec 1996 18:10:28 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Well I'm not sure I understand the notation (AH defined in RFC 1826 > doesn't have source/destination addresses), but I was thinking of the > former case. What I meant by "AH[x->y]" was AH using an SA or SPI from x to y.. In other words, x and y know the SA's key; y allocated the SPI, and is prepared to receive traffic authenticated using the key. Does that make sense? - Bill From owner-ipsec Mon Dec 2 18:19:29 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA22872 for ipsec-outgoing; Mon, 2 Dec 1996 18:19:19 -0500 (EST) Date: Mon, 2 Dec 1996 15:21:40 -0800 Message-Id: <199612022321.PAA04467@gump.eng.ascend.com> From: Karl Fox To: "Whelan, Bill" Cc: Bill Sommerfeld , kent@bbn.com, ho@earth.hpc.org, ipsec@tis.com Subject: Re[4]: AH (without ESP) on a secure gateway In-Reply-To: <9611028495.AA849576552@netx.nei.com> References: <9611028495.AA849576552@netx.nei.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Whelan writes: > >Hmm. Which "protocol tower" are we talking about, anyhow? > > > IP[H1->H2],AH[R1->R2],... > > >or > > > IP[R1->R2],AH[R1->R2],IP[H1->H2],... > > >(R1,R2 are routers, H1,H2 are hosts; the problem is only interesting > >if we assume H2 != R2). ... > Unless I'm really confused, the latter case is not even provided for in the > specifications... I certainly hope the latter case is legal, because it's used by quite a number of encrypting firewalls. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Mon Dec 2 18:36:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA22902 for ipsec-outgoing; Mon, 2 Dec 1996 18:34:19 -0500 (EST) Date: Mon, 02 Dec 96 18:32:55 EST From: "Whelan, Bill" Message-Id: <9611028495.AA849580455@netx.nei.com> To: Karl Fox Cc: sommerfeld@apollo.hp.com, kent@bbn.com, ho@earth.hpc.org, ipsec@tis.com Subject: Re[5]: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk >Bill Whelan writes: >> >Hmm. Which "protocol tower" are we talking about, anyhow? > >> > IP[H1->H2],AH[R1->R2],... >> >> >or >> >> > IP[R1->R2],AH[R1->R2],IP[H1->H2],... > >> >(R1,R2 are routers, H1,H2 are hosts; the problem is only interesting > >>if we assume H2 != R2). >... >> Unless I'm really confused, the latter case is not even provided for in the >> specifications... >I certainly hope the latter case is legal, because it's used by quite a >number of encrypting firewalls. Oh, I am quite certain it is legal. What I'm wondering is whether it is REQUIRED (two very different things). From some of the discussion I've seen in the last week, this appears to be an assumed requirement. I just don't see it REQUIRED by the IPSEC documents. >-- >Karl Fox, servant of God, employee of Ascend Communications >3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Bill From owner-ipsec Mon Dec 2 19:03:00 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA22916 for ipsec-outgoing; Mon, 2 Dec 1996 19:02:21 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199612021501.KAA18888@earth.hpc.org> References: Yourmessage <199612021214.FAA13018@baskerville.CS.Arizona.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Dec 1996 18:56:39 -0500 To: ho@earth.hpc.org (Hilarie Orman) From: Stephen Kent Subject: Re: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, I think the conflict for "transport" use of AH is fatal. Consider the following example: - firewalls A and B use AH for protection between them - all traffic from A is AH protected using a single SA - host A.1 (behind firewall A) establishes an SA to B.1 (behind firewall B) and this SA is also an AH SA - host B.1 chooses the same SPI for the traffic from A.1 to B.1 that firewall B chose for traffic from A to B If A applies a second AH, it would look the same as the original AH used by A.1 and thus there would be an ambiguity, right? I think that trying to fix this through the establishment of conventions for order of interpretation is not a good idea. There may be other problems from trying to do nesting of non-tunnel mode AH, that have not occurred to me yet. Steve From owner-ipsec Mon Dec 2 22:26:12 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA23134 for ipsec-outgoing; Mon, 2 Dec 1996 22:22:58 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <9611028495.AA849549400@netx.nei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Dec 1996 21:20:17 -0500 To: "Whelan, Bill" From: Stephen Kent Subject: Re[2]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, I have assumed that hosts would implement both AH and ESP, not just the former or the latter. Since ESP no longer implies the use of encryption, i.e., it may be used just for authentication, the question of export is still open in principle. The real issue is what set of algorithms is supported by an ESP implementation, not whether the protocol, per se, could be used for encryption. If we choose to define a compliant subset implementation for export, which has not been the mood of the WG so far, one could explicitly address the export issue and make ESP subset implementations just as exportable as AH implementations. Steve From owner-ipsec Mon Dec 2 22:26:16 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA23133 for ipsec-outgoing; Mon, 2 Dec 1996 22:22:58 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199612021501.KAA18888@earth.hpc.org> References: Yourmessage <199612021214.FAA13018@baskerville.CS.Arizona.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Dec 1996 21:25:04 -0500 To: ho@earth.hpc.org (Hilarie Orman) From: Stephen Kent Subject: Re: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, Another thought on multiple instances of AH in a single packet. In the current spec, the inclusion of another header would violate the positioning requirement, which calls for AH (as an option in IPv4) to come directly after the IP header. The "second" AH option would not be directly after the header; it would be after the first AH option. Hence I had never envision multiple AH options/payloads as being compliant. Also, note that the computation of the AH integrity check value is complicated by the need to consider some header fields as zero during the computation. The ESP computation, in a tunnel mode context, would be simplier and faster, making it more attractive for a firewall. Steve From owner-ipsec Mon Dec 2 22:34:02 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA23158 for ipsec-outgoing; Mon, 2 Dec 1996 22:33:55 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9611028495.AA849580455@netx.nei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Dec 1996 22:37:30 -0500 To: "Whelan, Bill" From: Stephen Kent Subject: Re[5]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, I agree that the IP-AH-IP configuration is "legal" and the question, as you mentioned, is whether it is required. Our rewrite of the architecture, ESP and AH documents (which have not been distributed yet) addresses these questions with some proposals, but the WG as a whole needs to consider these minimum essential requirements questions. The recently revised architecture I-D has only a small number of my proposed changes in it, but it does broach the subject of what a compliant AH or ESP implementation must support at either a host or gateway. It's not complete, though. Steve From owner-ipsec Mon Dec 2 23:30:56 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA23184 for ipsec-outgoing; Mon, 2 Dec 1996 23:29:56 -0500 (EST) Message-Id: <199612030431.XAA25585@amaterasu.sandelman.ottawa.on.ca> To: Stephen Kent CC: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-reply-to: Your message of "Mon, 02 Dec 1996 18:56:39 EST." Date: Mon, 02 Dec 1996 23:31:16 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Okay, I had to draw a diagram to parse what you said, which means that I might not have understood it: [I'll pick actual SPI's here] Scenario: A.1 <-----A--------------------B-----------> B.1 Kent> - firewalls A and B use AH for protection between them This must be in tunnel mode. There is no other option. While they might have reasons to authentication packets directly in a network address translation case (application layer firewalls for instance, remember Bob Moskovitz's challenge) that is involved layers above IP. Kent> - all traffic from A is AH protected using a single SA (i) A--------SPI=257---->B Kent> - host A.1 (behind firewall A) establishes an SA to B.1 (behind Kent> firewall B) and this SA is also an AH SA A B (ii) A.1 ---------------SPI=x------------------> B.1 Kent> - host B.1 chooses the same SPI for the traffic from A.1 to B.1 that Kent> firewall B chose for traffic from A to B Let x=257. So the issue is what does firewall B do when it receives a packet for with SPI=257. Here are some packets (e.g. DNS requests in UDP) 1. [IP src=A.1, dst=B.1][AH SPI=257 [UDP [DNS]]] 2. [IP src=A, dst=B][AH SPI=257 [IP src=A.1, dst=B.1] [UDP [DNS]]] 3. [IP src=A, dst=B][AH SPI=257 [IP src=A.1, dst=B.1] [AH SPI=257 UDP [DNS]]] 4. [IP src=A.1, dst=B.1] [AH SPI=257 [AH SPI=257 UDP [DNS]]] Several observations: a. SPI's are index by destination address. Firewall B can notice that case #1 is not addressed to it. Firewalls with transparency concepts (BlackHole, Eagle 4.0, BorderWare, ???) will have to be aware of these things. b. Case #4 was decided to be illegal some months ago. c. Why would firewall B let packets of type #1 through? Who is A.1? How did B.1 authorize such a packet? This is the question that I addressed during my minutes at the montreal IETF. Packet types #2 and #3 represent tunnel mode with and without end-to-end authentication. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. p.s: no I won't be in San Jose. I no longer have a corporate sponsor to pay my bills. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQBVAwUBMqOszdTTll4efmtZAQES7QIAtRaKrKDxTZQWF44m1A3l0shWH9G7HcXk byNCZlvyOndSRb/Po+pIpWKz7z/x5zNYyjc7uUDHG5kKxNsOvDs61g== =IGlv -----END PGP SIGNATURE----- From owner-ipsec Tue Dec 3 01:27:46 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA23221 for ipsec-outgoing; Tue, 3 Dec 1996 01:26:54 -0500 (EST) Message-Id: <3.0.32.19961202222904.009e13c0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 02 Dec 1996 22:29:11 -0800 To: Stephen Kent From: Bob Monsour Subject: Re: Re[5]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:37 PM 12/2/96 -0500, you wrote: ... >Our rewrite of the >architecture, ESP and AH documents (which have not been distributed yet) ... Steve, Any idea when we'll be seeing the new ESP and AH documents? -Bob From owner-ipsec Tue Dec 3 07:23:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA23485 for ipsec-outgoing; Tue, 3 Dec 1996 07:19:55 -0500 (EST) Date: Mon, 2 Dec 96 21:40:17 GMT From: "William Allen Simpson" Message-ID: <5520.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Whelan, Bill" > >But this potential conflict is not necessarily fatal, is it? Assuming > >cooperating firewalls, the conflict can exist and be irrelevant. The > >firewalls unwrap outer headers according to their notions of the SA > >mappings, and the end hosts unwrap inner headers according to their > >notions. Conflicts are invisible as long as the firewalls are in > >place. > > Outer headers and inner headers? Per RFC1826, the Authentication Header > sits between the IP header and the upper layer protocol. It appears the > same whether it's inserted by the host system or the gateway. > This makes no sense to me at all. Since the SPI is relative to the Destination, and supposedly protects the IP Header, I do not understand this assumption that AH or ESP could or should ever be inserted/removed by a router/firewall. That is, only "tunneling" should be used for secure communication to or between firewall/routers, with SPIs that reflect the firewall Destination, not the host Destination. Besides, what would you do if there were multiple firewall paths to the same host? Or when communicating securely to an "intranet" Destination, passing no firewalls at all? The Destination host could be assigning that same SPI to a different session that travels a different path! That way lies madness.... And I'm sure that we covered this on this list over 2 years ago. This means that the "architecture" document is inadequate.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Dec 3 10:10:06 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24057 for ipsec-outgoing; Tue, 3 Dec 1996 10:08:28 -0500 (EST) Date: Tue, 3 Dec 96 10:09:47 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612031509.AA19307@dolphin.ncsc.mil> To: ps@sectra.se Subject: Re: How to skip phase 1? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Patrik, > Dear sir, > In your internet-draft ISAKMP, chapter 1.4.2 you write: > "If a basic set of security attributes is already in place > between the negotiating server entities, the initial ISAKMP > exchange may be skipped and the establishment of a security > association can be done directly". > > I can't find any descriptions how this is supposed to be > done however. As this is something we would like to be able > to do (we will distribute some basic attributes as part of the > configuration of our Security Gateways) we would like to > get some hints on how "the initial ISAKMP excange may be skipped". You have answered your own question. If there is no SA between ISAKMP daemons, then an ISAKMP Phase 1 exchange must be done in order to negotiate a Phase 2 SA. If you don't want to do the Phase 1 exchange, the alternative is to distribute the basic attributes separately, read manually placed SA attributes and keys. > One idea is to create complete SA entries together with cookies > in the Management utility. This seems to increase the workload of > the Management utility quite a bit. I'm not familiar with your Security Gateway product, but it sounds like the Management Utility would be the place to perform the manual insertion of SA attributes. > Another idea is to add a new exchange that can use some of > the existing SA-attributes to establish a complete SA. We would > like to have no plaintext communication in between the SGs at any > time (including ISAKMP negotiation). Once you have an existing SA (manually placed), you can use ISAKMP to negotiate additional SAs and none of the communication will be plaintext. It will be protected by the security mechanisms defined by the manually placed SA. > > ---------------------------------------------------------- > Patrik Sjvgren Tel : +46 13 235606 > SECTRA AB Fax : +46 13 212185 > Teknikringen 2 mailto:ps@sectra.se > 583 30 Linkoping, Sweden url:http://www.sectra.se/ > --------------------------------------------------------- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Tue Dec 3 10:10:06 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24051 for ipsec-outgoing; Tue, 3 Dec 1996 10:07:57 -0500 (EST) Date: Tue, 3 Dec 96 09:57:10 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612031457.AA19295@dolphin.ncsc.mil> To: carterg@entrust.com Subject: Re: Certificate Request Payload Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, > From draft 6 of ISAKMP > 3.10 Certificate Request Payload > ..."The responder to the Certificate Request payload MUST send its > immediate certificate, > if certificates are supported, and SHOULD send as much of its > certificate chain as possible." > > As part of the certificate chain can we send Certificate Revocation > Lists (CRL) and Authority Revocation > Lists (ARL)? ISAKMP is not intended to provide the services of the certificate infrastructure. Thus, we did not intend to include CRLs and ARLs within ISAKMP messages as part of the certificate chain. If the CRLs and ARLs can fit within the Certificate Payload format AND the WG feels this is a necessary requirement, then we can explore supporting this functionality (including, possibly changing the payload formats). However, I don't feel this is the job of ISAKMP. > Or was it intended that the certificate chain only include the immediate > certificates of the users/CAs in question? Correct. The purpose of the Certificate Request payload is just to get the immediate certificate(s) of the user/CA in question. The Certificate Request payload was added so that if the certificate infrastructure was not available, users could still communicate by using this payload (along with the Certificate payload) to exchange certificate chains. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Tue Dec 3 10:25:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24108 for ipsec-outgoing; Tue, 3 Dec 1996 10:25:02 -0500 (EST) Date: Tue, 3 Dec 96 10:26:01 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612031526.AA19314@dolphin.ncsc.mil> To: carterg@entrust.com Subject: Re: ISAKMP & IPSEC DOI Drafts - Notify Payload - Certificate Authorities Cc: ipsec@tis.com Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Greg, > Questions on ISAKMP draft: > > Can Notify Payloads be sent in any exchange or are they valid only in > Informational Exchanges? Because Notify and Delete messages are one-way, i.e. no acknowledgement expected, they were separated out to their own exchange. Nothing precludes you from defining an exchange that allows Notify or Delete payloads anywhere in the exchange. We defined a default set of exchanges in ISAKMP. None of those exchanges (Base, ID Protect, Aggressive, and Auth Only) allow Notify or Delete payloads as part of the exchange. We separated out the Notify and Delete payload into their own exchange, i.e. Informational. > What action should be taken when a Notify Payload is received and the > Message Type is not known. i.e. My ISAKMP server is using some of the > private Message Types to exchange Environment information, but the peer > ISAKMP server has no concept of this info (and hence the private message > types). Section 5.12 specifies a RECOMMENDED way to handle the problem. We probably should add more to this section to make it like the other sections (similar detail and clarity for error handling). Additionally, I would expect that ISAKMP servers using Private Message Types would be able to handle them appropriately. As you state, it is only when an ISAKMP server has no idea what to do with the Private Message Type that this becomes an issue. > Section 3.10 Certificate Request Payload of ISAKMP - draft 6 > > For the Certificate Authorities field it references the IPSEC DOI > document, however I couldn't find any reference to 'Distinguished Name > Attribute Type' value in the IPSEC DOI doc. > > Could someone expand on this? I think this might have been something that got lost or overlooked in the transfer of stuff from the appendices of ISAKMP-05 to the IPSEC DOI document. I'll check with Derrell Piper (piper@tgv.com). Feel free to contact him as well. > ---- > Greg Carter > Nortel Secure Networks - Entrust > carterg@entrust.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Tue Dec 3 11:06:40 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24220 for ipsec-outgoing; Tue, 3 Dec 1996 11:06:30 -0500 (EST) Date: Tue, 3 Dec 96 10:42:38 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612031542.AA19323@dolphin.ncsc.mil> To: ps@sectra.se Subject: Re: ISAKMP questions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Patrik, > Dear sirs, > We have recently decided to use ISAKMP for some of our > key management. Some problems will raise the need for > "patches" of the ISAKMP or using functions to solve > something they were not designed to solve. > Please excuse me if this has been discussed in some > other forum as I'm new to this field. If these questions > have been answered before, please direct me to the answers. > > 1) Dynamic IPs > There is no support in ISAKMP for Dynamic IP > addresses. This is vital for our application > which has mobile PC-clients. > I would like to solve this with additional SA > attributes. Do you have any other ideas how to > approach this problem? Correct. ISAKMP expects the user/client to have an IP address. I would expect that DHCP (or a similar protocol) would be executed to get a dynamic IP address assignment and then, once I have my IP address I would use ISAKMP to establish the security attributes for communication with a peer/server. > 2) Complex SA parameters > SA-attributes handled by ISAKMP are always atomary. > We need an SA attribute of a table form which > contents can be added/removed after the initial > negotiation. > I would like to solve this with additional > Notify message types (ADD/DELETE). Do you have > any other ideas how to approach this problem? The SA attributes handled by ISAKMP are defined by the DOI document. In the case of IPSEC, the SA attributes are handled by the IPSEC DOI I-D. If someone wants to define a different DOI, then they would also need to define the SA attributes that are negotiated as part of that DOI. ISAKMP is not responsible for the definition of the SA attributes, just the negotiation to establish the SAs which will use the SA attributes. As for changing the Notify Message Types to add additional functionality for ADD-ing and DELETE-ing SA attributes, I'll leave that to the IPSEC WG for discussion. > 3) It is not clear if additions to the internet DOI > violates the DOI specification and a new DOI is > needed. > Extra SA-attributes are needed. Does this imply a new DOI? > Extra exchanges are needed. Does this imply a new DOI? Using the current structure of documents (ISAKMP, ISAKMP/Oakley, and IPSEC DOI), additional SA attributes and exchanges would constitute the creation of a new DOI. However, things are still pretty fluid so ... if you have requirements for specific SA attributes and/or exchanges which are appropriate for the IPSEC DOI, then get in touch with the authors (IPSEC DOI == piper@tgv.com and ISAKMP/Oakley == dharkins or carrel @cisco.com). > thanks/Patrik Sjogren, Sectra AB > > PS: The circular references between chapter 2 and appendix A > raises some amout of frustration while trying to understand > the draft. I think you must be looking at ISAKMP-05. There are no references from chapter 2 to Appendix A in the recently announced ISAKMP-06 (draft-ietf-ipsec-isakmp-06). However, there are several references to the IPSEC DOI document (draft-ietf-ipsec-ipsec-doi-00). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Tue Dec 3 11:30:11 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24295 for ipsec-outgoing; Tue, 3 Dec 1996 11:27:59 -0500 (EST) From: pau@watson.ibm.com Date: Tue, 3 Dec 1996 11:33:05 -0500 Message-Id: <9612031633.AA22788@secpwr.watson.ibm.com> To: ipsec@tis.com, isakmp-proto@epoch.ncsc.mil Subject: ISAKMP DELETE payload Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: BleGdb7qODg3x5+7u1cnzQ== Sender: owner-ipsec@ex.tis.com Precedence: bulk Should the DELETE payload be authenticated using an ISAKMP SA (or pre-shared key) ? Otherwise there seems to be an easy denial-of-service attack. Pau-Chen From owner-ipsec Tue Dec 3 12:45:45 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24371 for ipsec-outgoing; Tue, 3 Dec 1996 12:44:00 -0500 (EST) Date: Tue, 3 Dec 96 12:41:56 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612031741.AA19438@dolphin.ncsc.mil> To: pau@watson.ibm.com Subject: Re: ISAKMP DELETE payload Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen, > Should the DELETE payload be authenticated using an ISAKMP SA > (or pre-shared key) ? Otherwise there seems to be an easy > denial-of-service attack. The second paragraph of section 5.13 of ISAKMP-06 states .... "Deletion of Security Associations MUST always be performed under the protection of an ISAKMP SA." Unless the ISAKMP SA is established without authentication-related SA attributes, I think we are protected from the DOS attack. Please correct me if I'm wrong. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Tue Dec 3 14:45:12 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24635 for ipsec-outgoing; Tue, 3 Dec 1996 14:41:01 -0500 (EST) From: pau@watson.ibm.com Date: Tue, 3 Dec 1996 14:45:54 -0500 Message-Id: <9612031945.AA23198@secpwr.watson.ibm.com> To: pau@watson.ibm.com, wdm@epoch.ncsc.mil Subject: Re: ISAKMP DELETE payload Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: SnYe4qTTYlly3g0egEw2rQ== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA24632 Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, you are right. Does the draft also define a standard way to authenticate the payload, like a keyed-hash or signature should be computed over certain parts of the msg (or payload) ? Pau-Chen > > Pau-Chen, > > > Should the DELETE payload be authenticated using an ISAKMP SA > > (or pre-shared key) ? Otherwise there seems to be an easy > > denial-of-service attack. > > The second paragraph of section 5.13 of ISAKMP-06 states .... > > "Deletion of Security Associations MUST always be performed > under the protection of an ISAKMP SA." > > Unless the ISAKMP SA is established without authentication-related SA > attributes, I think we are protected from the DOS attack. > > Please correct me if I'm wrong. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * Douglas Maughan Voice: (301) 688-0847 * > * Technical Director, R23 Fax: (301) 688-0255 * > * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * > * 9800 Savage Road maughan@cs.umbc.edu * > * Fort Meade, MD. 20755-6000 * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > From owner-ipsec Tue Dec 3 14:50:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24668 for ipsec-outgoing; Tue, 3 Dec 1996 14:50:03 -0500 (EST) Message-Id: <199612031951.LAA16394@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Tue, 3 Dec 1996 11:51:40 PST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@tis.com Subject: WG Last Call: ISAKMP draft set to Proposed Standard Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the formal WG Last Call for the 3 documents below to advance to Proposed Standard (mandatory to implement for IPv6; elective to implement for IPv4). This WG Last Call will end at 5pm PST on 3rd January 1997. Comments on this proposed action should be sent to the WG co-chairs at the email addresses at the bottom of this note. draft-ietf-ipsec-isakmp-06.* draft-ietf-ipsec-isakmp-oakley-02.txt draft-ietf-ipsec-ipsec-doi-01.txt Paul Lambert palamber@us.oracle.com Randall Atkinson rja@cisco.com -- From owner-ipsec Tue Dec 3 14:55:49 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24681 for ipsec-outgoing; Tue, 3 Dec 1996 14:55:33 -0500 (EST) Message-Id: <199612031957.LAA16489@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Tue, 3 Dec 1996 11:57:44 PST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@tis.com Subject: San Jose Agenda for IPsec Sender: owner-ipsec@ex.tis.com Precedence: bulk Everyone, Because the IETF Agenda for San Jose is completely full (with a waiting list for slots should there be a cancellation !), IPsec only has __1__ meeting slot in San Jose. We are on the waiting list should another slot open up in future, but I'm told that its very unlikely we will obtain a second slot. Paul has been accepting agenda requests on the premise that we would have two separate meetings in San Jose. I seriously doubt that we can fit in all of the presentations currently proposed at the original time lengths that were requested. If anyone had requested agenda time but would be willing to give it up and use this mailing list instead, please send me and Paul an email note volunteering to give up the time. As of this minute, I am not sure how tight the schedule will be. I'll be in touch with Paul immediately to try to sort things out somewhat. Its looking like it will be a very full meeting agenda in San Jose no matter what happens. Ran rja@cisco.com -- From owner-ipsec Tue Dec 3 15:29:22 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24715 for ipsec-outgoing; Tue, 3 Dec 1996 15:28:32 -0500 (EST) Message-Id: <2.2.32.19961203203636.00c1bbec@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 15:36:36 -0500 To: ipsec@tis.com From: Naganand Doraswamy Subject: SA lifetime and key lifetime Sender: owner-ipsec@ex.tis.com Precedence: bulk Is it necessary to have two different lifetimes? It makes sense to have different lifetimes when we refresh the keys when the key lifetime expires based on some cached data that was established during SA negotiation. However, in case of ISAKMP the procedure for modifying an SA is to delete the SA and create a new SA, if I understand it correct. In this case, it does not make sense to have two different lifetimes. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Dec 3 15:32:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24728 for ipsec-outgoing; Tue, 3 Dec 1996 15:32:32 -0500 (EST) Message-Id: <199612032034.PAA00915@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: ipsec@tis.com Subject: Terminology: what do you call a set of related SA/SPI's? Date: Tue, 03 Dec 1996 15:34:27 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk The current ipsec architecture documents define a "security association" as a unidirectional link; if you want communication in both directions (the normal case at least with today's apps), you need a pair of SA/SPI's. If you're using both AH and ESP at the same time, you need *two* SPI's in each direction (though this is less likely with the current "grand unified transforms"). If you're doing regular key changes and expiring SA's/SPI's, the "relationship" between the communicating principals may outlast the lifetime of individual SA's.. [I don't see this explicitly stated, but I don't see a way to cleanly rekey an active SA without changing the SPI number]. I think we need a name for a higher-level relationship between principals involving multiple SA/SPI's.. Unfortunately, "security association" is already taken. I'm real bad at naming. Anyone got any bright ideas? - Bill From owner-ipsec Tue Dec 3 16:34:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24826 for ipsec-outgoing; Tue, 3 Dec 1996 16:32:22 -0500 (EST) Date: Tue, 03 Dec 96 16:33:08 EST From: "Whelan, Bill" Message-Id: <9611038496.AA849659648@netx.nei.com> To: ipsec@tis.com, Bill Sommerfeld Subject: Re: Terminology: what do you call a set of related SA/SPI's? Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been simply using "SA pairs." Do we need anything more than that? ______________________________ Reply Separator _________________________________ Subject: Terminology: what do you call a set of related SA/SPI's? Author: Bill Sommerfeld at internet-mail Date: 12/3/96 4:29 PM The current ipsec architecture documents define a "security association" as a unidirectional link; if you want communication in both directions (the normal case at least with today's apps), you need a pair of SA/SPI's. If you're using both AH and ESP at the same time, you need *two* SPI's in each direction (though this is less likely with the current "grand unified transforms"). If you're doing regular key changes and expiring SA's/SPI's, the "relationship" between the communicating principals may outlast the lifetime of individual SA's.. [I don't see this explicitly stated, but I don't see a way to cleanly rekey an active SA without changing the SPI number]. I think we need a name for a higher-level relationship between principals involving multiple SA/SPI's.. Unfortunately, "security association" is already taken. I'm real bad at naming. Anyone got any bright ideas? - Bill From owner-ipsec Tue Dec 3 16:36:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24859 for ipsec-outgoing; Tue, 3 Dec 1996 16:35:51 -0500 (EST) Date: Tue, 3 Dec 1996 16:38:02 -0500 (EST) Message-Id: <199612032138.QAA00326@carp.morningstar.com> From: Ben Rogers To: Bill Sommerfeld Cc: ipsec@tis.com Subject: Terminology: what do you call a set of related SA/SPI's? In-Reply-To: <199612032034.PAA00915@thunk.orchard.medford.ma.us> References: <199612032034.PAA00915@thunk.orchard.medford.ma.us> Reply-To: ben@ascend.com (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > I think we need a name for a higher-level relationship between > principals involving multiple SA/SPI's.. Unfortunately, "security > association" is already taken. > > I'm real bad at naming. Anyone got any bright ideas? We use the term "Security Scheme". Perhaps not the best, but it does get the point across. ben From owner-ipsec Tue Dec 3 16:38:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24885 for ipsec-outgoing; Tue, 3 Dec 1996 16:38:25 -0500 (EST) Date: Tue, 3 Dec 96 16:31:31 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612032131.AA19551@dolphin.ncsc.mil> To: pau@watson.ibm.com Subject: Re: ISAKMP DELETE payload Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen, > Yes, you are right. Does the draft also define a standard way > to authenticate the payload, like a keyed-hash or signature > should be computed over certain parts of the msg (or payload) ? No. That is really dependent on the mechanisms negotiated. These mechanisms will differ in most DOIs. So, in our case, the IPSEC DOI document defines the mechanisms negotiable for IPSEC and the ISAKMP/Oakley document defines how the hashes and/or signatures are computed for ISAKMP exchanges. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Tue Dec 3 16:39:25 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24898 for ipsec-outgoing; Tue, 3 Dec 1996 16:39:22 -0500 (EST) Message-Id: <199612032141.QAA01028@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "Whelan, Bill" Cc: ipsec@tis.com Subject: Re: Terminology: what do you call a set of related SA/SPI's? In-Reply-To: bwhelan's message of Tue, 03 Dec 1996 16:33:08 -0500. <9611038496.AA849659648@netx.nei.com> Date: Tue, 03 Dec 1996 16:41:18 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I've been simply using "SA pairs." Do we need anything more than > that? What about the case when there are more than two SA's involved? - Bill From owner-ipsec Tue Dec 3 16:49:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24913 for ipsec-outgoing; Tue, 3 Dec 1996 16:49:26 -0500 (EST) Message-ID: From: Greg Carter To: "'wdm%epoch.ncsc.mil@bnr400'" Cc: "Michael Wiener (9C21-I)" , "'ipsec@tis.com'" Subject: RE: Certificate Request Payload Date: Tue, 3 Dec 1996 16:47:58 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk > >>ISAKMP is not intended to provide the services of the certificate >>infrastructure. Thus, we did not intend to include CRLs and ARLs within >>ISAKMP messages as part of the certificate chain. If the CRLs and ARLs >>can fit within the Certificate Payload format AND the WG feels this is >>a necessary requirement, then we can explore supporting this >>functionality (including, possibly changing the payload formats). >>However, I don't feel this is the job of ISAKMP. Hi Douglas, Let me give you a very probable situation: Remote user connecting through a firewall to home network. The remote user acts as an ISAKMP peer as does the Firewall. The Firewall has access to the directory services and is using X.509 certificates. The remote user has no access to the directory during ISAKMP negotiation, but knows how to handle X.509 certificates. During the negotiation the remote user ISAKMP engine requests the peers certificate. In order to do full validation of the certificate a good CRL is needed. If cross-certificates are returned in the certificate chain then ARLs will also be need to validate the certificate. It wouldn't make sense to be able to get a certificate but not the ARLs-CRLs necessary to validate it through ISAKMP. I don't think there would be any problem fitting the ARLs and CRLs within the Cert payload. It MAY mean the addition of some cert types. >---- >Greg Carter >Nortel Secure Networks - Entrust >carterg@entrust.com > From owner-ipsec Tue Dec 3 17:08:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA24968 for ipsec-outgoing; Tue, 3 Dec 1996 17:08:01 -0500 (EST) From: pau@watson.ibm.com Date: Tue, 3 Dec 1996 17:13:25 -0500 Message-Id: <9612032213.AA22506@secpwr.watson.ibm.com> To: wdm@epoch.ncsc.mil Subject: Re: ISAKMP DELETE payload Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: n23LZbGkFGVejZ3WoX80XA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id RAA24965 Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Pau-Chen, > > > Yes, you are right. Does the draft also define a standard way > > to authenticate the payload, like a keyed-hash or signature > > should be computed over certain parts of the msg (or payload) ? > > No. That is really dependent on the mechanisms negotiated. These > mechanisms will differ in most DOIs. So, in our case, the IPSEC DOI > document defines the mechanisms negotiable for IPSEC and the > ISAKMP/Oakley document defines how the hashes and/or signatures are > computed for ISAKMP exchanges. Doug, I more or less understand negotiation and ISAKMP/OAKLEY. Unless I am missing something, neither doc defines how a hash is going to be computed over a ISAKMP DELETE payload. I don't mean the hash algorithm, but rather the input (say SPI's, protocols, ...) and/or the key to be used for the hash; whatever the actual hash algorithm may be. Such should be independent of any particular hash algorithm or KEP, since nothing in the DELETE payload is depedenent on them. Also, I would suggest that ISAKMP doc should state explicitly that a DELETE payload should be sent together with a HASH paylaod, assuming that is the intention of ISAKMP. Pau-Chen > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * Douglas Maughan Voice: (301) 688-0847 * > * Technical Director, R23 Fax: (301) 688-0255 * > * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * > * 9800 Savage Road maughan@cs.umbc.edu * > * Fort Meade, MD. 20755-6000 * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > From owner-ipsec Tue Dec 3 22:44:45 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA25412 for ipsec-outgoing; Tue, 3 Dec 1996 22:39:36 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199612030431.XAA25585@amaterasu.sandelman.ottawa.on.ca> References: Your message of "Mon, 02 Dec 1996 18:56:39 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Dec 1996 18:17:41 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, You mention early in your message the key issue, which is the focus of this debate. I maintained that it makes sense to use AH between a pair of firewalls ONLY if the header is applied to a tunneled SA. Once we agree on that, the rest ought to be easy. The disagreement has been on whether it is appropriate to have two (or more) instances of AH without an intervening IP header. We have seen several messages now arguing why this is not an appropriate header sequence, including your message to which I am responding. So, I don't disagree with the examples you cited. Steve From owner-ipsec Tue Dec 3 22:44:48 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA25411 for ipsec-outgoing; Tue, 3 Dec 1996 22:39:35 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.32.19961202222904.009e13c0@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Dec 1996 18:10:14 -0500 To: Bob Monsour From: Stephen Kent Subject: Re: Re[5]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, A major revision of the IPSEC architecture document was completed about a month ago, but got lost in transmission to Ran fpr review and formatting. So, it was resent on or about 11/20 and thus will not be available for distribution prior to the WG meeting. The "grand unified" AH and ESP specs were sent to Ran for review (they were already formatted) in mid-November and thus should be out soon. My hope is to get a slot on the agenda to describe the salient aspects of the revised architecture document, to get some feedback and make sure that the WG agrees with the direction proposed in that document, before work begins on the next pass (since we missed the deadline and we can see the need for more changes, ...). Steve From owner-ipsec Tue Dec 3 23:58:48 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA25468 for ipsec-outgoing; Tue, 3 Dec 1996 23:57:34 -0500 (EST) Message-Id: <199612040458.XAA18260@raptor.research.att.com> To: Stephen Kent cc: Michael Richardson , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway Date: Tue, 03 Dec 1996 23:58:30 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk You mention early in your message the key issue, which is the focus of this debate. I maintained that it makes sense to use AH between a pair of firewalls ONLY if the header is applied to a tunneled SA. Once we agree on that, the rest ought to be easy. The disagreement has been on whether it is appropriate to have two (or more) instances of AH without an intervening IP header. We have seen several messages now arguing why this is not an appropriate header sequence, including your message to which I am responding. So, I don't disagree with the examples you cited. It's very clear to me that firewall-to-firewall IPSEC -- whether it's ESP or AH -- should be done *only* in tunnel mode. To do otherwise is inviting trouble. In fact, I had thought that was what was done -- no other possibility had occurred to me. There's a second issue that has come up here -- how does one know which the right firewall is? This is one of the points I raised at the last IETF meeting; in my opinion, it's very closely related to the naming issue and the certificate issue, and we haven't really tackled either of those. (See ftp://ftp.research.att.com/dist/smb/ipsec-cert.ps for the (few) slides I used.) From owner-ipsec Wed Dec 4 08:08:16 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA26119 for ipsec-outgoing; Wed, 4 Dec 1996 08:05:35 -0500 (EST) Date: Wed, 4 Dec 96 07:54:32 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612041254.AA19741@dolphin.ncsc.mil> To: pau@watson.ibm.com Subject: Re: ISAKMP DELETE payload Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen, > > Pau-Chen, > > > > > Yes, you are right. Does the draft also define a standard way > > > to authenticate the payload, like a keyed-hash or signature > > > should be computed over certain parts of the msg (or payload) ? > > > > No. That is really dependent on the mechanisms negotiated. These > > mechanisms will differ in most DOIs. So, in our case, the IPSEC DOI > > document defines the mechanisms negotiable for IPSEC and the > > ISAKMP/Oakley document defines how the hashes and/or signatures are > > computed for ISAKMP exchanges. > > Doug, > > I more or less understand negotiation and ISAKMP/OAKLEY. Unless I am > missing something, neither doc defines how a hash is going to be computed > over a ISAKMP DELETE payload. I don't mean the hash algorithm, but rather > the input (say SPI's, protocols, ...) and/or the key to be used for the > hash; whatever the actual hash algorithm may be. Such should be independent > of any particular hash algorithm or KEP, since nothing in the DELETE payload > is depedenent on them. You are correct. I was thinking the ISAKMP/Oakley document specified this, but they only specify how to do the hash for the other exchanges and not for the Informational Exchange. > Also, I would suggest that ISAKMP doc should state explicitly that a > DELETE payload should be sent together with a HASH paylaod, assuming that > is the intention of ISAKMP. Does this belong in the ISAKMP doc or in the ISAKMP/Oakley doc? The ISAKMP/Oakley doc outlines which of the ISAKMP exchanges it uses and then adds the additional ones. Should they also specify how to use Informational Exchanges within the context of an IPSEC DOI using Oakley or should this be done in the ISAKMP doc? If I specify it in the ISAKMP doc then any DOI/Key Exchange would have to use it in the way specified. The splitting of the details from the ISAKMP doc to the other docs was to eliminate this. Would appreciate any other opinions on this issue? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Wed Dec 4 08:32:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA26169 for ipsec-outgoing; Wed, 4 Dec 1996 08:29:34 -0500 (EST) Date: Wed, 04 Dec 96 08:29:49 EST From: "Whelan, Bill" Message-Id: <9611048497.AA849717071@netx.nei.com> To: mcr@sandelman.ottawa.on.ca, Stephen Kent Cc: ipsec@tis.com Subject: Re[2]: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk >I maintained that it makes sense to use AH between a pair of firewalls >ONLY if the header is applied to a tunneled SA. Once we agree on that, >the rest ought to be easy. I agree (now :-)) completely. This discussion started when something which was obvious to most people was not obvious to me. It appeared the document allowed (advocated?) transport mode on a secure gateway which made no sense to me. But then I've always subscribed to the philosophy that "it is better to state the obvious than to assume everyone knows it!" Sorry for the confusion and thanks to everyone for straightening me out. Bill From owner-ipsec Wed Dec 4 09:02:47 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26254 for ipsec-outgoing; Wed, 4 Dec 1996 09:02:39 -0500 (EST) Date: Wed, 4 Dec 96 09:02:40 EST X-Sender: mckenney@smiley.mitre.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steven Bellovin From: mckenney@mitre.org (Brian McKenney) Subject: Re: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >It's very clear to me that firewall-to-firewall IPSEC -- whether it's >ESP or AH -- should be done *only* in tunnel mode. To do otherwise >is inviting trouble. In fact, I had thought that was what was done -- >no other possibility had occurred to me. This is more an implementation issue rather than a standards issue. If you have an IPSEC-compliant firewall, then ESP Transport Mode could be used for firewall-to-firewall encryption. Vendors should note in their documentation about possible problems and issues with this mode for firewall-to-firewall communications. The documentation should address threat environments, likelihood of threats, and whether some threats go away with certain transforms. Maybe Section 5.1, Use with Firewalls (in Security Architecture for the Internet Protocol), should provide a discussion of this issue. Your concerns also apply to desktop-to-desktop IPSEC. An example of standard vs. implementation is key management. The standard notes that manual key management can be performed. I remember reading one vendor manual that provides a warning that you should not communicate SA attributes over a cordless telephone. This is completely outside the scope of the standard. -Brian From owner-ipsec Wed Dec 4 09:05:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26283 for ipsec-outgoing; Wed, 4 Dec 1996 09:05:10 -0500 (EST) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9612041407.AA02872@katahdin.columbia.sparta.com> Subject: Re: San Jose Agenda for IPsec To: rja@cisco.com (Ran Atkinson) Date: Wed, 4 Dec 1996 09:07:31 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199612031957.LAA16489@cornpuffs.cisco.com> from "Ran Atkinson" at Dec 3, 96 11:57:44 am Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Everyone, > > Because the IETF Agenda for San Jose is completely full (with a waiting > list for slots should there be a cancellation !), IPsec only has __1__ > meeting slot in San Jose. We are on the waiting list should another slot > open up in future, but I'm told that its very unlikely we will obtain > a second slot. > > Paul has been accepting agenda requests on the premise that we would > have two separate meetings in San Jose. I seriously doubt that we can > fit in all of the presentations currently proposed at the original time > lengths that were requested. > > If anyone had requested agenda time but would be willing to give it up > and use this mailing list instead, please send me and Paul an email > note volunteering to give up the time. > > As of this minute, I am not sure how tight the schedule will be. I'll > be in touch with Paul immediately to try to sort things out somewhat. > Its looking like it will be a very full meeting agenda in San Jose > no matter what happens. > > Ran > rja@cisco.com What about Thurs evening after the IESG Open Plenary that ends at 7pm? There are no sessons scheduled. It is not unheard of to run an evening session 'till 10 or 11pm. We could break for a hour and then have a productive 2 or 3 hour session. 1800-1900 Open Plenary and IESG Howie -- ________________________________________________________________________ | | | Howard Weiss phone (410) 381-9400 x201 | | SPARTA, Inc. (301) 621-8145 x201 (DC)| | 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | | Columbia, MD 21046 email: hsw@columbia.sparta.com| |________________________________________________________________________| From owner-ipsec Wed Dec 4 09:07:38 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26298 for ipsec-outgoing; Wed, 4 Dec 1996 09:07:12 -0500 (EST) Date: Wed, 4 Dec 1996 09:00:41 -0500 Message-Id: <199612041400.JAA07204@MAILSERV-2HIGH.FTP.COM> To: wdm@epoch.ncsc.mil Subject: Re: ISAKMP DELETE payload From: mamros@ftp.com (Shawn Mamros) Cc: pau@watson.ibm.com, ipsec@tis.com Repository: mailserv-2high.ftp.com, [message accepted at Wed Dec 4 09:00:40 1996] Originating-Client: cavedog.ftp.com Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk >> Also, I would suggest that ISAKMP doc should state explicitly that a >> DELETE payload should be sent together with a HASH paylaod, assuming that >> is the intention of ISAKMP. > >Does this belong in the ISAKMP doc or in the ISAKMP/Oakley doc? The >ISAKMP/Oakley doc outlines which of the ISAKMP exchanges it uses and >then adds the additional ones. Should they also specify how to use >Informational Exchanges within the context of an IPSEC DOI using Oakley >or should this be done in the ISAKMP doc? If I specify it in the ISAKMP >doc then any DOI/Key Exchange would have to use it in the way >specified. The splitting of the details from the ISAKMP doc to the >other docs was to eliminate this. Would appreciate any other opinions >on this issue? Given that: - DELETE payloads only have meaning when under the protection of an ISAKMP SA, - Oakley is a specific transform used for establishing ISAKMP SAs under the IPSEC DOI (and in fact is the only transform fully defined so far for this DOI), - it is the transform which defines the encryption and hash algorithms in use, and how to derive keys for those algorithms, then the definition of how to protect a DELETE payload in the Informational exchange must be part of the transform document, which in this case is the ISAKMP/Oakley draft. I was working under the (possibly incorrect) assumption that the way to protect the Informational exchange under ISAKMP/Oakley would be the same as the way the Oakley Quick Mode and New Group Mode exchanges are protected - namely, by encryption with the key derived from SKEYID_e. -Shawn Mamros E-mail to: mamros@ftp.com From owner-ipsec Wed Dec 4 09:24:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26401 for ipsec-outgoing; Wed, 4 Dec 1996 09:24:09 -0500 (EST) Date: Wed, 4 Dec 96 09:34:28 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612041434.AA19799@dolphin.ncsc.mil> To: carterg@nortel.ca Subject: RE: Certificate Request Payload Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, > >>ISAKMP is not intended to provide the services of the certificate > >>infrastructure. Thus, we did not intend to include CRLs and ARLs within > >>ISAKMP messages as part of the certificate chain. If the CRLs and ARLs > >>can fit within the Certificate Payload format AND the WG feels this is > >>a necessary requirement, then we can explore supporting this > >>functionality (including, possibly changing the payload formats). > >>However, I don't feel this is the job of ISAKMP. > > Let me give you a very probable situation: > > Remote user connecting through a firewall to home network. The remote > user acts as an ISAKMP peer as does the Firewall. The Firewall has > access to the directory services and is using X.509 certificates. > > The remote user has no access to the directory during ISAKMP > negotiation, but knows how to handle X.509 certificates. During the > negotiation the remote user ISAKMP engine requests the peers certificate. > > In order to do full validation of the certificate a good CRL is needed. > If cross-certificates are returned in the certificate chain then ARLs > will also be need to validate the certificate. It wouldn't make > sense to be able to get a certificate but not the ARLs-CRLs necessary to > validate it through ISAKMP. Very valid scenario. > I don't think there would be any problem fitting the ARLs and CRLs > within the Cert payload. It MAY mean the addition of some cert types. As I stated in my previous response, ISAKMP was not designed to provide the services of the certificate infrastructure. However, I agree with you that this functionality COULD be provided by adding some new certificate types for requesting CRLs and/or ARLs as part of the protocol. This would allow your remote user the capability to request CRLs and ARLs (when needed). Given the draft is now in Last Call, I'll leave this discussion to the working group and the WG chairs. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Wed Dec 4 09:56:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26552 for ipsec-outgoing; Wed, 4 Dec 1996 09:56:13 -0500 (EST) Message-Id: <199612041458.GAA26678@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Wed, 4 Dec 1996 06:58:38 PST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@tis.com Subject: IPsec Implementation Survey update Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Its been a while since we updated our IPsec Implementation Survey. Please send me email with any revised data. Note that this survey is NOT intended for marketing purposes so don't send me marketing material. :-) Time permitting, we'll summarise this data during the IPsec WG meeting. A sample template is below in case we have newcomers on the list who aren't familiar with the format. Ran rja@cisco.com This is the revised IETF IPsec WG's Implementation Status "template". If you have an implementation of any portion of the IETF IPsec specifications and are willing to let this be known in public, please fill this in and email it to me. I expect to post a revised summary in a few days time. Suggested answers are in parenthesis ready for you to edit. Thanks, Randall Atkinson Co-Chair, IPsec WG, IETF ______________________________________________________________________ Name of Implementation: (name of your implementation/product) Organisation: (name of your organisation) Which IP versions are supported: (IPv4, IPv6, or IPv4 and IPv6) Implements RFC-1825 & RFC-1826 AH: (YES, NO, In Progress, Planned, Partial) Implements RFC-1825 & RFC-1827 ESP: (YES, NO, In Progress, Planned, Partial) Implements RFC-1828 AH MD5: (YES, NO, In Progress, Planned, Partial) Implements RFC-1829 ESP DES-CBC:(YES, NO, In Progress, Planned, Partial) Implements AH HMAC MD5: (YES, NO, In Progress, Planned, Partial) Implements AH HMAC SHA-1: (YES, NO, In Progress, Planned, Partial) Implements Combined ESP (DES+MD5+Replay): (YES, NO, In Progress, Planned, Partial) Other AH Implemented Transforms: (none, proprietary) Other ESP Implemented Transforms: (none, ESP-3DES, ESP-RC4, ESP-RC5, proprietary) Key Management: (manual, ISAKMP, ISAKMP+Oakley, Oakley, Photuris, SKIP, proprietary) Platforms: (4.4-Lite BSD, Solaris, IRIX, , STREAMS, LINUX, etc) Lineage of IPsec Code: (, ETHZ, JI, KA9Q, NIST, NRL, SUN, not applicable) Lineage of Key Mgmt Code: (, SUN, ETHZ, JI, cisco, not applicable) Location of Source Code: (provide URL if freely available, use the word "proprietary" if isn't freely available) Point of Contact: (email address, optionally also phone/fax/name) Claimed Interoperability: (list of systems that your implementation fully interoperates with) _______________________________________________________________________ -- From owner-ipsec Wed Dec 4 10:17:05 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26586 for ipsec-outgoing; Wed, 4 Dec 1996 10:15:43 -0500 (EST) From: pau@watson.ibm.com Date: Wed, 4 Dec 1996 10:20:47 -0500 Message-Id: <9612041520.AA21880@secpwr.watson.ibm.com> To: wdm@epoch.ncsc.mil, mamros@ftp.com Subject: Re: ISAKMP DELETE payload Cc: pau@watson.ibm.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: qRLBaHKfIjvd5Q8/WePFZA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA26583 Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> Also, I would suggest that ISAKMP doc should state explicitly that a > >> DELETE payload should be sent together with a HASH paylaod, assuming that > >> is the intention of ISAKMP. > > > >Does this belong in the ISAKMP doc or in the ISAKMP/Oakley doc? The > >ISAKMP/Oakley doc outlines which of the ISAKMP exchanges it uses and > >then adds the additional ones. Should they also specify how to use > >Informational Exchanges within the context of an IPSEC DOI using Oakley > >or should this be done in the ISAKMP doc? If I specify it in the ISAKMP > >doc then any DOI/Key Exchange would have to use it in the way > >specified. The splitting of the details from the ISAKMP doc to the > >other docs was to eliminate this. Would appreciate any other opinions > >on this issue? > > Given that: > - DELETE payloads only have meaning when under the protection of an > ISAKMP SA, > - Oakley is a specific transform used for establishing ISAKMP SAs under > the IPSEC DOI (and in fact is the only transform fully defined so far for > this DOI), > - it is the transform which defines the encryption and hash algorithms in > use, and how to derive keys for those algorithms, > > then the definition of how to protect a DELETE payload in the Informational > exchange must be part of the transform document, which in this case is the > ISAKMP/Oakley draft. I think this is an ISAKMP job. IMHO, Oakley is a Key Exchange Protocol but deleting an SA is part of SA management, not key exchange. From an operational point of view, the SPI's in the msg header will identify the ISAKMP SA, which leads to the right hash algorithm and key. So no KEP-specific details are needed here. After all, the DELETE and HASH payloads are defined by ISAKMP, not OAKLEY. Pau-Chen > > I was working under the (possibly incorrect) assumption that the way > to protect the Informational exchange under ISAKMP/Oakley would be the > same as the way the Oakley Quick Mode and New Group Mode exchanges are > protected - namely, by encryption with the key derived from SKEYID_e. > > -Shawn Mamros > E-mail to: mamros@ftp.com > > From owner-ipsec Wed Dec 4 10:17:48 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26600 for ipsec-outgoing; Wed, 4 Dec 1996 10:17:43 -0500 (EST) Message-Id: <199612041519.KAA13479@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Steven Bellovin cc: Stephen Kent , Michael Richardson , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-reply-to: Your message of "Tue, 03 Dec 1996 23:58:30 EST." <199612040458.XAA18260@raptor.research.att.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 04 Dec 1996 10:19:49 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Bellovin writes: > It's very clear to me that firewall-to-firewall IPSEC -- whether it's > ESP or AH -- should be done *only* in tunnel mode. To do otherwise > is inviting trouble. In fact, I had thought that was what was done -- > no other possibility had occurred to me. Nor to me, for that matter, when the idea originated in the hallway at Toronto a couple of years ago. > There's a second issue that has come up here -- how does one know which > the right firewall is? This is one of the points I raised at the last > IETF meeting; in my opinion, it's very closely related to the naming > issue and the certificate issue, and we haven't really tackled either > of those. A notable void in our work to date... Perry From owner-ipsec Wed Dec 4 11:09:32 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26643 for ipsec-outgoing; Wed, 4 Dec 1996 11:08:59 -0500 (EST) Message-Id: <199612041612.IAA08731@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: wdm@epoch.ncsc.mil (W. Douglas Maughan) Cc: pau@watson.ibm.com, ipsec@tis.com Subject: Re: ISAKMP DELETE payload In-Reply-To: Your message of "Wed, 04 Dec 1996 07:54:32 EST." <9612041254.AA19741@dolphin.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 08:12:11 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Doug, Pau-Chen, > > Also, I would suggest that ISAKMP doc should state explicitly that a > > DELETE payload should be sent together with a HASH paylaod, assuming that > > is the intention of ISAKMP. > > Does this belong in the ISAKMP doc or in the ISAKMP/Oakley doc? The > ISAKMP/Oakley doc outlines which of the ISAKMP exchanges it uses and > then adds the additional ones. Should they also specify how to use > Informational Exchanges within the context of an IPSEC DOI using Oakley > or should this be done in the ISAKMP doc? If I specify it in the ISAKMP > doc then any DOI/Key Exchange would have to use it in the way > specified. The splitting of the details from the ISAKMP doc to the > other docs was to eliminate this. Would appreciate any other opinions > on this issue? I think it belongs in the ISAKMP/Oakley doc. SKEYID_a is used to protect the integrity of exchanges (e.g. Quick Mode) and it should be used to protect this one. Any other comments? Dan. From owner-ipsec Wed Dec 4 11:39:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26736 for ipsec-outgoing; Wed, 4 Dec 1996 11:36:54 -0500 (EST) Date: Wed, 4 Dec 1996 11:38:58 -0500 Message-Id: <199612041638.LAA23901@MAILSERV-2HIGH.FTP.COM> To: pau@watson.ibm.com Subject: Re: ISAKMP DELETE payload From: mamros@ftp.com (Shawn Mamros) Reply-To: mamros@ftp.com Cc: wdm@epoch.ncsc.mil, ipsec@tis.com Repository: mailserv-2high.ftp.com, [message accepted at Wed Dec 4 11:38:58 1996] Originating-Client: cavedog.ftp.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > I think this is an ISAKMP job. IMHO, Oakley is a Key Exchange Protocol > but deleting an SA is part of SA management, not key exchange. From an > operational point of view, the SPI's in the msg header will identify the > ISAKMP SA, which leads to the right hash algorithm and key. So no > KEP-specific details are needed here. After all, the DELETE and HASH > payloads are defined by ISAKMP, not OAKLEY. On the one hand, I understand your viewpoint. On the other, though, one cannot establish an ISAKMP SA from the details of the ISAKMP draft alone. One needs a DOI definition, and specific transforms need to be proposed by the initiator for the ISAKMP SA; those transforms are in turn defined by the DOI. It also isn't clear that one would always want to use a HASH payload to protect the DELETE. A DOI definition could just as well mandate that the Informational exchange must be encrypted, rather than hashed. Also, keep in mind that one may be using the Informational exchange to delete not the ISAKMP SA, but rather some underlying protocol SA, such as an IPSEC SA. By definition, the details of those protocol SAs are defined by the DOI, and not in the base ISAKMP document. -Shawn Mamros E-mail to: mamros@ftp.com From owner-ipsec Wed Dec 4 11:48:12 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26774 for ipsec-outgoing; Wed, 4 Dec 1996 11:48:08 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9611048497.AA849717071@netx.nei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Dec 1996 11:51:43 -0500 To: "Whelan, Bill" From: Stephen Kent Subject: Re[2]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You were absoluitely right to raise this issue; the debate that ensued, on both sides, clearly showed the need for the discussion. I think the architecture and AH specs have not been clear about this. In fact, I am willing to bet that my re-write didn't get this right either! Contrary to the suggestion made by Brian McKenney, I do think this is a standards issue. If two security gateways (to use the terminology in the IPSEC documents) choose to use AH in transport mode between themselves, to create an authentticated and integrity protected securiry association for all traffic between the sites, this will impinge on the ability of subscriber hosts served by these gatewatys to make use of AH in transport mode. Thus, to avoid deployment of security gateways that can be configured in a fashion that would cause such problems, and because there are alternative IPSEC configurations that will achieve the desired security goals, I think it imperative that the standards prohibit this use of AH. Steve From owner-ipsec Wed Dec 4 12:03:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26889 for ipsec-outgoing; Wed, 4 Dec 1996 12:03:11 -0500 (EST) Message-Id: <199612041706.JAA08899@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: mamros@ftp.com Cc: pau@watson.ibm.com, wdm@epoch.ncsc.mil, ipsec@tis.com Subject: Re: ISAKMP DELETE payload In-Reply-To: Your message of "Wed, 04 Dec 1996 11:38:58 EST." <199612041638.LAA23901@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 09:06:01 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, (responding to Pau-Chen) > > I think this is an ISAKMP job. IMHO, Oakley is a Key Exchange Protocol > > but deleting an SA is part of SA management, not key exchange. From an > > operational point of view, the SPI's in the msg header will identify the > > ISAKMP SA, which leads to the right hash algorithm and key. So no > > KEP-specific details are needed here. After all, the DELETE and HASH > > payloads are defined by ISAKMP, not OAKLEY. > > On the one hand, I understand your viewpoint. On the other, though, > one cannot establish an ISAKMP SA from the details of the ISAKMP draft > alone. One needs a DOI definition, and specific transforms need to > be proposed by the initiator for the ISAKMP SA; those transforms are in > turn defined by the DOI. And ISAKMP does not specify the key exchange. There must be something used to protect this message; ISAKMP does not specify how to generate this thing but ISAKMP/Oakley does. The technique used to protect Quick Mode can easily be used to protect Informational exchanges. > It also isn't clear that one would always want to use a HASH payload > to protect the DELETE. A DOI definition could just as well mandate > that the Informational exchange must be encrypted, rather than hashed. It *is* encrypted. Informational exchanges must be sent under the protection of an existing ISAKMP SA. The issue is authenticating the message as well. Steve Bellovin (in a paper whose title I cannot remember and I don't have on hand right now since I'm at home) noted some attacks that can be made on messages that are encrypted but not authenticated. We must protect ourselves against this sort of attack. > Also, keep in mind that one may be using the Informational exchange to > delete not the ISAKMP SA, but rather some underlying protocol SA, such > as an IPSEC SA. By definition, the details of those protocol SAs are > defined by the DOI, and not in the base ISAKMP document. A good point. regards, Dan. From owner-ipsec Wed Dec 4 12:50:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27029 for ipsec-outgoing; Wed, 4 Dec 1996 12:48:12 -0500 (EST) Message-Id: <199612041750.MAA00147@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-reply-to: Your message of "Tue, 03 Dec 1996 18:17:41 EST." Date: Wed, 04 Dec 1996 12:50:15 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> is the focus of this debate. I maintained that it makes Stephen> sense to use AH between a pair of firewalls ONLY if the Stephen> header is applied to a tunneled SA. Once we agree on Stephen> that, the rest ought to be easy. The disagreement has I thought we *DID* agree to that over the summer. ... i just spent some time slurping through the IPsec archives. Ick why aren't they at least in Mailbox or digest format? Argh. Please see http://www.sandelman.ottawa.on.ca/ipsec/maillist.html for a MHonArc version of Jan-Sept. Chairs, if you'd like the mbox format it is there as ipsec.960?.mbox, or the perl script to produce them from what is there, 'toDigest.pl' is also in that directory. Unless requested, I won't be leaving the stuff there, it is large, and I'm on a single 64k B-channel. ... well I give up. Even after looking through things in thread mode, I couldn't find anything. Maybe it says this in the RFCs somewhere. I was sure that AH could not be used except as IP-AH-IP-AH was said sometime ago. Maybe it was said in 1995? :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQBVAwUBMqW5y9TTll4efmtZAQEKJwIAqzkujHGhuWruCNHffG4xGWDYOeR0eJS6 LqsIxyEuTuKeGsBA0TekP2Vo1ITowaywHl3noZJa9/IB6PMX+b135Q== =8JIP -----END PGP SIGNATURE----- From owner-ipsec Wed Dec 4 13:33:22 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27189 for ipsec-outgoing; Wed, 4 Dec 1996 13:33:11 -0500 (EST) Date: Wed, 4 Dec 96 13:32:57 EST X-Sender: mckenney@smiley.mitre.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Stephen Kent From: mckenney@mitre.org (Brian McKenney) Subject: Re[2]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I agree with you. My statement was too strong. I did suggest that these issues (issue of tunnel mode only for firewall-to-firewall communications raised by Steve Bellovin) be discussed in one or more of the RFCs (e.g., Section 5.1, Use With Firewalls, in Security Architecture for Internet Protocol). The point I was making (or tried to make) is that the selection of particular configurable options or parameters defined in a standard may not be safe for specific threat environments. If these issues (or red flags) (with particular IPSEC configurations) are not dicussed in the standard then they should be discussed in vendor product literature. -Brian >Bill, > > You were absoluitely right to raise this issue; the debate that >ensued, on both sides, clearly showed the need for the discussion. I think >the architecture and AH specs have not been clear about this. In fact, I >am willing to bet that my re-write didn't get this right either! Contrary >to the suggestion made by Brian McKenney, I do think this is a standards >issue. If two security gateways (to use the terminology in the IPSEC >documents) choose to use AH in transport mode between themselves, to create >an authentticated and integrity protected securiry association for all >traffic between the sites, this will impinge on the ability of subscriber >hosts served by these gatewatys to make use of AH in transport mode. Thus, >to avoid deployment of security gateways that can be configured in a >fashion that would cause such problems, and because there are alternative >IPSEC configurations that will achieve the desired security goals, I think >it imperative that the standards prohibit this use of AH. > >Steve From owner-ipsec Wed Dec 4 13:36:46 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27222 for ipsec-outgoing; Wed, 4 Dec 1996 13:36:42 -0500 (EST) Date: Wed, 4 Dec 1996 13:38:01 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199612041838.NAA14180@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > To: Stephen Kent > cc: Michael Richardson , ipsec@tis.com > Subject: Re: AH (without ESP) on a secure gateway > Date: Tue, 03 Dec 1996 23:58:30 -0500 > From: Steven Bellovin > > There's a second issue that has come up here -- how does one know which > the right firewall is? This is one of the points I raised at the last > IETF meeting; in my opinion, it's very closely related to the naming > issue and the certificate issue, and we haven't really tackled either > of those. (See ftp://ftp.research.att.com/dist/smb/ipsec-cert.ps for > the (few) slides I used.) I thought there was only one firewall - Cheswick & Bellovin's collection of components that can't be bypassed. Therefore there isn't a "right" firewall. A simplified rendition of one of Stephen Kent's slides illustrates the context: +------+ ------------ +-------| FW A |>-----/ \ | +------+ | | +--------+ | | The Internet | +--------+ | Host 1 |------+ LAN | |----<| Host 6 | +--------+ | | | +--------+ | +------+ | | +-------| FW B |>----| | +------+ \ / ------------ If Host 6 initiates a connection to Host 1, it shouldn't matter whether the first packet of the SA setup gets routed to box "FW A" or "FW B" - they are both part of the firewall that isolates Host 1 from the Net. If the tunnel-mode connection between Host 6 and one of the FW boxes has properties that depend on where the first packet happens to arrive, or if Host 6 is able to choose a policy by choosing the tunnel endpoint, then the firewall probably isn't doing what it's operators intended. Am I missing a different context to which the question applies? From owner-ipsec Wed Dec 4 13:43:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27241 for ipsec-outgoing; Wed, 4 Dec 1996 13:43:11 -0500 (EST) Date: Wed, 4 Dec 1996 10:45:09 -0800 From: Ran Atkinson Message-Id: <199612041845.KAA01568@cornpuffs.cisco.com> To: ben@ascend.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: <199611262230.RAA27739@carp.morningstar.com> References: <199611261929.OAA01715@thunk.orchard.medford.ma.us> Organization: cisco Systems Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Earlier, someone (possibly Bill Sommerfeld) wrote: >> The "policy engines" on each end need to be sophisticated enough to >> deal with things like this. In particular, if ip-address based access >> controls are in use, then the policy engine should probably do >> consistency checks between the SPI and the source address.. Absolutely true. Such checks are important to prevent certain kinds of attacks and have ALWAYS been present in the NRL implementation. In article <199611262230.RAA27739@carp.morningstar.com> Ben wrote: >I believe the RFC states that the Security Association(SA) is >chosen using only the destination address and the SPI. Incorrect. It says that the receiver is capable of locating the SA for the received packet by using SPI and Destination Address. Ran rja@cisco.com From owner-ipsec Wed Dec 4 13:53:33 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27285 for ipsec-outgoing; Wed, 4 Dec 1996 13:51:41 -0500 (EST) Date: Wed, 4 Dec 1996 10:53:55 -0800 From: Ran Atkinson Message-Id: <199612041853.KAA01789@cornpuffs.cisco.com> To: kurt@RSA.COM Subject: Re: ANNOUNCEMENT: 1997 RSA Data Security Conference In-Reply-To: <199612021319.IAA21249@portal.ex.tis.com> Organization: IETF Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Kurt, Commercial announcements, such as for RSADSI's conference, are NOT appropriate use for the IPsec WG mailing list. Please do not post such items here in future. Thank you, Ran rja@cisco.com Co-chair, IPsec WG, IETF From owner-ipsec Wed Dec 4 13:57:46 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27301 for ipsec-outgoing; Wed, 4 Dec 1996 13:57:42 -0500 (EST) Date: Wed, 4 Dec 1996 10:59:50 -0800 From: Ran Atkinson Message-Id: <199612041859.KAA01913@cornpuffs.cisco.com> To: kent@bbn.com Subject: Re: Re[5]: AH (without ESP) on a secure gateway In-Reply-To: References: <3.0.32.19961202222904.009e13c0@earthlink.net> Organization: cisco Systems Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk The 2nd draft revised IPsec Architecture document and the draft proposed ESP/AH specs will not be out before San Jose because the logistics of getting them out before the I-D submission deadline could not be achieved. I anticipate those drafts will be out online after San Jose and well before the Spring meeting. Given the extremely tight meeting time we have for IPsec in San Jose, I'd like to propose that discussion of those drafts be deferred until the Spring 1997 IETF (at which point they will have been online so that folks could review/discuss them via email and so we can have a more focused meeting discussion). We would not consider these documents for advancement prior to the Spring IETF meeting in this proposal, so it wouldn't adversely impact folks' ability to review things thoroughly. Would that be agreeable to folks ? (Objectors please send me unicast email and I'll summarise back to the list :-) Ran rja@cisco.com From owner-ipsec Wed Dec 4 14:03:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27368 for ipsec-outgoing; Wed, 4 Dec 1996 14:03:11 -0500 (EST) Message-Id: <199612041904.OAA01378@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: mckenney@mitre.org (Brian McKenney) Cc: Steven Bellovin , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: mckenney's message of Wed, 04 Dec 1996 09:02:40 -0500. Date: Wed, 04 Dec 1996 14:04:35 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > This is more an implementation issue rather than a standards issue. If you > have an IPSEC-compliant firewall, then ESP Transport Mode could be used for > firewall-to-firewall encryption. Vendors should note in their > documentation about possible problems and issues with this mode for > firewall-to-firewall communications. There may be a terminology clash here. By "firewall", do you mean "filtering border router" or "application-layer gateway" or what? I know I'm repeating myself (and others), but I think we've (re)established over the past few days that performing transport-mode ESP or AH encapsulation/decapsulation in a router is problematic. If the end systems are also using ESP and AH, both the receiving end system and the receiving router could allocate the same numeric SPI and there wouldn't be an unambiguous interpretation of each packet. This would impede deployment of end-to-end ESP/AH, and I think that's reason enough to specify that configuration as a "SHOULD NOT" or "MUST NOT"..' - Bill From owner-ipsec Wed Dec 4 14:09:47 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27384 for ipsec-outgoing; Wed, 4 Dec 1996 14:09:15 -0500 (EST) Date: Wed, 4 Dec 1996 11:11:35 -0800 From: Ran Atkinson Message-Id: <199612041911.LAA02222@cornpuffs.cisco.com> To: ipsec@tis.com Subject: Re: Re[2]: AH (without ESP) on a secure gateway In-Reply-To: References: <9611028495.AA849549400@netx.nei.com> Organization: cisco Systems Cc: rja@cisco.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe that ESP should continue to always imply that encryption is in use. The presence/absence of encryption is the primary reason that AH is separate from ESP. Were it not for the political realities of regulation of encryption in various locales, AH and ESP would not have been separate protocols in the first place. I am aware of cases where in practice more than one government regulatory authority has been persuaded to handle AH export/use licensing with significantly less hassle BECAUSE the AH spec does not support encryption. I am aware that many implementers of AH have in fact implemented a "tunnel-mode AH" (which looks like this: [ip:r1->r2][ah][ip:h1->h2][ulp], where r1,r2 are security gateways and h1,h2 are end nodes). I believe that the best approach is to simply add a definition of this tunnel-mode AH into the AH base specification. This also has the virtue of having the least amount of negative impact on interoperability of existing AH implementations. Comments ? Ran rja@cisco.com From owner-ipsec Wed Dec 4 14:19:56 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27399 for ipsec-outgoing; Wed, 4 Dec 1996 14:19:47 -0500 (EST) From: pau@watson.ibm.com Date: Wed, 4 Dec 1996 14:21:21 -0500 Message-Id: <9612041921.AA23932@secpwr.watson.ibm.com> To: mamros@ftp.com, dharkins@cisco.com, wdm@epoch.ncsc.mil Subject: Re: ISAKMP DELETE payload Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: 7q82lHVuqeZJ357PRtqbfw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA27396 Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, it seems that we are in basic agreement on : 1. The DELETE payload has to be authenticated. 2. The exact way of authentication (input/format to the hash, the key, ...) should be defined. The only disagreement is where it should be defined. I still prefer ISAKMP. But I think this topic is minor relative to many other issues of ISAKMP and OAKLEY. So either 1. ISAKMP/OAKLEY start defining it, Or 2. we can say in ISAKMP "The entire DELETE payload minus the generic payload header must be authenticated" and leave the exact crypto algorithm and key to the KEP. Either way, we can always move the definition later if needed. > > Shawn, > > (responding to Pau-Chen) > > > I think this is an ISAKMP job. IMHO, Oakley is a Key Exchange Protocol > > > but deleting an SA is part of SA management, not key exchange. Fom an > > > operational point of view, the SPI's in the msg header will identify the > > > ISAKMP SA, which leads to the right hash algorithm and key. So no > > > KEP-specific details are needed here. After all, the DELETE and HASH > > > payloads are defined by ISAKMP, not OAKLEY. > > > > On the one hand, I understand your viewpoint. On the other, though, > > one cannot establish an ISAKMP SA from the details of the ISAKMP draft > > alone. One needs a DOI definition, and specific transforms need to > > be proposed by the initiator for the ISAKMP SA; those transforms are in > > turn defined by the DOI. > > And ISAKMP does not specify the key exchange. There must be something > used to protect this message; ISAKMP does not specify how to generate > this thing but ISAKMP/Oakley does. The technique used to protect Quick > Mode can easily be used to protect Informational exchanges. > > > It also isn't clear that one would always want to use a HASH payload > > to protect the DELETE. A DOI definition could just as well mandate > > that the Informational exchange must be encrypted, rather than hashed. > > It *is* encrypted. Informational exchanges must be sent under the protection > of an existing ISAKMP SA. The issue is authenticating the message as well. > Steve Bellovin (in a paper whose title I cannot remember and I don't have > on hand right now since I'm at home) noted some attacks that can be made > on messages that are encrypted but not authenticated. We must protect > ourselves against this sort of attack. > > > Also, keep in mind that one may be using the Informational exchange to > > delete not the ISAKMP SA, but rather some underlying protocol SA, such > > as an IPSEC SA. By definition, the details of those protocol SAs are > > defined by the DOI, and not in the base ISAKMP document. > > A good point. > > regards, > > Dan. > From owner-ipsec Wed Dec 4 14:22:47 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27412 for ipsec-outgoing; Wed, 4 Dec 1996 14:22:44 -0500 (EST) Date: Wed, 4 Dec 1996 11:24:51 -0800 From: Ran Atkinson Message-Id: <199612041924.LAA02582@cornpuffs.cisco.com> To: ipsec@tis.com Subject: Re: ISAKMP DELETE payload In-Reply-To: <199612041612.IAA08731@spook> References: <9612041254.AA19741@dolphin.ncsc.mil> Organization: cisco Systems Sender: owner-ipsec@ex.tis.com Precedence: bulk [co-chair hat off] It seems to me that the ISAKMP base document needs to explicitly state that the DELETE payload MUST be ignored upon receipt unless it is properly authenticated. If we were to have the ISAKMP document specify how to compute the HASH or SIG, then that would apply to all uses of ISAKMP (including those that might not be using Oakley or IPsec). Its not clear to me whether we want to do that or whether it would be better to let the mechanism for the DELETE payload authentication be specified on a per-DOI or per-SessionExchange basis. Ran rja@cisco.com From owner-ipsec Wed Dec 4 15:16:57 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27492 for ipsec-outgoing; Wed, 4 Dec 1996 15:14:57 -0500 (EST) From: Uri Blumenthal Message-Id: <9612042017.AA174418@hawpub.watson.ibm.com> Subject: Re: Re[2]: AH (without ESP) on a secure gateway To: rja@cisco.com (Ran Atkinson) Date: Wed, 4 Dec 1996 15:17:12 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199612041911.LAA02222@cornpuffs.cisco.com> from "Ran Atkinson" at Dec 4, 96 11:11:35 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson says: > I believe that ESP should continue to always imply that encryption is > in use. The presence/absence of encryption is the primary reason that AH is > separate from ESP..................Comments ? I support your position. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Wed Dec 4 15:25:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27520 for ipsec-outgoing; Wed, 4 Dec 1996 15:25:24 -0500 (EST) Date: Wed, 4 Dec 96 15:35:35 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612042035.AA20062@dolphin.ncsc.mil> To: rpereira@TimeStep.com Subject: Re: SA, Proposal and Transform payloads Cc: isakmp-oakley@cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, > The current ISAKMP draft, draft-ietf-ipsec-isakmp-06.txt [isakmp], > defines a new method to exchange proposals. ISAKMP-06 does not define a "new" method. What has been done is the combining of the ENVelope payload, Collate bit of the Flags field, and Appendix A material from ISAKMP-05. Additionally, ISAKMP-06 now supports multiple proposals using different logical AND and OR constructs. > It states that the proposals and transforms are payloads and thus have > the same generic payload structure. Logically, though they are not > used at the 'same level' as all other payloads. They are only used > within, or after, the SA payload. Furthermore, the Transform payload > is only used within a Proposal payload. I think it might be confusing > and logically incorrect to call these two structures 'payloads' and > have them equate to the other payloads. Agreed they are not used at the 'same level' as other payloads and are only used as part of the SA negotiation. The reason they were included as payloads and include the generic payload header is for processing reasons. Using this method all payload headers can be processed using the same code. In the end, the 'naming' or 'equating' is not really that important. > Thus, the only valid 'Next Payload' value for the SA payload is > 'Proposal'. The only valid 'Next Payload' value for a Proposal > payload is 'Transform' or NIL. And the only valid 'Next Payload' > value for the Transform payload is 'Transform' or NIL. Thus I believe > that this field confuses the process of parsing a complete proposal. This may be true for IPSEC and the method of establishing SAs using the Proposal and Transform payloads, but I'm not sure you can make the same blanket statement for all possible DOIs. > I propose moving the Proposal and Transform structures away from the > 'Payload' definition and as well as simplifying them. > > Proposal := > Proposal Number 1 octet > Protocol ID 1 octet > Length 2 octets > Number of Transforms 2 octets > Reserved 2 octets > SPI 8 octets > > Transform := > Transform Number 1 octet > Transform ID 1 octet > Length 2 octets > Attributes... multiple of 4 octets > > The main advantage is the removal of the 'Next Payload' field. For > this to work properly though, we require another field in the SA > payload to state how many proposals we are sending. Or we can utilize > the 'Reserved' field in the Proposal structure and add a flag that > denotes whether there are any other proposals after this one. We changed the protocol so that all payloads had the same header. This was done for efficiency and simplicity. It's easy to say, "Get rid of the Next Payload" field, but "Add another field in the SA Payload". Significant thought went into the current method. I'll leave it up to the IPSEC WG, co-chairs, and others to debate the necessity of the proposed changes. In the end, I don't think you're saving very much bandwidth and I'm not convinced the proposal is "more simple". A good exercise might be to look at the savings when a complex proposal (e.g. (ESP{DES OR 3DES} AND AH{MD5 OR SHA}) OR (HUGHES)) is made. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Wed Dec 4 15:31:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27550 for ipsec-outgoing; Wed, 4 Dec 1996 15:31:25 -0500 (EST) Message-ID: From: Roy Pereira To: "'IPSEC Mailing List'" Subject: SA, Proposal and Transform payloads Date: Wed, 4 Dec 1996 15:25:37 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > >The current ISAKMP draft, draft-ietf-ipsec-isakmp-06.txt [isakmp], defines a >new method to exchange proposals. > >It states that the proposals and transforms are payloads and thus have the >same generic payload structure. Logically, though they are not used at the >'same level' as all other payloads. They are only used within, or after, the >SA payload. Furthermore, the Transform payload is only used within a >Proposal payload. I think it might be confusing and logically incorrect to >call these two structures 'payloads' and have them equate to the other >payloads. > >Thus, the only valid 'Next Payload' value for the SA payload is 'Proposal'. >The only valid 'Next Payload' value for a Proposal payload is 'Transform' or >NIL. And the only valid 'Next Payload' value for the Transform payload is >'Transform' or NIL. Thus I believe that this field confuses the process of >parsing a complete proposal. > >I propose moving the Proposal and Transform structures away from the >'Payload' definition and as well as simplifying them. > >Proposal := > Proposal Number 1 octet > Protocol ID 1 octet > Length 2 octets > Number of Transforms 2 octets > Reserved 2 octets > SPI 8 octets > >Transform := > Transform Number 1 octet > Transform ID 1 octet > Length 2 octets > Attributes... multiple of 4 octets > >The main advantage is the removal of the 'Next Payload' field. For this to >work properly though, we require another field in the SA payload to state how >many proposals we are sending. Or we can utilize the 'Reserved' field in the >Proposal structure and add a flag that denotes whether there are any other >proposals after this one. >--------------------------------------------- >Roy Pereira TimeStep Corporation >rpereira@timestep.com Ottawa, Ontario >613-599-3610 x 4808 http://www.timestep.com > From owner-ipsec Wed Dec 4 15:42:53 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27563 for ipsec-outgoing; Wed, 4 Dec 1996 15:42:25 -0500 (EST) Message-Id: <199612042045.MAA09234@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: Your message of "Wed, 04 Dec 1996 13:38:01 EST." <199612041838.NAA14180@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 12:45:09 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk David P. Kemp wrote: > > From: Steven Bellovin > > > > There's a second issue that has come up here -- how does one know which > > the right firewall is? This is one of the points I raised at the last > > IETF meeting; in my opinion, it's very closely related to the naming > > issue and the certificate issue, and we haven't really tackled either > > of those. (See ftp://ftp.research.att.com/dist/smb/ipsec-cert.ps for > > the (few) slides I used.) > > I thought there was only one firewall - Cheswick & Bellovin's > collection of components that can't be bypassed. Therefore there > isn't a "right" firewall. I think what he means is something you allude to later on when you mention setting a policy to choose tunnel endpoints. How do you identify the endpoint? How are you assured that FW A is, in fact, the appropriate on with which to establish a connection? > > +------+ ------------ > +-------| FW A |>-----/ \ > | +------+ | | > +--------+ | | The Internet | +--------+ > | Host 1 |------+ LAN | |----<| Host 6 | > +--------+ | | | +--------+ > | +------+ | | > +-------| FW B |>----| | > +------+ \ / > ------------ > > If Host 6 initiates a connection to Host 1, it shouldn't matter whether > the first packet of the SA setup gets routed to box "FW A" or "FW B" - > they are both part of the firewall that isolates Host 1 from the Net. If the packet is addressed to Host 1 I would imagine either FW A or FW B would drop it-- else they're not very good firewalls. Host 6 must decide what the encrypting firewall for host 1 is-- what is the "right" firewall-- and address packets to it. That is the crux of the problem. Once the SAs between FW (whatever) and Host 6 are established it's plain old tunnel mode IPsec: [IP:host6->FWx] [ESP] [IP:host6->host1] [blah] Dan. From owner-ipsec Wed Dec 4 16:03:21 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27681 for ipsec-outgoing; Wed, 4 Dec 1996 16:02:55 -0500 (EST) Message-Id: <2.2.32.19961204211101.00fc2204@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 16:11:01 -0500 To: Ran Atkinson From: Naganand Doraswamy Subject: Re: Re[2]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com, rja@cisco.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > I am aware that many implementers of AH have in fact implemented a >"tunnel-mode AH" (which looks like this: [ip:r1->r2][ah][ip:h1->h2][ulp], >where r1,r2 are security gateways and h1,h2 are end nodes). I believe that >the best approach is to simply add a definition of this tunnel-mode AH into >the AH base specification. This also has the virtue of having the least >amount of negative impact on interoperability of existing AH implementations. > Agreed. I had raised this issue of AH in tunnel mode a couple of months back, and I didnt get any message against it. I guess adding it to the base spec will help. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Wed Dec 4 16:38:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27761 for ipsec-outgoing; Wed, 4 Dec 1996 16:35:03 -0500 (EST) Message-ID: From: Roy Pereira To: "'wdm@epoch.ncsc.mil'" Cc: "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: RE: SA, Proposal and Transform payloads Date: Wed, 4 Dec 1996 16:36:51 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Douglas, I do believe that we should alter the language to state that the Proposal and Transform payloads are not at the 'same level' as other payloads. I do agree that we should try and generalize structures to keep processing overhead down in our code, but I still find the "Transform" Next Payload field redundant, since we have a 'number of transforms' field in the Proposal payload. Being able to process the transforms by using two different fields is dangerous. If we don't have a "number of proposals" field, then perhaps we shouldn't have a "number of transforms" field as well, since we can find this information out by using the Next Payload field in the Transform payload. I'd just like to see more conformity with the ISAKMP structures and I think that v6 goes a long way to doing this, but it isn't perfect. > From owner-ipsec Wed Dec 4 18:03:53 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27861 for ipsec-outgoing; Wed, 4 Dec 1996 18:03:00 -0500 (EST) Message-Id: <199612042304.SAA02239@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-reply-to: Your message of "Tue, 03 Dec 1996 23:58:30 EST." <199612040458.XAA18260@raptor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2236.849740683.1@amaterasu.sandelman.ottawa.on.ca> Date: Wed, 04 Dec 1996 18:04:44 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk [this may be a repeat. Emacs crashed.] -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Steven" == Steven Bellovin writes: Steven> mode. To do otherwise is inviting trouble. In fact, I Steven> had thought that was what was done -- no other possibility Steven> had occurred to me. Are you suggesting we need specific wording in the drafts? Steven> There's a second issue that has come up here -- how does Steven> one know which the right firewall is? This is one of the I favour a firewall discovery system. ICMP Admin denied messages can provide the right info. I am not certain if this is workable, since I haven't been able to prototype it all. (And no longer have the funding to even try.) Steven> points I raised at the last IETF meeting; in my opinion, Steven> it's very closely related to the naming issue and the Steven> certificate issue, and we haven't really tackled either of I am retrieving your slides. [how do you get the AT&T logo inside of slidex? Cool.] The problem I see is that there may be different firewalls involved. Both firewalls in parallel and firewalls in series. While this doesn't sound very likely very soon with most current application layer firewalls, Checkpoint has announced state-sharing facilities. It could be a different firewall that is involved each time! Should the encryption state be shared too? Maybe. Maybe not. Firewalls in series are more interesting. I expect to see this. I am seeing this. The best system I can imagine is one where an end node is provided with a certificate, signed by its intended destination stating that "firewall X is a legitimate firewall for me". The local node will also need to be able to recognize a certificate from a local authority saying "firewall Y is a legitimate firewall to get to 0.0.0.0/0" (local node)-------- Y --------- X ------- (end node) The SPKI groups' proposal has the notion of cache certificate that could reduce a series of statements into single self-signed certificate. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQBVAwUBMqW1dtTTll4efmtZAQFF/gH/VzzF8DFKLgRbWYZGUecEkcCFCbiKz/ee bC3GQX0/IKYVIceV9sIV2HYn+bXlb454bzwCuhn90q1ytlVr1kwNNg== =51h3 -----END PGP SIGNATURE----- From owner-ipsec Wed Dec 4 21:26:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA28028 for ipsec-outgoing; Wed, 4 Dec 1996 21:24:50 -0500 (EST) Message-Id: <199612050223.VAA02436@raptor.research.att.com> To: Michael Richardson cc: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway Date: Wed, 04 Dec 1996 21:23:56 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk [this may be a repeat. Emacs crashed.] -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Steven" == Steven Bellovin writes: Steven> mode. To do otherwise is inviting trouble. In fact, I Steven> had thought that was what was done -- no other possibility Steven> had occurred to me. Are you suggesting we need specific wording in the drafts? If people are trying to do AH at the firewall, without an intervening IP header -- yes, we should prohibit that. Steven> There's a second issue that has come up here -- how does Steven> one know which the right firewall is? This is one of the I favour a firewall discovery system. ICMP Admin denied messages can provide the right info. I am not certain if this is workable, since I haven't been able to prototype it all. (And no longer have the funding to even try.) We need some mechanism -- but I'm not convinced I know the right answer. Certainly, firewall discovery is part of it, but we also need some sort of authentication mechanism, so that you know you've heard from a legitimate firewall. Steven> points I raised at the last IETF meeting; in my opinion, Steven> it's very closely related to the naming issue and the Steven> certificate issue, and we haven't really tackled either of I am retrieving your slides. [how do you get the AT&T logo inside of slidex? Cool.] The problem I see is that there may be different firewalls involved. Both firewalls in parallel and firewalls in series. While this doesn't sound very likely very soon with most current application layer firewalls, Checkpoint has announced state-sharing facilities. It could be a different firewall that is involved each time! Should the encryption state be shared too? Maybe. Maybe not. Firewalls in series are more interesting. I expect to see this. I am seeing this. [I use latex for my slides, and once upon a time, someone wrote a Metafont definition for the Death Star logo. So to latex, it's just another character.] We certainly will see many combinations of firewalls. That's part of the fun... The best system I can imagine is one where an end node is provided with a certificate, signed by its intended destination stating that "firewall X is a legitimate firewall for me". The local node will also need to be able to recognize a certificate from a local authority saying "firewall Y is a legitimate firewall to get to 0.0.0.0/0" Something like that, though wildcard DNS-like records might be needed as well. (local node)-------- Y --------- X ------- (end node) The SPKI groups' proposal has the notion of cache certificate that could reduce a series of statements into single self-signed certificat e. All of these are reasonable ideas. Now we need concrete proposals and implementations.... From owner-ipsec Wed Dec 4 21:27:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA28042 for ipsec-outgoing; Wed, 4 Dec 1996 21:27:46 -0500 (EST) Message-Id: <199612050226.VAA02599@raptor.research.att.com> To: Daniel Harkins cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway Date: Wed, 04 Dec 1996 21:26:05 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > David P. Kemp wrote: > > > From: Steven Bellovin > > > > > > There's a second issue that has come up here -- how does one know which > > > the right firewall is? This is one of the points I raised at the last > > > IETF meeting; in my opinion, it's very closely related to the naming > > > issue and the certificate issue, and we haven't really tackled either > > > of those. (See ftp://ftp.research.att.com/dist/smb/ipsec-cert.ps for > > > the (few) slides I used.) > > > > I thought there was only one firewall - Cheswick & Bellovin's > > collection of components that can't be bypassed. Therefore there > > isn't a "right" firewall. > > I think what he means is something you allude to later on when you mention > setting a policy to choose tunnel endpoints. How do you identify the > endpoint? How are you assured that FW A is, in fact, the appropriate on > with which to establish a connection? > > > > > +------+ ------------ > > +-------| FW A |>-----/ \ > > | +------+ | | > > +--------+ | | The Internet | +--------+ > > | Host 1 |------+ LAN | |----<| Host 6 | > > +--------+ | | | +--------+ > > | +------+ | | > > +-------| FW B |>----| | > > +------+ \ / > > ------------ > > > > If Host 6 initiates a connection to Host 1, it shouldn't matter whether > > the first packet of the SA setup gets routed to box "FW A" or "FW B" - > > they are both part of the firewall that isolates Host 1 from the Net. > > If the packet is addressed to Host 1 I would imagine either FW A or FW B > would drop it-- else they're not very good firewalls. Host 6 must decide what > the encrypting firewall for host 1 is-- what is the "right" firewall-- and > address packets to it. That is the crux of the problem. Once the SAs between > FW (whatever) and Host 6 are established it's plain old tunnel mode IPsec: > > [IP:host6->FWx] [ESP] [IP:host6->host1] [blah] > > Dan. Basically. More to the point, you want to make sure that hackers-r-us.edu doesn't claim to the the firewall for spooks.nsa.gov (or some such). Either spooks.nsa.gov or nsa.gov can delegate such control -- and we need mechanisms to check that. From owner-ipsec Wed Dec 4 23:28:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA28071 for ipsec-outgoing; Wed, 4 Dec 1996 23:23:16 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199612041911.LAA02222@cornpuffs.cisco.com> References: <9611028495.AA849549400@netx.nei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Dec 1996 23:18:46 -0500 To: Ran Atkinson From: Stephen Kent Subject: Re: Re[2]: AH (without ESP) on a secure gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, I'll comment on your suggestion that we retain mandatory use of encryption in ESP. I feel that AH is an awkward way to provide authentication for a payload, due to the selective inclusion of IP header fields. The computation of the integrity check value will be slower than a corresponding computation for ESP, because of the selectivity of the computation. AH does offer a different function from ESP, even if ESP is offered in a version that provides integrity and autenticity without encryption. ESP, if allowed to be used without encryption, provides a clean way to integrity protect just encapsulated data, if that is what is wanted. I suspect that this latter capability will often be appropriate, a the recent firewall discussion has shown. I agree that the original distinction between AH and ESP was one in which the encryption vs. integrity/authenticity was the primary motivation. However, the other major difference is the scope of the protection, with AH and ESP differing noticeably in that regard as well. As ESP added more features, I think it makes more sense to allow for it to be more modular, and to reserve the use of AH for exactly the circumstances where it's coverage of the IP header is appropriate. The notion of tunnel mode for AH has not been a very strong one in the documents, though it certainly can be added. However, I suggest we consider the better documented tunnel mode notion of ESP, combined with the new notion of an encryptionless use of ESP, as a candidate for many instances where one might have used tunneled AH. Unless the protection of the "outer" IP header is necessary e.g., to bind a security label to the outer packet, tunneled AH would appear to offer no advantages relative to this mode of use of ESP. Steve From owner-ipsec Thu Dec 5 01:47:59 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA28123 for ipsec-outgoing; Thu, 5 Dec 1996 01:46:47 -0500 (EST) Date: Thu, 5 Dec 1996 08:42:30 +0200 (IST) From: Dan Frommer To: Ran Atkinson Cc: ipsec@tis.com, rja@cisco.com Subject: Re: Re[2]: AH (without ESP) on a secure gateway In-Reply-To: <199612041911.LAA02222@cornpuffs.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 4 Dec 1996, Ran Atkinson wrote: > I believe that ESP should continue to always imply that encryption is > in use. The presence/absence of encryption is the primary reason that AH is > separate from ESP. Were it not for the political realities of regulation of > encryption in various locales, AH and ESP would not have been separate > protocols in the first place. I am aware of cases where in practice more than > one government regulatory authority has been persuaded to handle AH export/use > licensing with significantly less hassle BECAUSE the AH spec does not support > encryption. > > I am aware that many implementers of AH have in fact implemented a > "tunnel-mode AH" (which looks like this: [ip:r1->r2][ah][ip:h1->h2][ulp], > where r1,r2 are security gateways and h1,h2 are end nodes). I believe that > the best approach is to simply add a definition of this tunnel-mode AH into > the AH base specification. This also has the virtue of having the least > amount of negative impact on interoperability of existing AH implementations. > > Comments ? > > Ran > rja@cisco.com > AH in tunnel mode is required for the above case as well as the case of a host that implements AH (h1) talking via a gateway (r2) to a host behind the gateway (h2). In this case the headers would look like this: [ip:h1->r2][ah][ip:h1->h2][ulp]. Such a mode is indeed required and would ease exportability issues. Dan Frommer dan@radguard.com From owner-ipsec Thu Dec 5 08:36:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28371 for ipsec-outgoing; Thu, 5 Dec 1996 08:35:47 -0500 (EST) Date: Thu, 5 Dec 96 10:33:27 GMT From: "William Allen Simpson" Message-ID: <5524.wsimpson@greendragon.com> To: ipsec@tis.com Subject: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk I support moving all "tunneling" language and descriptions to the Architecture document, with appropriate references in AH and ESP. I support requiring encryption in any ESP transform, and using AH for all authentication-only functions. I support not discussing any draft revisions that are not available before the IETF meeting at this meeting. They should be discussed on the mailing list. 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 Dec 5 08:45:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28403 for ipsec-outgoing; Thu, 5 Dec 1996 08:45:47 -0500 (EST) Date: Thu, 5 Dec 1996 08:45:47 -0500 (EST) Message-Id: <199612051345.IAA28403@portal.ex.tis.com> From: Robert Glenn HAA04604; Thu, 5 Dec 1996 07:54:14 -0500 (EST) Date: Thu, 5 Dec 1996 07:54:14 -0500 (EST) Message-Id: <199612051254.HAA04604@sloth.ncsl.nist.gov> To: ipsec@tis.com Subject: Re: Re[2]: AH (without ESP) on a secure gate Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk In article <199612041911.LAA02222@cornpuffs.cisco.com>, Ran Atkinson writes: > > I am aware that many implementers of AH have in fact implemented a >"tunnel-mode AH" (which looks like this: [ip:r1->r2][ah][ip:h1->h2][ulp], >where r1,r2 are security gateways and h1,h2 are end nodes). I believe that >the best approach is to simply add a definition of this tunnel-mode AH into >the AH base specification. This also has the virtue of having the least >amount of negative impact on interoperability of existing AH implementations. > > I couldn't agree more. This would also help better align the ESP and AH specs. Rob G. -- rob.glenn@nist.gov From owner-ipsec Thu Dec 5 09:44:32 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28521 for ipsec-outgoing; Thu, 5 Dec 1996 09:43:20 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Dec 1996 09:37:06 -0500 To: ipsec@tis.com From: Stephen Kent Subject: discussing revised documents Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, The revisions to the architecture, AH and ESP specs raise some important issues that the WG does not seem to have addressed. While one could raise these topics in the context of the mailing list, and hold off until the spring IETF meeting to discuss them, after distribution of the docuemnts, this creates the potential for editing and distributing documents that contain proposals that the WG ultimately will decline to adopt. Some of the changes I refer to did appear in the most recent versions of AH and ESP specs, and elicited no comments on the list. Yet, in looking at much of the traffic, it seems likely that most folks have not noticed these changes (based on oft-cited assumptions). This suggests that we are not all reading the specs (no big surprize there), and that ongoing implementation work will be out of synch with the specs. So, what I would like to do is spend a little time at the next meeting to present two things: - major changes that have already been cited in recent (published) specs but which seem to have booen overlooked - proposed changes in the newest versions of the specs (that have not made it through the editing and publication process), with an emphasis on both the flavor of and rationale for the changes, as well as some details Steve From owner-ipsec Thu Dec 5 11:09:39 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28867 for ipsec-outgoing; Thu, 5 Dec 1996 11:07:49 -0500 (EST) Date: Thu, 5 Dec 1996 08:10:15 -0800 From: Ran Atkinson Message-Id: <199612051610.IAA16407@cornpuffs.cisco.com> To: kent@bbn.com Subject: Re: discussing revised documents In-Reply-To: Organization: cisco Systems Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk In article Steve Kent wrote: > So, what I would like to do is spend a little time at the next >meeting to present two things: > - major changes that have already been cited in recent (published) > specs but which seem to have booen overlooked This seems fine to me. > - proposed changes in the newest versions of the specs (that have >not made it through the editing and publication process), with an emphasis >on both the flavor of and rationale for the changes, as well as some details I have heard considerable sentiment against discussing these in San Jose on grounds that the proposed changes haven't been available online prior to the IETF meeting (no one's fault -- just a reality at present), so I'd like to defer this to the mailing list for now with the intent of presenting/discussing these in detail at the Spring 97 IETF meeting. Ran rja@cisco.com From owner-ipsec Thu Dec 5 12:28:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA29006 for ipsec-outgoing; Thu, 5 Dec 1996 12:26:18 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "Michael Wiener (9C21-I)" , Ron Vandergeest , "'wdmaugh@tycho.ncsc.mil'" , "'palamber@us.oracle.com'" Subject: Additional Certificate Types to support CRL\ARL Date: Thu, 5 Dec 1996 12:24:17 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk The following applies to the ISAKMP draft version 6 wrt to Certificate Payloads and X.509 Certificates. As noted in previous exchanges on this mailing list it would be advantageous to be able to send Certificate Revocation Lists (CRL) and Authority Revocation Lists (ARL) in ISAKMP Certificate Payloads. Allowing X.509 certificates but not the accompanying CRLs\ARLs to be exchanged in ISAKMP is of questionable worth. The current definition of a Certificate Payload is generic enough to support both user certificates and CRLs\ARLs. The only change to the current draft necessary to allow the exchange of CRLs\ARLs is the addition of two Certificate Types as defined in section 3.9 Certificate Payload on page 32. The types proposed are: X.509 Certificate Revocation List 6 X.509 Authority Revocation List 7 If more discussion is required I would like to request that this topic be added to the IETF ipsec meeting agenda . Thanks! ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Thu Dec 5 12:45:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA29036 for ipsec-outgoing; Thu, 5 Dec 1996 12:44:50 -0500 (EST) Date: Thu, 5 Dec 96 12:55:19 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9612051755.AA20546@dolphin.ncsc.mil> To: carterg@entrust.com Subject: Re: Additional Certificate Types to support CRL\ARL Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, > The following applies to the ISAKMP draft version 6 wrt to Certificate > Payloads and X.509 Certificates. > > As noted in previous exchanges on this mailing list it would be > advantageous to be able to send Certificate Revocation Lists (CRL) and > Authority Revocation Lists (ARL) in ISAKMP Certificate Payloads. > Allowing X.509 certificates but not the accompanying CRLs\ARLs to be > exchanged in ISAKMP is of questionable worth. The current definition of > a Certificate Payload is generic enough to support both user > certificates and CRLs\ARLs. The only change to the current draft > necessary to allow the exchange of CRLs\ARLs is the addition of two > Certificate Types as defined in section 3.9 Certificate Payload on page > 32. > > The types proposed are: > X.509 Certificate Revocation List 6 > X.509 Authority Revocation List 7 > > If more discussion is required I would like to request that this topic > be added to the IETF ipsec meeting agenda . I've captured the issue in my presentation for next week. Hopefully it will generate further discussion. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Douglas Maughan Voice: (301) 688-0847 * * Technical Director, R23 Fax: (301) 688-0255 * * National Security Agency E-mail: wdmaugh@tycho.ncsc.mil * * 9800 Savage Road maughan@cs.umbc.edu * * Fort Meade, MD. 20755-6000 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From owner-ipsec Thu Dec 5 16:58:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29552 for ipsec-outgoing; Thu, 5 Dec 1996 16:55:31 -0500 (EST) From: "Marcus Leech" Message-Id: <199612051931.AA288314281@bcarh6dc.ott.bnr.ca> Subject: Replay counter sizes: AH vs ESP To: ipsec@ans.net Date: Thu, 5 Dec 1996 14:31:21 -0500 (EST) Organization: Nortel Technologies, System Security Services X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I note in reviewing: draft-ietf-ipsec-esp-des-md5-03.txt and draft-ietf-ipsec-ah-hmac-md5-04.txt That the counter sizes are different, even though the underlying integrity mechanisms are identical (HMAC MD5). I can see this costing extra code in implementations, which wouldn't be necessary if the counters were of the same size. I apologize if I've brought up a long-dead topic, but I haven't been paying seriously close attention to the list for the last little while. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMqcjB6p9EtiCAjydAQFAjQIAsqltGt7xo40rS4hWYnZC6ffCllnXye++ cQ8cDqyuJX22TbLQcae6TPm/aVu+EH+HWBnnkS2e33bQ/xfqtk9WLA== =0WXW -----END PGP SIGNATURE----- -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 4C16, MS 238, CAR Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Systems Security Services Fax: (ESN) 393-7679 +1 613 763 9435 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Thu Dec 5 20:36:49 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA29850 for ipsec-outgoing; Thu, 5 Dec 1996 20:35:36 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 05 Dec 1996 17:37:23 -0800 From: CJ Lee To: mleech@nortel.ca Cc: ipsec@tis.com Subject: Replay counter sizes: AH vs ESP -Reply Sender: owner-ipsec@ex.tis.com Precedence: bulk >>> "Marcus Leech" 12/05/96 11:31am wrote:>>> I note in reviewing: draft-ietf-ipsec-esp-des-md5-03.txt and draft-ietf-ipsec-ah-hmac-md5-04.txt That the counter sizes are different, even though the underlying integrity mechanisms are identical (HMAC MD5). I can see this costing extra code in implementations, which wouldn't be necessary if the counters were of the same size. Marcus, Both Derrell Piper and I raised the same question without getting any response. I suggest that unless someone can provide reasonable argument to justify the difference of the replay counter sizes, we should make them the same. cj_lee@novell.com From owner-ipsec Fri Dec 6 08:00:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00509 for ipsec-outgoing; Fri, 6 Dec 1996 07:52:12 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Dec 1996 07:32:19 -0500 To: CJ Lee From: Stephen Kent Subject: Re: Replay counter sizes: AH vs ESP -Reply Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk In the re-write of the AH and ESP documents, which we apparently do not have time to discuss next week, the anti-replay counter sizes were both set to be 32 bits. There also was a change to eliminate the sequence windiw size of 1, which would require strict sequencing of all packets on an SA, and instead only integral multiples of 32 were left as window sizes. This latter change was motivated by the observation that the IP layer does not nornmally impose any sequencing and that the anti-replay feature in AH and ESP ought not fundamentally chnage the semantics of the IP layer. The goal of a replay window is to reject as too old any packets that would not, in normal internet operational scenarios, arrive "that late." If one selects an appropriate window size, then packets should rarely be rejected because of benign reordering in traversing the internet, but should be rejected as a result of active attacks that impose significant delays on selected packets (or that duplicate packets within the chosen window). One might argue that a window size of 1 would create a form of denial of service vulnerability as the out of order arrival of a packet would cause rejection of legitimate packets that happend to arrive just slightly out of order. This would then require transport layer or application layer retransmission. Steve From owner-ipsec Fri Dec 6 08:06:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00568 for ipsec-outgoing; Fri, 6 Dec 1996 08:01:12 -0500 (EST) Date: Fri, 6 Dec 1996 08:01:12 -0500 (EST) Message-Id: <199612061301.IAA00568@portal.ex.tis.com> From: "Theodore Y. Ts'o" To: Ran Atkinson Cc: kent@bbn.com, ipsec@tis.com In-Reply-To: Ran Atkinson's message of Thu, 5 Dec 1996 08:10:15 -0800, <199612051610.IAA16407@cornpuffs.cisco.com> Subject: Re: discussing revised documents Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 5 Dec 1996 08:10:15 -0800 From: Ran Atkinson I have heard considerable sentiment against discussing these in San Jose on grounds that the proposed changes haven't been available online prior to the IETF meeting (no one's fault -- just a reality at present), so I'd like to defer this to the mailing list for now with the intent of presenting/discussing these in detail at the Spring 97 IETF meeting. This boils down to the "is a wg meeting for presentations or is it for high-bandwidth discussions that are more efficiently handled in person instead of on the mailing list". Normally I'd agree that it would perhaps be useful for Steve to make a quick presentation of proposed changes, since it might help the e-mail discussion later. As wg presentations go, I believe this is probably would be one of the more useful ones. However, given that we seem to have only once wg slot, I can understand why the wg chairs might want to defer this discussion to the mailing list. The fact that we have only one slot means that we really have to use our time wisely. - Ted From owner-ipsec Fri Dec 6 08:07:45 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00603 for ipsec-outgoing; Fri, 6 Dec 1996 08:02:11 -0500 (EST) From: "Marcus Leech" Message-Id: <199612051931.AA288314281@bcarh6dc.ott.bnr.ca> Subject: Replay counter sizes: AH vs ESP To: ipsec@ans.net Date: Thu, 5 Dec 1996 14:31:21 -0500 (EST) Organization: Nortel Technologies, System Security Services X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I note in reviewing: draft-ietf-ipsec-esp-des-md5-03.txt and draft-ietf-ipsec-ah-hmac-md5-04.txt That the counter sizes are different, even though the underlying integrity mechanisms are identical (HMAC MD5). I can see this costing extra code in implementations, which wouldn't be necessary if the counters were of the same size. I apologize if I've brought up a long-dead topic, but I haven't been paying seriously close attention to the list for the last little while. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMqcjB6p9EtiCAjydAQFAjQIAsqltGt7xo40rS4hWYnZC6ffCllnXye++ cQ8cDqyuJX22TbLQcae6TPm/aVu+EH+HWBnnkS2e33bQ/xfqtk9WLA== =0WXW -----END PGP SIGNATURE----- -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 4C16, MS 238, CAR Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Systems Security Services Fax: (ESN) 393-7679 +1 613 763 9435 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Fri Dec 6 08:19:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00776 for ipsec-outgoing; Fri, 6 Dec 1996 08:13:41 -0500 (EST) Message-Id: <199612061313.IAA00776@portal.ex.tis.com> From: Kurt Stammberger To: "'Ran Atkinson'" Cc: "'ipsec@tis.com'" Subject: RE: ANNOUNCEMENT: 1997 RSA Data Security Conference Date: Thu, 5 Dec 1996 12:04:21 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry, Ran - Several IETF working groups are already planning to meet at the conference, and I thought folks might be interested. We've always run the conference as not-for-profit and cross-industry. Won't happen again. Kurt >---------- >From: Ran Atkinson[SMTP:rja@cisco.com] >Sent: Wednesday, December 04, 1996 10:53 AM >To: Kurt Stammberger >Cc: ipsec@tis.com >Subject: Re: ANNOUNCEMENT: 1997 RSA Data Security Conference > >Kurt, > > Commercial announcements, such as for RSADSI's conference, >are NOT appropriate use for the IPsec WG mailing list. Please >do not post such items here in future. > >Thank you, > >Ran >rja@cisco.com >Co-chair, IPsec WG, IETF > > From owner-ipsec Fri Dec 6 08:27:40 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00895 for ipsec-outgoing; Fri, 6 Dec 1996 08:24:14 -0500 (EST) Date: Fri, 6 Dec 1996 08:24:14 -0500 (EST) Message-Id: <199612061324.IAA00895@portal.ex.tis.com> From: Robert Glenn IAA04917; Fri, 6 Dec 1996 08:23:37 -0500 (EST) Date: Fri, 6 Dec 1996 08:23:37 -0500 (EST) Message-Id: <199612061323.IAA04917@sloth.ncsl.nist.gov> To: ipsec@tis.com Subject: Re: Replay counter sizes: AH vs ESP -Reply Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Keep in mind that these transforms are specified to provide security services for both version 4 and 6 of IP. IPv6 insists that "each extension header be an integer multiple of 8 octets, in order to retain 8-octet alignment for subsequent headers." (RFC1883) The differences in the Replay Prevention fields is primarily due to this alignment. A change to either would require adding an additional 32 bits of wasteful pad. Rob G. -- rob.glenn@nist.gov From owner-ipsec Fri Dec 6 10:06:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01040 for ipsec-outgoing; Fri, 6 Dec 1996 10:01:15 -0500 (EST) From: HUGO@watson.ibm.com Message-Id: <199612061503.KAA209583@mailhub1.watson.ibm.com> Date: Fri, 6 Dec 96 10:03:22 EST To: glenn@snad.ncsl.nist.gov, ipsec@tis.com Subject: Replay counter sizes: AH vs ESP -Reply Sender: owner-ipsec@ex.tis.com Precedence: bulk Ref: Your note of Fri, 6 Dec 1996 08:24:14 -0500 (EST) (attached) > Keep in mind that these transforms are specified to provide security services > for both version 4 and 6 of IP. IPv6 insists that "each extension header > be an integer multiple of 8 octets, in order to retain 8-octet alignment for > subsequent headers." (RFC1883) The differences in the Replay Prevention fields > is primarily due to this alignment. A change to either would require > adding an additional 32 bits of wasteful pad. As I recommended in the past, and still recommend, 32 bit can be easily saved (at least in the SHA case) by truncating the output of HMAC. SO far I got no "official" response to my recommednation during the "last call" of the AH-HMAC documents. Hugo From owner-ipsec Fri Dec 6 11:57:20 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01316 for ipsec-outgoing; Fri, 6 Dec 1996 11:53:14 -0500 (EST) Date: Fri, 6 Dec 1996 11:54:42 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199612061654.LAA27936@earth.hpc.org> To: kent@bbn.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199612050439.VAA19643@baskerville.CS.Arizona.EDU> Subject: Re: Re[2]: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that authentication only is a valid use of ESP. I had always felt that the scope of the protection was more of a distinguishing factor than the type of protection, when discussing AH vs. ESP. This isn't a new idea, it came up a couple of years ago. I'm not sure why tunneling is an issue that requires special discussion. If IPinIP is required, then tunneling follows naturally, IP[AH]*[ESP]*(IP[AH]*[ESP]*)* is a direct corollary, and it is easy to implement. As far as I know, all IPSEC implementations can handle this on input (if all the SA's are relevant to the current host), though generating complex structures on output is a separate question (except for the hop-by-hop enhancement schemes, such as firewalls). If a packet has the form, IP(s,d)AH(spi)... then the header is validated iff 1. (d, spi) maps to a security association known at the current host and 2. The security policy of the current host requires validation of this header (e.g., the first header of the packet). and the AH header is removed after validation iff 1. The current host is the destination or 2. The security policy of the current host requires removal These rules are applied as often as necessary to process a packet. The same rules apply when ESP is the current "next protocol". Hilarie From owner-ipsec Fri Dec 6 14:51:45 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01544 for ipsec-outgoing; Fri, 6 Dec 1996 14:45:54 -0500 (EST) Message-Id: <199612061947.OAA21839@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Kurt Stammberger cc: "'Ran Atkinson'" , "'ipsec@tis.com'" Subject: Re: ANNOUNCEMENT: 1997 RSA Data Security Conference In-reply-to: Your message of "Thu, 05 Dec 1996 12:04:21 PST." <199612061313.IAA00776@portal.ex.tis.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 06 Dec 1996 14:47:22 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Kurt Stammberger writes: > Sorry, Ran - > > Several IETF working groups are already planning to meet at the > conference, That isn't possible, Mr. Stammberger. The IETF meets at IETF meetings, not at RSA conferences. Certainly the IPSEC working group is not meeting at the RSA conference. Perry > and I thought folks might be interested. We've always run > the conference as not-for-profit and cross-industry. > > Won't happen again. > > Kurt > > >---------- > >From: Ran Atkinson[SMTP:rja@cisco.com] > >Sent: Wednesday, December 04, 1996 10:53 AM > >To: Kurt Stammberger > >Cc: ipsec@tis.com > >Subject: Re: ANNOUNCEMENT: 1997 RSA Data Security Conference > > > >Kurt, > > > > Commercial announcements, such as for RSADSI's conference, > >are NOT appropriate use for the IPsec WG mailing list. Please > >do not post such items here in future. > > > >Thank you, > > > >Ran > >rja@cisco.com > >Co-chair, IPsec WG, IETF > > > > > > From owner-ipsec Fri Dec 6 16:09:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01756 for ipsec-outgoing; Fri, 6 Dec 1996 16:03:18 -0500 (EST) To: IETF-Announce:; cc: ipsec@tis.com From: The IESG Subject: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 06 Dec 1996 15:40:15 -0500 Message-ID: <9612061540.aa11029@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider "Combined DES-CBC, HMAC and Replay Prevention Security Transform" for the status of Proposed Standard. The IESG will also consider reclassifying The ESP DES-CBC Transform as Historic. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 27, 1996. Files can be obtained via ftp://ds.internic.net/internet-drafts/ From owner-ipsec Fri Dec 6 16:11:53 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01778 for ipsec-outgoing; Fri, 6 Dec 1996 16:07:19 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: SA Attribute Negotiation Date: Fri, 6 Dec 1996 16:04:45 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk I am a little unclear as to how to negotiate variable length SA attributes, such as any of the Duration attributes. Are these variable length attributes non negotiable? Simply stated by the initiator and accepted by the responder? If not how are we supposed to handle differences in values? It would seem impractical to reject a proposal because the requested Key Duration was not exactly that expected. Is it local policy as to what to do (i.e. accept shorter durations, but reject longer)? I took a quick look at the Cisco code and it looks like variable length attributes are not negotiated. from the comments... * a value of a VPI cannot be specified in a protection suite. * Therefore if att_type is non-zero the matching attribute be basic. or is this an implementation issue? Thanks. Bye. ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Sat Dec 7 13:59:26 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02808 for ipsec-outgoing; Sat, 7 Dec 1996 13:53:01 -0500 (EST) Message-Id: <199612071855.KAA06500@greatdane.cisco.com> To: Greg Carter cc: "'ipsec@tis.com'" , "'isakmp-oakley@cisco.com'" Subject: Re: SA Attribute Negotiation In-reply-to: Your message of "Fri, 06 Dec 1996 16:04:45 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 07 Dec 1996 10:55:08 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, > I am a little unclear as to how to negotiate variable length SA > attributes, such as any of the Duration attributes. > > Are these variable length attributes non negotiable? Simply stated by > the initiator and accepted by the responder? > > If not how are we supposed to handle differences in values? It would > seem impractical to reject a proposal because the requested Key Duration > was not exactly that expected. Is it local policy as to what to do > (i.e. accept shorter durations, but reject longer)? > > I took a quick look at the Cisco code and it looks like variable length > attributes are not negotiated. > from the comments... > > * a value of a VPI cannot be specified in a protection suite. > * Therefore if att_type is non-zero the matching attribute be basic. > > or is this an implementation issue? Absolutely an implementation issue. D-H Group characteristics such as the prime (when establishing a new group description with New Group Mode) should be evaluated. The other ISAKMP SA attribute which can variable is the lifetime. If this is a critical issue for you I imagine that you would not accept an offer of a lifetime which is greater than that which is set in your local policy. Basically, there are no requirements in the document to do any checking for strong primes or realistic lifetimes but I'd imagine that implementations would do some checking. Dan. From owner-ipsec Mon Dec 9 12:01:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05478 for ipsec-outgoing; Mon, 9 Dec 1996 11:47:51 -0500 (EST) Message-Id: <199612091649.IAA01400@fluffy.cisco.com> To: ipsec@tis.com Subject: Updated IPSEC DOI draft Date: Mon, 09 Dec 1996 08:49:38 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Here's an updated IPSEC DOI draft that incorporates most of the comments I've received since its initial posting. Derrell ------ cut here ------ Network Working Group Derrell Piper INTERNET-DRAFT cisco Systems draft-ietf-ipsec-ipsec-doi-02.txt December 9, 1996 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 inapproporiate 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. 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 Piper Expires in 6 months [Page 1] INTERNET DRAFT IPSEC DOI December 9, 1996 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 data origin authentication and/or data 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 capitalised. 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 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 2] INTERNET DRAFT IPSEC DOI December 9, 1996 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. 4.2.2 SIT_SECRECY The SIT_SECRECY type specifies that the security association is being negotiated in an environment that requires labeled secrecy. If SIT_SECRECY is present in the Situation bitmap, the Situation field Piper Expires in 6 months [Page 3] INTERNET DRAFT IPSEC DOI December 9, 1996 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 ISAKMP/Oakley key management daemon. On protected-mode multiuser operating systems, this key management daemon will likely exist as a Piper Expires in 6 months [Page 4] INTERNET DRAFT IPSEC DOI December 9, 1996 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. 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. 4.3.4 Certificate Management Host systems implementing a certificate-based authentication scheme Piper Expires in 6 months [Page 5] INTERNET DRAFT IPSEC DOI December 9, 1996 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. 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 The values 4-15360 are reserved to IANA. Values 15361-16384 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 Piper Expires in 6 months [Page 6] INTERNET DRAFT IPSEC DOI December 9, 1996 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 data origin authentication. 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. Data origin authentication, if required, must be provided as part of the ESP transform. The default ESP transform includes data origin authentication and replay prevention. 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 The values 4-15360 are reserved to IANA. Values 15361-16384 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. Piper Expires in 6 months [Page 7] INTERNET DRAFT IPSEC DOI December 9, 1996 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 data origin authentication. The following table lists the defined AH Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform Value --------- ----- RESERVED 0 AH_MD5_KPDK 1 AH_MD5_HMAC 2 AH_MD5_HMAC_REPLAY 3 AH_SHA_MHAC_REPLAY 4 The values 5-15360 are reserved to IANA. Values 15361-16384 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 and RFC-1828. This mode should be used only for compatibility with existing implementations. 4.4.3.2 AH_MD5_HMAC The AH_MD5_HMAC type specifies the transform described in [HMAC]. This mode should be used only for compatibility with existing implementations. 4.4.3.3 AH_MD5_HMAC_REPLAY The AH_MD5_HMAC_REPLAY type specifies the transform described in [HMACMD5]. This transform MUST be supported by all implementations and is the preferred AH transform for the IPSEC DOI. 4.4.3.4 AH_SHA_HMAC_REPLAY The AH_SHA_HMAC_REPLAY type specifies the transform described in [HMACSHA]. While not required, it is strongly recommended that all implementations include the AH_SHA_HMAC_REPLAY transform in addition Piper Expires in 6 months [Page 8] INTERNET DRAFT IPSEC DOI December 9, 1996 to AH_MD5_HMAC_REPLAY. 4.4.4 IPSEC ESP Transform Identifiers The Encapsulating Security Protocol (ESP) defines one mandatory and several optional transforms used to provide data confidentiality. The following table lists the defined ESP Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 ESP_DES_CBC_TRANSPORT 1 ESP_DES_CBC_TUNNEL 2 ESP_3DES_CBC 3 ESP_DES_CBC_HMAC_REPLAY 4 The values 5-15360 are reserved to IANA. Values 15361-16384 are reserved for private use. 4.4.4.1 ESP_DES_CBC_TRANSPORT The ESP_DES_CBC_TRANSPORT type specifies the ESP transform described in RFC-1827 and RFC-1829, operating in Transport Mode. This mode should be used only for compatibility with existing implementations. 4.4.4.2 ESP_DES_CBC_TUNNEL The ESP_DES_CBC_TUNNEL type specifies the ESP transform described in RFC-1827 and RFC-1829, operating in Tunnel Mode. This mode should be used only for compatibility with existing implementations. 4.4.4.3 ESP_3DES_CBC The ESP_3DES_CBC type specifies the transform described in RFC-1851. This mode should be used only for compatiblity with existing implementations. 4.4.4.4 ESP_DES_CBC_HMAC_REPLAY The ESP_DES_CBC_HMAC_REPLAY type specifies the transform described in [Hughes]. This transform MUST be supported by all implementations and is the preferred ESP transform for the IPSEC DOI. 4.5 IPSEC Security Association Atttributes The following SA attribute definitions are used in phase II of an ISAKMP/Oakley negotation. Attribute types can be either Basic (B) or Piper Expires in 6 months [Page 9] INTERNET DRAFT IPSEC DOI December 9, 1996 Variable-Length (V). Encoding of these attributes is defined in the base ISAKMP specification. Attribute Classes class value type ------------------------------------------------- Auth Key Life Type 1 B Auth Key Life Duration 2 B/V Enc Key Life Type 3 B Enc Key Life Duration 4 B/V SA Life Type 5 B SA Life Duration 6 B/V Replay Protection 7 B Group Description 8 B CA Distinguished Name 9 B Class Values Auth Key Life Type Enc Key Life Type SA Life Type seconds 1 kilobytes 2 Values 3-65000 are reserved to IANA. Values 65001-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. Replay Protection not required 0 required 1 Values 2-65000 are reserved to IANA. Values 65001-65535 are for experimental use. Group Description default group 1 ([IO], Section 5.5.1) Values 2-32767 are reserved to IANA. Values 32768-65535 are for private use among mutually consenting parties. CA Distinguished Name DNS Security 1 (Section 4.8) Values 2-32767 are reserved to IANA. Values 32768-65535 Piper Expires in 6 months [Page 10] INTERNET DRAFT IPSEC DOI December 9, 1996 are for private use among mutually consenting parties. 4.5.1 Attribute List Parsing Requirement In order 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) 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.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 ! Piper Expires in 6 months [Page 11] INTERNET DRAFT IPSEC DOI December 9, 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 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 Intepretation (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, Piper Expires in 6 months [Page 12] INTERNET DRAFT IPSEC DOI December 9, 1996 of the secrecy level identifier. o Secrecy Category Length (2 octets) - Specifies the length, in bits, of the secrecy category (compartment) bitmap. o Secrecy Category Bitmap (variable length) - A bitmap used to designate secrecy categories (compartments) that are required. o Integrity Length (2 octets) - Specifies the length, in octets, of the integrity level identifier. o Integrity Category Length (2 octets) - Specifies the length, in bits, of the integrity category (compartment) bitmap. o Integrity Category Bitmap (variable length) - A bitmap used to designate integrity categories (compartments) that are required. 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 data origin authentication without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (Hughes) 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 Piper Expires in 6 months [Page 13] INTERNET DRAFT IPSEC DOI December 9, 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Identification Payload Format The Identification Payload field 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 identification data, including the generic header. o Identification Type (1 octet) - Value describing the identity information found in the Identification Data field. o RESERVED (3 octets) - Unused, must be zero (0). 4.6.2.1 Identifiction 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_RANGE 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_RANGE 6 The values 6-500 are reserved to IANA. Values 501-512 are reserved for private use. 4.6.2.2 ID_IPV4_ADDR The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. Piper Expires in 6 months [Page 14] INTERNET DRAFT IPSEC DOI December 9, 1996 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". 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". 4.6.2.5 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 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_RANGE The ID_IPV6_ADDR_RANGE 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.7 IPSEC Security Parameter Index (SPI) Encoding ISAKMP defines the SPI field as eight octets in length, however the IPSEC transforms use only four octets. All implementation MUST use the following mapping for the ISAKMP SPI field in the IPSEC DOI. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ISAKMP SPI Encoding Piper Expires in 6 months [Page 15] INTERNET DRAFT IPSEC DOI December 9, 1996 The ISAKMP SPI field is defined as follows: o SPI - Security Paramater Index (4 octets) - contains the SPI value which identifies the security association. o RESERVED (4 octets) - Unused, must be zero (0). 4.8 IPSEC Certificate Authorities The ISAKMP Certificate Request Payload allows either side of an ISAKMP negotiation to request its peer to provide a certificate chain needed to authenticate itself. The Certificate Request Payload includes a list of acceptable Certificate Types and Certificate Authorities. Appropriate certificate chains are then returned in a Certificate Payload response. The IPSEC DOI defines the following Certificate Authorities for the processing of Certificate Request Payloads. See Section 4.5 for details on the specific data attribute type values for these CAs. Certificate Authority --------------------- DNS Security 4.8.1 DNS Security This CA type represents the combination of KEY and SIG records, as defined in [DNSSEC], that can be used for authentication. The particular encoding required to formulate the Certificate Payload (response) is TBD. 4.9 IPSEC Key Exchange Requirements The IPSEC DOI introduces no additional Key Exhange types. 5. Security Considerations This entire draft pertains to a hybrid protocol, combining Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive 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. Acknowledgements This document is derived, in part, from previous works by Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, Piper Expires in 6 months [Page 16] INTERNET DRAFT IPSEC DOI December 9, 1996 and Dave Carrel. References [DNSSEC] Eastlake, Donald E., Kaufman, Charles W., "Domain Name System Security Extensions", draft-ietf-dnssec-secext-10.txt. [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-md5-01.txt. [HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with Replay Prevention," draft-ietf-ipsec-ah-hmac-md5-03.txt. [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA IP Authentication with Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-03.txt. [Hughes] Hughes, J., Editor, "Combined DES-CBC, HMAC and Replay Prevention Transform," draft-ietf-ipsec-esp-des-md5-03.txt. [IO] Carrel, D., Harkins, D., "The Resolution of ISAKMP with Oakley," draft-ietf-ipsec-isakmp-oakley-02.txt. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-06.{ps,txt}. [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-ietf-ipsec-oakley-01.txt. [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key Management API, Version 2", draft-mcdonald-pf-key-v2-00.txt, work in progress. 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 17] From owner-ipsec Mon Dec 9 12:57:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05595 for ipsec-outgoing; Mon, 9 Dec 1996 12:51:01 -0500 (EST) Date: Mon, 9 Dec 1996 09:53:21 -0800 From: Ran Atkinson Message-Id: <199612091753.JAA28578@cornpuffs.cisco.com> To: CJ_LEE@novell.com Subject: Re: Replay counter sizes: AH vs ESP -Reply In-Reply-To: Organization: cisco Systems Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk [speaking only for myself] In article CJ_LEE@novell.com wrote: >Marcus, > Both Derrell Piper and I raised the same question >without getting any response. Incorrect. I'll repeat the explanation below for those who missed it the first time it appeared on this list. >I suggest that unless >someone can provide reasonable argument to justify >the difference of the replay counter sizes, we should >make them the same. The AH and ESP are designed to be used with both IPv4 and IPv6. IPv6 _requires_ 64-bit alignment, which causes more bandwidth to be consumed in various places, while IPv4 does not require this. In order to avoid gratuitously consuming IPv4 bandwidth on an IPv6-only requirement, the replay counter sizes were made selectable. I've written about as much IPsec code as anyone. It really isn't a lot of code and it isn't a lot of complexity to support two replay counter sizes (even on BSD with its mbuf data structures). Ran rja@cisco.com From owner-ipsec Tue Dec 10 11:47:38 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08301 for ipsec-outgoing; Tue, 10 Dec 1996 11:42:35 -0500 (EST) Message-Id: <199612101645.IAA02030@fluffy.cisco.com> To: rja@cisco.com (Ran Atkinson) Cc: ipsec@tis.com Subject: Re: Replay counter sizes: AH vs ESP -Reply In-reply-to: Your message of "Mon, 09 Dec 1996 09:53:21 PST." <199612091753.JAA28578@cornpuffs.cisco.com> Date: Tue, 10 Dec 1996 08:45:09 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk > The AH and ESP are designed to be used with both IPv4 and IPv6. IPv6 > _requires_ 64-bit alignment, which causes more bandwidth to be consumed in > various places, while IPv4 does not require this. In order to avoid > gratuitously consuming IPv4 bandwidth on an IPv6-only requirement, the replay > counter sizes were made selectable. I must have missed this. Personally, I think a negotiated replay counter adds unnecessary complexity to the protocol. I'd much rather see a fixed 64-bit field than a negotiated one. In any case, neither the AH nor ESP drafts describe this field as negotiable and they continue to assert different sizes for the field. This has not been addressed in the drafts. Derrell From owner-ipsec Tue Dec 10 16:49:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09468 for ipsec-outgoing; Tue, 10 Dec 1996 16:43:45 -0500 (EST) Message-Id: <199612102143.NAA17334@mailsun3-fddi.us.oracle.com> Date: 10 Dec 96 13:39:15 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Agenda 37th IETF - December 10, 1996 Cc: rja@cisco.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.25) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk Agenda of the IPSEC Working Group Thirty-seventh IETF - San Jose (December 10, 1996) TUESDAY, December, 1996 1530-1730 IP Security Protocol WG 15:30 Introductions Charter RFC's and Internet Drafts Process and Milestones 15:40 Architecture Architecture Document Update - Steve Kent 15:45 IP layer security - ESP and AH Status of Drafts and RFC's ESP and AH and ... 15:50 HMAC Status - Hugo Krawczyk 15:55 Compression - Rodney Thayer Bob Monsour draft-thayer-seccomp-00.txt draft-sabin-esp-des3-lzs-md5-00.txt draft-sabin-lzs-payload-00.txt 16:10 IP Layer Issues Replay Counter Size Other 16:20 Key Management ISAKMP - Doug Maughan 16:40 Oakley & ISAKMP/ Oakley Resolution - DOI - 16:45 In-Line Keying - Bill Sommerfield 16:55 GKMP and Multicast Security - Hugh Harney 17:10 API's - Dan McDonald draft-mcdonald-simple-ipsec-api-00.txt 17:15 Open Work Items (discussion), Paul Lambert Interoperability Testing and Implementors List 17:25 Summary and Action Items 17:30 Adjourn From owner-ipsec Wed Dec 11 07:23:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10018 for ipsec-outgoing; Wed, 11 Dec 1996 07:19:32 -0500 (EST) Date: Wed, 11 Dec 1996 14:21:47 +0200 (EET) From: Santeri Paavolainen X-Sender: santtu@hutcs To: Bob Monsour cc: ipsec@tis.com Subject: Re: Decoupling compression and security In-Reply-To: <3.0.32.19961126100305.00987ae0@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 26 Nov 1996, Bob Monsour wrote: (Yes, I'm a little slow to reply) > At 10:34 AM 11/25/96 +0200, Santeri Paavolainen wrote: > >Of course, this would mean there is overhead of SPI vs. "bit", but I > >think the generality is a clear plus. What if you later find out the > >cryptographic transformation you have embedded the compression layer > >is not secure? Also, there is no clear way how to interoperate between > >different transformations which have the same compression engine (you > >must remember that each transformation should be self-contained from > >the coding point of view). > ... > > This is more than just an issue of the overhead of an SPI vs. a "bit". Let > me explain by way of example. Let's say that a security association has > been set up for traffic traveling from a sender to a receiver. Thus the SPI > for traffic in that direction is specified. Let's also say that the SPI > specifies the use of a particular set of compression, encryption and > authentication algorithms. Then, let's say that the sender wants to send a > datagram to the receiver. Suppose the data expands. The sender would then > want to send the original uncompressed form of the data. Under our > proposal, all the sender would have to do is to change a bit at the start > of the payload. Under what you propose, the SPI is no longer valid since > the reciever will erroneously attempt to decompress raw data. Your method > would thus require that a new SPI be used which would likely require some > renegotiation between the sender and receiver as to which algorithms and > modes are to be used for the connection. Why regenotiation? Why can't they negotiate multiple valid SPI groups for a single "connection"? Is this a limit of ISAKMP? The way I have read the drafts I see no implicit reason that a single "connection" could not have multiple valid SPI groups. In essence, there would be two valid SPI groups negotiated for the connection CRYPT,COMPRESS and (used for compressed and crypted packets) CRYPT (packets which do not benefit from compression) By the way (a general question) -- how do current implementations handle the following situations: - A single "receiving port" (defined such as a TCP port) receiving packets with different SPI's or no IPSEC at all, and handling them correctly (as with UDP receiver, receiving packets from multiple senders, each with their own different security parameters eg. SPIs, or having the abovementioned maybe-compressed packet situation) - Sending packets with different SPIs from same source to same destination (several processes with access to the same socket, each having set its own security parameters!) - Handling of deeply-nested packets, eg. ESP(ESP(ESP(ESP(ESP(...))))), all with the same or different SPIs (this is a denial of service attack) when there is no receiver wanting packets in a such configuration And one more thing that has been in my mind: Instead of defining separate transport and tunnel modes for all transformations (AH and ESP alike), why not define just transformations which take no ground whether they are working on a transformation or tunnel packet? Then there would be a need for a "tunnel transformation" which would in essence do IP-in-IP encapsulation, but within IPSEC and SPI framework. Like that ESP-tunneled packet would look ESP(TUNNEL(packet)) Naturally, this incurs the overhead of having to insert Yet Another SPI to the transported packet. Truly, I do not think that replacing the current scheme with this would be good.. but there are most likely some situations where someone wants to TUNNEL a packet without wanting to use tunneling ESP/AH for it (or any other IPSEC transformation that would support tunneling)? -- sjpaavol@cc.Helsinki.FI I have become death, destroyer of the worlds. From owner-ipsec Wed Dec 11 08:07:26 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA10177 for ipsec-outgoing; Wed, 11 Dec 1996 08:06:00 -0500 (EST) Date: Wed, 11 Dec 1996 08:06:00 -0500 (EST) Message-Id: <199612111306.IAA10177@portal.ex.tis.com> From: Robert Glenn HAA06856; Wed, 11 Dec 1996 07:38:50 -0500 (EST) Date: Wed, 11 Dec 1996 07:38:50 -0500 (EST) Message-Id: <199612111238.HAA06856@sloth.ncsl.nist.gov> To: piper@tgv.com Subject: Re: Replay counter sizes: AH vs ESP -Reply Cc: rob.glenn@nist.gov, ipsec@tis.com Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Derrell, Both the AH HMAC transform drafts specify that the field is optional. >From the HMAC-MD5 draft - Section 2.1 Replay Prevention "Each IPsec Security Association specifies whether Replay Prevention is used for that Security Association. If Replay Prevention is NOT in use, then the Authentication Data field will directly follow the SPI field." Since the presence of the replay field is known before you receive the packet (i.e. it was negotiated as part of the SA), the added complexity is rather low. As the current ESP transform is specified, the Replay Prevention field cannot be optional since its removal would break 64-bit alignment. Rob G. From owner-ipsec Wed Dec 11 14:23:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13599 for ipsec-outgoing; Wed, 11 Dec 1996 14:18:49 -0500 (EST) Message-Id: <199612111922.LAA24802@scv3.apple.com> Subject: Status of SKIP/ISAKMP/Oakley Date: Wed, 11 Dec 96 11:21:02 -0000 x-sender: lubetv@mail.apple.com x-mailer: Claris Emailer 1.1 From: Vincent Lubet To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm very new to this working group and I would like to find out what is the standardization status of SKIP, ISAKMP and Oakley. Is it true that: - ISAKMP and SKIP are optional for IPV4 - ISAKMP is required for IPV6? Thanks, Vincent Lubet Apple Computer, Inc. 1 Infinite Loop, M/S: 301-2CT Cupertino, CA 95014, USA From owner-ipsec Fri Dec 13 11:41:05 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00155 for ipsec-outgoing; Fri, 13 Dec 1996 11:32:42 -0500 (EST) Message-ID: From: Roy Pereira To: "'Greg Carter'" , "'Daniel Harkins'" Cc: "'ipsec@tis.com'" , "'isakmp-oakley@cisco.com'" Subject: RE: SA Attribute Negotiation Date: Thu, 12 Dec 1996 19:48:11 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >> I am a little unclear as to how to negotiate variable length SA >> attributes, such as any of the Duration attributes. >> >> Are these variable length attributes non negotiable? Simply stated by >> the initiator and accepted by the responder? >> >> If not how are we supposed to handle differences in values? It would >> seem impractical to reject a proposal because the requested Key Duration >> was not exactly that expected. Is it local policy as to what to do >> (i.e. accept shorter durations, but reject longer)? I would like to see a standard length for some of the attributes, like key durations. If we decide upon a 32 bit integer to represent these and other values, then all implementations would be able to handle these attributes correctly. But if one implementation sends out a key duration of 1^199 seconds and codes it as a 128 bit integer, a lot of implementations will not be able to utilize it and thus it will not accept that proposal. We need to define standard variable attribute that has a lenth of 32 bits. This would be used by attributes that need integers as values, but that can't or dont wish to represent them as 16-bits with a basic attribute. From owner-ipsec Mon Dec 16 15:49:56 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05510 for ipsec-outgoing; Mon, 16 Dec 1996 15:37:16 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: Another SA Attribute Question Date: Mon, 16 Dec 1996 15:35:18 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello All, Are all SA attributes defined in the ipsec doi mandatory? ie should a transform payload contain an entry for each attribute? If not how should missing attributes be handled? Should the responder send back any att\values it will be using but that were not specified in the initiators transform payload?, reject? local policy\implementation issue?. Thanks. Bye. ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Mon Dec 16 16:48:07 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07364 for ipsec-outgoing; Mon, 16 Dec 1996 16:45:30 -0500 (EST) Message-Id: <9612162147.AA19450@ludwigia.raleigh.ibm.com> To: hughes@network.com Cc: ipsec@tis.com, iesg@ietf.org Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard In-Reply-To: Your message of "Fri, 06 Dec 1996 15:40:15 EST." <9612061540.aa11029@ietf.org> Date: Mon, 16 Dec 1996 16:47:27 -0400 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a number of comments on the draft. IMO, the draft could use another revision (to clarify some points) before being promoted to Proposed Standard. Most of my concerns are minor. However, the first two points may be significant. First, the draft says: >1. Discussion > > This draft allows a combination of MD5 and DES-CBC. In addition to > privacy, the goal of this transform is to ensure that the packet is > authentic, can not be modified in transit, or replayed. The last sentence is misleading. In contrast to the standalone AH headers (which cover the invariant fields of the IP header), the transform described in the draft apparently does not cover the IP header (or if it does, this fact completely escaped me). Thus, modifications to the IP header fields (including the source/dest addresses, which are part of the TCP transport identifiers) would not be detected by this transform. Thus, I conclude that the combined transform provides *weaker* authentication than the standalone transforms. This surprises me, and seems a mistake. Another important point: > 1. (Optional step) Decrypt the first bock of data using the > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- > ity check" of the count. If the count has decreased below the win- > dow or has increased by more than 65k, then it is safe to discard > this packet as either a replay, non-authentic or too old. If the > count is within 65K, then the probability that the packet is > authentic is 65535/65536. (The following replay check and HMAC > check are both still required). Maybe I'm missing something, but the above would appear to not handle network partitions well. If a destination becomes unreachable (for whatever reason), and the sender sends 65K packets during the outage, packets sent after the destination becomes reachable again will continue to be rejected. Thus, this "optimization" seems wrong. The remainder of my comments are fairly minor. The draft never mentions IPv6. It apparently is intended to cover both IPv4 and IPv6, and I think that fact should be explicitely stated at the beginning to minimize confusion. >2. Packet Format > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- > | Security Parameters Index (SPI) | ^ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | How about putting bit numbers at the top (as is standard in other drafts) to make it obvious that fields are 32 bits in size. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | | > + Initialization Vector (Optional) + | > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I assume the IV needs to be a multiple of 64-bits (to insure that the Data starts on a 64-bit boundary for IPv6)? If so, the draft should state this explicitely (it doesn't seem to). > This field is optional and is only used when an explicit IV is nego- > tiated during key exchange. This field is contains random data or ^^ Extra word. > For the packet which the explicit IV is received, the explicit IV is ^ Missing word "in" >2.3. Replay Prevention > > Replay Prevention is an unsigned 32 bit incrementing counter starting > at a mutual agreed upon value (see Key Material) and is enforced to > be within a mutually negotiated window size. This section should more clearly state that every distinct IP packet (including retransmissions) must use a new counter value. Retransmissions that use the same replay counter may result in deadlock. > If a value of 32 is negotiated, then the most recent 32 packets are > allowed to arrive out of order. That is, these 32 packets can arrive The first sentence above is misleading. The "most recent" 32 packets aren't accepted. Only those packets whose replay counter is within 32 of the highest numbered packet received so far are accepted. > in any sequence relative to each other except that these packets are > guaranteed to arrive only once. Appendix A has actual code that Change "guaranteed to arrive only once" to "guaranteed to be accepted only once" > field. This field is an integral number of bytes in length; the fol- > lowing padding and pad length fields will help provide alignment to a > double word boundary. I found the above wording a bit confusing. How about "This field specifies the size of the payload in bytes" > tiator direction). The IV_key_ remains constant for all packets send > in this direction. "send" should be "sent". > CBC chaining with an constant IV_key_ is used. if an IV is present in > the packet, then the IV_key_ is not used and is replaced by the IV. I found the above somewhat confusing. How about rewording something like: By default, CBC chaining with a constant IV_key_ is used. The value of IV_key_ is negotiated as part of the SPI creation. It is also possible (if agreed upon by both parties during SPI setup) to include an IV in each packet, in which case the included IV is used. Note that the packet itself contains no indication of whether or not an IV in is included; this knowledge is maintained as part of the Security Association. > 1. (Optional step) Decrypt the first bock of data using the > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- > ity check" of the count. If the count has decreased below the win- > dow or has increased by more than 65k, then it is safe to discard > this packet as either a replay, non-authentic or too old. If the > count is within 65K, then the probability that the packet is > authentic is 65535/65536. (The following replay check and HMAC > check are both still required). What does it mean for the count to be "decreased below the window"? Also, I don't understand where the 65535/65536 probability comes from or what it means. > 3. Calculate the HMAC using the HMAC_key_ and create the digest > from the SPI, IV (if present) count, data, pad, pad length, and > payload type and checking the result at digest at the end of ^^^^^^^^ Typo. Perhaps reword as "compare the result with the digest"? >Appendix A > > This is a routine that implements a 32 packet window. This is intend- > ed on being an implementation sample. This code in fact assumes that the replay counter always starts at 0. It should state this, since this assumption is not made elsewhere in the draft. Also, if it is reasonable to always start the replay counter at zero, why does the draft not simply require this? Right now, the initial counter value is negotiated. Thomas From owner-ipsec Tue Dec 17 12:08:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00874 for ipsec-outgoing; Tue, 17 Dec 1996 12:02:40 -0500 (EST) Message-Id: <199612171705.JAA05985@fluffy.cisco.com> To: carterg@entrust.com (Greg Carter) cc: ipsec@tis.com ('ipsec@tis.com'), isakmp-oakley@cisco.com ('isakmp-oakley@cisco.com') Subject: Re: Another SA Attribute Question In-reply-to: Your message of "Mon, 16 Dec 1996 15:35:18 EST." Date: Tue, 17 Dec 1996 09:05:08 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I don't view most (any?) of the Phase II attributes as mandatory. I think we should define default values for each and allow either side to override the defaults if they so choose (based on local policy). If people generally agree with this, I'll pick some defaults for the next version of the draft. This would also help to address Roy's concerns that a default attribute size be specified for basic interoperability. Derrell From owner-ipsec Tue Dec 17 14:46:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA00464 for ipsec-outgoing; Tue, 17 Dec 1996 14:39:33 -0500 (EST) Date: Tue, 17 Dec 1996 14:41:59 -0500 Message-Id: <199612171941.OAA11918@MAILSERV-2HIGH.FTP.COM> To: ipsec@tis.com Subject: ISAKMP Notify and Delete payloads and Protocol-Id From: mamros@ftp.com (Shawn Mamros) Reply-To: mamros@ftp.com Repository: mailserv-2high.ftp.com, [message accepted at Tue Dec 17 14:41:56 1996] Originating-Client: cavedog.ftp.com Sender: owner-ipsec@ex.tis.com Precedence: bulk In the isakmp-06 draft, the Notify and Delete payloads both contain a Protocol-Id field, so that the SPI(s) contained in those payloads can be associated with the proper protocol SA(s) in question. However, Protocol-Id values (other than value 1, which is always used for the ISAKMP protocol itself) are defined in the DOI document, and there is no field in the Notify and Delete payloads which specify which DOI is being used. (The only place the DOI is specified is in the Security Association payload.) I suppose that, as long as any new Protocol-Id values for any yet-to- be-defined DOIs do not conflict with those already assigned for IPSEC AH and IPSEC ESP, then this isn't a problem. But, if there is a possibility of conflict, then there will have to be some way to associate the Protocol-Id with the proper DOI. Adding a DOI field to the Notify and Delete payloads might be one way to do this, if it's needed. So, I guess what I'm wondering is: Is there a possibility of conflicting Protocol-Ids between different DOIs? And, if so, what should be done about it for the Notify and Delete payloads? If, on the other hand, there will be no conflicts - if all future Protocol-Ids will be unique, regardless of DOI - then this should be stated somewhere. -shawn From owner-ipsec Tue Dec 17 18:05:21 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA01726 for ipsec-outgoing; Tue, 17 Dec 1996 18:02:30 -0500 (EST) Message-ID: From: Roy Pereira To: "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: FW: tunnel mode Date: Tue, 17 Dec 1996 18:06:07 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >---------- >From: Roy Pereira >Sent: Tuesday, December 17, 1996 6:00 PM >To: 'Derrell Piper' >Subject: RE: tunnel mode > >Derrell, how do we do DES-HMAC-MD5/SHA1 in tunnel mode? Your >current draft doesn't allow for this. Am I missing something? It also >doesn't include the newer 3DES-HMAC-MD5/SHA1. >Except for the old-style ESP, you can't in the current incarnation of the >drafts. > >I made a note during the ipsec wg that I needed to add Tunnel and Transport >SA Attributes. They'll be in the next version of the draft, along with a >proscribed set of defaults for the existing attributes. >Suggestions on what those defaults should be are most welcome... >SA Attributes is what I was thinking as well. >This also leads to us questioning if we should have a HMAC attribute as well? >As in which HMAC (if any) do you wish to use for the Encription transform X. >Then we could have ESP transforms > DES = 1 > 3DES = 2 > RC5 = 3 > >with attributes of: > IV size (int) [default=0, ECB mode] > Tunnel Mode (bool) [default=false] > HMAC Alg (int) > None = 0 (dont use HMAC authentication) [default] > MD5 = 1 > SHA1 = 2 > Replay (bool) [default=false] > key life type (int) [default=0, no limit] > seconds = 1 > kilobytes = 2 > key life duration (int) > > > > > > From owner-ipsec Tue Dec 17 23:10:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA03254 for ipsec-outgoing; Tue, 17 Dec 1996 23:08:21 -0500 (EST) Message-Id: <199612180411.UAA08264@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Roy Pereira Cc: "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: Re: FW: tunnel mode In-Reply-To: Your message of "Tue, 17 Dec 1996 18:06:07 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Dec 1996 20:11:19 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not sure, but I believe this was Derrell Piper responding to Roy Pereira: > >Derrell, how do we do DES-HMAC-MD5/SHA1 in tunnel mode? Your > >current draft doesn't allow for this. Am I missing something? It also > >doesn't include the newer 3DES-HMAC-MD5/SHA1. > > Except for the old-style ESP, you can't in the current incarnation of > the drafts. > > I made a note during the ipsec wg that I needed to add Tunnel and > Transport SA Attributes. They'll be in the next version of the draft, along > with a proscribed set of defaults for the existing attributes. > > Suggestions on what those defaults should be are most welcome... I don't see why Tunnel or Transport attributes need to be negotiated. There shouldn't be anything wrong with using a single SA for both provided there were no PFS restrictions on the SA. This seems to me to be an issue of the particular IPsec implementation's policy engine, not of SA negotiation. If some packet needs security to go through an encrypting router, and a SA exists to that router then the policy defined in that SA is applied in tunnel mode. If some later packet needs to go to the router itself (not through it) why not just apply the SA in transport mode? Dan. From owner-ipsec Wed Dec 18 00:46:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03633 for ipsec-outgoing; Wed, 18 Dec 1996 00:43:09 -0500 (EST) Message-ID: <32B7850C.2781@cs.umass.edu> Date: Wed, 18 Dec 1996 00:45:48 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: isakmp-oakley@cisco.com CC: ipsec@tis.com Subject: Re: key life attributes (Was: Re: FW: tunnel mode) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > Then we could have ESP transforms [...] with attributes of: [...] > key life type (int) [default=0, no limit] > seconds = 1 > kilobytes = 2 > key life duration (int) Is there interest in supporting a second-order key life, e.g. the minimum of a "clock lifetime" (measured in secs) and a "bandwidth lifetime" (measured in kb) ? Then it's possible to express the policy "it's time to change keys if the current key _either_ is old _or_ has been heavily used". I imagine this would require adding a fourth key life type (i.e. 3) for the combo option, and a second (optional?) key life duration field for the second duration value. It might also be done with implicit typing of the key lifetime(s) and reinterpreting the existing fields. The logic for the latter might look like: if (KeyLifeDurVal[0] == 0) if (KeyLifeDurVal[1] == 0) /* unlimited lifetime */ else /* bandwidth lifetime of KeyLifeDurVal[1] kb only */ fi else if (KeyLifeDurVal[1] == 0) /* time lifetime of KeyLifeDurVal[0] seconds only */ else /* lifetime = MIN(KeyLifeDurVal[0] secs., KeyLifeDurVal[1] kb) */ fi fi But my sense is that implicit typing is _not_ the way to go. -Lewis From owner-ipsec Wed Dec 18 10:57:59 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07412 for ipsec-outgoing; Wed, 18 Dec 1996 10:52:52 -0500 (EST) Message-Id: <199612181554.KAA09649@relay.hq.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: "Waterhouse, Richard" Date: Wed, 18 Dec 1996 15:55:47 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ISAKMP DOI Question (General, Not IP Specific) CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Sender: owner-ipsec@ex.tis.com Precedence: bulk Richard > - There can only be one SA between two machines at a given time. I suppose this depends on who owns the SA i.e. if the owner of an SA is identified by the IP addr only (and a host only has one IP addr) then IMHO there can be only one pair of unidirectional SAs between any pair of machines. Clearly, if SAs are associated with protocol numbers, user ids ?..., then many SAs can exist between any pair of hosts. > Therefore since there can only be one DOI to an SA, there can only > be one DOI active between two machines at a given time. Many SAs may be established/exist within any DOI ? > I can't find this in the standard. I understand "one DOI to an SA" but > not "one SA between two machines at a given time" What am I overlooking > ? Establishment of multiple SAs in one SA proposal can only be done for one DOI i.e. you cannot establish 2 SAs for 2 different DOIs within the same message exchange sequence. > My concern is that in my context I can have multiple independent types > of applications running between a pair of machines at a given time. And > each application type has independently defined security properties that > must be negotiated. It had been my intent to at least consider modeling > each application type as a different DOI. But if the above reported > statement is correct this approach can't be used. IMHO you do not have to define, and use, multiple DOIs to permit you to use multiple applications - just associate the application with the SA. **************************************************** Elfed T. Weaver Defence Research Agency Malvern UK weaver@hydra.dra.hmg.gb From owner-ipsec Wed Dec 18 11:41:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA07815 for ipsec-outgoing; Wed, 18 Dec 1996 11:39:55 -0500 (EST) Message-Id: <199612181641.LAA12602@relay.hq.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: isakmp-oakley@cisco.com Date: Wed, 18 Dec 1996 16:44:29 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: DOIs CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Sender: owner-ipsec@ex.tis.com Precedence: bulk In the ISAKMP header we have: Init Cookie Resp Cookie Next Payload Ver .. Exchange Type Flags Message ID Length Now, Exchange types are DOI specific ? Payload ordering/validity is exchange specific ? IMHO the ISAKMP header format should be: Destination SPI (or Cookie if you really believe they are useful ?) Source SPI (ditto) [SPIs being 4 octet fields] DOI [2 octets] Version [1 octet] Exchange type [1 octet] Next Payload [1 octet] Message ID [2 octets] Flags [1 octet] Length [4 octets] Processing the ISAKMP header:- Validate SPIs/Cookies Test if DOI supported Test if this version of the DOI is supported Test if Exchange type is supported by this DOI Test if Next Payload is legal for this Exchange Flags Message ID Length The ISAKMP header MUST be mandatory for ALL DOIs. This, IMHO, is a more natural processing order ? Also, assuming that DOIs have their own SPI name space and protocol ID name space, having the DOI in the mandatory ISAKMP header will identify which SA Delete messages actually relate to ? Leaving the situation Identifier in the SA payload would seem reasonable since the SA proposals, effectively encapsulated by the SA payload header, are all being established for the same situation. If I am not missing anything, it is only at this level of processing does it become necessary to know the situation. **************************************************** Elfed T. Weaver Defence Research Agency Malvern UK weaver@hydra.dra.hmg.gb From owner-ipsec Wed Dec 18 11:51:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA07888 for ipsec-outgoing; Wed, 18 Dec 1996 11:49:54 -0500 (EST) Date: Wed, 18 Dec 1996 11:51:54 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199612181651.LAA28698@earth.hpc.org> To: weaver@hydra.dra.hmg.gb Cc: ipsec@tis.com In-reply-to: Yourmessage <199612181613.JAA00614@baskerville.CS.Arizona.EDU> Subject: Re: ISAKMP DOI Question (General, Not IP Specific) Sender: owner-ipsec@ex.tis.com Precedence: bulk > > - There can only be one SA between two machines at a given time. > I suppose this depends on who owns the SA i.e. if the owner of an SA > is identified by the IP addr only (and a host only has one IP addr) > then IMHO there can be only one pair of unidirectional SAs between any pair of > machines. Why? The SA has an identifier; you can several SA's for the same identities without fear of confusion. From owner-ipsec Wed Dec 18 12:45:32 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08209 for ipsec-outgoing; Wed, 18 Dec 1996 12:42:08 -0500 (EST) Message-Id: <199612181743.MAA15608@relay.hq.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: ho@earth.hpc.org (Hilarie Orman) Date: Wed, 18 Dec 1996 17:46:43 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ISAKMP DOI Question (General, Not IP Specific) CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Wed, 18 Dec 1996 11:51:54 -0500 > From: ho@earth.hpc.org (Hilarie Orman) > To: weaver@hydra.dra.hmg.gb > Cc: ipsec@tis.com > Subject: Re: ISAKMP DOI Question (General, Not IP Specific) > > > - There can only be one SA between two machines at a given time. > > > I suppose this depends on who owns the SA i.e. if the owner of an SA > > is identified by the IP addr only (and a host only has one IP addr) > > then IMHO there can be only one pair of unidirectional SAs between any pair of > > machines. > > Why? The SA has an identifier; you can several SA's for the same identities > without fear of confusion. > > On the down call (or outbound), there is no notion of a SPI, the information available to identify an SA is Dest Addr and Port No (and possibly user id) **************************************************** Elfed T. Weaver Defence Research Agency Malvern UK weaver@hydra.dra.hmg.gb From owner-ipsec Wed Dec 18 13:13:53 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08421 for ipsec-outgoing; Wed, 18 Dec 1996 13:12:25 -0500 (EST) Message-ID: From: Roy Pereira To: "'Robert Glenn'" , "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: Re: Replay counter sizes: AH vs ESP -Reply Date: Wed, 18 Dec 1996 13:16:02 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk But adding padding would not hurt processing of the AH payload greatly. While having a replay field that may change in size due to the size of the digest algorythm, increases both code and complexity of that code to handle processing. I'd like to see both replay fields in AH and ESP to be 32-bits and then we may add extra padding to the end of these payloads to align them to 64-bits. >---------- >From: Robert Glenn[SMTP:glenn@snad.ncsl.nist.gov] >Sent: Friday, December 06, 1996 8:24 AM >To: Andrew Robison; Roy Pereira > >IAA04917; Fri, 6 Dec 1996 08:23:37 -0500 (EST) >Date: Fri, 6 Dec 1996 08:23:37 -0500 (EST) >Message-Id: <199612061323.IAA04917@sloth.ncsl.nist.gov> >To: ipsec@tis.com >Subject: Re: Replay counter sizes: AH vs ESP -Reply >Sender: owner-ipsec@portal.ex.tis.com >Precedence: bulk > >Keep in mind that these transforms are specified to provide security services >for both version 4 and 6 of IP. IPv6 insists that "each extension header >be an integer multiple of 8 octets, in order to retain 8-octet alignment for >subsequent headers." (RFC1883) The differences in the Replay Prevention >fields >is primarily due to this alignment. A change to either would require >adding an additional 32 bits of wasteful pad. > >Rob G. >-- >rob.glenn@nist.gov > > > > > From owner-ipsec Wed Dec 18 13:39:29 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08709 for ipsec-outgoing; Wed, 18 Dec 1996 13:37:54 -0500 (EST) Message-Id: <199612181839.NAA18594@relay.hq.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: ho@earth.hpc.org (Hilarie Orman) Date: Wed, 18 Dec 1996 18:42:35 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ISAKMP DOI Question (General, Not IP Specific) CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Wed, 18 Dec 1996 11:51:54 -0500 > From: ho@earth.hpc.org (Hilarie Orman) > To: weaver@hydra.dra.hmg.gb > Cc: ipsec@tis.com > Subject: Re: ISAKMP DOI Question (General, Not IP Specific) > > > - There can only be one SA between two machines at a given time. > > > I suppose this depends on who owns the SA i.e. if the owner of an SA > > is identified by the IP addr only (and a host only has one IP addr) > > then IMHO there can be only one pair of unidirectional SAs between any pair of > > machines. > > Why? The SA has an identifier; you can several SA's for the same identities > without fear of confusion. > > On outbbound calls there is no notion of a SPI. The only information available to identify an SA is: Destination Addr Port number **************************************************** Elfed T. Weaver Defence Research Agency Malvern UK weaver@hydra.dra.hmg.gb From owner-ipsec Wed Dec 18 13:51:47 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08779 for ipsec-outgoing; Wed, 18 Dec 1996 13:48:51 -0500 (EST) Date: Wed, 18 Dec 1996 10:51:29 -0800 From: Ran Atkinson Message-Id: <199612181851.KAA21032@cornpuffs.cisco.com> To: weaver@hydra.dra.hmg.gb Subject: Re: ISAKMP DOI Question (General, Not IP Specific) In-Reply-To: <199612181743.MAA15608@relay.hq.tis.com> Organization: cisco Systems Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk In article <199612181743.MAA15608@relay.hq.tis.com> Elfed Weaver wrote: >> Date: Wed, 18 Dec 1996 11:51:54 -0500 >> From: ho@earth.hpc.org (Hilarie Orman) >> To: weaver@hydra.dra.hmg.gb >> Cc: ipsec@tis.com >> Subject: Re: ISAKMP DOI Question (General, Not IP Specific) > >> > > - There can only be one SA between two machines at a given time. >> >> > I suppose this depends on who owns the SA i.e. if the owner of an SA >> > is identified by the IP addr only (and a host only has one IP addr) >> > then IMHO there can be only one pair of unidirectional SAs between any pair of >> > machines. >> >> Why? The SA has an identifier; you can several SA's for the same identities >> without fear of confusion. > >On the down call (or outbound), there is no notion of a SPI, the information >available to identify an SA is Dest Addr and Port No (and possibly >user id) For all outbound traffic, ipsec_output_policy() [or its equivalent] knows at least these data items for an outbound IP packet that is to use IPsec: Protocol in use (TCP, UDP, ICMP, etc) Source Address Source Port (if TCP or UDP are in use) Destination Address Destination Port (if TCP or UDP are in use) Additionally, a good IPsec implementation will also know: Source Identity for this session Destination Identity for this session [NB: "identity" might be IP address, IP Addr+ULP+Port, FQDN, USER_FQDN or whatever] A good IPsec implementation would probably also add information about which SA is being used currently for a particular session to that session's socket state (or the non-BSD equivalent of socket state). For example, in session-unique keying it is important to keep the right SA associated with the right IP session. Note that if IPsec Policy [or its equivalent] knows these data items, then a key management daemon using PF_KEYv2 can be informed by the kernel of these data items and hence can use these data items in creating new IPsec SAs as necessary. I don't think there is any problem picking the correct SA to use for outbound IPsec processing. It is a requirement of the current Proposed Standard RFCs that a pair of IPsec nodes be able to have more than one IPsec SA in use between those nodes. An IPsec implementation that is limited to one IPsec SA per destination is not conforming to the current specifications. Ran rja@cisco.com From owner-ipsec Wed Dec 18 15:30:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09509 for ipsec-outgoing; Wed, 18 Dec 1996 15:18:59 -0500 (EST) X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Wed, 18 Dec 1996 13:15:54 -0700 (MST) From: Oliver Spatscheck To: "Elfed T. Weaver" cc: Hilarie Orman , ipsec@tis.com Subject: Re: ISAKMP DOI Question (General, Not IP Specific) In-Reply-To: <199612181839.NAA18594@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 18 Dec 1996, Elfed T. Weaver wrote: >On outbbound calls there is no notion of a SPI. The only information >available to identify an SA is: > >Destination Addr >Port number > I think that is an API question. Our API allows to attach a SPI to outbound traffic at the application layer. Oliver -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMrhQ/TnVPgUZ7uZJAQHR9AQAnR/CJr6qX0uc6I5s514OeukWtzfON/I/ aYDrRYMkqjOS+51jvuXrRSAYMYeL/dwFfOMaiR54Zi5mB+f1sa75+/zltaQWRhk6 AHGHxmNNkonPUCYS+EJah2VaBH8cdt1gCWVihtP1gVVSL8mIl6KZRa/sQdY9xEle CwARWCIPpvU= =Jyo6 -----END PGP SIGNATURE----- From owner-ipsec Wed Dec 18 17:12:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10149 for ipsec-outgoing; Wed, 18 Dec 1996 17:07:33 -0500 (EST) Message-ID: From: Roy Pereira To: "'Daniel Harkins'" Cc: "'IPSEC Mailing List'" , "'isakmp-oakley'" Subject: RE: FW: tunnel mode Date: Wed, 18 Dec 1996 14:34:55 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The reason that Tunnel/Transport attributes are required are due to the fact that in our policy we may elect to dictate to our peer that they must do tunnel mode (or transport mode). Then our peer would not have the ability to use its local policy to determine which mode it uses. I beleive that some language stating that if no KEP tunnel attributes are present in the SA, then it is up to the local policy to decide which mode to use. But if some tunnel mode attributes are present in the SA, then the two communicating parties MUST use that mode when communicating between themselfs. i.e. If ISAKMP/Oakley contains tunnel mode attributes in the the aggreed proposal, then both parties must utilize those attributes, if not then then it is up to local policy. >---------- >From: Daniel Harkins[SMTP:dharkins@cisco.com] >Sent: Tuesday, December 17, 1996 11:11 PM >To: Roy Pereira >Cc: 'IPSEC Mailing List'; 'isakmp-oakley' >Subject: Re: FW: tunnel mode > >I'm not sure, but I believe this was Derrell Piper responding to Roy Pereira: >> >Derrell, how do we do DES-HMAC-MD5/SHA1 in tunnel mode? Your >> >current draft doesn't allow for this. Am I missing something? It also >> >doesn't include the newer 3DES-HMAC-MD5/SHA1. >> >> Except for the old-style ESP, you can't in the current incarnation of >> the drafts. >> >> I made a note during the ipsec wg that I needed to add Tunnel and >> Transport SA Attributes. They'll be in the next version of the draft, >>along >> with a proscribed set of defaults for the existing attributes. >> >> Suggestions on what those defaults should be are most welcome... > > I don't see why Tunnel or Transport attributes need to be negotiated. >There shouldn't be anything wrong with using a single SA for both provided >there were no PFS restrictions on the SA. > This seems to me to be an issue of the particular IPsec implementation's >policy engine, not of SA negotiation. If some packet needs security to go >through an encrypting router, and a SA exists to that router then the policy >defined in that SA is applied in tunnel mode. If some later packet needs to >go to the router itself (not through it) why not just apply the SA in >transport mode? > > Dan. > > From owner-ipsec Wed Dec 18 19:59:39 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA10931 for ipsec-outgoing; Wed, 18 Dec 1996 19:56:03 -0500 (EST) Message-Id: <2.2.16.19961218215258.589f2322@server1.cylink.com> X-Sender: jburke@server1.cylink.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Dec 1996 16:52:58 -0500 To: ipsec@tis.com From: John Burke Subject: RE: SA Attribute Negotiation Cc: isakmp-oakley@cisco.com, jburke@cylink.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:48 PM 12/12/96 -0500, Roy Pereira wrote: [ .. ] >I would like to see a standard length for some of the attributes, like >key durations. If we decide upon a 32 bit integer to represent these >and other values, then all implementations would be able to handle these >attributes correctly. > >But if one implementation sends out a key duration of 1^199 seconds and >codes it as a 128 bit integer, a lot of implementations will not be able >to utilize it and thus it will not accept that proposal. We need to >define standard variable attribute that has a lenth of 32 bits. This >would be used by attributes that need integers as values, but that can't >or dont wish to represent them as 16-bits with a basic attribute. [ ..etc. ] and on Tue, 17 Dec 1996 09:05:08 -0800 Derell Piper wrote: >I don't view most (any?) of the Phase II attributes as mandatory. > >I think we should define default values for each and allow either side to >override the defaults if they so choose (based on local policy). > >If people generally agree with this, I'll pick some defaults for the next >version of the draft. This would also help to address Roy's concerns that >a default attribute size be specified for basic interoperability. I want to suggest that certain points seem pretty clear, and ask for response from anyone who sees things otherwise: o If the Initiator omits a default attribute, the responder may legitimately return any legal value. Initiator can reject it by not proceeding, and sending Notify (SA unacceptable) if its policy permits response. o There is no need for Responder to send any attributes back at all, if it accepts the values it received and accepts defaults for attributes it did not receive. (The draft does not prescribe that any of the attributes MUST be returned.) o The Initiator indicates acceptance of all attributes sent by the Responder, if it proceeds with the exchange. o Either party may send a Lifetime shorter than the other's. This is generally not a grounds for rejection; the party who receives the Lifetime which is smaller would do well to enforce it, but it also could conceivably just leave enforcement of a smaller limit to the other party. Party A cannot possibly be required to allow the SA to last a longer lifetime based on what party B sends. This holds whether party A is Initiator or Responder. o The responder should not send back a longer Lifetime value than one explicitly sent by the initiator. o The standard has no need to define particular field sizes, other than to define default values. Given the attributes that presently exist: No implementation needs to store and act on a number received from its partner which is larger the max it permits. If you receive a Lifetime attribute of larger size than you support, the only decoding action you need is to discover where the high-order nonzero is; if this shows the value is bigger than what you support, then as discussed above you are allowed to ignore or reduce it. These remarks are based on the attributes we have now, i.e. only Lifetimes; the rule for them is, either party can reduce them. Quite conceivably a future standard might introduce attributes which would need different rules; but that is Futures. Not so clear: o If party A sends a Lifetime in Kilobytes but party B implements no Kilobyte limit, only a Time limit: I would think party B can accept the connection and depend on party A to enforce the limit which it announced. o I presume it is unreasonable that anyone would implement kilobyte limits and not time limits? The bald assertions above are based on my understanding and my wild-eyed beliefs about how it just has to be in order to work given the drafts; comments and corrections are welcome. Best regards, - John Burke From owner-ipsec Thu Dec 19 07:32:26 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14231 for ipsec-outgoing; Thu, 19 Dec 1996 07:29:06 -0500 (EST) From: dan.mcdonald@eng.sun.com (Dan McDonald) Message-Id: <199612182129.NAA07523@kebe.eng.sun.com> Subject: Re: ISAKMP DOI Question (General, Not IP Specific) To: spatsch@cs.arizona.edu (Oliver Spatscheck) Date: Wed, 18 Dec 1996 13:29:31 -0800 (PST) Cc: weaver@hydra.dra.hmg.gb, ho@earth.hpc.org, ipsec@tis.com from "Oliver Spatscheck" at Dec 18, 96 01:15:54 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@portal.ex.tis.com Precedence: bulk > >On outbbound calls there is no notion of a SPI. The only information > >available to identify an SA is: > > > >Destination Addr > >Port number > > > I think that is an API question. Our API allows to attach a SPI to > outbound traffic at the application layer. I agree with Oliver and Ran that on outbound data, you can (or should be able to) specify quite a bit about what properties you want in your SA (or SAs). What worries me a little here (Steve Bellovin, help me out here anytime you wish! :) is that I can specify the actually security association of the outbound traffic. On a single-user system, this isn't so bad, but on a multi-user box with malicious users, this could cause all sorts of chosen-plaintext problems. Just a thought. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + From owner-ipsec Thu Dec 19 07:40:12 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14399 for ipsec-outgoing; Thu, 19 Dec 1996 07:37:39 -0500 (EST) Message-Id: <199612191239.HAA08135@relay.hq.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" To: isakmp-oakley@cisco.com Date: Thu, 19 Dec 1996 12:34:35 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ISAKMP DOI Question (General not IP Specific) CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.40) Sender: owner-ipsec@ex.tis.com Precedence: bulk Originally Richard Waterhouse wrote: >The following statement is reported to have been made at an ISAKMP >meeting yesterday >- There can only be one SA between two machines at a given time. >Therefore since there can only be one DOI to an SA, there can only be >one DOI active between two machines at a given time. Elfed Weaver replied: >I suppose this depends on who owns the SA i.e. if the owner of an SA >is identified by the IP addr only (and a host only has one IP addr) >then IMHO there can be only one pair of unidirectional SAs between any pair of >machines. Clearly, if SAs are associated with protocol numbers, user >ids ?..., then many SAs can exist between any pair of hosts. The intent of my reply was to state that the number SAs that can exist between two machines depends on the granularity of the information available to identify an SA. Hilarie wrote: >Why? The SA has an identifier; you can several SA's for the same identities >without fear of confusion. Elfed Weavers response: >On the down call (or outbound), there is no notion of a SPI, the information >available to identify an SA is Dest Addr and Port No (and possibly >user id) My interpretation of Hilaries comment was that an explicit SA identifier existed which permitted an "identity" - however fine the identity granularity is - to own more than one SA for communicating with the same peer entity. Possibly I have misinterpretted the comment. If two physical "identities" wished to have more than one SA existing between them i.e. they require to exchange information at different security levels , then surely they would have to provide more information to allow the correct SA to be selected/used by IPsec. Thus providing a finer granularity for SA identification . This I believe is the essence of Rans comments and I quote from Rans comments: "[NB: "identity" might be IP address, IP Addr+ULP+Port, FQDN, USER_FQDN or whatever]" Elfed **************************************************** Elfed T. Weaver Defence Research Agency Malvern UK weaver@hydra.dra.hmg.gb From owner-ipsec Thu Dec 19 12:15:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16333 for ipsec-outgoing; Thu, 19 Dec 1996 12:13:00 -0500 (EST) Date: Thu, 19 Dec 1996 12:14:48 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199612191714.MAA01212@earth.hpc.org> To: dan.mcdonald@eng.sun.com Cc: spatsch@cs.arizona.edu, ipsec@tis.com, weaver@hydra.dra.hmg.gb In-reply-to: Yourmessage <199612182129.NAA07523@kebe.eng.sun.com> Subject: Re: ISAKMP DOI Question (General, Not IP Specific) Sender: owner-ipsec@ex.tis.com Precedence: bulk > What worries me a little here (Steve Bellovin, help me out here anytime you > wish! :) is that I can specify the actually security association of the > outbound traffic. > On a single-user system, this isn't so bad, but on a multi-user box with > malicious users, this could cause all sorts of chosen-plaintext problems. It depends on your local policy. I've never quite understood why SPI's (as names standing for SA's) aren't under access control. If Alice creates it, why should Bob be allowed to use it? Hilarie From owner-ipsec Thu Dec 19 12:51:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16601 for ipsec-outgoing; Thu, 19 Dec 1996 12:50:00 -0500 (EST) From: dan.mcdonald@eng.sun.com (Dan McDonald) Message-Id: <199612191748.JAA15120@kebe.eng.sun.com> Subject: Re: ISAKMP DOI Question (General, Not IP Specific) To: ho@earth.hpc.org (Hilarie Orman) Date: Thu, 19 Dec 1996 09:48:22 -0800 (PST) Cc: dan.mcdonald@eng.sun.com, spatsch@cs.arizona.edu, ipsec@tis.com, weaver@hydra.dra.hmg.gb In-Reply-To: <199612191714.MAA01212@earth.hpc.org> from "Hilarie Orman" at Dec 19, 96 12:14:48 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 > > On a single-user system, this isn't so bad, but on a multi-user box with > > malicious users, this could cause all sorts of chosen-plaintext problems. > > It depends on your local policy. I've never quite understood why > SPI's (as names standing for SA's) aren't under access control. If > Alice creates it, why should Bob be allowed to use it? That was my point. I believe we're in agreement. On a single user box, there's only Alice. On a multi-user box, Bob shouldn't (modulo policy, of course) be able to use any SA allocated for Alice. Phew, I thought I'd flubbed up or something. Dan From owner-ipsec Thu Dec 19 12:58:12 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16658 for ipsec-outgoing; Thu, 19 Dec 1996 12:58:02 -0500 (EST) Message-Id: <199612191800.KAA21718@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Thu, 19 Dec 96 10:00:47 -0800 To: ipsec@tis.com Subject: Q re draft-ietf-ipsec-isakmp-06.txt Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk The following is from Section 3.3, Data Attributes of draft-ietf-ipsec-isakmp-06.txt: > o Attribute Value (variable length) - Value of the attribute associated > with the DOI-specific Attribute Type. If the AF bit is a zero (0), > this field has a variable length defined by the Attribute Length > field and the field is right justified with zeros prepended for word ----------------------------------------------------------------------^^^^ > alignment. If the Attribute Value is not word aligned, the remaining > bits MUST be filled with 0. If the AF bit is a one (1), the > Attribute Value has a length of 2 octets. > What is a word? 16, 32, or 64 bits? -dpg From owner-ipsec Thu Dec 19 14:38:40 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17291 for ipsec-outgoing; Thu, 19 Dec 1996 14:36:28 -0500 (EST) Message-Id: <2.2.16.19961219163818.4e27c736@server1.cylink.com> X-Sender: jburke@server1.cylink.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Dec 1996 11:38:18 -0500 To: ipsec@tis.com, isakmp-oakley@cisco.com From: John Burke Subject: Length field and ISAKMP-encrypted size Cc: jburke@cylink.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I have not seen it mentioned in discussion and I believe it is nowhere mentioned in the drafts, what the state of affairs is if encryption on the ISAKMP SA causes expansion. I also believe ISAKMP presently requires the messages can be of unrounded size, since some payloads are defined of arbitrary length; therefore necessarily multi-byte encryptions can expand an ISAKMP message. IT seems that necessarily, encryption can expand the size of an ISAKMP message, but the Message Length field of the ISAKMP header must retain the original length of the unencrypted message. Therefore one must accept and decrypt a received packet of length larger than described by the header Message Length, up to the rounding required by the encryption method. Can an authoritative person please confirm this rumor? If this is not the desired state of affairs, there needs to be clarification, and, I believe, updates to the ISAKMP draft? Best regards, John Burke jburke@cylink.com From owner-ipsec Thu Dec 19 15:49:11 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17674 for ipsec-outgoing; Thu, 19 Dec 1996 15:42:20 -0500 (EST) Date: Thu, 19 Dec 1996 12:44:40 -0800 From: Ran Atkinson Message-Id: <199612192044.MAA10833@cornpuffs.cisco.com> To: ho@earth.hpc.org Subject: Re: ISAKMP DOI Question (General, Not IP Specific) In-Reply-To: <199612191714.MAA01212@earth.hpc.org> References: <199612182129.NAA07523@kebe.eng.sun.com> Organization: cisco Systems Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk In article <199612191714.MAA01212@earth.hpc.org> you write: >> What worries me a little here (Steve Bellovin, help me out here anytime you >> wish! :) is that I can specify the actually security association of the >> outbound traffic. > >> On a single-user system, this isn't so bad, but on a multi-user box with >> malicious users, this could cause all sorts of chosen-plaintext problems. > >It depends on your local policy. I've never quite understood why >SPI's (as names standing for SA's) aren't under access control. If >Alice creates it, why should Bob be allowed to use it? The NRL implementation has always permitted IPsec users to request "session-unique keying" that causes the kernel to enforce access control such that no two sessions (not even two of Alice's sessions) could share any SA. I believe that Dan McD's "Simple IPsec API" draft continues to contain this capability. The NRL implementation permits the existence of shared SAs. Shared SAs might be useful when manual key distribution is in use (hence the number of SAs available for use might be smaller than is really desirable) AND the node's users are not mutually suspicious. The quoted text above are among the reasons both for this implementation choice by NRL and also for the implementation requirement for "user-oriented" (which is an awkward phrase at best) or "session-unique" keying in a node implementing IPsec. Ran rja@cisco.com From owner-ipsec Thu Dec 19 17:12:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18136 for ipsec-outgoing; Thu, 19 Dec 1996 17:08:21 -0500 (EST) Message-Id: <199612192211.RAA02883@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Ran Atkinson Cc: ho@earth.hpc.org, ipsec@tis.com Subject: Re: ISAKMP DOI Question (General, Not IP Specific) In-Reply-To: rja's message of Thu, 19 Dec 1996 12:44:40 -0800. <199612192044.MAA10833@cornpuffs.cisco.com> Date: Thu, 19 Dec 1996 17:11:00 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk [this is a bit of a change in topic..] >It depends on your local policy. I've never quite understood why >SPI's (as names standing for SA's) aren't under access control. If >Alice creates it, why should Bob be allowed to use it? Actually, AH/ESP SPI's are not particularly convenient names for SA's from the point of view of applications. 1) They're unidirectional. Knowing the inbound SPI a message was protected with doesn't give you the outbound SPI to use for a reply to the message.. 2) At least some of them expire and get replaced over time. Because of these factors, I don't think SPI's should be visible at the "normal" API; some sort of local-only "SA-set" identifier may be more appropriate. (In the case of the sockets API, it might make sense to put it into the sockaddr; that way any program which just swaps the source and destination sockaddrs to construct the reply will Do The Right Thing. this is not likely to be an option for IPv4, but might be for IPv6..). - Bill From owner-ipsec Thu Dec 19 18:12:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18414 for ipsec-outgoing; Thu, 19 Dec 1996 18:09:19 -0500 (EST) Message-Id: <199612192312.PAA10462@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: John Burke Cc: ipsec@tis.com, isakmp-oakley@cisco.com Subject: Re: Length field and ISAKMP-encrypted size In-Reply-To: Your message of "Thu, 19 Dec 1996 11:38:18 EST." <2.2.16.19961219163818.4e27c736@server1.cylink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Dec 1996 15:12:01 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk John Burke wrote: > I have not seen it mentioned in discussion and I believe it is nowhere > mentioned in the drafts, what the state of affairs is if encryption on the > ISAKMP SA causes expansion. While not explicitly mentioned, the IPsec DOI mandates the ISAKMP/Oakley resolution document which lists valid encryption options for the ISAKMP SA. All are in CBC mode which basically means packet expansion. > I also believe ISAKMP presently requires the messages can be of unrounded > size, since some payloads are defined of arbitrary length; therefore > necessarily multi-byte encryptions can expand an ISAKMP message. > > IT seems that necessarily, encryption can expand the size of an ISAKMP > message, but the Message Length field of the ISAKMP header must retain the > original length of the unencrypted message. Therefore one must accept and > decrypt a received packet of length larger than described by the header > Message Length, up to the rounding required by the encryption method. > > Can an authoritative person please confirm this rumor? If this is not the > desired state of affairs, there needs to be clarification, and, I believe, > updates to the ISAKMP draft? The free cisco ISAKMP implementation (point your favorite browser to http://www.cisco.com/public/library/isakmp.html and follow the hotlinks) pads the plaintext to the block length of the cipher-- which in this case is 64 because it only does DES-- before encrypting. The message length in the ISAKMP header of an encrypted message *does* include the pad. After decrypting the message I run a sanity check on the entire payload to make sure that payloads are internally and globally consistant: attributes of a SA payload don't add up to more than the total length of the SA payload and all the payload lengths added don't exceed the total message length. If it's less (which it would be if the message was encrypted) I don't view it as a problem. It would seem to me to be more of a problem if the message was actually longer than the stated length. Yes, you're right, this might need to be spelled out explicitly. Dan. From owner-ipsec Fri Dec 20 09:49:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA22933 for ipsec-outgoing; Fri, 20 Dec 1996 09:43:32 -0500 (EST) X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs Date: Fri, 20 Dec 1996 07:27:23 -0700 (MST) From: Oliver Spatscheck To: Bill Sommerfeld cc: Ran Atkinson , ho@earth.hpc.org, ipsec@tis.com Subject: Re: ISAKMP DOI Question (General, Not IP Specific) In-Reply-To: <199612192211.RAA02883@thunk.orchard.medford.ma.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 19 Dec 1996, Bill Sommerfeld wrote: > >Actually, AH/ESP SPI's are not particularly convenient names for SA's >from the point of view of applications. > We implemented it the following way: 1. Each incomming (local) SPI is bound to an outgoing SPI. 2. All SAs are identified by the local SPI 3. ISAKMP makes sure that each local SPI exists only once for all SPI spaces. To avoid unecessary discussion let me mention again this is implementation dependend. Oliver -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMrqiTDnVPgUZ7uZJAQGlaAQAvdqkezROijS0khWvQ9pFOQKhhj6nuFcn P700+sJbcW0sxwt9u+FUVmGQS2uktagpnFDT3fVKXkjZniw5Vbgw0pAEng/VqlwK iP99mcuxVMQ+I0eT7xbQHFdIOrTzlsJVBLzfA9x54tucRCPoT+/dkcOlrI8hn/af 1c0T4zb4VXo= =1GDq -----END PGP SIGNATURE----- From owner-ipsec Fri Dec 20 11:06:47 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23525 for ipsec-outgoing; Fri, 20 Dec 1996 11:03:33 -0500 (EST) Message-ID: From: Greg Carter To: "'isakmp-oakley@cisco.com'" Cc: "'ipsec@tis.com'" , "'dharkins@cisco.com'" Subject: Class Type - Initialization Vector Date: Fri, 20 Dec 1996 11:00:05 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk I think an IV Attribute Class needs to be defined in the isakmp-oakley draft. There isn't one in the current draft. I see that the cisco code uses one and since DES-CBC is mandatory it would appear that an iv attribute would also be needed (and mandatory). A note on its use is also needed, ie do both sides start off with the same IV or do they exchange unique ones... Bye. ****Season's Greetings**** ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Fri Dec 20 11:58:32 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24028 for ipsec-outgoing; Fri, 20 Dec 1996 11:55:41 -0500 (EST) Message-Id: <199612201658.IAA11247@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Greg Carter Cc: "'isakmp-oakley@cisco.com'" , "'ipsec@tis.com'" Subject: Re: Class Type - Initialization Vector In-Reply-To: Your message of "Fri, 20 Dec 1996 11:00:05 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 08:58:26 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, > I think an IV Attribute Class needs to be defined in the isakmp-oakley > draft. There isn't one in the current draft. I see that the cisco code > uses one and since DES-CBC is mandatory it would appear that an iv > attribute would also be needed (and mandatory). A note on its use is > also needed, ie do both sides start off with the same IV the initiator> or do they exchange unique ones... draft-ietf-ipsec-isakmp-oakley-02.txt mentions how to generate IVs in appendix B. I don't really like the idea of negotiating an IV (or having one side dictate the IV) and only reluctantly added it into the cisco code since there was no definition on how to get one in -00.txt. Check out appendix B. Basically, both sides generate the same one independently. regards, Dan. From owner-ipsec Fri Dec 20 14:30:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25327 for ipsec-outgoing; Fri, 20 Dec 1996 14:25:32 -0500 (EST) Date: 20 Dec 96 13:27:56 -0600 Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard From: "James Hughes" To: hughes@nsco.network.com, "Thomas Narten" Cc: iesg@ietf.org, ipsec@tis.com X-Mailer: Cyberdog/1.2 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for the comments. They are indeed relevant. I will incorporate them at the next revision. Thanks. > I have a number of comments on the draft. IMO, the draft could use > another revision (to clarify some points) before being promoted to > Proposed Standard. Most of my concerns are minor. However, the first > two points may be significant. > > First, the draft says: > > >1. Discussion > > > > This draft allows a combination of MD5 and DES-CBC. In addition to > > privacy, the goal of this transform is to ensure that the packet is > > authentic, can not be modified in transit, or replayed. > > The last sentence is misleading. In contrast to the standalone AH > headers (which cover the invariant fields of the IP header), the > transform described in the draft apparently does not cover the IP > header (or if it does, this fact completely escaped me). Thus, > modifications to the IP header fields (including the source/dest > addresses, which are part of the TCP transport identifiers) would not > be detected by this transform. > > Thus, I conclude that the combined transform provides *weaker* > authentication than the standalone transforms. This surprises me, and > seems a mistake. In the case of IP in IP, the inner IP packet is the one protected by this transform. I will add a statement that IP in IP is what was ment... > Another important point: > > > 1. (Optional step) Decrypt the first bock of data using the > > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- > > ity check" of the count. If the count has decreased below the win- > > dow or has increased by more than 65k, then it is safe to discard > > this packet as either a replay, non-authentic or too old. If the > > count is within 65K, then the probability that the packet is > > authentic is 65535/65536. (The following replay check and HMAC > > check are both still required). > > Maybe I'm missing something, but the above would appear to not handle > network partitions well. If a destination becomes unreachable (for > whatever reason), and the sender sends 65K packets during the outage, > packets sent after the destination becomes reachable again will > continue to be rejected. Thus, this "optimization" seems wrong. 2 comments, First, my choice of 65000 was arbitrary. That number can be up to 16M with little change. That is, by making sure that the number was within 16M, then the probabilitiy of a bad packet being caught is 255/256, which makes this still reasonable. Second, if 2 units have lost contact and have continued to send many thousands of packets, then the far side comes back and you still allow the old key to be used, seems to me to be to be scarry. Other devices that I know of, if they lose contact, after a resonable period (less than 65000 packets), will force a new key to be negotiated (really it is forcing a new authentication, which, after a major outage, seems reasonable). Would you suggest a statement be added or the number be changes or? > The remainder of my comments are fairly minor. > > The draft never mentions IPv6. It apparently is intended to cover both > IPv4 and IPv6, and I think that fact should be explicitely stated at > the beginning to minimize confusion. Granted. > >2. Packet Format > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- > > | Security Parameters Index (SPI) | ^ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > How about putting bit numbers at the top (as is standard in other > drafts) to make it obvious that fields are 32 bits in size. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | | | > > + Initialization Vector (Optional) + | > > | | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > I assume the IV needs to be a multiple of 64-bits (to insure that the > Data starts on a 64-bit boundary for IPv6)? If so, the draft should > state this explicitely (it doesn't seem to). Interesting point. I assumed that the IV was a full DES block or 64 bits. I will add this. I am also lucky, the SPI and Replay are 32 so the data starts on a 64 bit boundry> > > This field is optional and is only used when an explicit IV is nego- > > tiated during key exchange. This field is contains random data or > ^^ > Extra word. OK. > > For the packet which the explicit IV is received, the explicit IV is > ^ > Missing word "in" OK. > >2.3. Replay Prevention > > > > Replay Prevention is an unsigned 32 bit incrementing counter starting > > at a mutual agreed upon value (see Key Material) and is enforced to > > be within a mutually negotiated window size. > > This section should more clearly state that every distinct IP packet > (including retransmissions) must use a new counter value. > Retransmissions that use the same replay counter may result in > deadlock. OK. > > If a value of 32 is negotiated, then the most recent 32 packets are > > allowed to arrive out of order. That is, these 32 packets can arrive > > The first sentence above is misleading. The "most recent" 32 packets > aren't accepted. Only those packets whose replay counter is within 32 > of the highest numbered packet received so far are accepted. OK. > > in any sequence relative to each other except that these packets are > > guaranteed to arrive only once. Appendix A has actual code that > > Change "guaranteed to arrive only once" to "guaranteed to be accepted > only once" OK. > > field. This field is an integral number of bytes in length; the fol- > > lowing padding and pad length fields will help provide alignment to a > > double word boundary. > > I found the above wording a bit confusing. How about "This field > specifies the size of the payload in bytes" OK. > > tiator direction). The IV_key_ remains constant for all packets send > > in this direction. > > "send" should be "sent". OK. > > CBC chaining with an constant IV_key_ is used. if an IV is present in > > the packet, then the IV_key_ is not used and is replaced by the IV. > > I found the above somewhat confusing. How about rewording something > like: > > By default, CBC chaining with a constant IV_key_ is used. The value of > IV_key_ is negotiated as part of the SPI creation. It is also possible > (if agreed upon by both parties during SPI setup) to include an IV in > each packet, in which case the included IV is used. Note that the > packet itself contains no indication of whether or not an IV in is > included; this knowledge is maintained as part of the Security > Association. OK. > > 1. (Optional step) Decrypt the first bock of data using the > > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- > > ity check" of the count. If the count has decreased below the win- > > dow or has increased by more than 65k, then it is safe to discard > > this packet as either a replay, non-authentic or too old. If the > > count is within 65K, then the probability that the packet is > > authentic is 65535/65536. (The following replay check and HMAC > > check are both still required). > > What does it mean for the count to be "decreased below the window"? > > Also, I don't understand where the 65535/65536 probability comes from > or what it means. Assuming that the packet received count (x) and the highest received replay count (r) are 32 bit unsigned number, if the packet is between r < x < r+65K then this checks to see if x is within the 64k possible. If the field has been randomized through modification of the first block -or- the attacker does not know the key, then the value of x will be any random 32 bit value or one of 4B numbers. The probability of 2 random 32 bit numbers being within 65K of each other is 4B/65K or 65K. If the range check is increased to 16M (24 bits) then the ratio is 4B/16M or 256. > > 3. Calculate the HMAC using the HMAC_key_ and create the digest > > from the SPI, IV (if present) count, data, pad, pad length, and > > payload type and checking the result at digest at the end of > ^^^^^^^^ > Typo. Perhaps reword as "compare the result with the digest"? OK. > >Appendix A > > > > This is a routine that implements a 32 packet window. This is intend- > > ed on being an implementation sample. > > This code in fact assumes that the replay counter always starts at > 0. It should state this, since this assumption is not made elsewhere > in the draft. > > Also, if it is reasonable to always start the replay counter at zero, > why does the draft not simply require this? Right now, the initial > counter value is negotiated. Good point. I assumed that the caller would normalize this (by subtracting the starting value. Since this is an unsigned value, this works.) Again, I will add commments regarding this. Again, thanks for the input, I will be adding this to the document next go-around. jim From owner-ipsec Fri Dec 20 17:02:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26544 for ipsec-outgoing; Fri, 20 Dec 1996 16:55:34 -0500 (EST) Message-Id: <2.2.32.19961220220440.00ba4e3c@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 17:04:40 -0500 To: ipsec@tis.com From: Naganand Doraswamy Subject: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk This is regarding the behavior of TCP when a packet is queued at the IPsec layer for want of keys. When TCP sends a packet down to the IPsec layer it starts it times for retransmission. IPsec then queues the packet and starts negotiating keys. If the TCP times out on the packet then it will modify its congestion window parameters assuming that the network is congested. Does it make sense for the IPsec layer to inform the TCP about the packet being queued locally so that when TCP retransmits the packet, it does not modify its congestion window? The advantage of doing this is that the performance does not suffer. However, what if the network is really congested by the time the keys are obtained. Should the connection start with slow start always. There are merits for both the cases and I would like to hear other people's views on this. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Fri Dec 20 18:07:53 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA26904 for ipsec-outgoing; Fri, 20 Dec 1996 18:03:40 -0500 (EST) Date: Fri, 20 Dec 1996 18:05:21 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199612202305.SAA10850@earth.hpc.org> To: naganand@ftp.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199612202218.PAA11878@baskerville.CS.Arizona.EDU> Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk I think the processing order is just wrong. Keying should be done before sending TCP data, i.e. the event that triggers keying must happen before invoking TCP or very early in the TCP open processing. Hilarie From owner-ipsec Fri Dec 20 20:37:10 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27522 for ipsec-outgoing; Fri, 20 Dec 1996 20:33:11 -0500 (EST) Message-Id: <3.0.32.19961220173329.00e3a2dc@netcom8.netcom.com> X-Sender: dpalma@netcom8.netcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 17:35:07 -0800 To: ho@earth.hpc.org (Hilarie Orman), naganand@ftp.com From: Derek Palma Subject: Re: IPsec and TCP Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I also ran into the same problem (which started this thread). When exactly do you think keying should start? If you defer until the user initiates a connection but before TCP starts, you must obtain control somewhere in the application layer. In a stack that I control, this issue was worked around by intercepting requests at the socket layer, determining if keying is required, and only letting TCP take control once the keying material is available. I also tried some other solutions that provided similar results (such as deferring TCP's timeout starting point) but they required more modifications to the stack and did not work any better (from a user's perspective). For stacks I do not control which is the case most of the time I have tried pre-calculating keys which I am sure sounds like a terrible solution to most people. I have also tried spoofing the stack regarding TCP connection setup and handling the actual TCP connection setup and keying myself which seems to work OK but is complex. I am interested to hear whay others have done. I think this may be an important problem to overcome in implementations since the side effects will be apparent to users. Derek At 06:05 PM 12/20/96 -0500, Hilarie Orman wrote: >I think the processing order is just wrong. Keying should be done before >sending TCP data, i.e. the event that triggers keying must happen before >invoking TCP or very early in the TCP open processing. > >Hilarie > > > From owner-ipsec Sat Dec 21 10:30:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00660 for ipsec-outgoing; Sat, 21 Dec 1996 10:26:48 -0500 (EST) Message-Id: <3.0.16.19961221101413.085f0250@pop3.pn.com> X-Test: thing1 X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (16) Date: Sat, 21 Dec 1996 10:25:10 -0500 To: Naganand Doraswamy From: Rodney Thayer Subject: Re: IPsec and TCP Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In the case where you are the clear-text machine behind a firewall, and the firewall is waiting for keys, you will still have this problem. On the other hand, I think there is already a mechanism for this. I think the ICMP SOURCE QUENCH message is exactly intended for the "please stop sending a moment, I am busy" case. So, since the problem you describe can happen in both cases (tcp and ipsec colocated, and tcp and ipsec in different nodes) I think it would be worth researching the meaning and implementation of Source Quench for this case. I believe Source Quench is in the Host Requirements RFC, and therefore it is reasonable to use this mechanism, assuming it's appropriate. OK, someone who has memorized all the ICMP RFC's and the Host Req RFC, please correct me ... At 05:04 PM 12/20/96 -0500, you wrote: >This is regarding the behavior of TCP when a packet is queued at the IPsec >layer for want of keys. When TCP sends a packet down to the IPsec layer it >starts it times for retransmission. IPsec then queues the packet and starts >negotiating keys. If the TCP times out on the packet then it will modify its >congestion window parameters assuming that the network is congested. > >Does it make sense for the IPsec layer to inform the TCP about the packet >being queued locally so that when TCP retransmits the packet, it does not >modify its congestion window? The advantage of doing this is that the >performance does not suffer. > >However, what if the network is really congested by the time the keys are >obtained. Should the connection start with slow start always. > >There are merits for both the cases and I would like to hear other people's >views on this. > > >--Naganand >---------------------------------------------------------------- >naganand@ftp.com >Tel #: (508)684-6743 (O) > > > -------- Rodney Thayer PGP Fingerprint: BB 1B 64 28 40 91 29 AC 07 6B 9D E1 4C 25 0D D8 From owner-ipsec Sat Dec 21 10:51:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00750 for ipsec-outgoing; Sat, 21 Dec 1996 10:49:20 -0500 (EST) Message-Id: <199612211551.KAA16786@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: API issues (was Re: IPsec and TCP ) In-reply-to: Your message of "Fri, 20 Dec 1996 17:35:07 PST." <3.0.32.19961220173329.00e3a2dc@netcom8.netcom.com> Date: Sat, 21 Dec 1996 10:51:13 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Derek" == Derek Palma writes: Derek> I also ran into the same problem (which started this Derek> thread). When exactly do you think keying should start? Derek> If you defer until the user initiates a connection but Derek> before TCP starts, you must obtain control somewhere in the Derek> application layer. It seems to me that there are three possibilities: 1. the application requested crypto with a setsockopt() 2. the system been told to communicate securely to this endpoint only. 3. there is a tunnel to this endpoint. For case #1, it seems one should do the key exchange during the setsockopt() call. I.e. do not return until the SA's are in place, or return an error. This has the problem that setsockopt() is not something you can normally do asynchronously. If some operation is going take some some time, you might want to be able to select() on it. For case #2, there are three subcases: + a common SA is desired/permitted. It should be setup when the system is told to do this. + a common SA is setup, but the application wants private keying. The application will arrange this, this is like #1. + the policy is for private keying for each connection. I do not know how to deal with this one. For case #3, the SA is setup when the tunnel is created. In all cases, if it takes a long time to negotiate the tunnel, then it must be because the network is congested and/or remote node is slow. In either case, it is appropriate for TCP's back off to be trigged. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBMrwHatTTll4efmtZAQHZvQH/WQSY48fmYJe/ivOzvvVFFKY1R3+cpZ7h xa7yVMq60iGc9V0ZClL+nAFtrEvO+WGqqtDb1Hq+7kTV5yLTHAKkTQ== =2uYT -----END PGP SIGNATURE----- From owner-ipsec Sat Dec 21 11:49:45 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01196 for ipsec-outgoing; Sat, 21 Dec 1996 11:47:18 -0500 (EST) X-Sender: mike.sabin@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hughes@nsco.network.com From: Michael Sabin Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard Cc: iesg@ietf.org, ipsec@tis.com Date: Sat, 21 Dec 1996 04:53:32 +0000 Message-ID: <19961221045324.AAB28451@LOCALNAME> Sender: owner-ipsec@ex.tis.com Precedence: bulk I went through the exercise of coding up an example datagram as per the draft. My goal was to chase down details about byte/bit orderings in and out of the DES, MD5, HMAC, and replay-count operations. I felt that most of the details were resolvable using the description in the draft and the cited references. However, in a few cases I felt I was guessing. One suggestion I have is that the draft include an example datagram, before and after encryption. This will unambiguously nail down all details about bit/byte ordering. Note that the individual specs for DES [FIPS-41], MD5 [RFC-1321], and HMAC [Krawczyk] include such examples. Below is the example I came up with. (If anybody is inclined to verify the example, I'd sure appreciate it. :-) ) Items marked with (*) are places where I felt I was guessing about byte/bit orderings; some clarification about these may be desirable. mike --------------------------------- EXAMPLE Suppose the "master key" K from the key managment layer is: K = 01 23 45 67 89 ab cd ef 23 45 67 89 ab cd ef 01 45 67 89 ab cd ef 01 23 67 89 ab cd ef 01 23 45 89 ab cd ef 01 23 45 67 ab cd ef 01 23 45 67 89 cd ef 01 23 45 67 89 ab ef 01 23 45 67 89 ab cd K consists of 512 octets. Octet 0 is 0x01, octet 1 is 0x23, octet 511 is 0xcd. K is used to compute the following quantities: DES_Key_I = a4 34 41 46 f6 dc 8b 1d IV_Key_I = c8 44 86 79 51 a6 83 cc HMAC_Key_I = 98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6 dd 4f 1c 8d RP_Key_I = d3 1f e3 42 Each of these quantities is a sequence of octets numbered 0, 1, 2, ..., with octet 0 listed first. Here is an example datagram prior to encryption, including the HMAC: 1f 2e 3d 4c // SPI d3 1f e3 42 // replay count 4e 6f 77 20 // payload 69 73 20 74 // payload 68 65 20 74 // payload 69 6d 65 20 // payload 66 6f 72 20 // payload 61 6c 6c 20 // payload f6 0f 02 06 // padding, pad length, payload type 8a 85 2a 16 // HMAC 2a 6a 0d de // HMAC 30 b1 e5 fa // HMAC a6 e1 fc c1 // HMAC (*) The initial value of the replay count, from RP_Key_I, is: initial replay count = 0xd31fe342 = 3,542,082,370 (*) When computing the HMAC, the octets of the datagram are digested in network order: 0x1f, 0x2e, 0x3d, ..., 0x0f, 0x02, 0x06. The HMAC key, from HMAC_Key_I, is [98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6 dd 4f 1c 8d]; 0x98 is octet 0, and 0x8d is octet 15. (*) The output of the HMAC calculation is inserted into the datagram in network order: 0x8a is octet 0, and 0xc1 is octet 15. Here is the datagram after encryption: 1f 2e 3d 4c // SPI ff 30 bf 0a // replay count 46 bd b7 94 // payload 33 ff 84 0e // payload d9 aa 76 7a // payload cb 20 da d8 // payload 87 8e bf 0f // payload 27 70 2c 99 // payload 2f e3 ce a2 // padding, pad length, payload type b1 cc 9a 6e // HMAC 34 b8 50 3a // HMAC 51 92 be 7f // HMAC e0 cb ba 05 // HMAC (*) The DES encryption key, prior to parity correction, is [a4 34 41 46 f6 dc 8b 1d], from DES_Key_I. (*) The IV is [c8 44 86 79 51 a6 83 cc], from IV_Key_I. (*) The first input block to the DES-CBC encryption is [d3 1f e3 42 4e 6f 77 20]. From owner-ipsec Sun Dec 22 01:49:10 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA05001 for ipsec-outgoing; Sun, 22 Dec 1996 01:45:34 -0500 (EST) Date: Sat, 21 Dec 1996 22:48:21 -0800 (PST) Message-Id: <199612220648.WAA29834@unix.ka9q.ampr.org> From: Phil Karn To: ipsec@tis.com Reply-To: karn@qualcomm.com In-reply-to: <199612211551.KAA16786@amaterasu.sandelman.ottawa.on.ca> (message from Michael Richardson on Sat, 21 Dec 1996 10:51:13 -0500) Subject: Re: API issues (was Re: IPsec and TCP ) Sender: owner-ipsec@ex.tis.com Precedence: bulk I think this is a non-problem. There is plenty of precedent in the Internet for paths that take a long time to handle the first packet, then handle subsequent packets rapidly. Examples include circuit-switched links, the most extreme being demand-dialed PPP modems that can take ~30 sec to come up. When TCP encounters such a path, it retransmits a few times but recovers quickly if its RTT algorithms are implemented correctly. The only harm is a few redundant SYN packets that come spewing through once the link (or security association) is set up. I just can't get too excited about them. Of course, if the link is already up, none of the above applies. I personally would not want to add a lot of layer violations to handle something that isn't really a problem to begin with. Phil From owner-ipsec Mon Dec 23 16:26:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15645 for ipsec-outgoing; Mon, 23 Dec 1996 16:16:53 -0500 (EST) Message-Id: <199612232119.QAA17496@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: rodney@sabletech.com, Naganand Doraswamy Cc: ipsec@tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: RE: IPsec and TCP Date: Mon, 23 Dec 1996 16:16:10 -0500 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 QAA15641 Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Reply to your message of 12/21/96 10:54 AM >In the case where you are the clear-text machine behind a firewall, and the >firewall is waiting for keys, you will still have this problem. > >On the other hand, I think there is already a mechanism for this. I think >the ICMP SOURCE QUENCH message is exactly intended for the "please stop >sending a moment, I am busy" case. > >So, since the problem you describe can happen in both cases (tcp and ipsec >colocated, and tcp and ipsec in different nodes) I think it would be worth >researching the meaning and implementation of Source Quench for this case. >I believe Source Quench is in the Host Requirements RFC, and therefore it >is reasonable to use this mechanism, assuming it's appropriate. > >OK, someone who has memorized all the ICMP RFC's and the Host Req RFC, >please correct me ... RFC-1122, page 40 ("I'll take Host Requirements for $400, Alex"..) seems to suggest that this would be acceptable. One possible issue, however, might be how you'd determine that the Source Quench you're receiving is the result of a rekeying event, in which case you'd want to stop your timers, vs. a real congestion situation, in which case you wouldn't. -- Frank From owner-ipsec Mon Dec 23 17:14:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15927 for ipsec-outgoing; Mon, 23 Dec 1996 17:12:55 -0500 (EST) Message-Id: <199612232215.RAA00652@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Frank T Solensky Cc: rodney@sabletech.com, Naganand Doraswamy , ipsec@tis.com Subject: Re: IPsec and TCP In-Reply-To: solensky's message of Mon, 23 Dec 1996 16:16:10 -0500. <199612232119.QAA17496@MAILSERV-2HIGH.FTP.COM> Date: Mon, 23 Dec 1996 17:15:34 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Hmm. Pushing "sane" support for handling SOURCE QUENCH to end systems probably involves changing the host's IP stack. If you're going to go to that much trouble, why not just implement ESP/AH in the end systems? :-). Seriously, I suspect that it shouldn't be too big a deal for a smart encrypting router to figure out how to squish duplicate TCP segments out of it's "waiting for SA" queue.... yes, it's a "layering violation" of sorts, but so's header compression. - Bill From owner-ipsec Mon Dec 23 22:30:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA17333 for ipsec-outgoing; Mon, 23 Dec 1996 22:27:56 -0500 (EST) Date: Mon, 23 Dec 1996 19:29:29 -0800 (PST) From: Phil Karn Message-Id: <199612240329.TAA29126@servo.qualcomm.com> To: sommerfeld@apollo.hp.com CC: solensky@ftp.com, rodney@sabletech.com, naganand@ftp.com, ipsec@tis.com In-reply-to: <199612232215.RAA00652@thunk.orchard.medford.ma.us> (message from Bill Sommerfeld on Mon, 23 Dec 1996 17:15:34 -0500) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk >Seriously, I suspect that it shouldn't be too big a deal for a smart >encrypting router to figure out how to squish duplicate TCP segments >out of it's "waiting for SA" queue.... yes, it's a "layering >violation" of sorts, but so's header compression. A while back I proposed a somewhat similar scheme for alleviating TCP throughput bottlenecks on highly asymmetric network paths, e.g., certain cable modems and satellite channels where the reverse link from the user to the Internet is much slower than the forward link to the user. The problem is that the reverse channel can saturate with dataless ACKs well before the forward link's full capacity is achieved. My scheme has the bottleneck reverse link router spy on the TCP packets as they go by. If a new packet arrives for a TCP connection that already has a packet in the queue, and if the older packet contains no flags or data, the older packet is replaced with the newer packet. The very same scheme should work on any path, including those with 'temporary' bottlenecks such as dialup IP routers and IPSEC tunnels with long key setup times. It's a layering violation in that you have an intermediate system spying on end-to-end headers, but it's in the same relatively benign class as VJ header compression as both leave the end-to-end TCP checksums alone. In fact, selective deletion of TCP packets is arguably less of a layer violation than VJ header compression because the only option the router has is to drop a packet or forward it unchanged. TCP and other end-to-end protocols have always been designed to handle packet drops as they've long been expected behavior of the Internet. Phil From owner-ipsec Mon Dec 23 22:37:00 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA17374 for ipsec-outgoing; Mon, 23 Dec 1996 22:35:54 -0500 (EST) Message-Id: <199612240338.TAA00788@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Mon, 23 Dec 96 19:38:43 -0800 To: ipsec@tis.com Subject: draft-ietf-ipsec-isakmp-06.txt Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk The following two clips of text are from draft-ietf-ipsec-isakmp-06.txt. > 3.10 Certificate Request Payload > > > The Certificate Request Payload provides a means to request certificates > via ISAKMP and can appear in any message. Certificate Request payloads > SHOULD be included in an exchange whenever an appropriate directory ser- > vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi- > cates. The Certificate Request payloads MUST be accepted at any point > during the exchange. The responder to the Certificate Request payload > MUST send its immediate certificate, if certificates are supported, and > SHOULD send as much of its certificate chain as possible. Figure 11 shows > the format of the Certificate Request Payload. > > > 5.8 Certificate Request Payload Processing > > > When a Certificate Request payload is received, the receiving entity (ini- > tiator or responder) MUST do the following: > [ snip ] > > 2. Determine if the Certificate Types are supported. If any of the > Certificate Types are not supported, the message is discarded and the > following actions are taken: > > (a) The event, INVALID CERTIFICATE TYPE, is logged in the appropriate > system audit file. > > (b) An Informational Exchange with a Notification payload containing > the INVALID-CERT-ENCODING message type MAY be sent to the > initiating entity. This action is dictated by a system security > policy. > What is the intention here? These statements imply the sender knows the certificate types the recipient supports. -dpg From owner-ipsec Tue Dec 24 00:09:57 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA17796 for ipsec-outgoing; Tue, 24 Dec 1996 00:07:59 -0500 (EST) Date: Mon, 23 Dec 1996 21:10:37 -0800 (PST) From: Phil Karn Message-Id: <199612240510.VAA29292@servo.qualcomm.com> To: karn@qualcomm.com CC: sommerfeld@apollo.hp.com, solensky@ftp.com, rodney@sabletech.com, naganand@ftp.com, ipsec@tis.com In-reply-to: <199612240329.TAA29126@servo.qualcomm.com> (karn) Subject: Re: IPsec and TCP Sender: owner-ipsec@ex.tis.com Precedence: bulk >My scheme has the bottleneck reverse link router spy on the TCP >packets as they go by. If a new packet arrives for a TCP connection >that already has a packet in the queue, and if the older packet >contains no flags or data, the older packet is replaced with the newer >packet. A minor modification is needed to drop TCP SYN packets piling up in a bottleneck router: if the older packet contains no flags or data, OR if the newer packet contains all data and flags of the older packet, then the older packet can be replaced with the newer one. Phil From owner-ipsec Tue Dec 24 10:16:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA20796 for ipsec-outgoing; Tue, 24 Dec 1996 10:14:30 -0500 (EST) Date: Tue, 24 Dec 1996 10:17:15 -0500 From: Norman Shulman To: Phil Karn cc: sommerfeld@apollo.hp.com, solensky@ftp.com, rodney@sabletech.com, naganand@ftp.com, ipsec@tis.com Subject: Re: IPsec and TCP In-Reply-To: <199612240510.VAA29292@servo.qualcomm.com> Message-Id: <96Dec24.101649est.30787-2@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 24 Dec 1996, Phil Karn wrote: > >My scheme has the bottleneck reverse link router spy on the TCP > >packets as they go by. If a new packet arrives for a TCP connection > >that already has a packet in the queue, and if the older packet > >contains no flags or data, the older packet is replaced with the newer > >packet. > > A minor modification is needed to drop TCP SYN packets piling up in a > bottleneck router: if the older packet contains no flags or data, OR > if the newer packet contains all data and flags of the older packet, > then the older packet can be replaced with the newer one. Or simply, if the newer packet contains all data and flags of the older packet, then the older packet can be replaced with the newer one. Norm Norman Shulman Secure Computing Canada Developer Tel 1 416 368 7157 ext 304 norm@border.com Fax 1 416 368 7178 From owner-ipsec Tue Dec 24 14:41:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA21851 for ipsec-outgoing; Tue, 24 Dec 1996 14:40:15 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <199612192211.RAA02883@thunk.orchard.medford.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Dec 1996 14:42:25 -0500 To: Oliver Spatscheck From: Stephen Kent Subject: Re: ISAKMP DOI Question (General, Not IP Specific) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been away on vacation, so pardon my tardy comments on this toipic. (At least I tried to read the whole thread before commenting ...) Ran did a good job of describing an IPSEC processing selector function, something that also I described in my presentation at the WG meeting a couple of weeks ago. This function examines a set of parameters derrived from the packet and/or passed along as PCI (e.g., the ones cited by Ran and, optionally, a security level is appropriate) to select the sequence of SAs to be applied to an outbound datagram. The parameters are defined by the security policy in force locally, and by what has been negotiated in the course of establishing SAs with other IPSEC sites. Note that an outbound datagram may be subjected to more than one layer of IPSEC processing, e.g., a transport mode AH above a tunnel mode ESP that terminates at a security gateway). Thus I've assumed that the output of the selection function would be not just one SA, but a sequence of SAs (which may, of course, be just one SA). This also suggests that it is not sufficient to specific the processing by using an SPI passed down by a higher layer protocol, since an SPI idetifies just one SA. So, on a multi-user end system, in addition to the need to prevent one user from being able to request processing under the imprimateur of another user, in general there is a need to support a sequence of IPSEC processing steps, involving multiple SAs. Steve From owner-ipsec Tue Dec 24 19:08:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA22805 for ipsec-outgoing; Tue, 24 Dec 1996 19:06:16 -0500 (EST) Message-Id: <199612250009.QAA01148@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Tue, 24 Dec 96 16:09:17 -0800 To: ipsec@tis.com Subject: Q re procol values in draft-ietf-ipsec-isakmp-06.txt Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk >From Appendix A of draft-ietf-ipsec-isakmp-06.txt: > Security protocol values 2-1024 are reserved for IANA use. Values 1025- > 15360 are reserved for future use. Values 15360-16384 are reserved for > private use. > The future and private use protocol values overlap. Should private use be 15361-16384? -dpg From owner-ipsec Tue Dec 24 19:09:49 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA22822 for ipsec-outgoing; Tue, 24 Dec 1996 19:09:45 -0500 (EST) Message-Id: <199612250012.QAA01152@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Tue, 24 Dec 96 16:12:44 -0800 To: ipsec@tis.com Subject: Note re protocol values in draft-ietf-ipsec-isakmp-06.txt Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk > >From Appendix A of draft-ietf-ipsec-isakmp-06.txt: > > > Security protocol values 2-1024 are reserved for IANA use. Values 1025- > > 15360 are reserved for future use. Values 15360-16384 are reserved for > > private use. > > > > The future and private use protocol values overlap. Should > private use be 15361-16384? > Also, if protocol values start at 0, the last possible value is 16383, not 16384. -dpg From owner-ipsec Wed Dec 25 23:46:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29039 for ipsec-outgoing; Wed, 25 Dec 1996 23:37:50 -0500 (EST) Message-Id: <199612260440.UAA01754@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 25 Dec 96 20:40:18 -0800 To: ipsec@tis.com Subject: byte order specification in draft-ietf-ipsec-isakmp-06.txt Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe draft-ietf-ipsec-isakmp-06.txt does not specify byte ordering of integral quantities. Is the ordering network order? -dpg From owner-ipsec Thu Dec 26 12:42:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02403 for ipsec-outgoing; Thu, 26 Dec 1996 12:35:57 -0500 (EST) Date: Thu, 26 Dec 1996 11:36:35 -0600 From: Matt Crawford Subject: Re: IPsec and TCP In-reply-to: "23 Dec 1996 21:10:37 PST." <"199612240510.VAA29292"@servo.qualcomm.com> To: Phil Karn Cc: ipsec@tis.com Message-id: <199612261736.LAA28125@gungnir.fnal.gov> Content-transfer-encoding: 7BIT 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{ A minor modification is needed to drop TCP SYN packets piling up in a > bottleneck router: if the older packet contains no flags or data, OR > if the newer packet contains all data and flags of the older packet, > then the older packet can be replaced with the newer one. You can drop the first half of the OR without change in its effect. And since SYN pileup may well prove to be the common case, there maybe be no speed payoff to checking for oldFlags==0 before checking oldFlags|newFlags == newFlags. From owner-ipsec Thu Dec 26 13:36:06 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02715 for ipsec-outgoing; Thu, 26 Dec 1996 13:35:53 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Dec 1996 13:40:15 -0500 To: Oliver Spatscheck From: Stephen Kent Subject: Re: ISAKMP DOI Question (General, Not IP Specific) more ... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I should have noted that the processing I described in my previous message (and in my slides at the IETF) is most appropriate when one looks at a security gateway (firewall) implemenmtation of IPSEC, or a stack "shim" implementation. In a socket-interface environment, this function can be applied to the set of parameters passed to the OS as part of creating a socket, and thus the steady-state processing for outbound traffic need not include this IPSEC processing selector funciton. Moreover, if one creates an API for IPSEC and applications are IPSEC-aware, then the function is applied as a result of an explicit call to create an SA (or a sequence of linked SAs), again making the per-packet, steady-state processing much simpler and faster. Steve From owner-ipsec Fri Dec 27 12:19:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09152 for ipsec-outgoing; Fri, 27 Dec 1996 12:09:01 -0500 (EST) Date: 27 Dec 96 10:45:25 -0600 Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard From: "James Hughes" To: "Michael Sabin" Cc: iesg@ietf.org, ipsec@tis.com X-Mailer: Cyberdog/1.2 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I went through the exercise of coding up an example datagram as per the > draft. My goal was to chase down details about byte/bit orderings in and > out of the DES, MD5, HMAC, and replay-count operations. I felt that > most of the details were resolvable using the description in the draft > and the cited references. However, in a few cases I felt I was > guessing. > > One suggestion I have is that the draft include an example datagram, > before and after encryption. This will unambiguously nail down all > details about bit/byte ordering. Note that the individual specs for DES > [FIPS-41], MD5 [RFC-1321], and HMAC [Krawczyk] include such examples. This is a fantastic idea. Previous versions had just such an example. I will add this verbatum as an appendix. > Below is the example I came up with. (If anybody is inclined to verify > the example, I'd sure appreciate it. :-) ) Items marked with (*) are > places where I felt I was guessing about byte/bit orderings; some > clarification about these may be desirable. Yes, independent verification would me nice. I have not done so. > mike From owner-ipsec Mon Dec 30 15:58:02 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27724 for ipsec-outgoing; Mon, 30 Dec 1996 15:47:08 -0500 (EST) Message-ID: X-MS-TNEF-Correlator: From: "Waterhouse, Richard" To: "'IPSEC Working Group'" Subject: FW: ISAKMP Version Date: Mon, 30 Dec 1996 15:50:40 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-ipsec@ex.tis.com Precedence: bulk Two questions/comments on version 1. The distinction of Major Version and Minor Version is not clear from the document. Why isn't there just a Version ? (In particular how should the future processing of minor version differ from the future processing of major version when there are multiple versions? I usually like to provide for future probable evolution paths and the fact that you have made this distinction seems to imply you have something in mind that isn't explicitly stated.) 2. If versioning is useful in ISAKMP itself it would appear to be at least as useful at the DOI level (which I would guess would be subject to more frequent change than is ISAKMP itself). Certainly our application envisions an evolving DOI with provision for some level of backward compatibility. begin 600 WINMAIL.DAT M>)\^(BH4`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S <,`!X` M#P`R`"@``0!G`0$@@ ,`#@```,P'# `>``\`,@`H``$`9P$!"8 !`"$````V M0S)!1#5$,#-$-C)$,#$Q0C9$13 P,#!#,#$R.41"1@`J!P$-@ 0``@````(` M`@`!!( !`!,```!&5SH@25-!2TU0(%9E`' ``0````@```!697)S:6]N``(!<0`! M````&P````&[YV?GN<)J'3-32A'0MMP``, 2G;\#RMJL!P`#``80_#89=0,` M!Q"%`@``'@`($ $```!E````5%=/455%4U1)3TY3+T-/34U%3E133TY615)3 M24].,51(141)4U1)3D-424].3T9-04I/4E9%4E-)3TY!3D1-24Y/4E9%4E-) M3TY)4TY/5$-,14%21E)/351(141/0U5-14Y45P`````#`! 0``````,`$1 ! M`````@$)$ $```#W`@``\P(``(X$``!,6D9U"+4\]?\`"@$/`A4"I /D!>L" M@P!0$P-4`@!C: K ?,C4U`H *@8,-L0M@;F)3$N($ 6("!DNP0`(-!N'? @ MX2&P9@705&%J!;%6(@0@`'!D;P70"X DV00`("7@!4!C3&QE"L$#4B!T(X)O MC&-U(6(C4%=H>2:1'&XG!4 GP1>@(&IUAR# )7 D]S\@*$D#H)\>42#0*" + M8 7 :&\'X!YS*Z K4"6@)\)F=73W"' CD!VA8P>0`) :H"1B_FTETR'U(Z$- MT 20)V@LG_0A@*Y#^82'P,0$U@2? )J$CNA'P_&5M!" U`0=P M"U HP#D7_G,#@"8 N M*2)L,OTC4$DD@"'U/.,$("FP#< #*U ]$DE304M-4'\FD"&0%C D@#ZP,> L M`V'L<' G,C4!8C*!!4 G(<\IPD&'..$GPD1/-! G(-LA\ ,@*#'P*S!H- %# M5#YG(*$$($-41%$T0&)JWQWB-0$$8"EQ`U!E()$",'\G`!' &J YT@.1)J%" M2RGY(U @0P20`9 +@#2!"&'_0Z(^@3>@)#()\#5@,Z,E2X>+PN1$O(? MJ5+U%L$"`%70``,`\3\)! ```P`F```````#`#8```````(!1P`!````+ `` M`&,]55,[83T@.W ]1U1%.VP]3D1(33 V+3DV,3(S,#(P-3 T,%HM-S,S,C0` M`@'Y/P$```!'`````````-RG0,C 0A :M+D(`"LOX8(!`````````"]//4=4 M12]/53U.1$A-+T-./5)%0TE0245.5%,O0TX]5T%415)(3U5310``'@#X/P$` M```4````5V%T97)H;W5S92P@4FEC:&%R9 `"`?L_`0```$<`````````W*= MR,!"$!JTN0@`*R_A@@$`````````+T\]1U1%+T]5/4Y$2$TO0TX]4D5#25!) M14Y44R]#3CU7051%4DA/55-%```>`/H_`0```!0```!7871ED_:[`0,`#33]/P```@$4- $` M```0````5)2AP"E_$!NEAP@`*RHE%QX`/0`!````!0```$97.B `````"P`I M``$````+`",```````(!?P`!````10```#QC/553)6$]7R5P/4=4125L/4Y$ M2$TP-BTY-C$R,S R,#4P-#!:+3 To: "Waterhouse, Richard" cc: "'IPSEC Working Group'" Subject: Re: FW: ISAKMP Version In-reply-to: Your message of "Mon, 30 Dec 1996 15:50:40 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <259.851997017.1@cisco.com> Date: Mon, 30 Dec 1996 17:50:17 -0800 From: David Carrel Sender: owner-ipsec@ex.tis.com Precedence: bulk > 1. The distinction of Major Version and Minor Version is not clear from the > document. Why isn't there just a Version ? (In particular how should the > future processing of minor version differ from the future processing of > major version when there are multiple versions? I usually like to provide > for future probable evolution paths and the fact that you have made this > distinction seems to imply you have something in mind that isn't explicitly > stated.) There is no pre-planned use for the minor version numbers. They can be useful, they can also go unused. Future use of them will be determined when we come up with an incompatible change to make. Nonetheless, your point is valid that their use is ambiguous. We should define for now that an implementation should never accept packets with a major OR minor number that is larger than it's own. As for accepting ones that are smaller, that will be defined as those changes are made. One motivation for the distinction between major and minor version is that the old 4 bit version number just happens to occupy the same four bits as the current major version number. So if previous implementations of ISAKMP receive the current packets, they can easily tell they are the wrong version. Same thing when going the other way as well. > 2. If versioning is useful in ISAKMP itself it would appear to be at least > as useful at the DOI level (which I would guess would be subject to more > frequent change than is ISAKMP itself). Certainly our application > envisions an evolving DOI with provision for some level of backward > compatibility. Good thought. I'll have to ponder this a bit more... Dave From owner-ipsec Tue Dec 31 11:06:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02624 for ipsec-outgoing; Tue, 31 Dec 1996 11:03:51 -0500 (EST) Message-Id: <199612311602.LAA01577@hygro.raleigh.ibm.com> To: "James Hughes" Cc: ipsec@tis.com Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard In-Reply-To: Your message of "20 Dec 1996 13:27:56 CST." Date: Tue, 31 Dec 1996 11:02:25 -0500 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk >> Thus, I conclude that the combined transform provides *weaker* >> authentication than the standalone transforms. This surprises me, and >> seems a mistake. >In the case of IP in IP, the inner IP packet is the one protected by this >transform. I will add a statement that IP in IP is what was ment... Thinking about this a bit, It has become less clear to me that the combined ESP/AH/Replay transfor is significantly less strong than an AH that covers the IP header. My reasoning is that with yhe addition of a replay counter, it becomes close to impossible to take an old packet, change the IP header fields and have it accepted at the destination - the replay field will always flag it as a duplicate. >> Another important point: >> >> > 1. (Optional step) Decrypt the first bock of data using the >> > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- >> > ity check" of the count. If the count has decreased below the win- >> > dow or has increased by more than 65k, then it is safe to discard >> > this packet as either a replay, non-authentic or too old. If the >> > count is within 65K, then the probability that the packet is >> > authentic is 65535/65536. (The following replay check and HMAC >> > check are both still required). >> >> Maybe I'm missing something, but the above would appear to not handle >> network partitions well. If a destination becomes unreachable (for >> whatever reason), and the sender sends 65K packets during the outage, >> packets sent after the destination becomes reachable again will >> continue to be rejected. Thus, this "optimization" seems wrong. >2 comments, First, my choice of 65000 was arbitrary. That number can be up >to 16M with little change. That is, by making sure that the number was >within 16M, then the probabilitiy of a bad packet being caught is 255/256, >which makes this still reasonable. It seems to me you don't want to have *any* limit. Replay protection requires that you not accept any packets with sequence numbers lower than the highest received so far (modulo the window). Under what conditions would it be correct to reject a packet with a higher sequence number than seen so far? I agree that receiving a packet with a replay coutners whole lot greater than expected should serve as a warning that something is not right (e.g., there was a network partition). However, simply rejecting such packets without taking further action (such as renegotiating keys) can lead to connectivity failures that won't fix themselves. My recommendation would be to remove the text and the quick test (since it may be incorrect) and add a paragraph suggesting that such a test might be useful to detect problems that require further investigation. E.g., it might be useful to renegotiate keys. Just blindly rejecting packets that arrive with a greatly advanced replay counter can lead to connectivity failures. >> I assume the IV needs to be a multiple of 64-bits (to insure that the >> Data starts on a 64-bit boundary for IPv6)? If so, the draft should >> state this explicitely (it doesn't seem to). >Interesting point. I assumed that the IV was a full DES block or 64 >bits. Oh, right. The IPv6 alignment requirement falls out naturally, but isn't the driving motivation. What is a "full DES block"? Wouldn't it be 64 bits as well? >> Also, I don't understand where the 65535/65536 probability comes from >> or what it means. >Assuming that the packet received count (x) and the highest received replay What exactly is the "received count" x? The number of received packets addressed to the same destination with the same SPI? >count (r) are 32 bit unsigned number, if the packet is between r < x < Do you mean if the "replay field of the packet is between.."? >r+65K then this checks to see if x is within the 64k possible. If the field >has been randomized through modification of the first block -or- the If which field has been randomized? The replay counter field? (Sorry if this seems really basic, but I'm missing something important obviously.) >attacker does not know the key, then the value of x will be any random 32 >bit value or one of 4B numbers. The probability of 2 random 32 bit numbers >being within 65K of each other is 4B/65K or 65K. >> >Appendix A >> > >> > This is a routine that implements a 32 packet window. This is intend- >> > ed on being an implementation sample. >> >> This code in fact assumes that the replay counter always starts at >> 0. It should state this, since this assumption is not made elsewhere >> in the draft. >> >> Also, if it is reasonable to always start the replay counter at zero, >> why does the draft not simply require this? Right now, the initial >> counter value is negotiated. >Good point. I assumed that the caller would normalize this (by subtracting >the starting value. Since this is an unsigned value, this works.) Again, I >will add commments regarding this. I'm still a bit unclear about whether the replay counter should/should not start at 0. If it shouldn't (and it probably shouldn't, since the first packet sent to a new SPI would then have a predictable replay field value) I think the document should say so explicitely. On another point that others have brought up, I don't see the value of having a *negotiated* replay window. I think its reasonable for the receiver to have one, but for the sender to know what its size is implies that the sender would (for some reason) find it useful to send (slightly) out of sequence packets and derive some sort of benefit. I don't have a clear sense of why a sender would do that and what benefit it would derive. Thomas From owner-ipsec Tue Dec 31 14:41:21 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03906 for ipsec-outgoing; Tue, 31 Dec 1996 14:39:36 -0500 (EST) Date: 31 Dec 96 13:41:47 -0600 Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard From: "James Hughes" To: "James Hughes" , "Thomas Narten" Cc: ipsec@tis.com X-Mailer: Cyberdog/1.2 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> I assume the IV needs to be a multiple of 64-bits (to insure that the > >> Data starts on a 64-bit boundary for IPv6)? If so, the draft should > >> state this explicitely (it doesn't seem to). > > >Interesting point. I assumed that the IV was a full DES block or 64 > >bits. > > Oh, right. The IPv6 alignment requirement falls out naturally, but > isn't the driving motivation. What is a "full DES block"? Wouldn't it > be 64 bits as well? Yes. > >> >Appendix A > >> > > >> > This is a routine that implements a 32 packet window. This is intend- > >> > ed on being an implementation sample. > >> > >> This code in fact assumes that the replay counter always starts at > >> 0. It should state this, since this assumption is not made elsewhere > >> in the draft. >From the text, the replay counter starts at: RP_key_I is the initial value and wrap point for the replay prevention field for traffic from the initiator -> responder. The appendix A code is relative to 0, not the actual value starting value, therefore, before calling the routine in Appendix A, RP_key_I must be (unsigned) subtracted from the count of a given received packet. > On another point that others have brought up, I don't see the value of > having a *negotiated* replay window. I think its reasonable for the > receiver to have one, but for the sender to know what its size is > implies that the sender would (for some reason) find it useful to send > (slightly) out of sequence packets and derive some sort of benefit. I > don't have a clear sense of why a sender would do that and what > benefit it would derive. If you are sending bridged packets, the sender may want to force the receiver to have a 0 window size, that it does not accept any out of order packets. It was added after a vote at a meeting. I did not propose it. >> > 1. (Optional step) Decrypt the first bock of data using the >> > appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- >> > ity check" of the count. Lets now take a -fresh- look at the optimization and forget what the draft says or what the previous email said. If someone wanted to perform a SYN type (clogging attack) of attack on an IPsec device, it could take any open SPI and send in packets with random data exchanged for the encrypted data. To detect a bogus packet, the decrypting device would require DES on the entire packet and MD5 on the whole packet as well. If the network the device is attached to is faster than the packet processing (DES/MD5) engine, then the queues will fill and packets will be tossed and denial of service may result. Since the count is encrypted (and assuming the attacker does not have the DES key and therefore can not create known non-duplicate counts), detecting someone trying to clog can be performed by decrypting the first block and seeing -if- the decrypted count is reasonably valid (since the attacker can not control what the data looks like after the decryption step). Next, if we 1) Assume that the packets are always decypted processed by the same decryption device (so that changes in topology do not create different decryption locations) and that all valid decryptions are performed by this single device (more succinctly, all valid received counts are processed by a single device). 2) This is not multicast with shared keys. (If this is a multicast with shared keys, then I can see some reason to allow the traffic to go away and come back, but this is not really intended to be a shared key multicast protocol?) 3) Assume that breakage of complete connectivity loss (topology changes that are fatal to traffic) for extend periods of time (greater than X packets) is tantamount to source or destination failure. Then > Under what conditions would it be correct to reject a packet with a higher > sequence number than seen so far? When the count has moved up by X or more packets. My initial assumption was that X of 64K packets was enough. X of 16M packets would be OK too. X of 4billion would be illogical, it is beyond the key lifetime. This is my logic on this. I have no problem with removing the section. Comments? jim From owner-ipsec Tue Dec 31 15:10:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04081 for ipsec-outgoing; Tue, 31 Dec 1996 15:10:13 -0500 (EST) Date: Tue, 31 Dec 1996 15:12:10 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199612312012.PAA16955@earth.hpc.org> To: hughes@nsco.network.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199612311956.MAA07022@baskerville.CS.Arizona.EDU> Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't think we want to define different transforms for multicast, but I'm not sure that having traffic "go away and come back" is a multicast property. Perhaps I'm missing the point. It seems to me that there are local problems (no buffer space) that could lead to long dropout periods. Hilarie :-) How does the replay mechanism behave if there is a stuck bit in the reply counter? From owner-ipsec Tue Dec 31 15:29:29 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04229 for ipsec-outgoing; Tue, 31 Dec 1996 15:29:16 -0500 (EST) Message-Id: <199612312028.PAA02656@hygro.raleigh.ibm.com> To: "James Hughes" Cc: ipsec@tis.com Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard In-Reply-To: Your message of "31 Dec 1996 13:41:47 CST." Date: Tue, 31 Dec 1996 15:28:11 -0500 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk >The appendix A code is relative to 0, not the actual value starting value, >therefore, before calling the routine in Appendix A, RP_key_I must be >(unsigned) subtracted from the count of a given received packet. Sounds good. Just be sure to add some text saying this, as it wasn't obvious to me at first. >> On another point that others have brought up, I don't see the value of >> having a *negotiated* replay window. I think its reasonable for the >> receiver to have one, but for the sender to know what its size is >> implies that the sender would (for some reason) find it useful to send >> (slightly) out of sequence packets and derive some sort of benefit. I >> don't have a clear sense of why a sender would do that and what >> benefit it would derive. >If you are sending bridged packets, the sender may want to force the >receiver to have a 0 window size, that it does not accept any out of order >packets. It was added after a vote at a meeting. I did not propose >it. Could someone provide the rational and add a few motivating lines to the text? It's come up enough times on the list that its usefulness is clearly not obvious to everyone. Plus, the bridge example seems bizarre to me. When does a sending node know that there are bridges in between it and the ultimate recipient? If it doesn't know, how can it take advantage of the (optional) window? >Lets now take a -fresh- look at the optimization and forget what the draft >says or what the previous email said. Good explanation. >> Under what conditions would it be correct to reject a packet with a >higher >> sequence number than seen so far? >When the count has moved up by X or more packets. But there are also scenarios where count will have increased by X or more legitimately (though I agree that this will not be a common case). So from a correctness perspective, it's not 100% clear that one should always perform this check. I'd like the document to explain the pros and cons of doing the check, so that an implementor can make an intelligent choice. The quick check is just to help deal with denial of service attacks. It is not needed for correctness, and can in fact lead to cases where legitimate packets are dropped (and all subsequent communication fails until a new SA is negotiated). If you end up leaving the text in the draft, I'd suggest adding a few sentences making this motivation more clear. (The step is optional.) There are also other tricks that could be employed to reduce the damage of denial of service attacks that wouldn't have the same problem. For example, keep track of the rate at which packets aren't authenticating properly, and when the rate exceeds some threshold, take more agressive action (like using the quick check on 95% of the packets, but still doing the full check every once in a while). Thomas From owner-ipsec Tue Dec 31 16:33:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04561 for ipsec-outgoing; Tue, 31 Dec 1996 16:29:14 -0500 (EST) Date: 31 Dec 96 15:31:51 -0600 Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard From: "James Hughes" To: "Thomas Narten" Cc: ipsec@tis.com X-Mailer: Cyberdog/1.2 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for the help. I will add your suggested clarifications to the next draft. > >The appendix A code is relative to 0, not the actual value starting value, > >therefore, before calling the routine in Appendix A, RP_key_I must be > >(unsigned) subtracted from the count of a given received packet. > > Sounds good. Just be sure to add some text saying this, as it wasn't > obvious to me at first. OK. > >> On another point that others have brought up, I don't see the value of > >> having a *negotiated* replay window. I think its reasonable for the > >> receiver to have one, but for the sender to know what its size is > >> implies that the sender would (for some reason) find it useful to send > >> (slightly) out of sequence packets and derive some sort of benefit. I > >> don't have a clear sense of why a sender would do that and what > >> benefit it would derive. > > >If you are sending bridged packets, the sender may want to force the > >receiver to have a 0 window size, that it does not accept any out of order > >packets. It was added after a vote at a meeting. I did not propose > >it. > > Could someone provide the rational and add a few motivating lines to > the text? It's come up enough times on the list that its usefulness is > clearly not obvious to everyone. Plus, the bridge example seems > bizarre to me. When does a sending node know that there are bridges in > between it and the ultimate recipient? If it doesn't know, how can it > take advantage of the (optional) window? Anyone? I do not know if this is -actually- negotiated, Hillary? > >> Under what conditions would it be correct to reject a packet with a > >>higher sequence number than seen so far? > > >When the count has moved up by X or more packets. > > But there are also scenarios where count will have increased by X or > more legitimately (though I agree that this will not be a common > case). So from a correctness perspective, it's not 100% clear that one > should always perform this check. > > I'd like the document to explain the pros and cons of doing the check, > so that an implementor can make an intelligent choice. The quick check > is just to help deal with denial of service attacks. It is not needed > for correctness, and can in fact lead to cases where legitimate > packets are dropped (and all subsequent communication fails until a > new SA is negotiated). If you end up leaving the text in the draft, > I'd suggest adding a few sentences making this motivation more > clear. (The step is optional.) OK. > There are also other tricks that could be employed to reduce the > damage of denial of service attacks that wouldn't have the same > problem. For example, keep track of the rate at which packets aren't > authenticating properly, and when the rate exceeds some threshold, > take more agressive action (like using the quick check on 95% of the > packets, but still doing the full check every once in a while). Good idea. Once and a while when the quick check fails, do the complete check... Interesting... Hmm... > Thomas Thanks! jim. From owner-ipsec Tue Dec 31 16:39:40 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04608 for ipsec-outgoing; Tue, 31 Dec 1996 16:38:21 -0500 (EST) Date: 31 Dec 96 15:41:04 -0600 Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention From: "James Hughes" To: hughes@nsco.network.com, "Hilarie Orman" Cc: ipsec@tis.com X-Mailer: Cyberdog/1.2 Message-Id: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I don't think we want to define different transforms for multicast, but I'm > not sure that having traffic "go away and come back" is a multicast > property. Other than a "broadcast" kinda of traffic which continues whether or not the destination is still there, (I am assuming that multicast is the method of choice for broadcast), is the major type of traffic that will continue to bable after the topology goes half duplex or no duplex... With routers, if the path goes away long enough, then the route protocols will give up as a bad path? > Perhaps I'm missing the point. It seems to me that there are > local problems (no buffer space) that could lead to long dropout periods. How long is long. I can agree that 65K is not too long at OC-48c.... > Hilarie > > :-) How does the replay mechanism behave if there is a stuck bit in the reply > counter? If X is 64K, if the stuck bit is in the top 16 bits, you will never come up. If it is in the lower 16 bits, you will lose half of the traffic. jim From owner-ipsec Tue Dec 31 19:10:21 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05384 for ipsec-outgoing; Tue, 31 Dec 1996 19:09:21 -0500 (EST) Message-Id: <199701010012.QAA02084@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Tue, 31 Dec 96 16:12:04 -0800 To: "James Hughes" Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard cc: "Thomas Narten" , ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> > 1. (Optional step) Decrypt the first bock of data using the > >> > appropriate DES_key_ and IV_key_ (or IV) and then do a quick > "san- > >> > ity check" of the count. > > Lets now take a -fresh- look at the optimization and forget what > the draft says or what the previous email said. > > If someone wanted to perform a SYN type (clogging attack) of > attack on an IPsec device, it could take any open SPI and send in > packets with random data exchanged for the encrypted data. To > detect a bogus packet, the decrypting device would require DES > on the entire packet and MD5 on the whole packet as well. If the > network the device is attached to is faster than the packet > processing (DES/MD5) engine, then the queues will fill and > packets will be tossed and denial of service may result. > > Since the count is encrypted (and assuming the attacker does > not have the DES key and therefore can not create known > non-duplicate counts), detecting someone trying to clog can > be performed by decrypting the first block and seeing -if- the > decrypted count is reasonably valid (since the attacker can > not control what the data looks like after the decryption > step). > Since is no mechanism to validate the replay counter without decrypting the whole packet and validating it, there is a replay window size dependent probability that randomly chosen "first DES words" may cause the whole packet to be processed. If the replay window is 64k and the replay counter 32 bits, then that probability is 64000/4294967296 = ~.000014, or ~1/67108. Presumably the replay window size is that large (64k) to account for high speed data. It seems reasonable to believe, then, from a flood of 67k packets one will result in a CPU spike. If we assume the attacker is able to monitor the receptor and detect the spike then some valuable information is gained: bogus_data = DES(replay count +/- 64k), or several bits of fixed, albeit unknown, text. I can't say how useful the knowledge of unknown fixed text will be to an attacker (it may be useful in conjunction with other data) or whether the assumption I made holds, successful attacks based on timing information have been mounted on systems in the past. -dpg From owner-ipsec Tue Dec 31 20:45:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA05757 for ipsec-outgoing; Tue, 31 Dec 1996 20:44:31 -0500 (EST) Message-Id: <199701010147.RAA02144@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Tue, 31 Dec 96 17:47:17 -0800 To: phan@itd.nrl.navy.mil, cmetz@inner.net, danmcd@eng.sun.com Subject: Comment regarding draft-mcdonald-pf-key-v2-00.txt cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk The following text is from section 2.1, BASE MESSAGE HEADER FORMAT of draft-mcdonald-pf-key-v2-00.txt: > sadb_sa_ivlen Contains the length of the initialization > vector (IV) for the security association, > expressed in bits. The IV is the random > data used by the cryptographic transform > to process a packet. The PF_KEY interface > does not communicate or generate the IV > data, but it does communicate the length > of data needed. A value of zero indicates > that no IV is needed. > If the PF_KEY interface does not communicate the IV, does that mean the kernel generates the IV? Assuming the kernel is supposed to generate the IV, why not allow the PF_KEY interface transfer an IV? It seems to me, if an external hardware were available, random data would be best obtained by a user level application rather than the kernel. Why not generalize and have a function where the kernel MAY request random data from a user level application for use as IV, Cookies, ... The document discusses the field "sadb_sa_dpd_domain" (Data Protection Domain of Interpretation (DOI)) of the structure sadb_msg_hdr but there is no such entry. Perhaps it is discussing "sadb_sa_sens_domain"? Similarly, "sadb_sa_sens_level" and "sadb_sa_integ_level" are described however "sadb_sa_sens_label" and "sadb_sa_integ_label" are sadb_msg_hdr's content. Regarding Section 2.3, ADDITIONAL MESSAGE FIELDS, since the daemons must always run locally, I disagree a sockaddr structure must be defined to include sa_len if the native one does not. Such a structure would be alien to the environment, and, as mentioned in draft-mcdonald-pf-key-v2-00.txt, redundant. Why is the inclusion of sa_len declared MUST? The data gram depicted in Section 2.4, ILLUSTRATION OF MESSAGE LAYOUT, does not match the definition of sadb_msg_hdr. Values for LIFETYPE_SEC, LIFETYPE_KB, and LIFETYPE_PACKETS are not defined. In section 3.2, SECURITY ASSOCIATION STATE, the description of SA_FORWARD does not follow the same format as the other state flags. -dpg