From owner-ipsec Tue Sep 1 16:05:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18213 for ipsec-outgoing; Tue, 1 Sep 1998 16:02:47 -0400 (EDT) Message-Id: <199809012019.PAA20646@gungnir.fnal.gov> To: ipsec@tis.com Cc: Thomas Narten , Steve Deering , Bob Hinden From: "Matt Crawford" Subject: ICMP type field as SPD selector? Date: Tue, 01 Sep 1998 15:19:16 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk I am trying to prepare a sufficient specification of how IPv6 "Router Renumbering" should (excuse me, MUST) be protected by IPsec. Router renumbering is done through ICMPv6 packets with Type=138. The Type field is not one of those listed in section 4.4.2 of the ipsec-arch-sec-07 as a REQUIRED or OPTIONAL selector parameter, and yet I'm sure one would not want to treat all ICMP types equally, in general. I would suggest that the Type field be mentioned as a selector parameter, but it seems a little late for that. Perhaps my document could dictate that implemetations must support such a selector, but that seems a bit far afield. I solicit other suggestions. ______________________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab "A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment, thoroughly smash them with a hammer or an ax, and scatter the pieces." From owner-ipsec Wed Sep 2 02:28:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA20397 for ipsec-outgoing; Wed, 2 Sep 1998 02:24:50 -0400 (EDT) Message-Id: <3.0.1.32.19980902104153.00703d0c@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 02 Sep 1998 10:41:53 +0500 To: "Scott G. Kelly" From: "S. B. Kulkarni" Subject: Re: Deletion of SA Cc: ipsec@tis.com In-Reply-To: <3516AEC5.5B35034@redcreek.com> References: <199803231507.KAA00292@morden.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Scott, I remember you raised the following question in response to my question regarding SA deletion. But there was no further discussion on this issue. The issue was that, which SA to be deleted when you receive the delete payload with multiple SPI. At 10:49 AM 3/23/98 -0800, you wrote: >This issue raises some confusion, and I'm also uncertain as to whether >the current document adequately addresses it. If there are SA's in both >directions between H1 and H2, and H1 sends a delete payload to H2, >which >SA may it apply to? If we say it only applies to the SA into H1 from H2 >(H1's INBOUND SA), no ambiguity exists. However, there may be ambiguity >if we permit H1 to also delete SA's which are outbound with respect to >H1. This is because the delete payload permits multiple SPI's to be >specified, but gives no mechanism for specifying which SPI is which. >Since the SPI's are generated independently, they could (in theory, at >least) be identical. > >It seems the only thing permitted by the protocol as it currently >stands >is for H1 to delete the INBOUND SA (from H2 to H1), and to send a >notify >payload with perhaps NOTIFY-SA-LIFETIME in it to delete the OUTBOUND SA. Thanks - Srinu ****************************************************************** * OFFICE ADDRESS : * * SrinivasRao. B. Kulkarni * * Rendezvous On Chip Pvt Ltd. * * First Floor, Plot No. 14, * * NewVasaviNagar, Kharkhana, * * SECUNDERABAD - 500015. * * STATE ANDHRA PRADESH * * INDIA * * Ph : (040) 7742606, 7740406 * * email address : srinu@trinc.com * ****************************************************************** From owner-ipsec Wed Sep 2 11:00:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22851 for ipsec-outgoing; Wed, 2 Sep 1998 10:58:24 -0400 (EDT) Message-ID: <35ED63E7.37BB7B34@tiac.net> Date: Wed, 02 Sep 1998 11:27:36 -0400 From: Michael Giniger X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: IP compression of entire datagram X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I was reading through the IP compression draft and it appears that the draft only intends for IP compression to be performed on the payload portion of IP packets. In the case of IP security gateways that operate in tunnel mode, is it correct (and standards compliant) to perform IP compression on the entire inner IP datagram instead of just the payload portion of the inner IP datagram? Thanks in advance sincerely Michael Giniger Assured Digital, Inc. From owner-ipsec Wed Sep 2 12:28:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23180 for ipsec-outgoing; Wed, 2 Sep 1998 12:27:25 -0400 (EDT) Message-ID: <35ED7628.A1FA0E0D@redcreek.com> Date: Wed, 02 Sep 1998 09:45:28 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "S. B. Kulkarni" CC: ipsec@tis.com Subject: Re: Deletion of SA References: <199803231507.KAA00292@morden.sandelman.ottawa.on.ca> <3.0.1.32.19980902104153.00703d0c@172.16.1.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk S. B. Kulkarni wrote: > > Hi Scott, > > I remember you raised the following question in response to my question > regarding SA deletion. But there was no further discussion on this issue. > The issue was that, which SA to be deleted when you receive the delete > payload with multiple SPI. > Right. For the entire thread, see http://www.sandelman.ottawa.on.ca/ipsec/1998/03/msg00235.html and follow the thread-next links. The issue was never resolved, although as a practical matter we decided (for our products) that you may only delete the incoming SA, and may send the notify for the outgoing SA as a courtesy. This dances around a much larger problem, one which is at the root of several other blossoming issues, not the least is which is the so-called 'rekey collision' problem, where both sides timeout the SA at the same time and collide while trying to rekey. This larger problem has to do with the semantic definition of the SA vs. the actual operational definition as we have implemented it. SA's are, by definition, unidirectional constructs. As a matter of convenience, this directional distinction has been blurred and SAs have been linked into inbound-outbound pairs in our current implementations. This simplifies parameter negotiation in that we can negotiate a symmetric SA pair with one exchange group, reducing the overhead associated with SA instantiation. On the other hand, this has several drawbacks, not the least of which are the behavioral ambiguities related to deleting SAs and rekeying. This is an issue which requires thoughtful exploration. While the convenience realized from 'bidirectionalizing' the SAs is substantial (and therefore perhaps justifiable), the ramifications have not been fully considered. I believe this issue is on the agenda for ipsecond. If you have suggestions for resolution, please post them. From owner-ipsec Wed Sep 2 12:54:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23251 for ipsec-outgoing; Wed, 2 Sep 1998 12:53:25 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809021712.KAA24790@kc.livingston.com> Subject: IP comression - Can this be made optional? To: ipsec@tis.com Date: Wed, 2 Sep 1998 10:12:01 -0700 (PDT) Cc: suresh@livingston.com (Pyda Srisuresh) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, When you have an SA bundle consisting of AH, ESP and Compression protocols defined for a class of packets, I understand, the entire SA bundle is required to be applied on packets in either direction. However, I believe, it is desirable to make application of some of the components (of SA bundle) optional. For example, one might not want to compress small packets (say, less than 64 bytes). I would hate to have packets dropped in bit bucket just because they are not compressed. What do others think of this? Is it reasonable to have a policy defined such that one or some of the SA bundle elements can be made optional? Thanks. cheers, suresh From owner-ipsec Wed Sep 2 14:06:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23541 for ipsec-outgoing; Wed, 2 Sep 1998 14:04:26 -0400 (EDT) Message-Id: <199809021821.OAA10927@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Reply-To: mcr@sandelman.ottawa.on.ca Subject: (administrivia) About my archives In-reply-to: Your message of "Wed, 02 Sep 1998 09:45:28 PDT." <35ED7628.A1FA0E0D@redcreek.com> Date: Wed, 02 Sep 1998 14:20:56 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott's post reminded me of something that I had been meaning to do with the archive: indicate useful places to start reading for specific topics. I have started this with Scott's post about Deletion of SAs. If you have other interesting starting points to past exchanges, please send them to me to be added. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Wed Sep 2 14:38:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23672 for ipsec-outgoing; Wed, 2 Sep 1998 14:37:31 -0400 (EDT) Date: Wed, 2 Sep 1998 14:54:07 -0400 Message-Id: <199809021854.OAA14882@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: suresh@livingston.com Cc: ipsec@tis.com Subject: Re: IP comression - Can this be made optional? References: <199809021712.KAA24790@kc.livingston.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Pyda" == Pyda Srisuresh writes: Pyda> Hi, Pyda> When you have an SA bundle consisting of AH, ESP and Pyda> Compression protocols defined for a class of packets, I Pyda> understand, the entire SA bundle is required to be applied on Pyda> packets in either direction. Pyda> However, I believe, it is desirable to make application of some Pyda> of the components (of SA bundle) optional. For example, one Pyda> might not want to compress small packets (say, less than 64 Pyda> bytes). I would hate to have packets dropped in bit bucket just Pyda> because they are not compressed. What do others think of this? That's already explicitly allowed. In fact, it is sometimes required, since the IPCOMP spec says you're not allowed to compress something that gets bigger when compressed. So the receiver already has to deal with the possibility that an incoming packet is not compressed even though the bundle has compression in it. (Unfortunately, the ESP envelope makes detecting this VERY painful.) paul From owner-ipsec Wed Sep 2 15:31:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23797 for ipsec-outgoing; Wed, 2 Sep 1998 15:29:38 -0400 (EDT) Date: Wed, 2 Sep 1998 15:44:34 -0400 (EDT) From: Henry Spencer To: Pyda Srisuresh cc: ipsec@tis.com Subject: Re: IP comression - Can this be made optional? In-Reply-To: <199809021712.KAA24790@kc.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > When you have an SA bundle consisting of AH, ESP and > Compression protocols defined for a class of packets, > I understand, the entire SA bundle is required to be > applied on packets in either direction. No, an SA bundle is unidirectional, just like the SAs themselves. In principle, the set of SAs connecting two systems could be asymmetric. (And there are situations where this would be worthwhile, e.g. a highly asymmetric communications link might want compression on only the slow side.) The "Security Architecture" draft says quite explicitly that there are separate SPDs for inbound and outbound traffic. > However, I believe, it is desirable to make application > of some of the components (of SA bundle) optional. For > example, one might not want to compress small packets > (say, less than 64 bytes)... It would be better to define a compression scheme that is intelligent about this, I would think. > Is it reasonable to have a policy defined such that one > or some of the SA bundle elements can be made optional? Is there another example of where it would be useful? Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Wed Sep 2 16:33:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24369 for ipsec-outgoing; Wed, 2 Sep 1998 16:31:13 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809022049.NAA04395@kc.livingston.com> Subject: Re: IP comression - Can this be made optional? To: pkoning@xedia.com (Paul Koning) Date: Wed, 2 Sep 1998 13:49:19 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: <199809021854.OAA14882@tonga.xedia.com> from "Paul Koning" at Sep 2, 98 02:54:07 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > >>>>> "Pyda" == Pyda Srisuresh writes: > > Pyda> Hi, > > Pyda> When you have an SA bundle consisting of AH, ESP and > Pyda> Compression protocols defined for a class of packets, I > Pyda> understand, the entire SA bundle is required to be applied on > Pyda> packets in either direction. > > Pyda> However, I believe, it is desirable to make application of some > Pyda> of the components (of SA bundle) optional. For example, one > Pyda> might not want to compress small packets (say, less than 64 > Pyda> bytes). I would hate to have packets dropped in bit bucket just > Pyda> because they are not compressed. What do others think of this? > > That's already explicitly allowed. In fact, it is sometimes required, > since the IPCOMP spec says you're not allowed to compress something > that gets bigger when compressed. > > So the receiver already has to deal with the possibility that an > incoming packet is not compressed even though the bundle has > compression in it. > > (Unfortunately, the ESP envelope makes detecting this VERY painful.) > > paul > OK. Thanks for the info. cheers, suresh From owner-ipsec Wed Sep 2 16:35:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24397 for ipsec-outgoing; Wed, 2 Sep 1998 16:35:13 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809022052.NAA04417@kc.livingston.com> Subject: Re: IP comression - Can this be made optional? To: henry@spsystems.net (Henry Spencer) Date: Wed, 2 Sep 1998 13:52:49 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: from "Henry Spencer" at Sep 2, 98 03:44:34 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > When you have an SA bundle consisting of AH, ESP and > > Compression protocols defined for a class of packets, > > I understand, the entire SA bundle is required to be > > applied on packets in either direction. > > No, an SA bundle is unidirectional, just like the SAs themselves. In > principle, the set of SAs connecting two systems could be asymmetric. > (And there are situations where this would be worthwhile, e.g. a highly > asymmetric communications link might want compression on only the slow > side.) The "Security Architecture" draft says quite explicitly that > there are separate SPDs for inbound and outbound traffic. > Are you refering to setting up asymetric SAs without the aid of IKE? cheers, suresh From owner-ipsec Wed Sep 2 20:30:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24790 for ipsec-outgoing; Wed, 2 Sep 1998 20:28:27 -0400 (EDT) Message-Id: <199809030044.RAA29320@airedale.cisco.com> X-Sender: shacham@airedale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 02 Sep 1998 17:43:26 -0700 To: Michael Giniger From: Avram Shacham Subject: Re: IP compression of entire datagram Cc: ipsec@tis.com, ippcp@external.cisco.com In-Reply-To: <35ED63E7.37BB7B34@tiac.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, At 03:27 PM 9/2/98 +0000, Michael Giniger wrote: >Hi > >I was reading through the IP compression draft and it appears that the >draft only intends for IP compression to be performed on the payload >portion of IP packets. In the case of IP security gateways that >operate in tunnel mode, is it correct (and standards compliant) to >perform IP compression on the entire inner IP datagram instead of just >the payload portion of the inner IP datagram? Right, IPComp is applied to the IP payload and in the case of a tunnel the payload does include the inner IP header. Example #1: [IP2][IP1][TCP][data] becomes [IP2][IPCOMP][IP1][TCP][data] ****************** compressed Example #2: [IP2] [ESP spi+replay+iv] [IPCOMP] [IP1] ** compressed [TCP] ** compressed [data] ** compressed [ESP padding+next protocol+auth] This subject was discussed on both ipsec and ippcp mailing lists in the past (recently during 5-98), in case you are looking for more information. Regards, avram From owner-ipsec Wed Sep 2 21:58:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA24996 for ipsec-outgoing; Wed, 2 Sep 1998 21:56:24 -0400 (EDT) Date: Wed, 2 Sep 1998 22:11:26 -0400 (EDT) From: Henry Spencer To: Pyda Srisuresh cc: ipsec@tis.com Subject: Re: IP comression - Can this be made optional? In-Reply-To: <199809022052.NAA04417@kc.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > No, an SA bundle is unidirectional, just like the SAs themselves. In > > principle, the set of SAs connecting two systems could be asymmetric... > > Are you refering to setting up asymetric SAs without the aid of IKE? Yes, either by hand or using a different key-exchange protocol (there are several). IKE has no provision for negotiating asymmetric connections (unless I've misremembered something), but the basic IPSEC architecture permits them. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Thu Sep 3 09:34:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA27285 for ipsec-outgoing; Thu, 3 Sep 1998 09:27:28 -0400 (EDT) Message-ID: <35EE78E7.55963A0E@into.ch> Date: Thu, 03 Sep 1998 13:09:28 +0200 From: Peter Fernandez X-Mailer: Mozilla 4.01 [de] (Win95; I) MIME-Version: 1.0 To: ipsec@ex.tis.com Subject: la Impact of Minimum MTU on Encrypted Packets X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I couldn't find any RFC that states what happens if an authenticated and encrypted packet follows a path with MTU 68 bytes. If tunnel encryption is used the min. lehgth of the packet will be 76 bytes according to my callulations. IP Header = 20, AH = 24, ESP = 12, IP = 20, data = ? -> min. 76 bytes If Path MTU Discovery returns a MTU of 68 bytes the packet can never be sent. Can anyone tell me a solution to this problem. Peter From owner-ipsec Thu Sep 3 12:43:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27795 for ipsec-outgoing; Thu, 3 Sep 1998 12:41:54 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <35EE78E7.55963A0E@into.ch> Date: Thu, 3 Sep 1998 12:59:11 -0400 To: Peter Fernandez From: Stephen Kent Subject: Re: la Impact of Minimum MTU on Encrypted Packets Cc: ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Peter, I'm afraid you can't send tunnel mode traffic using both Ah and ESP over such a small MTU path. Note, however, that you don't need to employ both AH and ESP in many instances, especially in tunnel mode. Steve From owner-ipsec Thu Sep 3 16:36:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28575 for ipsec-outgoing; Thu, 3 Sep 1998 16:34:20 -0400 (EDT) Message-Id: <3.0.1.32.19980903180635.0069a94c@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 03 Sep 1998 18:06:35 +0500 To: "Derrell D. Piper" From: "S. B. Kulkarni" Subject: Re: commit bit processing Cc: ipsec@tis.com In-Reply-To: <199808060235.TAA23868@gallium.network-alchemy.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I want to know what finally decided, on how to process commit bit At 07:35 PM 8/5/98 -0700, Derrell D. Piper wrote: >I agree that it's more logical under the QM exchange (since it's probably a QM >state in your state machine and it uses the QM message ID). My implementation >currently sends it under as an Informational, but I'm happy to change. > >Derrell Thank U - Srinu From owner-ipsec Thu Sep 3 18:25:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28850 for ipsec-outgoing; Thu, 3 Sep 1998 18:24:25 -0400 (EDT) Date: Thu, 3 Sep 1998 18:41:55 -0400 Message-Id: <199809032241.SAA21439@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: One more document: draft-ietf-ipsec-ciph-cbc Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk The RFC Editor has found normative references to which apparently wasn't part of the IPSEC document set that we forwarded to the IESG. This will hold up the IPSEC documents from being published as RFC's until we get this resolved. Oops. After talking to Jeff and Bob, this is how we'd like to fix this oversight. Next Wednesday, I plan to forward this ipsec-ciph-cbc to Jeff for advancement, so that the following day, it will go out to IETF Last Call. This will allow the IESG to vote on this document two weeks later at their teleconference. If anyone has any comments or knows of any changes that needs to be made to draft-ietf-ipsec-ciph-cbc-02.txt before we push it forward for advancement, I'd appreciate it you could let us know right away. Thanks!! - Ted From owner-ipsec Fri Sep 4 05:26:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA00567 for ipsec-outgoing; Fri, 4 Sep 1998 05:24:33 -0400 (EDT) Message-Id: <3.0.1.32.19980904114240.006bad20@172.16.1.10> X-Sender: srinu@172.16.1.10 (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 04 Sep 1998 11:42:40 +0500 To: "Scott G. Kelly" From: "S. B. Kulkarni" Subject: Re: Deletion of SA Cc: ipsec@tis.com In-Reply-To: <35ED7628.A1FA0E0D@redcreek.com> References: <199803231507.KAA00292@morden.sandelman.ottawa.on.ca> <3.0.1.32.19980902104153.00703d0c@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Scott, (May be you are already aware of this) The other day when was re-reading the draft I found that the draft is clear. It says if H1 has SA(s) with H2 and deleted it's inbound SA(s) it sends a delete payload with it's inbound SA(s) SPI to H2. The H2 on receiving delete payload from H1 associates the source address from the packet with SPI(s) and protocol-Id to delete it's outbound SA with H2. Because the draft says the SPI sent in the delete payload is the sending entity's SPI (Refer to the following paragraph from the draft). ******************************************************************** >From draft-ietf-ipsec-isakmp-10.txt, July 3, 1998 3.15 Delete Payload Deletion which is concerned with a Protocol SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH)and the SPI is the sending entity's SPI(s). ********************************************************************* But infact I agree with you that H1 MAY send a Notification Payload to H2 after deleting his outbound SA and delete payload to H2 after deleting his inbound SA. But the problem arises finding the corresponding inbound SA when you delete any outbound SA at H1. One possibility is to reverse the SA selectors and serach. But will it work for all the cases ? Thank U - Srinu At 09:45 AM 9/2/98 -0700, Scott G. Kelly wrote: >S. B. Kulkarni wrote: >> >> Hi Scott, >> >> I remember you raised the following question in response to my question >> regarding SA deletion. But there was no further discussion on this issue. >> The issue was that, which SA to be deleted when you receive the delete >> payload with multiple SPI. >> > > > >Right. For the entire thread, see > >http://www.sandelman.ottawa.on.ca/ipsec/1998/03/msg00235.html > >and follow the thread-next links. > >The issue was never resolved, although as a practical matter we decided >(for our products) that you may only delete the incoming SA, and may >send the notify for the outgoing SA as a courtesy. > >This dances around a much larger problem, one which is at the root of >several other blossoming issues, not the least is which is the so-called >'rekey collision' problem, where both sides timeout the SA at the same >time and collide while trying to rekey. > >This larger problem has to do with the semantic definition of the SA vs. >the actual operational definition as we have implemented it. SA's are, >by definition, unidirectional constructs. As a matter of convenience, >this directional distinction has been blurred and SAs have been linked >into inbound-outbound pairs in our current implementations. This >simplifies parameter negotiation in that we can negotiate a symmetric SA >pair with one exchange group, reducing the overhead associated with SA >instantiation. > >On the other hand, this has several drawbacks, not the least of which >are the behavioral ambiguities related to deleting SAs and rekeying. >This is an issue which requires thoughtful exploration. While the >convenience realized from 'bidirectionalizing' the SAs is substantial >(and therefore perhaps justifiable), the ramifications have not been >fully considered. > >I believe this issue is on the agenda for ipsecond. If you have >suggestions for resolution, please post them. > > ****************************************************************** * OFFICE ADDRESS : * * SrinivasRao. B. Kulkarni * * Rendezvous On Chip Pvt Ltd. * * First Floor, Plot No. 14, * * NewVasaviNagar, Kharkhana, * * SECUNDERABAD - 500015. * * STATE ANDHRA PRADESH * * INDIA * * Ph : (040) 7742606, 7740406 * * email address : srinu@trinc.com * ****************************************************************** From owner-ipsec Fri Sep 4 18:04:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03782 for ipsec-outgoing; Fri, 4 Sep 1998 17:57:09 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF38FE78@exchange.timestep.com> From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: updated draft-ietf-ipsec-ciph-cbc-03.txt Date: Fri, 4 Sep 1998 18:15:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BDD851.871AAA00" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BDD851.871AAA00 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDD851.871AAA00" ------_=_NextPart_001_01BDD851.871AAA00 Content-Type: text/plain; charset="iso-8859-1" Only some minor wording changes have been done since v02. <> Roy Pereira Product Manager, TimeStep Corporation (613) 599-3610 x4808 http://www.timestep.com ------_=_NextPart_001_01BDD851.871AAA00 Content-Type: text/html; charset="iso-8859-1" updated draft-ietf-ipsec-ciph-cbc-03.txt

Only some minor wording changes have been done since v02.

<<draft-ietf-ipsec-ciph-cbc-03.txt>>


Roy Pereira
Product Manager, TimeStep Corporation
(613) 599-3610 x4808
http://www.timestep.com

------_=_NextPart_001_01BDD851.871AAA00-- ------_=_NextPart_000_01BDD851.871AAA00 Content-Type: text/plain; name="draft-ietf-ipsec-ciph-cbc-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipsec-ciph-cbc-03.txt" Content-Location: ATT-0-DECCC0B23644D211931900805FBBADDF-D RB861%7E1.TXT Internet Engineering Task Force R. Pereira IP Security Working Group TimeStep Corporation Internet Draft R. Adams Expires in six months Cisco Systems Inc. September 4, 1998 The ESP CBC-Mode Cipher Algorithms Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. R. Pereira, R. Adams [Page 1] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 Table of Contents 1. Introduction...................................................2 1.1 Specification of Requirements...............................2 2. Cipher Algorithms..............................................3 2.1 Mode........................................................3 2.2 Key Size....................................................3 2.3 Weak Keys...................................................4 2.4 Block Size and Padding......................................6 2.5 Rounds......................................................6 2.6 Backgrounds.................................................6 2.7 Performance.................................................9 3. ESP Payload....................................................9 3.1 ESP Environmental Considerations............................9 3.2 Keying Material............................................10 4. Security Considerations.......................................10 5. References....................................................10 6. Acknowledgments...............................................12 7. Editors' Addresses............................................12 1. Introduction The Encapsulating Security Payload (ESP) [Kent98] provides confidentiality for IP datagrams by encrypting the payload data to be protected. This specification describes the ESP use of CBC-mode cipher algorithms. While this document does not describe the use of the default cipher algorithm DES, the reader should be familiar with that document. [Madson98] It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinson95], "IP Security Document Roadmap" [Thayer97], and "IP Encapsulating Security Payload (ESP)" [Kent98] documents. Furthermore, this document is a companion to [Kent98] and MUST be read in its context. 1.1 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. R. Pereira, R. Adams [Page 2] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 2. Cipher Algorithms All symmetric block cipher algorithms share common characteristics and variables. These include mode, key size, weak keys, block size, and rounds. All of which will be explained below. While this document illustrates certain cipher algorithms such as Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai] [MOV], and RC5 [Baldwin96], any other block cipher algorithm may be used with ESP if all of the variables described within this document are clearly defined. 2.1 Mode All symmetric block cipher algorithms described or insinuated within this document use Cipher Block Chaining (CBC) mode. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm's blocksize. The IV is XOR'd with the first plaintext block, before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext, before it is encrypted. More information on CBC mode can be obtained in [Schneier95]. 2.2 Key Size Some cipher algorithms allow for variable sized keys, while others only allow a specific key size. The length of the key correlates with the strength of that algorithm, thus larger keys are always harder to break than shorter ones. This document stipulates that all key sizes MUST be a multiple of 8 bits. This document does specify the default key size for each cipher algorithm. This size was chosen by consulting experts on the algorithm and by balancing strength of the algorithm with performance. R. Pereira, R. Adams [Page 3] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Algorithm | Key Sizes (bits) | Popular Sizes | Default | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 | +--------------+------------------+-----------------+----------+ | RC5 | 40 to 2040 | 40, 128, 160 | 128 | +--------------+------------------+-----------------+----------+ | IDEA | 128 | 128 | 128 | +--------------+------------------+-----------------+----------+ | Blowfish | 40 to 448 | 128 | 128 | +--------------+------------------+-----------------+----------+ | 3DES [2] | 192 | 192 | 192 | +--------------+------------------+-----------------+----------+ Notes: [1] With CAST-128, keys less than 128 bits MUST be padded with zeros in the rightmost, or least significant, positions out to 128 bits since the CAST-128 key schedule assumes an input key of 128 bits. Thus if you had a key with a size of 80 bits '3B5D831CFE', it would be padded to produce a key with a size of 128 bits '3B5D831CFE000000'. [2] The first 3DES key is taken from the first 64 bits, the second from the next 64 bits, and the third from the last 64 bits. Implementations MUST take into consideration the parity bits when initially accepting a new set of keys. Each of the three keys is really 56 bits in length with the extra 8 bits used for parity. The reader should note that the minimum key size for all of the above cipher algorithms is 40 bits, and that the authors strongly advise that implementations do NOT use key sizes smaller than 40 bits. 2.3 Weak Keys Weak key checks SHOULD be performed. If such a key is found, the key SHOULD be rejected and a new SA requested. Some cipher algorithms have weak keys or keys that MUST not be used due to their weak nature. New weak keys might be discovered, so this document does not in any way contain all possible weak keys for these ciphers. Please check with other sources of cryptography such as [MOV] and [Schneier] for further weak keys. R. Pereira, R. Adams [Page 4] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 CAST-128: No known weak keys. RC5: No known weak keys when used with 16 rounds. IDEA: IDEA has been found to have weak keys. Please check with [MOV] and [Schneier] for more information. Blowfish: Weak keys for Blowfish have been discovered. Weak keys are keys that produce the identical entries in a given S-box. Unfortunately, there is no way to test for weak keys before the S- box values are generated. However, the chances of randomly generating such a key are small. 3DES: DES has 64 known weak keys, including so-called semi-weak keys and possibly-weak keys [Schneier95, pp 280-282]. The likelihood of picking one at random is negligible. For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the use of multiple keys. However, if the first two or last two independent 64-bit keys are equal (k1 =3D=3D k2 or k2 =3D=3D k3), then the 3DES operation is = simply the same as DES. Implementers MUST reject keys that exhibit this property. R. Pereira, R. Adams [Page 5] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 2.4 Block Size and Padding All of the algorithms described in this document use a block size of eight octets (64 bits). Padding is used to align the payload type and pad length octets as specified in [Kent98]. Padding must be sufficient to align the data to be encrypted to an eight octet (64 bit) boundary. 2.5 Rounds This variable determines how many times a block is encrypted. While this variable MAY be negotiated, a default value MUST always exist when it is not negotiated. = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ | Algorithm | Negotiable | Default Rounds | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ | CAST-128 | No | key<=3D80 bits, 12 | | | | key>80 bits, 16 | +--------------------+------------+----------------------+ | RC5 | No | 16 | +--------------------+------------+----------------------+ | IDEA | No | 8 | +--------------------+------------+----------------------+ | Blowfish | No | 16 | +--------------------+------------+----------------------+ | 3DES | No | 48 (16x3) | +--------------------+------------+----------------------+ 2.6 Backgrounds CAST-128: The CAST design procedure was originally developed by Carlisle Adams and Stafford Tavares at Queen's University, Kingston, Ontario, Canada. Subsequent enhancements have been made over the years by Carlisle Adams and Michael Wiener of Entrust Technologies. CAST-128 is the result of applying the CAST Design Procedure as outlined in [Adams97]. R. Pereira, R. Adams [Page 6] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 RC5: The RC5 encryption algorithm was developed by Ron Rivest for RSA Data Security Inc. in order to address the need for a high- performance software and hardware ciphering alternative to DES. It is patented (pat.no. 5,724,428). A description of RC5 may be found in [MOV] and [Schneier]. IDEA: Xuejia Lai and James Massey developed the IDEA (International Data Encryption Algorithm) algorithm. The algorithm is described in detail in [Lai], [Schneier] and [MOV]. The IDEA algorithm is patented in Europe and in the United States with patent application pending in Japan. Licenses are required for commercial uses of IDEA. For patent and licensing information, contact: Ascom Systec AG, Dept. CMVV Gewerbepark, CH-5506 Magenwil, Switzerland Phone: +41 64 56 59 83 Fax: +41 64 56 59 90 idea@ascom.ch http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html Blowfish: Bruce Schneier of Counterpane Systems developed the Blowfish block cipher algorithm. The algorithm is described in detail in [Schneier93], [Schneier95] and [Schneier]. 3DES: This DES variant, colloquially known as "Triple DES" or as DES- EDE3, processes each block three times, each time with a different key. This technique of using more than one DES operation was proposed in [Tuchman79]. R. Pereira, R. Adams [Page 7] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 P1 P2 Pi | | | IV->->(X) +>->->->(X) +>->->->(X) v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k1->| E | ^ k1->| E | ^ k1->| E | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k2->| D | ^ k2->| D | ^ k2->| D | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | v ^ v ^ v +-----+ ^ +-----+ ^ +-----+ k3->| E | ^ k3->| E | ^ k3->| E | +-----+ ^ +-----+ ^ +-----+ | ^ | ^ | +>->->+ +>->->+ +>->-> | | | C1 C2 Ci The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algorithm [FIPS-46]. The "outer" chaining technique is used. In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 byte) plaintext block (P1). The keyed DES function is iterated three times, an encryption (Ek1) followed by a decryption (Dk2) followed by an encryption (Ek3), and generates the ciphertext (C1) for the block. Each iteration uses an independent key: k1, k2 and k3. For successive blocks, the previous ciphertext block is XOR'd with the current plaintext (Pi). The keyed DES-EDE3 encryption function generates the ciphertext (Ci) for that block. To decrypt, the order of the functions is reversed: decrypt with k3, encrypt with k2, decrypt with k1, and XOR the previous ciphertext block. Note that when all three keys (k1, k2 and k3) are the same, DES- EDE3-CBC is equivalent to DES-CBC. This property allows the DES- EDE3 hardware implementations to operate in DES mode without modification. For more explanation and implementation information for Triple DES, see [Schneier95]. R. Pereira, R. Adams [Page 8] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 2.7 Performance For a comparison table of the estimated speed of any of these and other cipher algorithms, please see [Schneier97] or for an up-to- date performance comparison, please see [Bosseleaers]. 3. ESP Payload The ESP payload is made up of the IV followed by raw cipher-text. Thus the payload field, as defined in [Kent98], is broken down according to the following diagram: +---------------+---------------+---------------+---------------+ | | + Initialization Vector (8 octets) + | | +---------------+---------------+---------------+---------------+ | | ~ Encrypted Payload (variable length) ~ | | +---------------------------------------------------------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 The IV field MUST be same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random. Common practice is to use random data for the first IV and the last block of encrypted data from an encryption process as the IV for the next encryption process. Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit. To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs. 3.1 ESP Environmental Considerations Currently, there are no known issues regarding interactions between these algorithms and other aspects of ESP, such as use of certain authentication schemes. R. Pereira, R. Adams [Page 9] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 3.2 Keying Material The minimum number of bits sent from the key exchange protocol to this ESP algorithm must be greater or equal to the key size. The cipher's encryption and decryption key is taken from the first bits of the keying material, where represents the required key size. 4. Security Considerations Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well. For information on the case for using random values please see [Bell97]. For further security considerations, the reader is encouraged to read the documents that describe the actual cipher algorithms. 5. References [Adams97] C. Adams, "The CAST-128 Encryption Algorithm", RFC2144, 1997. [Atkinson98]S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-04 [Baldwin96] R.W. Baldwin, R. Rivest, "The RC5, RC5-CBC, RC5-CBC- Pad, and RC5-CTS Algorithms", RFC2040, October 1996 [Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}). [Bosselaers]A. Bosselaers, "Performance of Pentium implementations", http://www.esat.kuleuven.ac.be/~bosselae/ [Bradner97] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997 R. Pereira, R. Adams [Page 10] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 [Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, Springer-Verlag, pp. 224-230. [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [Kent98] S. Kent, Atkinson, R., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v2-04 [Lai] X. Lai, "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992. [Madson98] C. Madson, N. Dorswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", draft-ietf-ipsec-ciph- des-expiv-02 [MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. ISBN 0-8493- 8523-7 [Schneier] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471- 12845-7 [Schneier93]B. Schneier, "Description of a New Variable-Length Key, 64-Bit Block Cipher", from "Fast Software Encryption, Cambridge Security Workshop Proceedings", Springer-Verlag, 1994, pp. 191-204. http://www.counterpane.com/bfsverlag.html [Schneier95]B. Schneier, "The Blowfish Encryption Algorithm - One Year Later", Dr. Dobb's Journal, September 1995, http://www.counterpane.com/bfdobsoyl.html [Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a Pentium." February 1997, http://www.counterpane.com/speed.html [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document Roadmap", draft-ietf-ipsec-doc-roadmap-02 [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. R. Pereira, R. Adams [Page 11] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 6. Acknowledgments This document is a merger of most of the ESP cipher algorithm documents. This merger was done to facilitate greater understanding of the commonality of all of the ESP algorithms and to further the development of these algorithm within ESP. The content of this document is based on suggestions originally from Stephen Kent and subsequent discussions from the IPSec mailing list as well as other IPSec drafts. Special thanks to Carlisle Adams and Paul Van Oorschot both of Entrust Technologies who provided input and review of CAST. Thanks to all of the editors of the previous ESP 3DES documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn. Thanks to Brett Howard from TimeStep for his original work of ESP- RC5. Thanks to Markku-Juhani Saarinen, Helger Lipmaa and Bart Preneel for their input on IDEA and other ciphers. 7. Editors' Addresses Roy Pereira TimeStep Corporation +1 (613) 599-3610 x 4808 Rob Adams Cisco Systems Inc. +1 (408) 457-5397 Contributors: Robert W. Baldwin or RSA Data Security, Inc. +1 (415) 595-8782 Greg Carter Entrust Technologies +1 (613) 763-1358 R. Pereira, R. Adams [Page 12] =0C Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98 Rodney Thayer rodney@sabletech.com Sable Technology Corporation +1 (617) 332-7292 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology R. Pereira, R. Adams [Page 13] =0C ------_=_NextPart_000_01BDD851.871AAA00-- From owner-ipsec Fri Sep 4 19:26:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03927 for ipsec-outgoing; Fri, 4 Sep 1998 19:24:09 -0400 (EDT) Message-Id: <199809042239.SAA02569@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 04 Sep 1998 16:41:28 -0700 To: ipsec@tis.com From: Rodney Thayer Subject: names in certificates for IPSec...? Cc: rodney@tillerman.nu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Anyone have ideas on how large a name for an IPSec certificate should be? How many parts (surname, organization, organizational unit, country, etc.) should it have? How big should each entry be allowed to be? I am interested in what IPSec users and implementors want, _not_ what certificate engine vendors are selling. For example, the fact some CA's jam copyright notices, nutritional information, and galactic polar coordinates into these things is not relevant. I was thinking of this: max 16 entries max 256 characters each entry Also, does this work for non-US names? I am not sure how non-US names should be stored in this, and I was present when someone from Japan pointed out we kind of got this wrong in the Open PGP work at the IETF meeting. From owner-ipsec Fri Sep 4 20:13:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA04038 for ipsec-outgoing; Fri, 4 Sep 1998 20:13:08 -0400 (EDT) From: Dan McDonald Message-Id: <199809050030.RAA01945@kebe.eng.sun.com> Subject: Re: names in certificates for IPSec...? To: rodney@tillerman.nu (Rodney Thayer) Date: Fri, 4 Sep 1998 17:30:05 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199809042239.SAA02569@2gn.com> from "Rodney Thayer" at Sep 4, 98 04:41:28 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 > Anyone have ideas on how large a name for an IPSec certificate should be? > How many parts (surname, organization, organizational unit, country, etc.) > should it have? How big should each entry be allowed to be? If you store this information in your kernel, you want them to be relatively small. SAs already take up (relative to other IP data structures) a lot of kernel memory, especially if you do performance tricks that trade space for time. > I am interested in what IPSec users and implementors want, _not_ what > certificate engine vendors are selling. For example, the fact some CA's > jam copyright notices, nutritional information, and galactic polar > coordinates into these things is not relevant. I want as small as possible. I'd _prefer_ something along the lines of a mailbox ID (e.g. danmcd@eng.sun.com), but that's unrealistic, given that you need to know who *ISSUED* the certificate, and probably one or two other really important pieces of data. BTW, I have to ask, is there a character in these entries apart from C's null-terminator that is illegal, and could be used as a separator? PF_KEY implementations may have to slightly change if I have to pass in several null-terminated strings for a single certificate name. > I was thinking of this: > > max 16 entries > max 256 characters each entry Ugggh, that's 4Kbytes. Now granted, given Moore's law, this might not be so bad. But IMHO less is better. > Also, does this work for non-US names? I am not sure how non-US names > should be stored in this, and I was present when someone from Japan pointed > out we kind of got this wrong in the Open PGP work at the IETF meeting. Ooof, that's a good point too. My philosophy is keep things as small as possible. An SA takes up a lot of state as it is. Dan From owner-ipsec Fri Sep 4 20:34:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA04115 for ipsec-outgoing; Fri, 4 Sep 1998 20:34:08 -0400 (EDT) Message-Id: <199809042349.TAA02849@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 04 Sep 1998 17:51:24 -0700 To: Dan McDonald From: Rodney Thayer Subject: Re: names in certificates for IPSec...? Cc: ipsec@tis.com In-Reply-To: <199809050030.RAA01945@kebe.eng.sun.com> References: <199809042239.SAA02569@2gn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for your response. I think you're going to have to handle non-string names since some people speak in terms of "distinguished names" which are not at all character strings. So it sounds like maybe four layers of maybe 64 characters each would be more appropriate. Verisign's Class 1 seems to have this: "Issuer: C=US, O=VeriSign, Inc., OU=Class 1 Public Primary Certification Authority" I suppose that's representative. At 05:30 PM 9/4/98 -0700, you wrote: >> Anyone have ideas on how large a name for an IPSec certificate should be? >> How many parts (surname, organization, organizational unit, country, etc.) >> should it have? How big should each entry be allowed to be? > >If you store this information in your kernel, you want them to be relatively >small. SAs already take up (relative to other IP data structures) a lot of >kernel memory, especially if you do performance tricks that trade space for >time. > >> I am interested in what IPSec users and implementors want, _not_ what >> certificate engine vendors are selling. For example, the fact some CA's >> jam copyright notices, nutritional information, and galactic polar >> coordinates into these things is not relevant. > >I want as small as possible. I'd _prefer_ something along the lines of a >mailbox ID (e.g. danmcd@eng.sun.com), but that's unrealistic, given that you >need to know who *ISSUED* the certificate, and probably one or two other >really important pieces of data. > >BTW, I have to ask, is there a character in these entries apart from C's >null-terminator that is illegal, and could be used as a separator? PF_KEY >implementations may have to slightly change if I have to pass in several >null-terminated strings for a single certificate name. > >> I was thinking of this: >> >> max 16 entries >> max 256 characters each entry > >Ugggh, that's 4Kbytes. Now granted, given Moore's law, this might not be so >bad. But IMHO less is better. > >> Also, does this work for non-US names? I am not sure how non-US names >> should be stored in this, and I was present when someone from Japan pointed >> out we kind of got this wrong in the Open PGP work at the IETF meeting. > >Ooof, that's a good point too. > >My philosophy is keep things as small as possible. An SA takes up a lot of >state as it is. > >Dan > From owner-ipsec Fri Sep 4 21:21:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA04241 for ipsec-outgoing; Fri, 4 Sep 1998 21:21:09 -0400 (EDT) Message-ID: <35F09315.B7D567D1@ire-ma.com> Date: Fri, 04 Sep 1998 21:25:41 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Rodney Thayer CC: Dan McDonald , ipsec@tis.com Subject: Re: names in certificates for IPSec...? References: <199809042239.SAA02569@2gn.com> <199809042349.TAA02849@2gn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk The longest string in the CA cert I've seen so far is the CRL Distribution point in the Microsoft CA Certificate, which is a very long URL Slava Rodney Thayer wrote: > Thanks for your response. I think you're going to have to handle non-string names since some people speak in terms of "distinguished names" which are not at all character strings. > > So it sounds like maybe four layers of maybe 64 characters each would be more appropriate. Verisign's Class 1 seems to have this: > > "Issuer: C=US, O=VeriSign, Inc., OU=Class 1 Public Primary Certification Authority" > > I suppose that's representative. > > At 05:30 PM 9/4/98 -0700, you wrote: > >> Anyone have ideas on how large a name for an IPSec certificate should be? > >> How many parts (surname, organization, organizational unit, country, etc.) > >> should it have? How big should each entry be allowed to be? > > > >If you store this information in your kernel, you want them to be relatively > >small. SAs already take up (relative to other IP data structures) a lot of > >kernel memory, especially if you do performance tricks that trade space for > >time. > > > >> I am interested in what IPSec users and implementors want, _not_ what > >> certificate engine vendors are selling. For example, the fact some CA's > >> jam copyright notices, nutritional information, and galactic polar > >> coordinates into these things is not relevant. > > > >I want as small as possible. I'd _prefer_ something along the lines of a > >mailbox ID (e.g. danmcd@eng.sun.com), but that's unrealistic, given that you > >need to know who *ISSUED* the certificate, and probably one or two other > >really important pieces of data. > > > >BTW, I have to ask, is there a character in these entries apart from C's > >null-terminator that is illegal, and could be used as a separator? PF_KEY > >implementations may have to slightly change if I have to pass in several > >null-terminated strings for a single certificate name. > > > >> I was thinking of this: > >> > >> max 16 entries > >> max 256 characters each entry > > > >Ugggh, that's 4Kbytes. Now granted, given Moore's law, this might not be so > >bad. But IMHO less is better. > > > >> Also, does this work for non-US names? I am not sure how non-US names > >> should be stored in this, and I was present when someone from Japan pointed > >> out we kind of got this wrong in the Open PGP work at the IETF meeting. > > > >Ooof, that's a good point too. > > > >My philosophy is keep things as small as possible. An SA takes up a lot of > >state as it is. > > > >Dan > > From owner-ipsec Sun Sep 6 19:17:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07825 for ipsec-outgoing; Sun, 6 Sep 1998 19:09:19 -0400 (EDT) Date: Mon, 7 Sep 1998 02:26:09 +0300 (EET DST) Message-Id: <199809062326.CAA29797@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Scott G. Kelly" Cc: ipsec@tis.com Subject: IKE problem? In-Reply-To: <35EB10D7.7AA8E07D@redcreek.com> References: <35EB10D7.7AA8E07D@redcreek.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly writes: > At last week's IETF meeting(s) there were several references to "Tero's > IKE problem", but I never heard the specifics on this. Can anyone fill > me in on this? Here is the mail I sent to some people just after the Los Angeles IETF meeting. ---------------------------------------------------------------------- From: Tero Kivinen To: dharkins@cisco.com, carrel@ipsec.org, ddp@network-alchemy.com, cmadson@cisco.com, rgm@icsa.net, tytso@MIT.EDU, rodney@sabletech.com CC: wdm@tycho.ncsc.mil, mss@tycho.ncsc.mil, mjs@terisa.com, jeff.turner@raba.com, ylo@ssh.fi (Tatu Ylonen), tmo@ssh.fi (Tero Mononen), mcr@ssh.fi, Subject: Some (not so serious) security problems in the IKE auth HASH. Organization: SSH Communications Security Oy In the Los Angeles IETF I noticed some small problems with the authentication hash used in the IKE protocol. I don't think these problems are serious enough to change the actual draft, but I just want to inform you about these, so if we are going to change something in the IKE we may want also to fix these problems (all of these attacks require active attack in the wire). Currently the authentication hash is calculated like this: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) The problem is that this authentication doesn't cover all of the information in the packets. Things that might have relevance and that are left out of the hash are: 1) ISAKMP major version number 2) ISAKMP minor version number 3) Flags (Commit bit) 4) Selected SA lifetimes 5) Certificate payloads 6) Certificate requests payloads 7) Vendor id payloads 8) Notification payloads (initial contact) 1, 2) ISAKMP major and minor version number I think very serious issue is the missing major and minor version numbers. This means that after we have newer version of IKE the attacker can change the initiators version numbers to 1.0 and force responder to use that older version of IKE. This might have security problems later depending why the 1.1 or 2.0 version of IKE was needed. 3) Flags (Commit bit) The flags field has commit bit flag and using that attacker can cause yet another kind of denial of service attack. In this attack the attacker will modify the host A packets to host B and set commit bit in those. After the negotiation has finished the host B will wait the CONNECTED notification from host A before it can send any packets to host A. Because the host A has't not actuallyrequested that it will not send it, thus the host B will timeout after some time and abort the negotiation. If the host B happens to be initiator it cannot start the quick mode before it receives the CONNECTED notification so the suggestion in the draft how to find out if the last message was lost doesn't apply. The thing that makes this different from other DoS-attacks is that the host A thinks it has valid ISAKMP SA, but the host B doesn't think so. This way the host A's ISAKMP SA table gets full of SA's that are not valid in the other end. 4) Selected SA lifetimes The selected SA sent by the responder is not authenticated in any other way that it must match the one send by initiator and also some parts of it is implictly checked when the ISAKMP SA is using the values of it (encryption and hash algorithms etc). For example the life times are not implictly checked in the process. So if the initiator sends out proposals: 1) DES, MD5, pre-shared, group 1, life seconds = 3600 2) DES, MD5, pre-shared, group 1, life seconds = 600 and the responder selects the first proposal, the attacker can change that to second by just modifying the SA payload sent by the responder. This will not be detected because different values of life time doesn't cause any failures in the negotiation process. If we later add some more isakmp attributes that are not implicitly checked they can also be modified as long as the initiator sends proposal that has different values for the given attribute. 5, 6) Certificate and Certificate requests payloads I don't think this is really a problem because validity of certificate is always checked before they are used, and certificate requests are just requests, if the other end cannot provide certificate for some ca then it cannot. 7) Vendor id payloads So the attacker can force the other end (A)to use some extensions that the other end (B) didn't requested, and if those extensions or backward compatibility stuff causes some security problems the attacker might succeeded doing something nasty. This requires that vendor has some old compatibility code for some broken implementation (of their own?) that has security problems in the protocol... I don't think this is an real issue. 8) Notification payloads (initial contact) This I think is the most serious of all the issues, because it makes the initial contact notify almost useless, as we cannot trust it in phase I at all if we are using aggressive mode (anyone can add any notify payload it pleases to aggressive mode exchanges, because they are not encrypted nor authenticated). Attacker can also modify the contents of notify payloads in the last packet of the main mode exchange even if it is encrypted, because it just has to know the location of notification payload and it can for example change its contents to invalid. Summary I was talking about this in the IETF with Cheryl, and I think that if we want to fix these, the easiest fix would be to change those HASHes to be the hash of all the packets received/sent so far (including all generic payload headers, message header etc), and the current packet. The contents of packets are taken in their plain unencrypted form (just before encryption or just after decryption (if we are using public key encryption then we are still hashing the rsa encrypted forms of payloads)) and in the order they are sent/received (the order of the packets in the wire). When calculating the hash of last packet the SIG/HASH payload is filled with zeros. I think we cannot change anything at this late point, but if we ever are going to revise the IKE draft we might want to fix some of these problems. We might also want to add something about these to the security considerations section in the draft(s). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Mon Sep 7 08:00:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA09668 for ipsec-outgoing; Mon, 7 Sep 1998 07:55:18 -0400 (EDT) Date: Mon, 7 Sep 1998 15:11:51 +0300 (EET DST) From: Markku Savela Message-Id: <199809071211.PAA09460@anise.tte.vtt.fi> To: ipsec@tis.com Subject: Digest length truncation, "algorithm differentiator"? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm trying to write IPSEC implementation which uses separately loadable cryptographic and authentication libraries. For this use, the IPSEC code itself doesn't care what the algorithm numbers in SA mean. Now I have run into minor uncertainty with the digest lengths of the authentication algorithms. Both hmac-md5-96 and hmac-sha1-96 documents specify truncation of the digest output into 96 bits. Is my interpretation correct: If for some weird reason someone wanted to use more bits of those digests, one would have to define a new algorithm number for the SA to use? (e.g. the current PFKEY numbers MD5HMAC=2 and SHA1HMAC=3 refer explicitly to the trunctated digests and the truncation amount is "algorithm differentiator" in PFKEY terms?) None of the PFKEY messages appear to have a parameter for the digest length. (I guess I just need to extend the configuration which now just maps the numbers to algorithms from loadable libraries, to include a digest length to be used?) In supported algorithms, there is this 'sadb_alg_ivlen'. What is its value with authentication algorithms? Digest length? If so, should it be the truncated 96 or the real 160 (sha1) or 128 (md5)? regards, -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Tue Sep 8 12:54:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14162 for ipsec-outgoing; Tue, 8 Sep 1998 12:41:29 -0400 (EDT) Message-ID: <35F56230.2ADB545A@verisign.com> Date: Tue, 08 Sep 1998 09:58:24 -0700 From: Alex Deacon Organization: VeriSign, Inc. X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Rodney Thayer CC: ipsec@tis.com Subject: Re: names in certificates for IPSec...? References: <199809042239.SAA02569@2gn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Remember that most DN attributes have an upperbound values defined. The ones you mentioned have upperbounds defined in Annex C of the X.520 document. Alex Annex C Upper bounds (This annex does not form an integral part of this Recommendation | International Standard) This annex includes all of the suggested upper bound value constraints used in these Directory Specifications, in the form of the ASN.1 module UpperBounds. UpperBounds {joint-iso-ccitt ds(5) module(1) upperBounds(10) 2} DEFINITIONS ::= BEGIN -- EXPORTS All -- -- The types and values defined in this module are exported for use in the other ASN.1 modules contained -- within the Directory Specifications, and for the use of other applications which will use them to access -- Directory services. Other applications may use them for their own purposes, but this will not constrain -- extensions and modifications needed to maintain or improve the Directory service. ub-answerback INTEGER ::= 8 ub-business-category INTEGER ::= 128 ub-common-name INTEGER ::= 64 ub-country-code INTEGER ::= 4 ub-description INTEGER ::= 1024 ub-destination-indicator INTEGER ::= 128 ub-directory-string-first-component-match INTEGER ::= 32768 ub-international-isdn-number INTEGER ::= 16 ub-knowledge-information INTEGER ::= 32768 ub-locality-name INTEGER ::= 128 ub-match INTEGER ::= 128 ub-name INTEGER ::= 32768 ub-organization-name INTEGER ::= 64 ub-organizational-unit-name INTEGER ::= 64 ub-physical-office-name INTEGER ::= 128 ub-post-office-box INTEGER ::= 40 ub-postal-code INTEGER ::= 40 ub-postal-line INTEGER ::= 6 ub-postal-string INTEGER ::= 30 ub-schema INTEGER ::= 1024 ub-serial-number INTEGER ::= 64 ub-state-name INTEGER ::= 128 ub-street-address INTEGER ::= 128 ub-surname INTEGER ::= 64 ub-tag INTEGER ::= 64 ub-telephone-number INTEGER ::= 32 ub-teletex-terminal-id INTEGER ::= 1024 ub-telex-number INTEGER ::= 14 ub-title INTEGER ::= 64 ub-user-password INTEGER ::= 128 ub-x121-address INTEGER ::= 15 END Rodney Thayer wrote: > > Anyone have ideas on how large a name for an IPSec certificate should be? How many parts (surname, organization, organizational unit, country, etc.) should it have? How big should each entry be allowed to be? > > I am interested in what IPSec users and implementors want, _not_ what certificate engine vendors are selling. For example, the fact some CA's jam copyright notices, nutritional information, and galactic polar coordinates into these things is not relevant. > > I was thinking of this: > > max 16 entries > max 256 characters each entry > > Also, does this work for non-US names? I am not sure how non-US names should be stored in this, and I was present when someone from Japan pointed out we kind of got this wrong in the Open PGP work at the IETF meeting. From owner-ipsec Tue Sep 8 13:13:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14256 for ipsec-outgoing; Tue, 8 Sep 1998 13:06:29 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809081724.KAA06755@kc.livingston.com> Subject: IPsec errata To: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Tue, 8 Sep 1998 10:24:31 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <3.0.5.32.19980825002428.009f0280@homebase.htt-consult.com> from "Robert Moskowitz" at Aug 25, 98 00:24:28 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, During the IPsec meeting in Chicago, you asked me to collect errata in the soon-to-be IPsec RFCs (principally, IKE and IPDOI). I assume, you are looking for an internet draft that addresses errors, omissions and clarifications in these drafts. Please confirm. What are the time constraints? Also, please confirm if this is the right forum to discuss these issues. Thanks. Have a nice day. Regards, suresh From owner-ipsec Tue Sep 8 13:27:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14335 for ipsec-outgoing; Tue, 8 Sep 1998 13:20:30 -0400 (EDT) Message-ID: <35F56A73.E0376BE8@cale.checkpoint.com> Date: Tue, 08 Sep 1998 19:33:39 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer , ipsec@tis.com Subject: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk draft-ietf-ipsec-pki-req-01.txt policy about alternate names is: > 4.1.2 subjectAltName Name Format > > For IPSec devices the actual name of the subject is stored in the > subjectAltName field. This field MUST contain exactly one of > these values: > > - ipAddress > - dNSName > - rFC822Name And in section (3.3) > The subjectAltName field must be checked for validity. For > ipAddress, the address MUST be checked to confirm it is valid for > the IKE negotiation in progress. For dNSName the name must be > retrived from the DNS to validate it is valid for the IP address > which was the source of the certificate, if known, and for the > IKE negotiation in progress. For rFC822Name, the email address > must be checked according to the style of SMTP to ensure email > name validity. So the policy is that IPSEC devices must select ONE ID that must recognized by all the other devices that want to communicate with it. This may be problematic if the devices is known by different identities to different peers. IPSEC devices are usually gateways and have more than one IP addresses, forcing them to have only one ipAddress every one to know them by that particular IP address. Specifying thing that must not be in a certificate may prevent the certificate to be used for other protocols. I.e. if one application requires the certificate to contain IP address and another require DNS name, the device will have to have at least two certificates. Another situation may be when the IPSEC device is behind a NAT device, it can put his translated address in the certificate, but then it would not be able to use this certificate to communicate with local application (IPSEC or others) that know him only by his local address. I suggest an alternative approach where the IPSEC device will put his certificate everything that might help some one to identify it, and let the peers look there for something that identifies it for them, ignoring all the other information. What I suggest is: Certificate contents: For IPSec devices the actual name of the subject is stored in the subjectAltName field. This field SHOULD contain all the names that the device is know by other IPSEC devices. At least one of the following names forms SHOULD be included: - ipAddress - dNSName - rFC822Name Certificate validation: The device MUST check that the certificate belongs to the peer in the IKE negotiations. It SHOULD do it by testing the subject name, or the alternate name forms: ipAddress, dNSName, rFC822Name or some combination of them. The ipsec device MUST handle cases where there are multiply alternate formats, or multiply values for the same formats. It SHOULD ignore any name that it does not recognize. regards, Moshe -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Tue Sep 8 14:12:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14670 for ipsec-outgoing; Tue, 8 Sep 1998 14:06:37 -0400 (EDT) Message-Id: <199809081823.OAA24516@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names In-reply-to: Your message of "Tue, 08 Sep 1998 19:33:39 +0200." <35F56A73.E0376BE8@cale.checkpoint.com> Date: Tue, 08 Sep 1998 14:23:16 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Moshe" == Moshe Litvin writes: Moshe> So the policy is that IPSEC devices must select ONE ID that must Moshe> recognized by all the other devices that want to communicate with Moshe> it. This may be problematic if the devices is known by different Moshe> identities to different peers. IPSEC devices are usually gateways Moshe> and have more than one IP addresses, forcing them to have only one Moshe> ipAddress every one to know them by that particular IP address. The case of the gateway with multiple IP addresses is a redherring: gateways should be abiding by the router requirements RFC, which means that the should have a well known router-id (i.e. one of their IP addresses). The problem still exists: some devices may prefer to be known by IP address for some peers and by DNS name for other peers (or the same peer at different times) [i.e. when my notebook is on the road, its uses a DNS or DN name, while when it is in my home office with a static IP, and some physical security, it is known by its IP address and gets some additional priviledge] Moshe> Specifying thing that must not be in a certificate may prevent the Moshe> certificate to be used for other protocols. I.e. if one Moshe> application requires the certificate to contain IP address and Moshe> another require DNS name, the device will have to have at least Moshe> two certificates. I'm not sure that we should prevent certificates from being used for multiple purposes, but I'm not sure that we should encourage it either. Moshe> Certificate contents: For IPSec devices the actual name of the Moshe> subject is stored in the subjectAltName field. This field SHOULD Moshe> contain all the names that the device is know by other IPSEC Moshe> devices. At least one of the following names forms SHOULD be Moshe> included: - ipAddress - dNSName - rFC822Name I would change the second SHOULD to MUST. (i.e. at least one MUST be included) Moshe> Certificate validation: The device MUST check that the certificate Moshe> belongs to the peer in the IKE negotiations. It SHOULD do it by Moshe> testing the subject name, or the alternate name forms: ipAddress, Moshe> dNSName, rFC822Name or some combination of them. The ipsec device Moshe> MUST handle cases where there are multiply alternate formats, or Moshe> multiply values for the same formats. It SHOULD ignore any name Moshe> that it does not recognize. We still get into the question of whether the CA is authorized to verify all of these things with a single signature. For the matter, it seems clear to me that these are all totally useless unless signed by a CA key directly under the control of the person administrating the gateway. But, perhaps we shouldn't try to solve that problem, just to document it. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNfV2B9iXVu0RiA21AQHcDAMAugpRDVCp+EIuZfGez5nosFoTQSVeJbAO H972XoagMvfh7uxq3tx2iO35B+ya6GpAwniea9bkWpw41jIW5ZCja40g+PWL+KY0 aFHrJ7HqWH00DRrHpMob+/DgjcpdBz46 =tk31 -----END PGP SIGNATURE----- From owner-ipsec Tue Sep 8 16:34:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15343 for ipsec-outgoing; Tue, 8 Sep 1998 16:27:49 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199809071211.PAA09460@anise.tte.vtt.fi> Date: Tue, 8 Sep 1998 16:38:32 -0400 To: msa@hemuli.tte.vtt.fi (Markku Savela) From: Stephen Kent Subject: Re: Digest length truncation, "algorithm differentiator"? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Markku, >Is my interpretation correct: > > If for some weird reason someone wanted to use more bits of > those digests, one would have to define a new algorithm number > for the SA to use? (e.g. the current PFKEY numbers MD5HMAC=2 > and SHA1HMAC=3 refer explicitly to the trunctated digests > and the truncation amount is "algorithm differentiator" in > PFKEY terms?) Yes, if one wanted to use more bits from the hash functions, a new algorithm ID would have to be defined. Steve From owner-ipsec Wed Sep 9 02:41:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA16979 for ipsec-outgoing; Wed, 9 Sep 1998 02:37:09 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: Daniel Harkins , astur@a01-unix.gsyc.inf.uc3m.es Date: Wed, 9 Sep 1998 08:30:50 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ISAKMP/Oakley under Linux Reply-to: kai@imib.med.tu-dresden.de CC: ipsec@tis.com In-reply-to: <199809081815.LAA05462@dharkins-ss20.cisco.com> References: Your message of "Tue, 08 Sep 1998 09:13:03 PDT." <199809081613.JAA02637@domohead.cisco.com> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <9CFB7013213@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, > which only runs on BSD4.4 systems. Linux is not BSD4.4. There is a > freeware version of IPSec and IKE for Linux though. Send some email to > ipsec@tis.com and ask if anyone knows where to get the code. I think > it's somewhere in Finland, but I don't know exactly where. Perhaps > someone on this list knows. > > Dan. > > On Tue, 08 Sep 1998 09:13:03 PDT you wrote > > > > Hello I'm informatic student from Spain and I would like to know if is > > posible mount ISAKMP/Oakley under Linux operating system and how to do it. > > > > I'd be grateful if you would answer me. > > > > my e-mail is: > > > > astur@a01-unix.gsyc.inf.uc3m.es. Linux-IPSec and -IKE is developed under the FreeS/WAN project. It's IKE daemon is named "pluto". The Website is www.xs4all.nl/~freeswan And there's also a Mailinglist: linux-ipsec@clinet.fi Regards Kai PS: Is there another freely (i.e. worldwide) available IKE implementation than this and SSH's (commercial) one? # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Wed Sep 9 10:31:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18868 for ipsec-outgoing; Wed, 9 Sep 1998 10:29:10 -0400 (EDT) Message-Id: <199809091446.KAA02304@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Date: Wed, 09 Sep 1998 10:46:03 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP CBC-Mode Cipher Algorithms Author(s) : R. Pereira, R. Adams Filename : draft-ietf-ipsec-ciph-cbc-03.txt Pages : 13 Date : 08-Sep-98 This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-cbc-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-cbc-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980908155816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-cbc-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980908155816.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Sep 9 12:22:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19270 for ipsec-outgoing; Wed, 9 Sep 1998 12:17:17 -0400 (EDT) Message-Id: <199809091531.LAA28720@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 09 Sep 1998 12:29:29 -0400 To: Alex Deacon From: Rodney Thayer Subject: Re: names in certificates for IPSec...? Cc: ipsec@tis.com In-Reply-To: <35F56230.2ADB545A@verisign.com> References: <199809042239.SAA02569@2gn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I just discovered that these numbers are also defined in draft-ietf-pkix-ipki-part1-10.txt, as well as OID's for them. So I'll change the text to say "128 or the documented max, see pkix part 1", which seems to be the net of what I want to add to the subject. I've submitted my draft through channels so it should pop out the other end "in 5 days", if the procedure works as documented. I'm working on the next round and trying to address comments from the list as I go along. At 09:58 AM 9/8/98 -0700, you wrote: >Remember that most DN attributes have an upperbound values defined. The >ones you mentioned have upperbounds defined in Annex C of the X.520 >document. > >Alex > >Annex C > >Upper bounds >(This annex does not form an integral part of this Recommendation | >International Standard) >This annex includes all of the suggested upper bound value constraints >used in these Directory Specifications, in the form of the ASN.1 module >UpperBounds. > > >UpperBounds {joint-iso-ccitt ds(5) module(1) upperBounds(10) 2} >DEFINITIONS ::= >BEGIN >-- EXPORTS All -- >-- The types and values defined in this module are exported for use in >the other ASN.1 modules contained >-- within the Directory Specifications, and for the use of other >applications which will use them to access >-- Directory services. Other applications may use them for their own >purposes, but this will not constrain >-- extensions and modifications needed to maintain or improve the >Directory service. > >ub-answerback INTEGER ::= 8 >ub-business-category INTEGER ::= 128 >ub-common-name INTEGER ::= 64 >ub-country-code INTEGER ::= 4 >ub-description INTEGER ::= 1024 >ub-destination-indicator INTEGER ::= 128 >ub-directory-string-first-component-match INTEGER ::= 32768 >ub-international-isdn-number INTEGER ::= 16 >ub-knowledge-information INTEGER ::= 32768 >ub-locality-name INTEGER ::= 128 >ub-match INTEGER ::= 128 >ub-name INTEGER ::= 32768 >ub-organization-name INTEGER ::= 64 >ub-organizational-unit-name INTEGER ::= 64 >ub-physical-office-name INTEGER ::= 128 >ub-post-office-box INTEGER ::= 40 >ub-postal-code INTEGER ::= 40 >ub-postal-line INTEGER ::= 6 >ub-postal-string INTEGER ::= 30 >ub-schema INTEGER ::= 1024 >ub-serial-number INTEGER ::= 64 >ub-state-name INTEGER ::= 128 >ub-street-address INTEGER ::= 128 >ub-surname INTEGER ::= 64 >ub-tag INTEGER ::= 64 >ub-telephone-number INTEGER ::= 32 >ub-teletex-terminal-id INTEGER ::= 1024 >ub-telex-number INTEGER ::= 14 >ub-title INTEGER ::= 64 >ub-user-password INTEGER ::= 128 >ub-x121-address INTEGER ::= 15 >END > >Rodney Thayer wrote: >> >> Anyone have ideas on how large a name for an IPSec certificate should be? How many parts (surname, organization, organizational unit, country, etc.) should it have? How big should each entry be allowed to be? >> >> I am interested in what IPSec users and implementors want, _not_ what certificate engine vendors are selling. For example, the fact some CA's jam copyright notices, nutritional information, and galactic polar coordinates into these things is not relevant. >> >> I was thinking of this: >> >> max 16 entries >> max 256 characters each entry >> >> Also, does this work for non-US names? I am not sure how non-US names should be stored in this, and I was present when someone from Japan pointed out we kind of got this wrong in the Open PGP work at the IETF meeting. > From owner-ipsec Wed Sep 9 15:34:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20093 for ipsec-outgoing; Wed, 9 Sep 1998 15:26:27 -0400 (EDT) Date: Wed, 9 Sep 1998 15:43:33 -0400 Message-Id: <199809091943.PAA24021@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Slides, notes solicited... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Folks, I am currently preparing the minutes for the Chicago IPSEC meeting. To that end, if any presentors who haven't yet sent me postscript or (if you must) Powerpoint files of their slides, I would greatly appreciate it. Also, if any folks have any notes which they took during the meeting that they think might help supplement the minutes, please also send them my way. They would be greatly appreciated. Thanks!! - Ted From owner-ipsec Wed Sep 9 17:28:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20483 for ipsec-outgoing; Wed, 9 Sep 1998 17:25:30 -0400 (EDT) Date: Wed, 9 Sep 1998 17:42:52 -0400 Message-Id: <199809092142.RAA24155@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: jis@MIT.EDU Cc: ipsec@tis.com Subject: draft-ietf-ipsec-cipb-cbc-03.txt to last call Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Jeff, Could you please submit draft-ietf-ipsec-cipb-cbc-03.txt for IETF Last Call and advancement for publication as a Proposed Standard? This document is part of the IPSEC standards suite which was approved by the IESG, and was left out as an oversight, as the other IPSEC documents make normative references to this document. Many thanks! - Ted > From: Internet-Drafts@ietf.org > Date: Wed, 09 Sep 1998 10:46:03 -0400 > > Note: This revision reflects comments received during the last call period. > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Protocol Working Group of the IETF. > > Title : The ESP CBC-Mode Cipher Algorithms > Author(s) : R. Pereira, R. Adams > Filename : draft-ietf-ipsec-ciph-cbc-03.txt > Pages : 13 > Date : 08-Sep-98 > > This document describes how to use CBC-mode cipher algorithms with > the IPSec ESP (Encapsulating Security Payload) Protocol. It not > only clearly states how to use certain cipher algorithms, but also > how to use all CBC-mode cipher algorithms. > From owner-ipsec Wed Sep 9 17:49:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20549 for ipsec-outgoing; Wed, 9 Sep 1998 17:49:29 -0400 (EDT) Message-Id: <199809092103.RAA30020@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 09 Sep 1998 18:04:35 -0400 To: "William Allen Simpson" From: Rodney Thayer Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Cc: ietf@ietf.org, ipsec@tis.com In-Reply-To: <7538.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'll check again myself, but where do you think it violates the roadmap? Presumably proper etiquette is to switch this conversation to the IPSec mailing list. At 07:11 PM 9/9/98 +0000, you wrote: >I was horrified to see this posting today, and this message is a formal >protest against this document being advanced: > >> From: Internet-Drafts@ietf.org >> Date: Wed, 09 Sep 1998 10:46:03 -0400 >> >> --NextPart >> >> Note: This revision reflects comments received during the last call period. >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IP Security Protocol Working Group of the IETF. >> >> Title : The ESP CBC-Mode Cipher Algorithms >> Author(s) : R. Pereira, R. Adams >> Filename : draft-ietf-ipsec-ciph-cbc-03.txt >> Pages : 13 >> Date : 08-Sep-98 >> >> This document describes how to use CBC-mode cipher algorithms with >> the IPSec ESP (Encapsulating Security Payload) Protocol. It not >> only clearly states how to use certain cipher algorithms, but also >> how to use all CBC-mode cipher algorithms. >> >Gentlefolk, it cannot "reflect comments", as this document has not been >through any "last call". Even the WG chose not to advance it during the >internal last call. It was deliberately _omitted_ from the IESG IPSec >last call. > >If it _had_ been included, then formal appeals processes would have >prevented publication of any and all documents that reference it, for a >_VERY_ long time! > >(1) If there is a need for a "normative" CBC mode description, this is > already available as draft-simpson-cbc-01.txt, which has long been > awaiting publication as Informational (no last call is needed). > >(2) Including multiple ciphers in the document makes it difficult or > impossible to advance. We have often had this problem with "kitchen > sink" options documents in other WGs. > >(3) Several of the ciphers are proprietary, and are not likely to be > universally implemented, again making it impossible to advance. > >(4) The document does not meet the WG doc-roadmap requirements, which > have been through last call. > >(5) Some of the ciphers are "standardized" for 40 bits. The formal > position of the IETF, after considerable debate, and acclaimation at > an open IESG plenary, has been that this is unacceptable! > >(6) This document is derivative from my own text without sufficient > attribution. Figures and quotations are plagiarized, from > draft-simpson-cbc-01.txt and draft-simpson-des3v2-03.txt (or earlier > versions thereof). > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > From owner-ipsec Wed Sep 9 18:09:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20581 for ipsec-outgoing; Wed, 9 Sep 1998 18:09:28 -0400 (EDT) Message-Id: <199809092123.RAA30098@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 09 Sep 1998 18:25:05 -0400 To: Moshe Litvin From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com In-Reply-To: <35F56A73.E0376BE8@cale.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:33 PM 9/8/98 +0200, you wrote: >draft-ietf-ipsec-pki-req-01.txt policy about alternate names is: > >> 4.1.2 subjectAltName Name Format >> >> For IPSec devices the actual name of the subject is stored in the >> subjectAltName field. This field MUST contain exactly one of >> these values: >> >> - ipAddress >> - dNSName >> - rFC822Name > >And in section (3.3) > >> The subjectAltName field must be checked for validity. For >> ipAddress, the address MUST be checked to confirm it is valid for >> the IKE negotiation in progress. For dNSName the name must be >> retrived from the DNS to validate it is valid for the IP address >> which was the source of the certificate, if known, and for the >> IKE negotiation in progress. For rFC822Name, the email address >> must be checked according to the style of SMTP to ensure email >> name validity. > >So the policy is that IPSEC devices must select ONE ID that must >recognized by all the other devices that want to communicate with it. >This may be problematic if the devices is known by different identities >to different peers. IPSEC devices are usually gateways and have more >than one IP addresses, forcing them to have only one ipAddress every one >to know them by that particular IP address. Suppose you have a multi-homed firewall device, with if1, if2 and if3. I believe that you'd possibly have several certificates, and you'd use the appropriate certificate to talk in different situations. So, for example, you might have three certs issued, one for each interface. > >Specifying thing that must not be in a certificate may prevent the >certificate to be used for other protocols. I.e. if one application >requires the certificate to contain IP address and another require DNS >name, the device will have to have at least two certificates. That's right. Life is complicated, IPSec life is more complicated, let's keep the certs simple. If you are known as 10.0.0.1 to some people and xxx.yyy.com to others, your life is already complicated. > >Another situation may be when the IPSEC device is behind a NAT device, >it can put his translated address in the certificate, but then it would >not be able to use this certificate to communicate with local >application (IPSEC or others) that know him only by his local address. If you put an IPSec device behind an NAT device then your IP address isn't your identity and you should use something else, like an FQDN. Or, the device on the other end has to somehow be willing to cope with the difference between the identity in the cert and the ip address it's talking to. > >I suggest an alternative approach where the IPSEC device will put his >certificate everything that might help some one to identify it, and let >the peers look there for something that identifies it for them, ignoring >all the other information. What I suggest is: > >Certificate contents: >For IPSec devices the actual name of the subject is stored in the >subjectAltName field. This field SHOULD contain all the names that the >device is know by other IPSEC devices. At least one of the following >names forms SHOULD be included: > - ipAddress > - dNSName > - rFC822Name This makes the cert processing at all levels more complicated... I don't like it. What if my ip address changes? what if the rfc822name changes relative to the host? I think we'd end up with some lowest common denominator where the only safe thing to do is to ignore the identity in the cert, which wasn't the intent. > > >Certificate validation: >The device MUST check that the certificate belongs to the peer in the >IKE negotiations. It SHOULD do it by testing the subject name, or the >alternate name forms: ipAddress, dNSName, rFC822Name or some combination >of them. The ipsec device MUST handle cases where there are multiply >alternate formats, or multiply values for the same formats. It SHOULD >ignore any name that it does not recognize. > >regards, > > Moshe > >-- >----------------------------------------------------------------------- >Moshe Litvin Check Point Software Technologies Ltd. > >moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) > Fax: +972-3-575-9256 >----------------------------------------------------------------------- > From owner-ipsec Wed Sep 9 18:42:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20628 for ipsec-outgoing; Wed, 9 Sep 1998 18:41:30 -0400 (EDT) Date: Wed, 9 Sep 1998 18:58:32 -0400 Message-Id: <199809092258.SAA24165@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "William Allen Simpson" Cc: ietf@ietf.org, ipsec@tis.com Reply-To: ipsec@tis.com In-Reply-To: William Allen Simpson's message of Wed, 9 Sep 98 19:11:01 GMT, <7538.wsimpson@greendragon.com> Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 9 Sep 98 19:11:01 GMT From: "William Allen Simpson" I was horrified to see this posting today, and this message is a formal protest against this document being advanced: > Title : The ESP CBC-Mode Cipher Algorithms > Author(s) : R. Pereira, R. Adams Gentlefolk, it cannot "reflect comments", as this document has not been through any "last call". Even the WG chose not to advance it during the internal last call. It was deliberately _omitted_ from the IESG IPSec last call. It was omitted from the IPSEC last call due to an oversight; which was only caught by the RFC Editor. As the other documents, in particular the DOI document, contain normative references to this document, we need to advance this document before the other IPSEC documents can be advanced. When I was notified of this last week, I consulted with Jeff Schiller and Bob Moskowitz, and we agreed that the most efficient way to deal with this oversight, while staying within the bounds of our standards process, was for me to send out a note explaining this situation to the IPSEC working group. There, we gave notice of our intention to advance this document to IETF Last Call the following week, and if folks had any issues with this, to please comment on the IPSEC list ASAP. (Note that an internal WG last call is not required by our processes before IETF last call, but we did want to give the working group time to make any last-minute comments.) As it turns out, the Roy Pereira, the document editor, had some changes batched up that clarified the document, and that so this was the -03 version of the document was sent to the Secretariat this week, and whose announcement apparently caused you great horror. Today, I formally asked Jeff Schiller to put this document out for the two-week IETF Last Call, which should get sent out tomorrow. ----------------------------------------------- As to your specific issues with the documents, let me address them one by one. Any further discussion on these points would probably be more appropriate on the IPSEC working group list, so I have set the Reply-to: field on this message to ipsec@tis.com. (Any folks who are not on the IPSEC mailing list and who are interested are very much welcome to send mail to ipsec-request@tis.com to get added to the IPSEC mailing list.) (1) If there is a need for a "normative" CBC mode description, this is already available as draft-simpson-cbc-01.txt, which has long been awaiting publication as Informational (no last call is needed). This document is a matched set with the DOI document, and contains details of the default key sizes, weak key checks, etc. needed for the various algorithms specified in the DOI. (The DOI document contains a listing of which algorithms are mandatory and which are optional; this document contains the details of how those algorithms are to be used with ESP.) (2) Including multiple ciphers in the document makes it difficult or impossible to advance. We have often had this problem with "kitchen sink" options documents in other WGs. (3) Several of the ciphers are proprietary, and are not likely to be universally implemented, again making it impossible to advance. Indeed, originally we had separate documents for each of the cipher algorithms. It was the decision of the IPSEC working group that having five or six documents of which 90% of the text was boilerplate, and only a minor portion of the text was specific to an encryption algorithm was hard to manage, and that it would be clearer to consolidate the algorithms into a single document. It is true that if we do not have more than the two required independent interoperable implementations for some of the various algorithms, we will need to drop those algorithms before we advance this document to Draft Standard. It is a relatively common occurance the IETF to drop optional-to-implement portions of a standard, if there aren't the requisite number of interoperable implementations of that part of the standard. Indeed, one could call that valuable implementation experience --- if we find out that part of the standard is not being implemented, that we can take it out when we advance the document. (4) The document does not meet the WG doc-roadmap requirements, which have been through last call. The Document Roadmap does in fact reference the draft-ietf-cipb-cbc document; again, it was originally the intent the IPSEC wg to advance this document. The fact that it was not advanced with the other IPSEC documents was purely an administrative oversight on my part, and I apologize for that. (5) Some of the ciphers are "standardized" for 40 bits. The formal position of the IETF, after considerable debate, and acclaimation at an open IESG plenary, has been that this is unacceptable! In fact, if you read draft-ietf-ipsec-cipg-cbc-03.txt, you will find that the document specifies a default key size of 128 bits for all ciphers except for 3DES, which as a key size of 192 bits. (6) This document is derivative from my own text without sufficient attribution. Figures and quotations are plagiarized, from draft-simpson-cbc-01.txt and draft-simpson-des3v2-03.txt (or earlier versions thereof). To quote from the Acknowledgements section: >This document is a merger of most of the ESP cipher algorithm >documents. This merger was done to facilitate greater >understanding of the commonality of all of the ESP algorithms and >to further the development of these algorithm within ESP. > >.... > >Thanks to all of the editors of the previous ESP 3DES documents; W. >Simpson, N. Doraswamy, P. Metzger, and P. Karn. I'm not sure what you mean by "quotations", since there aren't any quotations in draft-ietf-ciph-cbc-03.txt. Perhaps you mean bibliographic citations, such as where we cite [FIPS-46] and [Tuchman79]? As far as figures are concerned, there is a single figure depicting the DES-EDE3-CBC algorithm on page 8 which appears to have originated from your 3DES document. If the above text in the Acknowledgements section thanking the editors of the previous ESP 3DES documents is not sufficient, please advise me as to what text you would prefer to see in the Acknowledgements section. - Ted From owner-ipsec Wed Sep 9 19:58:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA20845 for ipsec-outgoing; Wed, 9 Sep 1998 19:56:33 -0400 (EDT) Date: Wed, 9 Sep 1998 20:16:48 -0700 (PDT) From: "Hilarie K. Orman" Message-Id: <199809100316.UAA19107@earth.hpc.org> To: dharkins@cisco.com Cc: isakmp-oakley@cisco.com, ipsec@tis.com In-reply-to: Yourmessage <199809081815.LAA05462@dharkins-ss20.cisco.com> Subject: IKE clarifications Sender: owner-ipsec@ex.tis.com Precedence: bulk Catherine Meadows at NRL has noted two points that need to be clarified in order to ensure that secure implementations of IKE are produced. The first is that message ID's must be pseudo-randomly generated; this necessity is mentioned in the ISAKMP document, but could be easily overlooked by an IKE implementor (and has been, more than once, it seems). The second point is to note that the decision about whether a message is a Quick Mode initial message or a reply to a QM init msg must be made on the basis of a pre-existing message ID only, not by using any other attribute of the message. Implementations that omit either of these recommendations are subject to a denial-of-service attack which results in the production of security associations that are not usable for communication with the intended remote party. Hilarie From owner-ipsec Wed Sep 9 23:38:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA21354 for ipsec-outgoing; Wed, 9 Sep 1998 23:35:32 -0400 (EDT) Message-Id: <3.0.5.32.19980909235056.00a1ba60@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Sep 1998 23:50:56 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Information on the IBM IPsec workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The application for attending is at: http://www.ciug.org:8080/IPSEC.html Remember that IBM is footing the cost, as was stated in Chicago. IBM does not get the room for setup until monday morning, so sometime late in the evening they will be finished. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Thu Sep 10 07:41:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22724 for ipsec-outgoing; Thu, 10 Sep 1998 07:37:36 -0400 (EDT) Date: Thu, 10 Sep 1998 14:54:34 +0300 (EET DST) Message-Id: <199809101154.OAA09700@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Rodney Thayer Cc: Moshe Litvin , ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names In-Reply-To: <199809092123.RAA30098@2gn.com> References: <35F56A73.E0376BE8@cale.checkpoint.com> <199809092123.RAA30098@2gn.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 13 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer writes: > >> the IKE negotiation in progress. For dNSName the name must be > >> retrived from the DNS to validate it is valid for the IP address > >> which was the source of the certificate, if known, and for the > >> IKE negotiation in progress. For rFC822Name, the email address > If you put an IPSec device behind an NAT device then your IP address > isn't your identity and you should use something else, like an FQDN. > Or, the device on the other end has to somehow be willing to cope > with the difference between the identity in the cert and the ip > address it's talking to. I think that there MUST not be any binding with the identity and the ip address of the source packet. The packets can come in from any source ip address, the identity payload contains the real identity information that should be used to first find the certificate (there is NO need to do any dns queries etc to map FQDN to ip address, if the identity payload is fqdn then the certificate MUST contain the same dns name in the dNSName). The process should go like this: 1) First find a valid certificate matching the identity payload. This means that if the identity payload contains ip address the certificate must contain same ip address (it may contain other ip address also). If the identity payload contains fqdn then the certificate must contain the same name (the ip address matching the fqdn is not enough unless the dns query was done in the secure way (dns sec or local database)). 2) Find the policy information using the identity payload. This policy information informs if the other end is allowed to connect and what kind of parameters are needed for it. 3) Verify the signature sent by the other end using the public key in the certificate found. > >I suggest an alternative approach where the IPSEC device will put his > >certificate everything that might help some one to identify it, and let > >the peers look there for something that identifies it for them, ignoring > >all the other information. What I suggest is: > > > >Certificate contents: > >For IPSec devices the actual name of the subject is stored in the > >subjectAltName field. This field SHOULD contain all the names that the > >device is know by other IPSEC devices. At least one of the following > >names forms SHOULD be included: > > - ipAddress > > - dNSName > > - rFC822Name > > This makes the cert processing at all levels more complicated... I > don't like it. Sorry you cannot get everything. Certificate processing is complicated thing, but that matching is some of the most easiest thing to do. There is only one key (identity payload) and you know the type of the key (ip, fqdn, user@fqdn, distinguished name). You just find the certificate that matches that. > What if my ip address changes? Then you get a new certificate and revoke the old one. If you plan to change your ip address often, you propably want to use something else like fqdn or user@fqdn instead. > what if the rfc822name changes relative to the host? If the username changes then you propably want to create new certificate anyway. > I think we'd end up with some lowest common denominator where the > only safe thing to do is to ignore the identity in the cert, which > wasn't the intent. No, you must not ignore it you must simply match it against the contents of the identity payload, and that matching must be done securely so no dns queries etc can be involved in that. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Sep 10 07:58:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA22806 for ipsec-outgoing; Thu, 10 Sep 1998 07:55:36 -0400 (EDT) Message-Id: <199809101109.HAA00656@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Sep 1998 08:11:48 -0400 To: Tero Kivinen From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com In-Reply-To: <199809101154.OAA09700@torni.ssh.fi> References: <199809092123.RAA30098@2gn.com> <35F56A73.E0376BE8@cale.checkpoint.com> <199809092123.RAA30098@2gn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk [this draft we keep talking about is going through the ietf draft papermill as we speak... a preliminary version is at ] At 02:54 PM 9/10/98 +0300, you wrote: >Rodney Thayer writes: >> >> the IKE negotiation in progress. For dNSName the name must be >> >> retrived from the DNS to validate it is valid for the IP address >> >> which was the source of the certificate, if known, and for the >> >> IKE negotiation in progress. For rFC822Name, the email address > >I think that there MUST not be any binding with the identity and the >ip address of the source packet. The packets can come in from any >source ip address, the identity payload contains the real identity >information that should be used to first find the certificate (there >is NO need to do any dns queries etc to map FQDN to ip address, if the >identity payload is fqdn then the certificate MUST contain the same >dns name in the dNSName). So a random packet from an illegitimate address identified with a certificate from example.com (a defined-to-be-invalid domain) is fine? > >The process should go like this: > >1) First find a valid certificate matching the identity payload. This >means that if the identity payload contains ip address the certificate >must contain same ip address (it may contain other ip address also). >If the identity payload contains fqdn then the certificate must >contain the same name (the ip address matching the fqdn is not enough >unless the dns query was done in the secure way (dns sec or local >database)). > >2) Find the policy information using the identity payload. This policy >information informs if the other end is allowed to connect and what >kind of parameters are needed for it. > >3) Verify the signature sent by the other end using the public key in >the certificate found. So the actual identity and the sanity of that identity are irrelevant? > >> >I suggest an alternative approach where the IPSEC device will put his >> >certificate everything that might help some one to identify it, and let >> >the peers look there for something that identifies it for them, ignoring >> >all the other information. What I suggest is: >> > >> >Certificate contents: >> >For IPSec devices the actual name of the subject is stored in the >> >subjectAltName field. This field SHOULD contain all the names that the >> >device is know by other IPSEC devices. At least one of the following >> >names forms SHOULD be included: >> > - ipAddress >> > - dNSName >> > - rFC822Name >> >> This makes the cert processing at all levels more complicated... I >> don't like it. > >Sorry you cannot get everything. Certificate processing is complicated >thing, but that matching is some of the most easiest thing to do. >There is only one key (identity payload) and you know the type of the >key (ip, fqdn, user@fqdn, distinguished name). You just find the >certificate that matches that. > >> What if my ip address changes? > >Then you get a new certificate and revoke the old one. If you plan to >change your ip address often, you propably want to use something else >like fqdn or user@fqdn instead. > >> what if the rfc822name changes relative to the host? > >If the username changes then you propably want to create new >certificate anyway. > >> I think we'd end up with some lowest common denominator where the >> only safe thing to do is to ignore the identity in the cert, which >> wasn't the intent. > >No, you must not ignore it you must simply match it against the >contents of the identity payload, and that matching must be done >securely so no dns queries etc can be involved in that. but you're saying ignore the legitimacy of the identities relative to the rest of the world... From owner-ipsec Thu Sep 10 08:42:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23251 for ipsec-outgoing; Thu, 10 Sep 1998 08:40:35 -0400 (EDT) Message-Id: <3.0.5.32.19980910155808.00a383f0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Sep 1998 15:58:08 +0300 To: Rodney Thayer From: Joern Sierwald Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com In-Reply-To: <199809101109.HAA00656@2gn.com> References: <199809101154.OAA09700@torni.ssh.fi> <199809092123.RAA30098@2gn.com> <35F56A73.E0376BE8@cale.checkpoint.com> <199809092123.RAA30098@2gn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id IAA23248 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:11 10/09/98 -0400, you wrote: >So a random packet from an illegitimate address identified with >a certificate from example.com (a defined-to-be-invalid domain) is fine? Do you trust the CA that signed the certificate? Is the certificate still valid? If you answer both questions with "yes", it is fine. >So the actual identity and the sanity of that identity are irrelevant? You don't check the "sanity of that identity". The CA should do. You just check the sanity of the CA. Jörn Sierwald From owner-ipsec Thu Sep 10 08:43:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23276 for ipsec-outgoing; Thu, 10 Sep 1998 08:43:35 -0400 (EDT) Date: Thu, 10 Sep 1998 16:00:37 +0300 (EET DST) Message-Id: <199809101300.QAA11201@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names In-Reply-To: <199809101109.HAA00656@2gn.com> References: <199809092123.RAA30098@2gn.com> <35F56A73.E0376BE8@cale.checkpoint.com> <199809101154.OAA09700@torni.ssh.fi> <199809101109.HAA00656@2gn.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer writes: > [this draft we keep talking about is going through the ietf draft papermill as we speak... a preliminary version is at ] > > At 02:54 PM 9/10/98 +0300, you wrote: > >Rodney Thayer writes: > >> >> the IKE negotiation in progress. For dNSName the name must be > >> >> retrived from the DNS to validate it is valid for the IP address > >> >> which was the source of the certificate, if known, and for the > >> >> IKE negotiation in progress. For rFC822Name, the email address > > > >I think that there MUST not be any binding with the identity and the > >ip address of the source packet. The packets can come in from any > >source ip address, the identity payload contains the real identity > >information that should be used to first find the certificate (there > >is NO need to do any dns queries etc to map FQDN to ip address, if the > >identity payload is fqdn then the certificate MUST contain the same > >dns name in the dNSName). > So a random packet from an illegitimate address identified with a > certificate from example.com (a defined-to-be-invalid domain) is > fine? Yes, provided that the other end also have the private key of that public key in the certificate AND the certificate is signed by the CA I trust AND my policy database have entry that example.com is valid host to connect. > So the actual identity and the sanity of that identity are irrelevant? Identity is just a key to be used when searching certificate and the entries from the policy database. The actual value doesn't matter. If my policy database says that the identity is valid and it should be allowed to connect, the sanity of it is not a issue. How are you going to check sanity of key-id? You just use that key id as a key to your policy database and map it to some policy, and some authentication information. > but you're saying ignore the legitimacy of the identities relative > to the rest of the world... I am saying, that in most cases you should not trust only the certificate to give access to your host, you also should have some kind of policy statement (authorization) saying if that yes the owner of that certificate is authorized to do something. For some cases it is ok just to allow anybody in who can provide the certificate signed by verisign, but at least in VPN boxes you propably dont want to use that kind of policy. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Sep 10 08:58:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23417 for ipsec-outgoing; Thu, 10 Sep 1998 08:58:36 -0400 (EDT) Message-Id: <3.0.5.32.19980909231807.00b31dc0@homebase.htt-consult.com> X-Sender: rgm-ietf@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Sep 1998 23:18:07 -0400 To: ipsec@tis.com, "William Allen Simpson" From: Robert Moskowitz Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Cc: ietf@ietf.org, ipsec@tis.com In-Reply-To: <199809092258.SAA24165@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:58 PM 9/9/98 -0400, Theodore Y. Ts'o wrote: > >It was omitted from the IPSEC last call due to an oversight; which was >only caught by the RFC Editor. As the other documents, in particular >the DOI document, contain normative references to this document, we need >to advance this document before the other IPSEC documents can be >advanced. Not to argue with my good co-chair, but the oversight was the normative references. Back in April when we were finally getting the docs out of last call (and yes, draft-ietf-ipsec-ciph-cbc-01.txt and 02.txt were part of that last call in the workgroup), our AD worked with me to see if we could 'stage' the drafts for the IESG. draft-ietf-ipsec-ciph-cbc-02.txt was then taken out of the list sent on to the IESG even though the doc editor asked thta it be included with the orginal set. For this reason there never was an IETF last call on it. Now that our alert RFC editor found the normative reference, we have rewoken the wg on this doc as Ted mentioned. With the publication of draft-ietf-ipsec-ciph-cbc-03.txt, there will now be a IETF last call and then on to the IESG so we can get the full set out. >From: "William Allen Simpson" > > (1) If there is a need for a "normative" CBC mode description, this is > already available as draft-simpson-cbc-01.txt, which has long been > awaiting publication as Informational (no last call is needed). > This is the problem with wgs that take years to complete. draft-simpson-cbc-01.txt talks about CBC, as some people felt that the IETF needed a document defining how to do CBC. draft-ietf-ipsec-ciph-cbc-03.txt defines a set of CBCish crypto algorithms for use in IPsec as per the Roadmap doc. The name space overlap is regretable. And of course, not all of the CBC cryptos are in this unified doc. DES is not, and you, Bill, are working on a revised DESX per the note from Bellovin and Rivest. > (2) Including multiple ciphers in the document makes it difficult or > impossible to advance. We have often had this problem with "kitchen > sink" options documents in other WGs. > > (3) Several of the ciphers are proprietary, and are not likely to be > universally implemented, again making it impossible to advance. > >Indeed, originally we had separate documents for each of the cipher >algorithms. It was the decision of the IPSEC working group that having >five or six documents of which 90% of the text was boilerplate, and only >a minor portion of the text was specific to an encryption algorithm was >hard to manage, and that it would be clearer to consolidate the >algorithms into a single document. For those that have not looked at this doc for a while, the algorithms included are: 3DES, RC5, CAST, IDEA, and BLOWFISH. From casual conversations, we very well might see all of these in a few implementations. I am aware of one small company for whom the IDEA royalties are not a problem and it sounds like they have licensed BSAFE. We shall see. Bill's point is a good one about option groupings, but the wg was just getting document overload. From owner-ipsec Thu Sep 10 08:59:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23451 for ipsec-outgoing; Thu, 10 Sep 1998 08:59:42 -0400 (EDT) Message-Id: <199809101316.JAA13237@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Tero Kivinen cc: Rodney Thayer , Moshe Litvin , ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Sep 1998 09:16:07 -0400 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199809101154.OAA09700@torni.ssh.fi>, Tero Kivinen writes: >Rodney Thayer writes: >> >> the IKE negotiation in progress. For dNSName the name must be >> >> retrived from the DNS to validate it is valid for the IP address >> >> which was the source of the certificate, if known, and for the >> >> IKE negotiation in progress. For rFC822Name, the email address >> If you put an IPSec device behind an NAT device then your IP address >> isn't your identity and you should use something else, like an FQDN. >> Or, the device on the other end has to somehow be willing to cope >> with the difference between the identity in the cert and the ip >> address it's talking to. > >I think that there MUST not be any binding with the identity and the >ip address of the source packet. The packets can come in from any >source ip address, the identity payload contains the real identity >information that should be used to first find the certificate (there >is NO need to do any dns queries etc to map FQDN to ip address, if the >identity payload is fqdn then the certificate MUST contain the same >dns name in the dNSName). There's a delicate point here. You're absolutely right that certificate identities are far better than addresses -- IP addresses are transient and are quite meaningless as long-term addresses. However -- consider the case of a bump-in-the-wire or firewall-based IPsec box. Such a box knows *only* the IP address of the destination. For that matter, its policy table saying what should be encrypted is based on IP addresses. This has several implications. First, of course, certificates must be retrievable knowing only the IP address of the destination. (You could just ask the destination, of course.) This certificate needs to mention the IP address in some fashion, to guard against active attacks. The original user undoubtedly typed a DNS name, which means that we really need DNSsec, to protect that mapping. In fact, there are a trio of resources that need to be linked: the "identity" certificate (see below), the domain name, and the IP address. The latter two can be tied together via DNSsec (in both directions?, or does the cross-check suffice?); I suggest that the identity certificate be a signing certificate, and that it be used to create temporary certificates that also contain the domain name and IP address. (To avoid distractions -- when I say "identity certificate", I mean "your identity to the party with whom you wish to communicate. That is, it may be a certificate issued to you by the corporate firewall administrator, or your electronic bank, or whomever. Or it may be an X.509 certificate with your government's idea of your One True Name. For our purposes here, the question is irrelevant.) There is an asymmetry between clients and servers. For servers, the domain name is often the primary identity to be used in the certificate. We thus need strong protection on the domain name to IP address mapping, and on the IP address to certificate mapping. For clients, the domain name and IP address are quite transient, and the proferred certificate is all that matters. "Is this the party to whom I am speaking" is more than just a tag line -- it's all you know, unless there's an identity in the certificate. From owner-ipsec Thu Sep 10 08:59:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23449 for ipsec-outgoing; Thu, 10 Sep 1998 08:59:38 -0400 (EDT) Message-Id: <199809101206.IAA25581@ietf.org> To: IETF-Announce:;;;;;;;@tis.com@tis.com;;;@tis.com;;;;;;@tis.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Cc: ipsec@tis.com From: The IESG SUBJECT: Last Call: The ESP CBC-Mode Cipher Algorithms to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 10 Sep 1998 08:06:43 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider The ESP CBC-Mode Cipher Algorithms as a Proposed Standard. 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 September 24, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-cbc-03.txt From owner-ipsec Thu Sep 10 08:59:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23450 for ipsec-outgoing; Thu, 10 Sep 1998 08:59:40 -0400 (EDT) Message-Id: <35F78BA2.455E6CEA@cclk400.ccl.itri.org.tw> Date: Thu, 10 Sep 1998 16:19:46 +0800 From: Jen-Chi Liu X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ipsec@tis.com Subject: the implementation status of Internet Key Exchange/Management!! X-Priority: 1 (Highest) Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id EAA22220 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id IAA23444 Sender: owner-ipsec@ex.tis.com Precedence: bulk Everybody, Currently, our company are developing virtual private network technology. The VPN technology employs IPSEC, Internet Key Exchange/Management, and L2TP. So we would like to understand the current status of Internet Key Exchnage/Management. This IKE/IKM protocol seem under draft or to be standards?? There are products with IKE/IKM in market?? Who are shipping these source codes?? Thanks a lot!! Best Regards Jen-Chi -- Jen-Chi Liu (¼B«Ø§Ó)Ph.D. System Engineer/Project Leader K400, Bidg.51, CCL/ITRI, Hsinchu,Taiwan (Tel) 886+3+5914663 (Fax) 886+3+5820310 From owner-ipsec Thu Sep 10 10:18:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23815 for ipsec-outgoing; Thu, 10 Sep 1998 10:16:39 -0400 (EDT) Message-Id: <199809101434.KAA27602@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt Date: Thu, 10 Sep 1998 10:34:19 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : PKI Requirements for IP Security Author(s) : R. Thayer Filename : draft-ietf-ipsec-pki-req-00.txt Pages : 22 Date : 09-Sep-98 The IP Security (IPSec) protocol set now being defined in the IETF uses public key cryptography for authentication in it's key management protocol. This document defines the requirements that IPSec has for Public Key Infrastructure (PKI) protocols, formats, and services. The key words 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ipsec@tis.com mailing list. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-pki-req-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-pki-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980909162526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980909162526.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Sep 10 11:29:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24088 for ipsec-outgoing; Thu, 10 Sep 1998 11:25:40 -0400 (EDT) Message-ID: From: Greg Carter To: Tero Kivinen , "'Rodney Thayer'" Cc: ipsec@tis.com Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate name s Date: Thu, 10 Sep 1998 11:37:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > but you're saying ignore the legitimacy of the identities relative to the > rest of the world... > > Hi Rodney, If the rest of the world is not secure then yes. You trust that your CA only allowed valid names, whether or not those names can be resolved via DNS (or whatever) is not important. What is important is that your policy database contain an entry for the name. If it does then apply the rules found. You know that the other end is who they say they are because your CA allowed the identity in the certificate. You allow the connection because you found relevant policy for that identity. If the name can be resolved then that may be a good sanity check, but unless its secured it hasn't gained you much. So I am in agreement with Tero. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec Thu Sep 10 12:15:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24258 for ipsec-outgoing; Thu, 10 Sep 1998 12:12:50 -0400 (EDT) Date: Thu, 10 Sep 98 15:41:28 GMT From: "William Allen Simpson" Message-ID: <7543.wsimpson@greendragon.com> To: ietf@ietf.org Cc: ipsec@tis.com, rfc-editor@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Wed, 09 Sep 1998 23:18:07 -0400 > From: Robert Moskowitz > At 06:58 PM 9/9/98 -0400, Theodore Y. Ts'o wrote: > > > >It was omitted from the IPSEC last call due to an oversight; which was > >only caught by the RFC Editor. As the other documents, in particular > >the DOI document, contain normative references to this document, we need > >to advance this document before the other IPSEC documents can be > >advanced. > > Not to argue with my good co-chair, but the oversight was the normative > references. Back in April when we were finally getting the docs out of > last call (and yes, draft-ietf-ipsec-ciph-cbc-01.txt and 02.txt were part > of that last call in the workgroup), our AD worked with me to see if we > could 'stage' the drafts for the IESG. draft-ietf-ipsec-ciph-cbc-02.txt > was then taken out of the list sent on to the IESG even though the doc > editor asked thta it be included with the orginal set. For this reason > there never was an IETF last call on it. > I am pleased to see that Bob has already corrected Ted's misconceptions, and that we are now in agreement that there was never an IETF Last Call on this document. This means that we all agree that the original draft announcement was in error. The changes were not a result of any last call, and a last call would have to proceed before the document could be approved. > Now that our alert RFC editor found the normative reference, we have > rewoken the wg on this doc as Ted mentioned. With the publication of > draft-ietf-ipsec-ciph-cbc-03.txt, there will now be a IETF last call and > then on to the IESG so we can get the full set out. > An alert reviewer (me) already noted during the IETF last call that ciph-cbc was referenced in more than one doc, and the issue was included in my detailed message (to the IESG). I am sorry to see that the references were not properly removed. I cannot understand why, as this has been far longer than 2 weeks (April was a long time ago). The entire suite of documents should have been published, and well on their way to Draft stage. Given the large amount of time, I can only conclude that the IESG reviewers were negligent. Thank goodness there was more care by the RFC Editor staff. In doc-roadmap, there is a reference to [CBC], which can simply be removed without affecting the text in any way. There are also other references to unpublished documents in the Acknowledgements section. I explicitly requested to the IESG that the following changes be made: Layering the documents was originally proposed by William Allen Simpson, and the contents of this document corresponds to the sections and requirements in RFC-1828, RFC-1829, RFC-1851 and RFC-1852, and includes wording from later "shim" drafts for DES, 3DES, and DESX. Additional wording was suggested by Hugh Daniel, Cheryl Madson, Roy Periera, .... [all references to unpublished or work in progress documents should be deleted]. In IKE DOI, there are several references to unpublished drafts, including [ESPCBC] and [DESMAC]. They are not required for interoperability, and thus are not part of the Proposed Standard. They should simply be removed. > This is the problem with wgs that take years to complete. > draft-simpson-cbc-01.txt talks about CBC, as some people felt that the IETF > needed a document defining how to do CBC. draft-ietf-ipsec-ciph-cbc-03.txt > defines a set of CBCish crypto algorithms for use in IPsec as per the > Roadmap doc. The name space overlap is regretable. And of course, not all > of the CBC cryptos are in this unified doc. DES is not, and you, Bill, are > working on a revised DESX per the note from Bellovin and Rivest. > Yes. And have a 3DES as well. However, it was apparent at the time that the name space overlap was deliberate, and there exist several sections of text that are nearly identical to my own text. I fail to see how the million monkeys accidently wrote the same words and diagrams. > [At 06:58 PM 9/9/98 -0400, Theodore Y. Ts'o wrote:] > >Indeed, originally we had separate documents for each of the cipher > >algorithms. It was the decision of the IPSEC working group that having > >five or six documents of which 90% of the text was boilerplate, and only > >a minor portion of the text was specific to an encryption algorithm was > >hard to manage, and that it would be clearer to consolidate the > >algorithms into a single document. > Under our standards process, the WG was simply wrong. It is nigh impossible to advance unless multiple interoperable implementations have all implemented all of the options (in the same implementation). It is very unlikely that some of these algorithms will ever be widely implemented. > For those that have not looked at this doc for a while, the algorithms > included are: 3DES, RC5, CAST, IDEA, and BLOWFISH. From casual > conversations, we very well might see all of these in a few > implementations. I am aware of one small company for whom the IDEA > royalties are not a problem and it sounds like they have licensed BSAFE. > We shall see. Bill's point is a good one about option groupings, but the > wg was just getting document overload. > And the correct solution was proposed. Take the main set to publication, and then go back and work on the extensions in a new WG. I seem to remember taking this approach in another area ... :-) WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec Thu Sep 10 12:37:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA24337 for ipsec-outgoing; Thu, 10 Sep 1998 12:34:45 -0400 (EDT) Message-ID: <35F802DE.8EF44F9A@cale.checkpoint.com> Date: Thu, 10 Sep 1998 18:48:30 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer CC: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names References: <199809092123.RAA30098@2gn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer wrote: > > At 07:33 PM 9/8/98 +0200, you wrote: > >draft-ietf-ipsec-pki-req-01.txt policy about alternate names is: > > > >> 4.1.2 subjectAltName Name Format > >> > >> For IPSec devices the actual name of the subject is stored in the > >> subjectAltName field. This field MUST contain exactly one of > >> these values: > >> > >> - ipAddress > >> - dNSName > >> - rFC822Name > > > >And in section (3.3) > > > >> The subjectAltName field must be checked for validity. For > >> ipAddress, the address MUST be checked to confirm it is valid for > >> the IKE negotiation in progress. For dNSName the name must be > >> retrived from the DNS to validate it is valid for the IP address > >> which was the source of the certificate, if known, and for the > >> IKE negotiation in progress. For rFC822Name, the email address > >> must be checked according to the style of SMTP to ensure email > >> name validity. > > > >So the policy is that IPSEC devices must select ONE ID that must > >recognized by all the other devices that want to communicate with it. > >This may be problematic if the devices is known by different identities > >to different peers. IPSEC devices are usually gateways and have more > >than one IP addresses, forcing them to have only one ipAddress every one > >to know them by that particular IP address. > > Suppose you have a multi-homed firewall device, with if1, if2 and if3. > I believe that you'd possibly have several certificates, and you'd use > the appropriate certificate to talk in different situations. So, for example, > you might have three certs issued, one for each interface. > > > > >Specifying thing that must not be in a certificate may prevent the > >certificate to be used for other protocols. I.e. if one application > >requires the certificate to contain IP address and another require DNS > >name, the device will have to have at least two certificates. > > That's right. Life is complicated, IPSec life is more complicated, let's keep the certs simple. > If you are known as 10.0.0.1 to some people and xxx.yyy.com to others, your life is already complicated. But you add a lot of complication. First I have to manage a lot of certificates. I also have to know by which name I am known to each entity. > > > > >Another situation may be when the IPSEC device is behind a NAT device, > >it can put his translated address in the certificate, but then it would > >not be able to use this certificate to communicate with local > >application (IPSEC or others) that know him only by his local address. > > If you put an IPSec device behind an NAT device then your IP address isn't your identity and you should use something else, like an FQDN. Or, the device on the other end has to somehow be willing to cope with the difference between the identity in the cert and the ip address it's talking to. > >Certificate contents: > >For IPSec devices the actual name of the subject is stored in the > >subjectAltName field. This field SHOULD contain all the names that the > >device is know by other IPSEC devices. At least one of the following > >names forms SHOULD be included: > > - ipAddress > > - dNSName > > - rFC822Name > > This makes the cert processing at all levels more complicated... I don't like it. What if my ip address changes? what if the rfc822name changes relative to the host? I think we'd end up with some lowest common denominator where the only safe thing to do is to ignore the identity in the cert, which wasn't the intent. As with your original suggestion if the identity was changed you MUST get a new certificate. If one of the identities is transient don't include it in the cert, this is why I said SHOULD and not MUST. As for the complication - it is more complicated to iterate through the alternate names looking for something that you recognize. But it much more complicated to manage several certificate and decide who should get what. -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Thu Sep 10 14:22:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24799 for ipsec-outgoing; Thu, 10 Sep 1998 14:20:01 -0400 (EDT) Message-ID: <35F81C5E.1C58A5AE@lucent.com> Date: Thu, 10 Sep 1998 14:37:18 -0400 From: "Hsu, Yung-Kao" Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: ipsec Subject: questions: key length & cert retrieve: draft-ietf-ipsec-pki-req-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm new, don't know enough, and have two questions. 1) In section 2.2, it is stated All the certificates used in the IPSec device and the PKI must be of the same key length. So, for examples, I can't have a CA with a 2048-bit key signs a cert of 1024-bit key for my IPsec device. Why? 2) In section 3.2, it is stated IPSec devices MUST be able to retrieve their own fulfilled certificates, signing certificates for other IPSec devices, and identification certificates for other IPSec devices. Does this mean that, from an IPsec device, I can query cert of other IPsec devices even without establishing any communication to them? Yung-Kao Hsu Lucent Technologies From owner-ipsec Thu Sep 10 16:52:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA25323 for ipsec-outgoing; Thu, 10 Sep 1998 16:42:57 -0400 (EDT) Message-ID: <39ADCF833E74D111A2D700805F1951EF053FA365@RED-MSG-06> From: Brian Swander To: "'ipsec@tis.com'" Subject: cert chain processing Date: Thu, 10 Sep 1998 13:59:57 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk Is it possible to mandate that if sending a cert chain, it be sent as a single cert payload as pkcs7 wrapping of all necessary certs? I can't think of any good reason to support sending all the certs in arbitrary orders in the payload. Ex: Chain : Root, CA1, CA2, UserCert Possible payload: ID, CA2, Sig, CA1, User Much Better: ID, Cert, Sig where Cert contains all the necessary certs in one place. Of course its possible to grovel around the entire payload and build up the chain before processing the sig payload, but I see no benefit in supporting this complexity. Also, say someone wanted to send 2 chains, for whatever reason. If we had it mandatory that chains sent as single cert payloads, this is easy. Supporting multiple chains with in the freeforall individual cert payload format is just stupid. Comments? bs From owner-ipsec Thu Sep 10 17:40:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25477 for ipsec-outgoing; Thu, 10 Sep 1998 17:37:05 -0400 (EDT) Message-Id: <199809102051.QAA02975@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Sep 1998 17:53:12 -0400 To: "Hsu, Yung-Kao" From: Rodney Thayer Subject: Re: questions: key length & cert retrieve: draft-ietf-ipsec-pki-req-01.txt Cc: ipsec@tis.com In-Reply-To: <35F81C5E.1C58A5AE@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:37 PM 9/10/98 -0400, you wrote: >I'm new, don't know enough, and have two questions. > >1) In section 2.2, it is stated > > All the certificates used in the IPSec device and the PKI must > be of the same key length. > >So, for examples, I can't have a CA with a 2048-bit key signs a cert of >1024-bit key for my IPsec device. Why? I said it the way I did to keep things simple. a 2048 signing a 1024 seems safe although "downshifting" is still questionable. a 512 signing a 1024 seems insecure, to me. > >2) In section 3.2, it is stated > > IPSec devices MUST be able to retrieve their own fulfilled > certificates, signing certificates for other IPSec devices, and > identification certificates for other IPSec devices. > >Does this mean that, from an IPsec device, I can query cert of other IPsec >devices even without establishing any communication to them? No, it means you have posess your own cert and the signing cert[s] for the other party in order to do this. > >Yung-Kao Hsu >Lucent Technologies > From owner-ipsec Thu Sep 10 18:04:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA25550 for ipsec-outgoing; Thu, 10 Sep 1998 18:02:09 -0400 (EDT) Date: Thu, 10 Sep 1998 18:23:31 -0400 (EDT) From: Dave Mason Message-Id: <199809102223.SAA28761@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Sender: owner-ipsec@ex.tis.com Precedence: bulk Can someone give me a real-life example of how having the subjectAltName field closes a security hole that exists when the subjectAltName field isn't present? Does stating that the PKI MUST provide for the use of at least two public key technologies (section 2.1) mean that IPSec devices MUST always have at least two usage certificates with differing public key technologies? If not, why is having two public key technologies required for a PKI cryptographically sound environment but not for an IPsec device cryptographically sound environment? In section 2.2 what is the basis for the seemingly arbitrary number of 8 in the paragraph that starts "IPSec devices MUST support a signing hierarchy ...". I'm not really sure what is meant by this paragraph. Does it mean you must be able support the simultaneous use of eight or more root signing certificates or does it mean you must support signing chains of length up to 8 or longer? In the next paragraph, why must all the certificates have the same key length? Why can't the root signing cert be 2048 and the usage cert be 1024? Why can't the IPsec device have a 1024 cert that it uses for most connections and a 2048 cert that it uses for connections requiring a greater level of security? Does the third paragraph of section 3.2 mean that IKE implementations should not accept or send certificate chains via IKE? -dmason From owner-ipsec Thu Sep 10 19:22:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA25677 for ipsec-outgoing; Thu, 10 Sep 1998 19:21:09 -0400 (EDT) Message-Id: <199809102337.XAA08924@orchard.arlington.ma.us> To: Rodney Thayer cc: "Hsu, Yung-Kao" , ipsec@tis.com Subject: Re: questions: key length & cert retrieve: draft-ietf-ipsec-pki-req-01.txt In-Reply-To: Message from Rodney Thayer of "Thu, 10 Sep 1998 17:53:12 EDT." <199809102051.QAA02975@2gn.com> Date: Thu, 10 Sep 1998 19:37:56 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > a 512 signing a 1024 seems insecure, to me. Not necessarily, if the smaller key is a short-term key and the larger key is a longer-term key. An odd configuration, no doubt, but I know at least some people like the idea of on-line CA's which give out short-term certs... Also, it's not immediatley clear how to compare (e.g.) RSA and DSS key lengths. It's certainly technically possible to have a cert signed by a DSS key which contains an RSA key and vice versa. Moreover, the "all keys must be the same length" restriction seems tailor-made to prevent the gradual deployment of longer-length keys through a network. For this and other reasons I think the "all key lengths must be the same" restriction should be removed from the draft. - Bill From owner-ipsec Thu Sep 10 21:06:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26032 for ipsec-outgoing; Thu, 10 Sep 1998 21:03:08 -0400 (EDT) Message-Id: <199809110017.UAA03786@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Sep 1998 21:14:08 -0400 To: Joern Sierwald From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com In-Reply-To: <3.0.5.32.19980910155808.00a383f0@smtp.datafellows.com> References: <199809101109.HAA00656@2gn.com> <199809101154.OAA09700@torni.ssh.fi> <199809092123.RAA30098@2gn.com> <35F56A73.E0376BE8@cale.checkpoint.com> <199809092123.RAA30098@2gn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id VAA26029 Sender: owner-ipsec@ex.tis.com Precedence: bulk It's an IP _Security_ gateway. It' in the protection business. If it finds something funny about anything (like the wrong cert coming from the wrong place) it should do something. It's supposed to be protecting against, for example, IP address spoofing or use of stolen router. At 03:58 PM 9/10/98 +0300, you wrote: >At 08:11 10/09/98 -0400, you wrote: > >>So a random packet from an illegitimate address identified with >>a certificate from example.com (a defined-to-be-invalid domain) is fine? > >Do you trust the CA that signed the certificate? Is the certificate >still valid? >If you answer both questions with "yes", it is fine. > >>So the actual identity and the sanity of that identity are irrelevant? > >You don't check the "sanity of that identity". The CA should do. >You just check the sanity of the CA. > >Jörn Sierwald > From owner-ipsec Thu Sep 10 21:17:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26055 for ipsec-outgoing; Thu, 10 Sep 1998 21:17:09 -0400 (EDT) Message-Id: <199809110030.UAA03832@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Sep 1998 21:32:41 -0400 To: Greg Carter From: Rodney Thayer Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk So this means that what we are trusting is that the CA signed a certificate which represented some identification that the CA found acceptable. It seems to me that all this "but the CA said it was ok" logic ignores the possibility that the private key might be stolen. I am not arguing with the fact the CA said it was ok, I am thinking about the case where the situation has changed, and, for example, the private key got stolen (i.e. the router was stolen and is now sitting on some other network with a different IP address.) At 11:37 AM 9/10/98 -0400, you wrote: > >> but you're saying ignore the legitimacy of the identities relative to the >> rest of the world... >> >> >Hi Rodney, >If the rest of the world is not secure then yes. You trust that your CA >only allowed valid names, whether or not those names can be resolved via DNS >(or whatever) is not important. What is important is that your policy >database contain an entry for the name. If it does then apply the rules >found. You know that the other end is who they say they are because your CA >allowed the identity in the certificate. You allow the connection because >you found relevant policy for that identity. > >If the name can be resolved then that may be a good sanity check, but unless >its secured it hasn't gained you much. > >So I am in agreement with Tero. >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com > From owner-ipsec Thu Sep 10 21:43:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26083 for ipsec-outgoing; Thu, 10 Sep 1998 21:43:11 -0400 (EDT) Message-Id: <199809110057.UAA03917@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Sep 1998 21:49:20 -0400 To: Bill Sommerfeld From: Rodney Thayer Subject: Re: questions: key length & cert retrieve: draft-ietf-ipsec-pki-req-01.txt Cc: ipsec@tis.com In-Reply-To: <199809102337.XAA08924@orchard.arlington.ma.us> References: <199809102051.QAA02975@2gn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:37 PM 9/10/98 -0400, you wrote: >> a 512 signing a 1024 seems insecure, to me. > >Not necessarily, if the smaller key is a short-term key and the larger >key is a longer-term key. An odd configuration, no doubt, but I know >at least some people like the idea of on-line CA's which give out >short-term certs... I can see this argument but some people don't believe in short-term certs (some CA engines have limited capabilities to set how far in the future a certificate expires, for example) > >Also, it's not immediatley clear how to compare (e.g.) RSA and DSS key >lengths. It's certainly technically possible to have a cert signed by >a DSS key which contains an RSA key and vice versa. good point. > >Moreover, the "all keys must be the same length" restriction seems >tailor-made to prevent the gradual deployment of longer-length keys >through a network. very good point. text changed. > >For this and other reasons I think the "all key lengths must be the >same" restriction should be removed from the draft. > > - Bill > From owner-ipsec Thu Sep 10 21:43:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26084 for ipsec-outgoing; Thu, 10 Sep 1998 21:43:12 -0400 (EDT) Message-Id: <199809110057.UAA03920@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Sep 1998 21:54:30 -0400 To: Brian Swander From: Rodney Thayer Subject: Re: cert chain processing Cc: ipsec@tis.com In-Reply-To: <39ADCF833E74D111A2D700805F1951EF053FA365@RED-MSG-06> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk requiring pkcs7 wrapping of things together doesn't add any value I can see. You have to store all the certs anyway, you have to process them individually (check sigs, check names, check not-before and not-after times, etc. etc.) You also can't be sure you'll get the entire chain at once, so you still have to process one at a time. At 01:59 PM 9/10/98 -0700, you wrote: >Is it possible to mandate that if sending a cert chain, it be sent as a >single cert payload as pkcs7 wrapping of all necessary certs? > >I can't think of any good reason to support sending all the certs in >arbitrary orders in the payload. > >Ex: > >Chain : Root, CA1, CA2, UserCert > >Possible payload: >ID, CA2, Sig, CA1, User > >Much Better: > >ID, Cert, Sig where Cert contains all the necessary certs in one place. > >Of course its possible to grovel around the entire payload and build up the >chain before processing the sig payload, but I see no benefit in supporting >this complexity. > >Also, say someone wanted to send 2 chains, for whatever reason. If we had >it mandatory that chains sent as single cert payloads, this is easy. >Supporting multiple chains with in the freeforall individual cert payload >format is just stupid. > >Comments? > >bs > From owner-ipsec Thu Sep 10 21:51:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26106 for ipsec-outgoing; Thu, 10 Sep 1998 21:51:10 -0400 (EDT) Message-Id: <199809110104.VAA03979@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 10 Sep 1998 22:07:41 -0400 To: Dave Mason From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com, rodney@tillerman.nu In-Reply-To: <199809102223.SAA28761@rubicon.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:23 PM 9/10/98 -0400, you wrote: >Can someone give me a real-life example of how having the subjectAltName >field closes a security hole that exists when the subjectAltName field >isn't present? subjectAltName is the (standard) way to present the IP address, if you want to match the IP address in the ID payload to the certificate. > >Does stating that the PKI MUST provide for the use of at least two public >key technologies (section 2.1) mean that IPSec devices MUST always have at >least two usage certificates with differing public key technologies? If >not, why is having two public key technologies required for a PKI >cryptographically sound environment but not for an IPsec device >cryptographically sound environment? well all those DES-only boxes out there that couldn't trivially switch to Triple DES or something else were somewhat inconvienced by the DES cracker... > >In section 2.2 what is the basis for the seemingly arbitrary number >of 8 in the paragraph that starts "IPSec devices MUST support a signing >hierarchy ...". I'm not really sure what is meant by this paragraph. >Does it mean you must be able support the simultaneous use of eight >or more root signing certificates or does it mean you must support >signing chains of length up to 8 or longer? must be able to support at least 8, don't have to use them all. I wanted some real number in there. > >In the next paragraph, why must all the certificates have the same >key length? Why can't the root signing cert be 2048 and the usage >cert be 1024? Why can't the IPsec device have a 1024 cert that it >uses for most connections and a 2048 cert that it uses for connections >requiring a greater level of security? > >Does the third paragraph of section 3.2 mean that IKE implementations >should not accept or send certificate chains via IKE? No, it means you shouldn't accept a root you didn't get in a secure manner. you can send the usage cert and the chain (except for the root) over IKE but you shouldn't send the root over IKE. "trust me, I'm certified, see? I just signed the root myself here on my PC...) > >-dmason > From owner-ipsec Fri Sep 11 08:02:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA27648 for ipsec-outgoing; Fri, 11 Sep 1998 08:00:15 -0400 (EDT) Message-Id: <199809111113.HAA06472@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 11 Sep 1998 08:12:43 -0400 To: "Rizwan Mallal" From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com In-Reply-To: <000801bddd56$de1e8530$e20115ac@tigershark.raptor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk If you used a dynamically assigned address you wouldn't have had an IP address in your cert because you, your network manager, and your CA wouldn't have chosen to do that anyway. The validity checking is only a part of the picture, it's not a whole answer by itself. I changed the text (my current plan is to resubmit Monday) so all that stuff is 'MAY' and a few 'SHOULD's so it should line up with the rough consensus we're seeing here. At 12:35 AM 9/11/98 -0700, you wrote: >What if that stolen router is instead your stolen mobile IKE laptop?. >What kind of binding between SubjectAltName to >smtp or ipaddress or dns prevents the above scenario? > > >--Rizwan Mallal >Raptor Systems Inc > > > >-----Original Message----- >From: Rodney Thayer >To: Greg Carter >Cc: ipsec@tis.com >Date: Thursday, September 10, 1998 7:53 PM >Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names > > >>So this means that what we are trusting is that the CA signed a certificate >which represented some identification that the CA found acceptable. >> >>It seems to me that all this "but the CA said it was ok" logic ignores the >possibility that the private key might be stolen. I am not arguing with the >fact the CA said it was ok, I am thinking about the case where the situation >has changed, and, for example, the private key got stolen (i.e. the router >was stolen and is now sitting on some other network with a different IP >address.) >> >> >> >>At 11:37 AM 9/10/98 -0400, you wrote: >>> >>>> but you're saying ignore the legitimacy of the identities relative to >the >>>> rest of the world... >>>> >>>> >>>Hi Rodney, >>>If the rest of the world is not secure then yes. You trust that your CA >>>only allowed valid names, whether or not those names can be resolved via >DNS >>>(or whatever) is not important. What is important is that your policy >>>database contain an entry for the name. If it does then apply the rules >>>found. You know that the other end is who they say they are because your >CA >>>allowed the identity in the certificate. You allow the connection because >>>you found relevant policy for that identity. >>> >>>If the name can be resolved then that may be a good sanity check, but >unless >>>its secured it hasn't gained you much. >>> >>>So I am in agreement with Tero. >>>---- >>>Greg Carter, Entrust Technologies >>>greg.carter@entrust.com >>> >> > From owner-ipsec Fri Sep 11 09:00:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA28024 for ipsec-outgoing; Fri, 11 Sep 1998 09:00:18 -0400 (EDT) Message-Id: <199809111317.JAA14994@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names In-reply-to: Your message of "Fri, 11 Sep 1998 08:12:43 EDT." <199809111113.HAA06472@2gn.com> Date: Fri, 11 Sep 1998 09:17:43 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Rodney" == Rodney Thayer writes: Rodney> If you used a dynamically assigned address you wouldn't have had Rodney> an IP address in your cert because you, your network manager, and Rodney> your CA wouldn't have chosen to do that anyway. I might, but it might be my at-home-permanent address. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Sat Sep 12 04:19:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00264 for ipsec-outgoing; Sat, 12 Sep 1998 04:16:53 -0400 (EDT) From: bmanning@isi.edu Posted-Date: Fri, 11 Sep 1998 07:48:52 -0700 (PDT) Message-Id: <199809111448.AA04563@zed.isi.edu> Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate To: rodney@tillerman.nu (Rodney Thayer) Date: Fri, 11 Sep 1998 07:48:52 -0700 (PDT) Cc: saira@thecia.net, ipsec@tis.com In-Reply-To: <199809111113.HAA06472@2gn.com> from "Rodney Thayer" at Sep 11, 98 08:12:43 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Actually, this raises an interesting question wrt the recent A6 RR type being proposed in the IPv6 group. The plan is to compose the IP address on the fly, depending on where you are. How would IPSEC deal with that model? > > If you used a dynamically assigned address you wouldn't have had an IP address in your cert because you, your network manager, and your CA wouldn't have chosen to do that anyway. > > The validity checking is only a part of the picture, it's not a whole answer by itself. > > I changed the text (my current plan is to resubmit Monday) so all that stuff is 'MAY' and a few 'SHOULD's so it should line up with the rough consensus we're seeing here. > > At 12:35 AM 9/11/98 -0700, you wrote: > >What if that stolen router is instead your stolen mobile IKE laptop?. > >What kind of binding between SubjectAltName to > >smtp or ipaddress or dns prevents the above scenario? > > > > > >--Rizwan Mallal > >Raptor Systems Inc > > > > > > > >-----Original Message----- > >From: Rodney Thayer > >To: Greg Carter > >Cc: ipsec@tis.com > >Date: Thursday, September 10, 1998 7:53 PM > >Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names > > > > > >>So this means that what we are trusting is that the CA signed a certificate > >which represented some identification that the CA found acceptable. > >> > >>It seems to me that all this "but the CA said it was ok" logic ignores the > >possibility that the private key might be stolen. I am not arguing with the > >fact the CA said it was ok, I am thinking about the case where the situation > >has changed, and, for example, the private key got stolen (i.e. the router > >was stolen and is now sitting on some other network with a different IP > >address.) > >> > >> > >> > >>At 11:37 AM 9/10/98 -0400, you wrote: > >>> > >>>> but you're saying ignore the legitimacy of the identities relative to > >the > >>>> rest of the world... > >>>> > >>>> > >>>Hi Rodney, > >>>If the rest of the world is not secure then yes. You trust that your CA > >>>only allowed valid names, whether or not those names can be resolved via > >DNS > >>>(or whatever) is not important. What is important is that your policy > >>>database contain an entry for the name. If it does then apply the rules > >>>found. You know that the other end is who they say they are because your > >CA > >>>allowed the identity in the certificate. You allow the connection because > >>>you found relevant policy for that identity. > >>> > >>>If the name can be resolved then that may be a good sanity check, but > >unless > >>>its secured it hasn't gained you much. > >>> > >>>So I am in agreement with Tero. > >>>---- > >>>Greg Carter, Entrust Technologies > >>>greg.carter@entrust.com > >>> > >> > > > > -- --bill From owner-ipsec Sat Sep 12 04:19:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00097 for ipsec-outgoing; Sat, 12 Sep 1998 04:15:47 -0400 (EDT) Message-Id: <199809111748.KAA09458@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: ipsec@tis.com Subject: issues with IKE that need resolution MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9456.905536092.1@cisco.com> Date: Fri, 11 Sep 1998 10:48:12 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm compiling a list of issues with IKE that need addressing. Once the RFCs come out of the shoot I understand IKE will again be open for edits. To that end, here are the issues I've received. I divided it into two sections: one for clarifications and codification of behavior that, while most all implementations do already, is open to interpretation; and, another for changes that will effect interoperability. Clarification and Codification: 1. A new Diffie-Hellman group should be added. I know of vendors that already implement this as group 5-- that's what it should become: A MODP group with a 1536 bit prime The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF The generator is 2. 2. Verbage on the deprication of DES and the mandatory status of 3DES. 3. Clarification of use of the commit bit in IKE. This will constrain the freeform (and confusing) verbage in the base ISAKMP document. For IKE the commit bit only makes sense in Quick Mode. Most people I spoke to said that they return a "INVALID_FLAGS" notify message if the peer tries to set it in any other mode. They also only use it to extend Quick Mode by a single message-- from the responder back to the initiator. This was its intended use anyway. Also, most people send this message as a final Quick Mode exchange message and not an Informational. The only person I spoke to who did otherwise said Quick Mode made more sense and was going to change. 4. Verbage similar to what is in the IP DOI regarding lifetime negotiation for phase 2 has to be added to IKE for phase 1 negotiation. 5. What type of cert encoding is used in a cert request payload if you wish to obtain the peer's encryption certificate (assuming the peer has one signature only and one for encipherment only)? This might actually be a draft-ietf-ipsec-pki-req-01.txt issue and will defer to Rodney if that's where people think this should go. 6. There was also some desire to add new elliptic curve groups for Diffie-Hellman. Perhaps new groups would be best handled by a separate document. What do people feel? IKE or seperate document? 7. There's a IP DOI issue to partition the protocol (4.4.1) and transform (4.4.2) numberspace to reserve the bulk to IANA and leave some for "private use". Changes to affect interoperability 1. The ISAKMP header is not authenticated! An attack can be launched against Quick Mode by selectively setting and clearing the commit bit to make one side wait for a final message that the other side does not think it has to send! 2. None of the optional payloads-- cert, cert_req, notify for initial contact, vendor ID-- are authenticated. Any other things, please post. I'm generating some html for Ted to include in http://web.mit.edu/tytso/www/ipsec and will happily include more. Ted and Bob want a central repository of issues to focus work on them-- and so things don't get forgotten Dan. From owner-ipsec Sat Sep 12 04:19:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00199 for ipsec-outgoing; Sat, 12 Sep 1998 04:16:09 -0400 (EDT) Date: Fri, 11 Sep 1998 12:24:48 -0400 (EDT) From: Dave Mason Message-Id: <199809111624.MAA06490@rubicon.rv.tis.com> To: rodney@tillerman.nu Cc: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Can someone give me a real-life example of how having the subjectAltName >>field closes a security hole that exists when the subjectAltName field >>isn't present? > >subjectAltName is the (standard) way to present the IP address, if you >want to match the IP address in the ID payload to the certificate. Don't you mean proposed standard:?) The certificate they use identifies them and determines what type of connections (algorithm(s), local address(es), remote address(es), etc.) they're allowed to setup. The database would of course determine what local sites they're allowed access to and for certificates of non-mobile peers part of the database would state the peer addresses they're allowed to connect from. With the right certificate-based policy database, matching a remote ip address to a certificate without the use of a subjectAltName field is not that difficult (it's just a subject/issuer DN regex match of certificate to database). The only advantage of the subjectAltName field that I can see is that it allows you to deny the connection without having to consult the policy database if the subjectAltName is an IP address and it doesn't match the source IP address of the sender. Lots of people seem to really like subjectAltName so there must be other advantages I'm missing here. Actually, since the certificate identifies the peer and determines the policy to apply to the connection(s) I'm not really sure why you even need an ID payload in phase I when using certificates especially if it's mandated to be just a redundant copy of contents within the certificate (if it's just a copy of what's in the certificate why not just use the certificate?). >>Does stating that the PKI MUST provide for the use of at least two public >>key technologies (section 2.1) mean that IPSec devices MUST always have at >>least two usage certificates with differing public key technologies? If >>not, why is having two public key technologies required for a PKI >>cryptographically sound environment but not for an IPsec device >>cryptographically sound environment? > >well all those DES-only boxes out there that couldn't trivially switch to Triple DES or something else were somewhat inconvienced by the DES cracker... Yes, but if those des-only boxes had been required to support two different 56-bit key technologies they probably wouldn't be any better off today because of it. I would prefer wording something like this (yes, I know the second sentence is redundant) for the paragraph that starts "IPSec devices MUST support a signing hierarchy ..." in section 2.2: IPSec devices SHOULD support interaction with peers from many (at least 8) different signing hierarchies. That is, IPSec devices SHOULD support peer certificate validation against many (at least 8) different root certificates. Could you change the wording of the third paragraph of section 3.2 to say: A root signing certificate ^^^^ And maybe add the following sentence to the end of section 4.4.1 (or maybe in the Terminology section 1.1): A 'Root' Signing Certificate is also sometimes referred to as a self signed certificate. -dmason From owner-ipsec Sat Sep 12 04:19:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00263 for ipsec-outgoing; Sat, 12 Sep 1998 04:16:32 -0400 (EDT) Message-ID: <000801bddd56$de1e8530$e20115ac@tigershark.raptor.com> From: "Rizwan Mallal" To: "Rodney Thayer" Cc: Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Date: Fri, 11 Sep 1998 00:35:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk What if that stolen router is instead your stolen mobile IKE laptop?. What kind of binding between SubjectAltName to smtp or ipaddress or dns prevents the above scenario? --Rizwan Mallal Raptor Systems Inc -----Original Message----- From: Rodney Thayer To: Greg Carter Cc: ipsec@tis.com Date: Thursday, September 10, 1998 7:53 PM Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names >So this means that what we are trusting is that the CA signed a certificate which represented some identification that the CA found acceptable. > >It seems to me that all this "but the CA said it was ok" logic ignores the possibility that the private key might be stolen. I am not arguing with the fact the CA said it was ok, I am thinking about the case where the situation has changed, and, for example, the private key got stolen (i.e. the router was stolen and is now sitting on some other network with a different IP address.) > > > >At 11:37 AM 9/10/98 -0400, you wrote: >> >>> but you're saying ignore the legitimacy of the identities relative to the >>> rest of the world... >>> >>> >>Hi Rodney, >>If the rest of the world is not secure then yes. You trust that your CA >>only allowed valid names, whether or not those names can be resolved via DNS >>(or whatever) is not important. What is important is that your policy >>database contain an entry for the name. If it does then apply the rules >>found. You know that the other end is who they say they are because your CA >>allowed the identity in the certificate. You allow the connection because >>you found relevant policy for that identity. >> >>If the name can be resolved then that may be a good sanity check, but unless >>its secured it hasn't gained you much. >> >>So I am in agreement with Tero. >>---- >>Greg Carter, Entrust Technologies >>greg.carter@entrust.com >> > From owner-ipsec Sat Sep 12 04:19:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00140 for ipsec-outgoing; Sat, 12 Sep 1998 04:15:54 -0400 (EDT) Date: Fri, 11 Sep 1998 12:37:26 -0400 (EDT) From: Dave Mason Message-Id: <199809111637.MAA11444@rubicon.rv.tis.com> To: rodney@tillerman.nu Cc: ipsec@tis.com Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Sender: owner-ipsec@ex.tis.com Precedence: bulk >It seems to me that all this "but the CA said it was ok" logic ignores the possibility that the private key might be stolen. I am not arguing with the fact the CA said it was ok, I am thinking about the case where the situation has changed, and, for example, the private key got stolen (i.e. the router was stolen and is now sitting on some other network with a different IP address.) If it's marked as a non-mobile certificate in the policy database, the database would restrict the ip addresses allowed for the remote end. Having the ip address in the certificate might shrink the policy database a little (but probably not) and would just enlarge the certificate. -dmason From owner-ipsec Sat Sep 12 04:19:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA29999 for ipsec-outgoing; Sat, 12 Sep 1998 04:15:28 -0400 (EDT) Message-Id: <199809112157.RAA02441@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 11 Sep 1998 18:55:35 -0400 To: bmanning@isi.edu From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate Cc: ipsec@tis.com In-Reply-To: <199809111448.AA04563@zed.isi.edu> References: <199809111113.HAA06472@2gn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk well since nobody else seems to care where the packet came from I suppose it's fine. At 07:48 AM 9/11/98 -0700, you wrote: > >Actually, this raises an interesting question wrt the recent A6 RR type being >proposed in the IPv6 group. The plan is to compose the IP address on the fly, >depending on where you are. How would IPSEC deal with that model? > >> >> If you used a dynamically assigned address you wouldn't have had an IP address in your cert because you, your network manager, and your CA wouldn't have chosen to do that anyway. >> >> The validity checking is only a part of the picture, it's not a whole answer by itself. >> >> I changed the text (my current plan is to resubmit Monday) so all that stuff is 'MAY' and a few 'SHOULD's so it should line up with the rough consensus we're seeing here. >> >> At 12:35 AM 9/11/98 -0700, you wrote: >> >What if that stolen router is instead your stolen mobile IKE laptop?. >> >What kind of binding between SubjectAltName to >> >smtp or ipaddress or dns prevents the above scenario? >> > >> > >> >--Rizwan Mallal >> >Raptor Systems Inc >> > >> > >> > >> >-----Original Message----- >> >From: Rodney Thayer >> >To: Greg Carter >> >Cc: ipsec@tis.com >> >Date: Thursday, September 10, 1998 7:53 PM >> >Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names >> > >> > >> >>So this means that what we are trusting is that the CA signed a certificate >> >which represented some identification that the CA found acceptable. >> >> >> >>It seems to me that all this "but the CA said it was ok" logic ignores the >> >possibility that the private key might be stolen. I am not arguing with the >> >fact the CA said it was ok, I am thinking about the case where the situation >> >has changed, and, for example, the private key got stolen (i.e. the router >> >was stolen and is now sitting on some other network with a different IP >> >address.) >> >> >> >> >> >> >> >>At 11:37 AM 9/10/98 -0400, you wrote: >> >>> >> >>>> but you're saying ignore the legitimacy of the identities relative to >> >the >> >>>> rest of the world... >> >>>> >> >>>> >> >>>Hi Rodney, >> >>>If the rest of the world is not secure then yes. You trust that your CA >> >>>only allowed valid names, whether or not those names can be resolved via >> >DNS >> >>>(or whatever) is not important. What is important is that your policy >> >>>database contain an entry for the name. If it does then apply the rules >> >>>found. You know that the other end is who they say they are because your >> >CA >> >>>allowed the identity in the certificate. You allow the connection because >> >>>you found relevant policy for that identity. >> >>> >> >>>If the name can be resolved then that may be a good sanity check, but >> >unless >> >>>its secured it hasn't gained you much. >> >>> >> >>>So I am in agreement with Tero. >> >>>---- >> >>>Greg Carter, Entrust Technologies >> >>>greg.carter@entrust.com >> >>> >> >> >> > >> >> > > >-- >--bill > From owner-ipsec Sat Sep 12 13:18:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01200 for ipsec-outgoing; Sat, 12 Sep 1998 13:16:03 -0400 (EDT) Message-Id: <199809121732.NAA25373@penelope.ve3tla.ampr.org> To: Rodney Thayer cc: bmanning@isi.edu, ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate References: <199809111113.HAA06472@2gn.com> <199809112157.RAA02441@2gn.com> In-reply-to: rodney's message of "Fri, 11 Sep 1998 18:55:35 -0400". <199809112157.RAA02441@2gn.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Sat, 12 Sep 1998 13:32:22 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199809112157.RAA02441@2gn.com>, Rodney Thayer writes: > well since nobody else seems to care where the packet came from I suppose > it's fine. If you *do* care where the packet came from, then your local policy engine should do the enforcement. The point is that "caring where the packet came from" should *not* be a mandatory requirement of the standard. It's perfectly valid to not care where the packet came from when you know *who* it came from... -- C. Harald Koch "It takes a child to raze a village." -Michael T. Fry From owner-ipsec Sat Sep 12 13:34:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01240 for ipsec-outgoing; Sat, 12 Sep 1998 13:34:02 -0400 (EDT) Message-Id: <199809121650.MAA06822@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sat, 12 Sep 1998 13:49:45 -0400 To: Dave Mason From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com In-Reply-To: <199809111624.MAA06490@rubicon.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I misspoke, 'proposed' not 'standard' was the proper term. In Raleigh we found that most implementors found the subjectAltName proposal preferable over using some mechanism to use the subjectName. I myself just wanted to define rules for formatting subjectName (which would have allowed regex matching). So we already had this discussion once (not to mean at all that we should not be visiting the subject now, as it's on the main list...) At 12:24 PM 9/11/98 -0400, you wrote: >>>Can someone give me a real-life example of how having the subjectAltName >>>field closes a security hole that exists when the subjectAltName field >>>isn't present? >> >>subjectAltName is the (standard) way to present the IP address, if you >>want to match the IP address in the ID payload to the certificate. > >Don't you mean proposed standard:?) The certificate they use identifies >them and determines what type of connections (algorithm(s), local address(es), >remote address(es), etc.) they're allowed to setup. The database would of >course determine what local sites they're allowed access to and for >certificates of non-mobile peers part of the database would state the >peer addresses they're allowed to connect from. With the right >certificate-based policy database, matching a remote ip address to a >certificate without the use of a subjectAltName field is not that difficult >(it's just a subject/issuer DN regex match of certificate to database). > >The only advantage of the subjectAltName field that I can see is that >it allows you to deny the connection without having to consult the >policy database if the subjectAltName is an IP address and it doesn't >match the source IP address of the sender. Lots of people seem to >really like subjectAltName so there must be other advantages I'm >missing here. Actually, since the certificate identifies the peer >and determines the policy to apply to the connection(s) I'm not really >sure why you even need an ID payload in phase I when using certificates >especially if it's mandated to be just a redundant copy of contents >within the certificate (if it's just a copy of what's in the certificate >why not just use the certificate?). > > >>>Does stating that the PKI MUST provide for the use of at least two public >>>key technologies (section 2.1) mean that IPSec devices MUST always have at >>>least two usage certificates with differing public key technologies? If >>>not, why is having two public key technologies required for a PKI >>>cryptographically sound environment but not for an IPsec device >>>cryptographically sound environment? >> >>well all those DES-only boxes out there that couldn't trivially switch to Triple DES or something else were somewhat inconvienced by the DES cracker... > >Yes, but if those des-only boxes had been required to support two different >56-bit key technologies they probably wouldn't be any better off today >because of it. Well then I worded the text wrong. I meant two different algorithms. I'll change the text. Or are you saying RSA and DSA and ECC are the same thing (which I'm sure the RSA lawyers would love to hear :-)) > > >I would prefer wording something like this (yes, I know the second sentence >is redundant) for the paragraph that starts "IPSec devices MUST support a >signing hierarchy ..." in section 2.2: > > IPSec devices SHOULD support interaction with peers from many (at > least 8) different signing hierarchies. That is, IPSec devices SHOULD > support peer certificate validation against many (at least 8) different > root certificates. > yeah fine I'll change it. > >Could you change the wording of the third paragraph of section 3.2 to say: > >A root signing certificate > ^^^^ No. If it's not at the top of the hierarchy then it's not a root. Been there, got that wrong. You might not like my mandating 8 layers, and that's fine, but I am positive we'll need to deal with more than one-layer hierarchies. > >And maybe add the following sentence to the end of section 4.4.1 (or maybe >in the Terminology section 1.1): > >A 'Root' Signing Certificate is also sometimes referred to as a self >signed certificate. right. > > >-dmason > From owner-ipsec Sun Sep 13 00:52:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA02274 for ipsec-outgoing; Sun, 13 Sep 1998 00:50:03 -0400 (EDT) Message-Id: <199809130507.BAA04059@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names In-reply-to: Your message of "Fri, 11 Sep 1998 12:37:26 EDT." <199809111637.MAA11444@rubicon.rv.tis.com> Date: Sun, 13 Sep 1998 01:06:59 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Dave" == Dave Mason writes: Dave> If it's marked as a non-mobile certificate in the policy database, the Dave> database would restrict the ip addresses allowed for the remote If it's not a mobile node, then your local policy database will have a clear end-point for the router. So, even if they steal the router, drop in in somewhere with a different IP address, the SA's that would be allowed to be negotiated would be for the original location. The names in the certificate are *not* policy information. They are keys to policy information. If you use the stuff *as* policy information, then you are going to get hosed. Use KeyNote or something instead if you want scaling beyond your local config file. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Mon Sep 14 10:17:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06103 for ipsec-outgoing; Mon, 14 Sep 1998 10:11:05 -0400 (EDT) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13820.55119.456008.466445@lohi.eng.telia.fi> Date: Mon, 14 Sep 1998 11:43:59 +0300 (EEST) To: rob.glenn@nist.gov CC: kent@bbn.com, ipsec@tis.com Subject: null encryption X-Mailer: VM 6.47 under Emacs 19.34.1 Sender: owner-ipsec@ex.tis.com Precedence: bulk i don't know if the authors of the null encryption i-d have thought so, but ipsec can be used as a generic tunneling mechanism alternative to l2tp and in that application neither strong autentication nor encryption is always be desirable. so i would suggest changing the wording of the following sentence in the null encryption i-d in order not to exclude the tunneling application: As stated in [ESP], while the use of encryption algorithms and authentication algorithms are optional in ESP, it is imperative that an ESP SA specifies the use of at least one cryptographically strong encryption algorithm or one cryptographically strong authentication algorithm or one of each. -- juha ps. i'm not on ipsec list. From owner-ipsec Mon Sep 14 10:17:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06085 for ipsec-outgoing; Mon, 14 Sep 1998 10:10:05 -0400 (EDT) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13820.55119.456008.466445@lohi.eng.telia.fi> Date: Mon, 14 Sep 1998 11:43:59 +0300 (EEST) To: rob.glenn@nist.gov CC: kent@bbn.com, ipsec@tis.com Subject: null encryption X-Mailer: VM 6.47 under Emacs 19.34.1 Sender: owner-ipsec@ex.tis.com Precedence: bulk i don't know if the authors of the null encryption i-d have thought so, but ipsec can be used as a generic tunneling mechanism alternative to l2tp and in that application neither strong autentication nor encryption is always be desirable. so i would suggest changing the wording of the following sentence in the null encryption i-d in order not to exclude the tunneling application: As stated in [ESP], while the use of encryption algorithms and authentication algorithms are optional in ESP, it is imperative that an ESP SA specifies the use of at least one cryptographically strong encryption algorithm or one cryptographically strong authentication algorithm or one of each. -- juha ps. i'm not on ipsec list. From owner-ipsec Mon Sep 14 10:37:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06259 for ipsec-outgoing; Mon, 14 Sep 1998 10:36:05 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01C452A9@WADE> From: John Bassett To: "'ipsec@tis.com'" Subject: Some questions on IKE proposals... Date: Mon, 14 Sep 1998 15:52:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, A couple of questions on SA proposals in IKE. - Is there a method for using the NO-PROPOSAL-CHOSEN notification in connection with a quick mode exchange?. Section 5.4 of the ISAKMP spec says that the no-proposal notification should be sent using an informational exchange and hence has a unique message ID. Unfortunately this gives no way of connecting the notification with the quick mode exchange that caused it. As the error was probably caused by the user misconfiguring policies it would be useful to know which exchange (and hence which policy) it applied to. Could this be treated the same way as the CONNECTED notification and be sent using the quick mode message ID ? - When negotiating an SA protected with multiple protocols (e.g ESP+AH) is the ordering of the ESP and AH proposals (which have the same proposal number) significant? Does the ordering reflect the order in which transforms will be applied? I know it really only makes sense to do ESP first but could an implementation request AH followed by ESP ? Thanks, John From owner-ipsec Mon Sep 14 12:11:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06706 for ipsec-outgoing; Mon, 14 Sep 1998 12:10:14 -0400 (EDT) Message-Id: <199809141627.MAA11504@jekyll.piermont.com> To: Juha Heinanen cc: rob.glenn@nist.gov, kent@bbn.com, ipsec@tis.com Subject: Re: null encryption In-reply-to: Your message of "Mon, 14 Sep 1998 11:43:59 +0300." <13820.55119.456008.466445@lohi.eng.telia.fi> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Sep 1998 12:27:32 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Juha Heinanen writes: > i don't know if the authors of the null encryption i-d have thought so, > but ipsec can be used as a generic tunneling mechanism alternative to > l2tp I would say one is better off using GRE for such an application. .pm From owner-ipsec Mon Sep 14 12:22:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06835 for ipsec-outgoing; Mon, 14 Sep 1998 12:22:13 -0400 (EDT) Date: Mon, 14 Sep 1998 12:42:47 -0400 (EDT) From: Dave Mason Message-Id: <199809141642.MAA25689@rubicon.rv.tis.com> To: rodney@tillerman.nu Cc: ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Sender: owner-ipsec@ex.tis.com Precedence: bulk >> >>Could you change the wording of the third paragraph of section 3.2 to say: >> >>A root signing certificate >> ^^^^ > >No. If it's not at the top of the hierarchy then it's not a root. >Been there, got that wrong. You might not like my mandating 8 layers, and >that's fine, but >I am positive we'll need to deal with more than one-layer hierarchies. Without the "root" specification, this paragraph (as well as the last sentence of the second paragraph in section 3.3) precludes the sending of certificate chains via IKE (which is fine with me since the proper handling of chains received via IKE is not a simple matter :). -dmason From owner-ipsec Mon Sep 14 12:38:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06900 for ipsec-outgoing; Mon, 14 Sep 1998 12:38:21 -0400 (EDT) Message-Id: <199809141554.LAA17963@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 14 Sep 1998 12:48:47 -0400 To: Dave Mason From: Rodney Thayer Subject: Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names Cc: ipsec@tis.com, rodney@tillerman.nu In-Reply-To: <199809141642.MAA25689@rubicon.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk argh. I didn't mean to prohibit that. I myself don't like sending chains but I'm not trying to have that debate over this document. I'll think about how I worded things and come up with something less vague. At 12:42 PM 9/14/98 -0400, you wrote: >>> >>>Could you change the wording of the third paragraph of section 3.2 to say: >>> >>>A root signing certificate >>> ^^^^ >> >>No. If it's not at the top of the hierarchy then it's not a root. >>Been there, got that wrong. You might not like my mandating 8 layers, and >>that's fine, but >>I am positive we'll need to deal with more than one-layer hierarchies. > >Without the "root" specification, this paragraph (as well as the last >sentence of the second paragraph in section 3.3) precludes the sending >of certificate chains via IKE (which is fine with me since the proper >handling of chains received via IKE is not a simple matter :). > >-dmason > From owner-ipsec Mon Sep 14 12:43:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06934 for ipsec-outgoing; Mon, 14 Sep 1998 12:43:21 -0400 (EDT) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13821.18844.167174.536296@lohi.eng.telia.fi> Date: Mon, 14 Sep 1998 19:51:40 +0300 (EEST) To: perry@piermont.com Cc: rob.glenn@nist.gov, kent@bbn.com, ipsec@tis.com Subject: Re: null encryption In-Reply-To: <199809141627.MAA11504@jekyll.piermont.com> References: <13820.55119.456008.466445@lohi.eng.telia.fi> <199809141627.MAA11504@jekyll.piermont.com> X-Mailer: VM 6.47 under Emacs 19.34.1 Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger writes: > > i don't know if the authors of the null encryption i-d have thought so, > > but ipsec can be used as a generic tunneling mechanism alternative to > > l2tp > > I would say one is better off using GRE for such an application. i only want one tunneling mechanism between routers where authentication and/or encryption can be turned on or off depending on the situation. i prefer ipsec tunnels also because there are management tools available for controling the peering. further, where is gre standardized? -- juha From owner-ipsec Mon Sep 14 13:10:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07080 for ipsec-outgoing; Mon, 14 Sep 1998 13:10:27 -0400 (EDT) Date: Mon, 14 Sep 1998 13:26:38 -0400 (EDT) From: Henry Spencer To: Juha Heinanen cc: ipsec@tis.com Subject: Re: null encryption In-Reply-To: <13820.55119.456008.466445@lohi.eng.telia.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > i don't know if the authors of the null encryption i-d have thought so, > but ipsec can be used as a generic tunneling mechanism alternative to > l2tp and in that application neither strong autentication nor encryption > is always be desirable. RFC 2003 defined a generic tunnelling mechanism two years ago; there is no need to misapply IPSEC for this. I think it would be safe to say that such an application is beyond the intended scope of IPSEC, and hence need not be addressed by the IPSEC documents. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Mon Sep 14 13:17:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07124 for ipsec-outgoing; Mon, 14 Sep 1998 13:16:28 -0400 (EDT) Message-Id: <199809141733.NAA11842@jekyll.piermont.com> To: Juha Heinanen cc: ipsec@tis.com Subject: Re: null encryption In-reply-to: Your message of "Mon, 14 Sep 1998 19:51:40 +0300." <13821.18844.167174.536296@lohi.eng.telia.fi> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Sep 1998 13:33:45 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Juha Heinanen writes: > further, where is gre standardized? RFC's 1701 & 1702 .pm From owner-ipsec Mon Sep 14 13:43:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07265 for ipsec-outgoing; Mon, 14 Sep 1998 13:42:30 -0400 (EDT) Message-Id: <199809141759.NAA11934@jekyll.piermont.com> To: Juha Heinanen cc: perry@piermont.com, ipsec@tis.com Subject: Re: null encryption In-reply-to: Your message of "Mon, 14 Sep 1998 20:36:48 +0300." <13821.21552.733709.344694@lohi.eng.telia.fi> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Sep 1998 13:59:36 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Juha Heinanen writes: > Perry E. Metzger writes: > > > > further, where is gre standardized? > > > > RFC's 1701 & 1702 > > This memo does not specify an Internet standard of any kind. IPSec is not a standard, either. Just a proposed standard. GRE is very widely deployed at the moment. Perry From owner-ipsec Mon Sep 14 13:45:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07289 for ipsec-outgoing; Mon, 14 Sep 1998 13:45:28 -0400 (EDT) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13821.21552.733709.344694@lohi.eng.telia.fi> Date: Mon, 14 Sep 1998 20:36:48 +0300 (EEST) To: perry@piermont.com Cc: ipsec@tis.com Subject: Re: null encryption In-Reply-To: <199809141733.NAA11842@jekyll.piermont.com> References: <13821.18844.167174.536296@lohi.eng.telia.fi> <199809141733.NAA11842@jekyll.piermont.com> X-Mailer: VM 6.47 under Emacs 19.34.1 Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger writes: > > further, where is gre standardized? > > RFC's 1701 & 1702 This memo does not specify an Internet standard of any kind. -- juha From owner-ipsec Mon Sep 14 15:40:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07829 for ipsec-outgoing; Mon, 14 Sep 1998 15:38:36 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF3B5D4B@exchange> From: Roy Pereira To: ipsec@tis.com Subject: RE: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Date: Mon, 14 Sep 1998 15:57:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDE019.E5D93600" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDE019.E5D93600 Content-Type: text/plain; charset="iso-8859-1" Thank you for the very good reply. I was away on vacation and missed all of the 'exitement'. ;-) > -----Original Message----- > From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU] > Sent: Wednesday, September 09, 1998 6:59 PM > To: William Allen Simpson > Cc: ietf@ietf.org; ipsec@tis.com > Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt > > > Date: Wed, 9 Sep 98 19:11:01 GMT > From: "William Allen Simpson" > > I was horrified to see this posting today, and this > message is a formal > protest against this document being advanced: > > > Title : The ESP CBC-Mode Cipher Algorithms > > Author(s) : R. Pereira, R. Adams > > Gentlefolk, it cannot "reflect comments", as this document > has not been > through any "last call". Even the WG chose not to advance > it during the > internal last call. It was deliberately _omitted_ from > the IESG IPSec > last call. > > It was omitted from the IPSEC last call due to an oversight; which was > only caught by the RFC Editor. As the other documents, in particular > the DOI document, contain normative references to this > document, we need > to advance this document before the other IPSEC documents can be > advanced. > > When I was notified of this last week, I consulted with Jeff Schiller > and Bob Moskowitz, and we agreed that the most efficient way to deal > with this oversight, while staying within the bounds of our standards > process, was for me to send out a note explaining this > situation to the > IPSEC working group. There, we gave notice of our intention > to advance > this document to IETF Last Call the following week, and if > folks had any > issues with this, to please comment on the IPSEC list ASAP. > (Note that > an internal WG last call is not required by our processes before IETF > last call, but we did want to give the working group time to make any > last-minute comments.) > > As it turns out, the Roy Pereira, the document editor, had > some changes > batched up that clarified the document, and that so this was the -03 > version of the document was sent to the Secretariat this > week, and whose > announcement apparently caused you great horror. > > Today, I formally asked Jeff Schiller to put this document out for the > two-week IETF Last Call, which should get sent out tomorrow. > > ----------------------------------------------- > > As to your specific issues with the documents, let me address them one > by one. Any further discussion on these points would probably be more > appropriate on the IPSEC working group list, so I have set > the Reply-to: > field on this message to ipsec@tis.com. (Any folks who are not on the > IPSEC mailing list and who are interested are very much > welcome to send > mail to ipsec-request@tis.com to get added to the IPSEC mailing list.) > > > (1) If there is a need for a "normative" CBC mode > description, this is > already available as draft-simpson-cbc-01.txt, which > has long been > awaiting publication as Informational (no last call is needed). > > This document is a matched set with the DOI document, and contains > details of the default key sizes, weak key checks, etc. needed for the > various algorithms specified in the DOI. (The DOI document contains a > listing of which algorithms are mandatory and which are optional; this > document contains the details of how those algorithms are to be used > with ESP.) > > (2) Including multiple ciphers in the document makes it > difficult or > impossible to advance. We have often had this problem > with "kitchen > sink" options documents in other WGs. > > (3) Several of the ciphers are proprietary, and are not > likely to be > universally implemented, again making it impossible to advance. > > Indeed, originally we had separate documents for each of the cipher > algorithms. It was the decision of the IPSEC working group > that having > five or six documents of which 90% of the text was > boilerplate, and only > a minor portion of the text was specific to an encryption > algorithm was > hard to manage, and that it would be clearer to consolidate the > algorithms into a single document. > > It is true that if we do not have more than the two required > independent > interoperable implementations for some of the various algorithms, we > will need to drop those algorithms before we advance this document to > Draft Standard. It is a relatively common occurance the IETF to drop > optional-to-implement portions of a standard, if there aren't the > requisite number of interoperable implementations of that part of the > standard. Indeed, one could call that valuable implementation > experience --- if we find out that part of the standard is not being > implemented, that we can take it out when we advance the document. > > > (4) The document does not meet the WG doc-roadmap > requirements, which > have been through last call. > > The Document Roadmap does in fact reference the draft-ietf-cipb-cbc > document; again, it was originally the intent the IPSEC wg to advance > this document. The fact that it was not advanced with the other IPSEC > documents was purely an administrative oversight on my part, and I > apologize for that. > > (5) Some of the ciphers are "standardized" for 40 bits. The formal > position of the IETF, after considerable debate, and > acclaimation at > an open IESG plenary, has been that this is unacceptable! > > In fact, if you read draft-ietf-ipsec-cipg-cbc-03.txt, you will find > that the document specifies a default key size of 128 bits for all > ciphers except for 3DES, which as a key size of 192 bits. > > (6) This document is derivative from my own text without sufficient > attribution. Figures and quotations are plagiarized, from > draft-simpson-cbc-01.txt and > draft-simpson-des3v2-03.txt (or earlier > versions thereof). > > To quote from the Acknowledgements section: > > >This document is a merger of most of the ESP cipher algorithm > >documents. This merger was done to facilitate greater > >understanding of the commonality of all of the ESP algorithms and > >to further the development of these algorithm within ESP. > > > >.... > > > >Thanks to all of the editors of the previous ESP 3DES documents; W. > >Simpson, N. Doraswamy, P. Metzger, and P. Karn. > > I'm not sure what you mean by "quotations", since there aren't any > quotations in draft-ietf-ciph-cbc-03.txt. Perhaps you mean > bibliographic citations, such as where we cite [FIPS-46] and > [Tuchman79]? > > As far as figures are concerned, there is a single figure > depicting the > DES-EDE3-CBC algorithm on page 8 which appears to have originated from > your 3DES document. If the above text in the Acknowledgements section > thanking the editors of the previous ESP 3DES documents is not > sufficient, please advise me as to what text you would prefer > to see in > the Acknowledgements section. > > - Ted > ------_=_NextPart_001_01BDE019.E5D93600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt

Thank you for the very good reply.  I was away = on vacation and missed all of the 'exitement'.  ;-)

> -----Original Message-----
> From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU]
> Sent: Wednesday, September 09, 1998 6:59 = PM
> To: William Allen Simpson
> Cc: ietf@ietf.org; ipsec@tis.com
> Subject: Re: I-D = ACTION:draft-ietf-ipsec-ciph-cbc-03.txt
>
>
>    Date: Wed, 9 Sep 98 19:11:01 = GMT
>    From: "William Allen = Simpson" <wsimpson@greendragon.com>
>
>    I was horrified to see this = posting today, and this
> message is a formal
>    protest against this document = being advanced:
>
>    >  Title   =       : The ESP CBC-Mode Cipher = Algorithms
>    >  = Author(s)       : R. Pereira, R. = Adams
>
>    Gentlefolk, it cannot = "reflect comments", as this document
> has not been
>    through any "last = call".  Even the WG chose not to advance
> it during the
>    internal last call.  It = was deliberately _omitted_ from
> the IESG IPSec
>    last call.
>
> It was omitted from the IPSEC last call due to = an oversight; which was
> only caught by the RFC Editor.  As the = other documents, in particular
> the DOI document, contain normative references = to this
> document, we need
> to advance this document before the other IPSEC = documents can be
> advanced.
>
> When I was notified of this last week, I = consulted with Jeff Schiller
> and Bob Moskowitz, and we agreed that the most = efficient way to deal
> with this oversight, while staying within the = bounds of our standards
> process, was for me to send out a note = explaining this
> situation to the
> IPSEC working group.  There, we gave = notice of our intention
> to advance
> this document to IETF Last Call the following = week, and if
> folks had any
> issues with this, to please comment on the = IPSEC list ASAP. 
> (Note that
> an internal WG last call is not required by our = processes before IETF
> last call, but we did want to give the working = group time to make any
> last-minute comments.)
>
> As it turns out, the Roy Pereira, the document = editor, had
> some changes
> batched up that clarified the document, and = that so this was the -03
> version of the document was sent to the = Secretariat this
> week, and whose
> announcement apparently caused you great = horror.
>
> Today, I formally asked Jeff Schiller to put = this document out for the
> two-week IETF Last Call, which should get sent = out tomorrow.
>
> = -----------------------------------------------
>
> As to your specific issues with the documents, = let me address them one
> by one.  Any further discussion on these = points would probably be more
> appropriate on the IPSEC working group list, so = I have set
> the Reply-to:
> field on this message to ipsec@tis.com.  = (Any folks who are not on the
> IPSEC mailing list and who are interested are = very much
> welcome to send
> mail to ipsec-request@tis.com to get added to = the IPSEC mailing list.)
>
>
>    (1) If there is a need for a = "normative" CBC mode
> description, this is
>        = already available as draft-simpson-cbc-01.txt, which
> has long been
>        = awaiting publication as Informational (no last call is needed).
>
> This document is a matched set with the DOI = document, and contains
> details of the default key sizes, weak key = checks, etc. needed for the
> various algorithms specified in the DOI.  = (The DOI document contains a
> listing of which algorithms are mandatory and = which are optional; this
> document contains the details of how those = algorithms are to be used
> with ESP.)
>
>    (2) Including multiple = ciphers in the document makes it
> difficult or
>        = impossible to advance.  We have often had this problem
> with "kitchen
>        = sink" options documents in other WGs.
>
>    (3) Several of the ciphers = are proprietary, and are not
> likely to be
>        = universally implemented, again making it impossible to advance.
>
> Indeed, originally we had separate documents = for each of the cipher
> algorithms.  It was the decision of the = IPSEC working group
> that having
> five or six documents of which 90% of the text = was
> boilerplate, and only
> a minor portion of the text was specific to an = encryption
> algorithm was
> hard to manage, and that it would be clearer to = consolidate the
> algorithms into a single document.
>
> It is true that if we do not have more than the = two required
> independent
> interoperable implementations for some of the = various algorithms, we
> will need to drop those algorithms before we = advance this document to
> Draft Standard.  It is a relatively common = occurance the IETF to drop
> optional-to-implement portions of a standard, = if there aren't the
> requisite number of interoperable = implementations of that part of the
> standard.  Indeed, one could call that = valuable implementation
> experience --- if we find out that part of the = standard is not being
> implemented, that we can take it out when we = advance the document.
>
>
>    (4) The document does not = meet the WG doc-roadmap
> requirements, which
>        have = been through last call.
>
> The Document Roadmap does in fact reference the = draft-ietf-cipb-cbc
> document; again, it was originally the intent = the IPSEC wg to advance
> this document.  The fact that it was not = advanced with the other IPSEC
> documents was purely an administrative = oversight on my part, and I
> apologize for that.
>
>    (5) Some of the ciphers are = "standardized" for 40 bits.  The formal
>        = position of the IETF, after considerable debate, and
> acclaimation at
>        an = open IESG plenary, has been that this is unacceptable!
>
> In fact, if you read = draft-ietf-ipsec-cipg-cbc-03.txt, you will find
> that the document specifies a default key size = of 128 bits for all
> ciphers except for 3DES, which as a key size of = 192 bits. 
>
>    (6) This document is = derivative from my own text without sufficient
>        = attribution.  Figures and quotations are plagiarized, from
>        = draft-simpson-cbc-01.txt and
> draft-simpson-des3v2-03.txt (or earlier
>        = versions thereof).
>
> To quote from the Acknowledgements = section:
>
> >This document is a merger of most of the = ESP cipher algorithm
> >documents.  This merger was done to = facilitate greater
> >understanding of the commonality of all of = the ESP algorithms and
> >to further the development of these = algorithm within ESP.
> >
> >....
> >
> >Thanks to all of the editors of the = previous ESP 3DES documents; W.
> >Simpson, N. Doraswamy, P. Metzger, and P. = Karn.
>
> I'm not sure what you mean by = "quotations", since there aren't any
> quotations in draft-ietf-ciph-cbc-03.txt.  = Perhaps you mean
> bibliographic citations, such as where we cite = [FIPS-46] and
> [Tuchman79]?
>
> As far as figures are concerned, there is a = single figure
> depicting the
> DES-EDE3-CBC algorithm on page 8 which appears = to have originated from
> your 3DES document.  If the above text in = the Acknowledgements section
> thanking the editors of the previous ESP 3DES = documents is not
> sufficient, please advise me as to what text = you would prefer
> to see in
> the Acknowledgements section.
>
>       =               =           - Ted

>

------_=_NextPart_001_01BDE019.E5D93600-- From owner-ipsec Mon Sep 14 17:13:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08139 for ipsec-outgoing; Mon, 14 Sep 1998 17:11:33 -0400 (EDT) Date: Mon, 14 Sep 1998 17:29:15 -0400 (EDT) Message-Id: <199809142129.RAA01991@pong.morningstar.com> From: leonard_samuelson@ascend.com (Len Samuelson) To: ipsec@tis.com Subject: Re: null encryption In-Reply-To: <199809141759.NAA11934@jekyll.piermont.com> References: <13821.21552.733709.344694@lohi.eng.telia.fi> <199809141759.NAA11934@jekyll.piermont.com> Reply-To: leonard_samuelson@ascend.com (Len Samuelson) Sender: owner-ipsec@ex.tis.com Precedence: bulk Perry E. Metzger writes: > > Juha Heinanen writes: > > Perry E. Metzger writes: > > > > > > further, where is gre standardized? > > > > > > RFC's 1701 & 1702 > > > > This memo does not specify an Internet standard of any kind. > > IPSec is not a standard, either. Just a proposed standard. > > GRE is very widely deployed at the moment. > > Perry Many vendors have placed a high priority on verifying that their IPsec packages interoperate with their peers' systems. I do not know of similar efforts being applied to GRE. Other tunneling protocols that *use* GRE are being implemented, but that's not the same thing. I was not surprised to see a suggestion to use null transforms in IPsec as a "well known", "widely available" tunneling solution. An obvious bonus is that it's trivial to add high quality protection services to such a solution should the necessity arise. -- Leonard Samuelson, Ascend Communications, Inc. 614-760-4024 NOTE: These are my *opinions*, and as such, obviously do not represent the views of my employer. From owner-ipsec Mon Sep 14 17:47:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08234 for ipsec-outgoing; Mon, 14 Sep 1998 17:47:34 -0400 (EDT) Date: Mon, 14 Sep 1998 18:08:54 -0700 (PDT) From: "Hilarie K. Orman" Message-Id: <199809150108.SAA01333@earth.hpc.org> To: dharkins@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199809111748.KAA09458@dharkins-ss20.cisco.com> Subject: Re: issues with IKE that need resolution Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'm compiling a list of issues with IKE that need addressing. Once > the RFCs come out of the shoot I understand IKE will again be open > for edits. To that end, here are the issues I've received. Could you include the issues that Catherine Meadows and I have discussed with you and posted on the mailing lists re Quick Mode? Since posting my note last week I've learned of more implementations that do not use pseudrandom MessageID's, yet these are crucial to security. Hilarie From owner-ipsec Mon Sep 14 18:24:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA08305 for ipsec-outgoing; Mon, 14 Sep 1998 18:23:38 -0400 (EDT) Date: Mon, 14 Sep 1998 18:40:07 -0400 (EDT) From: Henry Spencer To: Juha Heinanen cc: ipsec@tis.com Subject: Re: null encryption In-Reply-To: <199809141759.NAA11934@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > RFC's 1701 & 1702 > > This memo does not specify an Internet standard of any kind. > > IPSec is not a standard, either. Just a proposed standard. RFC 2003 tunnelling is a Proposed Standard, if that's deemed important. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Mon Sep 14 19:46:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08496 for ipsec-outgoing; Mon, 14 Sep 1998 19:45:35 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Henry Spencer , Juha Heinanen Cc: ipsec@tis.com Subject: RE: null encryption Date: Mon, 14 Sep 1998 17:02:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Henry, > > i don't know if the authors of the null encryption i-d have > thought so, > > but ipsec can be used as a generic tunneling mechanism > alternative to > > l2tp and in that application neither strong autentication > nor encryption > > is always be desirable. > > RFC 2003 defined a generic tunnelling mechanism two years > ago; there is no > need to misapply IPSEC for this. As used with VPNs, there are a lot of requirements for a generic tunneling protocol, over and above the need to encapsulate data packets. For example to reduce the configuration burden of setting up lots of tunnels, a signalling protocol that allows the establishment and negotiation of tunnel attributes is very useful. IPSEC (IKE) and L2TP have such a signalling protocol. GRE and IP/IP (RFC2003) do not. Also a multiplexing field that allows multiple tunnels to be set up between the same two endpoints is very useful (to support different VPNs for example). Again IPSEC (via the SPI field) and L2TP (via the tunnel-id, call-id fields) have such a multiplexing field, but GRE and IP/IP do not. The ability to send opaque and multiprotocol frames across an IP backbone is also not addressed by IP/IP. It is somewhat difficult to discuss particular modifications and mechanisms in isolation (such as why a null encryption and null authentication mode for IPSEC may be useful) without a broader framework which indicates the problems that need to be solved, and looks at the trade-offs involved in adapting different existing protocols (such as IPSEC, L2TP, MPLS, GRE and IP/IP) to solve these problems. To this end we are currently working on a VPN Framework Draft, which will be ready shortly, at which time I'll send notification to the list for those interested. Bryan Gleeson Shasta Networks. From owner-ipsec Mon Sep 14 21:05:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA08756 for ipsec-outgoing; Mon, 14 Sep 1998 21:04:34 -0400 (EDT) Message-ID: <35FDBE52.9EB19810@ire-ma.com> Date: Mon, 14 Sep 1998 21:09:39 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Daniel Harkins CC: "ipsec@tis.com" Subject: Re: issues with IKE that need resolution References: <199809150108.SAA01333@earth.hpc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I think that the "stale" SA issue deserves some resolution as well - and that is - how a just re-booted IPsec network element should react upon receiving an IPsec traffic originated from previously established but no longer existing IPsec connection? I think many existing implementations initiate MM in this situation, but I don't think it is a "good" practice, on the other hand sending DELETEs to the other end is not required and delivery is not guranteed, but on the other hand how do you gracefully re-engage with the other end, which has no clue what happened........ Slava Kavsan IRE From owner-ipsec Tue Sep 15 02:12:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA09355 for ipsec-outgoing; Tue, 15 Sep 1998 02:10:35 -0400 (EDT) Message-ID: <3C3175FCC945D211B65100805F158089C2E055@RED-MSG-07> From: William Dixon To: "'ipsec@tis.com'" Subject: Redmond Bakeoff Summary Report (long) Date: Mon, 14 Sep 1998 23:28:17 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk Attached is an HTML page containing my summary report for the bakeoff. I apologize for the delay and appreciate your patience. Wm William Dixon, 425-703-8729, wdixon@microsoft.com Program Manager, Internet Protocol Security PBS Windows Networking & Communications Microsoft Corporation <> begin 600 IPSec-Interoperability-Workshop-Summary-4sep98.htm M/$A434P^#0H\2$5!1#X-"CQ-151!($A45%`M15%5258](D-O;G1E;G0M5'EP M92(@0T].5$5.5#TB=&5X="]H=&UL.R!C:&%R&5N="]287!T;W(L($-I2P@36EC#H@:&%D(#0S(&]P=&EO M;G,@*B`H=')A;G-P;W)T("L@='5N;F5L*2`J("AI;FET:6%L("L@65RDG,@9')A9G0@ M25!396,@8V5R=&EF:6-A=&4@<')O9FEL93PO4#X-"CQ0/DE04V5C(%)E:V5Y M:6YG($ES'0\+U`^#0H\4#Y0;W=E'0\+U`^#0H\4#Y-:6-R M;W-O9G0@1&ER96-T;W)Y($5N86)L960@3F5T=V]R:VEN9R!0;W=E2!3=&5V92!*=61D/"]0/@T*/%`^36EC65D(#@@8V]M<&%N:65S('=I=&@@=&AE M(&9O;&QO=VEN9R!Q=65S=&EO;G,L('-A>6EN9R!T:&%T($D@=V]U;&0@8V]M M<&EL92!A(&QI2!I M;F1I8V%T:6YG(&EN('!A71E2!P87EL;V%D(&]F(&-E2!)1',@9'5R:6YG M(%%-('=H96X@;F5G;W1I871I;F<@=')A;G-P;W)T(&UO9&4L('=E('=O=6QD M(&9A:6PN($UO2X\+U`^#0H\4#Y)9B!W92!D:60@;F]T(')E8V5I=F4@ M=&AE(&5N8V%P2!H M96%D97(@;&5N9W1H('1O(#0@8GET92!B;W5N9&%R:65S/"]0/@T*/%`^0G5G M(&9O=6YD(&EN('1E2!S=7!P;W)T960@8GD@2&E&;BP@0T$@=F5N M9&]R2!M96-H86YI M2!D97-I9VX\+U`^#0H\ M4#Y7:&5N('1U;FYE;&EN9R!T2!V M96YD;W)S(&EN(&9A=F]R(&]F(&%G9W)E2X@(%=H96X@:6YI=&EA=&]R('-H;W5L9"!P M7!E+W!O2!C'!R97-S960@:6X@<&]L:6-Y+"!N96=O=&EA=&5D+"!O2!F;W(@875T:&5N M=&EC871I;VX@=VAE;B!B;W1H('-Y2!P'!O2!D:7-T7-T M96US(&%R92!T86ME;B!U<"]D;W=N+"!A9&1R97-S(&-H86YG97,L(&5T8RX\ M+U`^#0H\4#Y":6=G97-T(&-H86QL96YG92!I7!T960@;F]N8V5S/"]0/@T*/%`^16YF;W)C:6YG(&-H96-K('1H M870@=')A9F9I8R!S96YT('1HF4L(&=O;V0@=V]R:VEN9R!T:6UE("@T*3PO4#X-"CQ0/D]R9V%N:7IE9"!W M96QL("@R*3PO4#X-"CQ0/E!R;W9I9&EN9R!00W,L(&-A8FQE2!#4DQS+"!D:69F97)E;G0@8V5R M=',\+U`^#0H\4#Y0;&5N='D@;V8@2!T97-T:6YG/"]0/@T*/%`^)FYB2!N965D(#0M-2!C;&%S2!M M;W)N:6YG("@R*3PO4#X-"CQ0/DEN=&5R;F5T(&%C8V5S2!S;&]W("@R*3PO4#X-"CQ0/D1I9&Z2="!S965M('1H M870@86YY;VYE(#Q)/F-O=6QD/"])/B!C;W9E6]N M92!S=&EL;"!P:6YG('1E2!T97-T960L(&UO2!V96YD;W(G7-T96US('=O=6QD(&YO="!I;G1E2!I;B!)4%-E8R!%4U`L($%(('5N9&5R(&QO M860@*#(I/"]0/@T*/%`^4V5A="!V96YD;W)S('1O9V5T:&5R('=H;R!M;W)E M(&%D=F%N8V5D(&EN('1H96ER($E04T5#+TE+12!I;7!L96UE;G1A=&EO;G,N M($]T:&5R=VES92!I="!W:6QL(&)E(&XM6"UN('1E3PO4#X-"CQ0/DAA=F4@8F%K96]F9B!A="!T:&4@2P@:6X@:&]T96P\+U`^#0H\4#Y!='1A8VL@ M=&5S=&EN9SPO4#X-"@T*/%`^16YD(&]F(%)E<&]R=#PO4#X-"@T*/%`^)FYB @ From: Stephen Waters To: Bryan Gleeson Cc: ipsec@tis.com Subject: RE: null encryption Date: Tue, 15 Sep 1998 09:35:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk It would be very useful to get an agreement on 'what the VPN problem is', I agree. I consider IPSEC as 'just security'. Transport-mode protection is clearly not a tunnel and tunnel-mode is poorly named - I think. 'Tunnel-mode' is more like 'encapsulation-mode' - If you've encrypted the original header, some other address header needs to be applied. Originally, IPSEC negotiated just authentication and encryption parameters and now covers compression as well - can be it be expanded further? As things stand, I think the only approach we have (our implementation) is to use L2TP with IPSEC protection (L2TP does the tunnel, IPSEC protects with transport mode). I know other folk have various IP-tunnel things that 'just work' over IPSEC - presumably in Transport mode. I suspect the answer is a hybrid of L2TP (voluntary model) and the various IP/IP tunnels. As a pet interest, I'd like to see some time spent of 'VPN tunnel quality monitoring'. Steve. -----Original Message----- From: Bryan Gleeson [mailto:BGleeson@shastanets.com] Sent: Tuesday, September 15, 1998 1:03 AM To: Henry Spencer; Juha Heinanen Cc: ipsec@tis.com Subject: RE: null encryption Henry, > > i don't know if the authors of the null encryption i-d have > thought so, > > but ipsec can be used as a generic tunneling mechanism > alternative to > > l2tp and in that application neither strong autentication > nor encryption > > is always be desirable. > > RFC 2003 defined a generic tunnelling mechanism two years > ago; there is no > need to misapply IPSEC for this. As used with VPNs, there are a lot of requirements for a generic tunneling protocol, over and above the need to encapsulate data packets. For example to reduce the configuration burden of setting up lots of tunnels, a signalling protocol that allows the establishment and negotiation of tunnel attributes is very useful. IPSEC (IKE) and L2TP have such a signalling protocol. GRE and IP/IP (RFC2003) do not. Also a multiplexing field that allows multiple tunnels to be set up between the same two endpoints is very useful (to support different VPNs for example). Again IPSEC (via the SPI field) and L2TP (via the tunnel-id, call-id fields) have such a multiplexing field, but GRE and IP/IP do not. The ability to send opaque and multiprotocol frames across an IP backbone is also not addressed by IP/IP. It is somewhat difficult to discuss particular modifications and mechanisms in isolation (such as why a null encryption and null authentication mode for IPSEC may be useful) without a broader framework which indicates the problems that need to be solved, and looks at the trade-offs involved in adapting different existing protocols (such as IPSEC, L2TP, MPLS, GRE and IP/IP) to solve these problems. To this end we are currently working on a VPN Framework Draft, which will be ready shortly, at which time I'll send notification to the list for those interested. Bryan Gleeson Shasta Networks. From owner-ipsec Tue Sep 15 09:04:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10767 for ipsec-outgoing; Tue, 15 Sep 1998 09:03:34 -0400 (EDT) Message-Id: <199809151219.IAA22887@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 15 Sep 1998 09:16:24 -0400 To: briansw@microsoft.com, kivenen@ssh.fi From: Rodney Thayer Subject: cert request payload proposal Cc: rodney@tillerman.nu, dharkins@cisco.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In talking to Dan Harkins about Cert Request payloads, I thought of something that might satisfy a few requirements, including comments from you two. How about something like this... Proposal to extend IKE Cert Request Payload Format ================================================== Rodney Thayer Currently the Cert Request payload has by tradition contained either NOTHING or a DN of an Issuer. I propose to document and extend this: If the contents of the Cert Request payload is EMPTY then the receiver is to respond with any valid certificate. If the contents of the Cert Request payload is not empty, it should contain this: first byte 0x30 -- entire contents is Distinguished Name of an issuer (for backwards compatibility) first byte 0x00 -- remainder is one DN of one issuer first byte 0x01 -- list of hashes of public keys of issuers the sender is willing to work with (do I have to do this once for RSA and once for DSA?): first byte - 0x01 second, third bytes - count (network order) of hashes fourth..last bytes - SHA-1 hashes of public keys, 20*(count) bytes total, max is UDP max size first byte 0x02 -- remainder is PKCS-7 wrapped list of certs of issuers, RFC23xx format for PKCS-7 wrapped list of certificates first byte 0x80..0x2f, 0x31..0xff -- reserved for private use first byte 0x03..0x7f -- reserved for IANA From owner-ipsec Tue Sep 15 09:04:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10758 for ipsec-outgoing; Tue, 15 Sep 1998 09:02:33 -0400 (EDT) Date: Mon, 14 Sep 1998 22:46:36 -0400 (EDT) From: "H.Krawczyk" To: Daniel Harkins Cc: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-Reply-To: <199809111748.KAA09458@dharkins-ss20.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I would very much like to see a recommendation (e.g. in the security considerations section) about using the OAEP mode now supported by PKCS. See the attached note that I sent a while ago. Hugo From hugo@ee.technion.ac.il Mon Sep 14 22:41:05 1998 Date: Tue, 18 Aug 1998 18:30:58 +0300 (IDT) From: Hugo Krawczyk To: ipsec@tis.com Subject: encryption mode and CCA attacks Now that I am into IKE stuff: There is one issue that I wanted to raise for long time for those implementing the encryption mode(s). If you read our internet-draft draft-ietf-ipsec-dhless-enc-mode-00.txt you'll see the following pargraph in the security considerations: The public key encryption modes of authentication in IKE require strong public key encryption. In particular, resistance to strong attacks generally known as "chosen ciphertext attacks" (CCA) is necessary. This is a practical need as well as the basis for a sound analysis of these protocols [BeCaKr]. Recently, an explicit chosen ciphertext attack on the PKCS #1 encryption standard was demonstrated [Ble]. RSA Labs., the authors of PKCS#1, are preparing a new release of PKCS #1 that will include the OAEP format of RSA encryption [RSAlabs]. It is strongly recommended that IKE specifications and implementations move to that format which was designed to resist CCA and other attacks. This recommendation should be followed by the implementers of the current IKE encryption modes that use PKCS RSA encryption (and not only by those interested in a DH-less mode as proposed in the mentioned draft). Hugo From owner-ipsec Tue Sep 15 10:10:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10992 for ipsec-outgoing; Tue, 15 Sep 1998 10:08:37 -0400 (EDT) Message-Id: <199809151426.KAA21795@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wallner-key-arch-01.txt Date: Tue, 15 Sep 1998 10:26:07 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Key Management for Multicast: Issues and Architectures Author(s) : D. Wallner, E. Harder, R. Agee Filename : draft-wallner-key-arch-01.txt Pages : 16 Date : 14-Sep-98 This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wallner-key-arch-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-wallner-key-arch-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-wallner-key-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980914151019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wallner-key-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-wallner-key-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980914151019.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Sep 15 12:38:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11514 for ipsec-outgoing; Tue, 15 Sep 1998 12:32:51 -0400 (EDT) Message-Id: <199809151649.LAA24702@gungnir.fnal.gov> To: "'ipsec@tis.com'" From: "Matt Crawford" Subject: Re: Redmond Bakeoff Summary Report (long) In-reply-to: Your message of Mon, 14 Sep 1998 23:28:17 PDT. <3C3175FCC945D211B65100805F158089C2E055@RED-MSG-07> Date: Tue, 15 Sep 1998 11:49:59 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk Mr. Chairman, I move that the house consider censure of the gentleman from Redmond on the grounds of blatant disregard for established standards. His email had an invalid message-id (no FQDN). His email contained an inline uuencoded file instead of using MIME. The decoded HTML file uses an unregistered character set "windows-1252". (Character sets called windows-1250, windows-1251, and windws-1253 through windows-1258 have been registered with the IANA, but not a windows-1252.) The body of the HTML file mocks the purpose of HTML by using explicit size and font changes instead of structured header tags, and sequences of one-line paragraphs instead of lists. From owner-ipsec Tue Sep 15 13:49:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11716 for ipsec-outgoing; Tue, 15 Sep 1998 13:46:59 -0400 (EDT) Message-ID: <3C3175FCC945D211B65100805F158089C2E06F@RED-MSG-07> From: William Dixon To: "'ipsec@tis.com'" Subject: Redmond Bakeoff Summary Report (long) - RTF format Date: Tue, 15 Sep 1998 11:04:43 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk IPSec Interoperability Workshop Aug 31st- Sept 3 1998 Summary Report Location: Microsoft Campus, Redmond WA Attending: 60 people, 19 companies. Axent/Raptor, Cisco IOS, Checkpoint, Intel, HiFn, Interlink, IRE, Microsoft NT5, Netscreen, Redcreek, SSH, Timestep, Worldcom/ANS, IRE, Free SWAN Verisign, Entrust, Worldcom Advanced Networks - James Matheke, Digital Signature Trust Company, Microsoft PKI & Directory reps L2TP/IPSec: Microsoft NT5 and Cisco IOS Handouts: (I will get these on a public web site ASAP. Stay tuned for pointer) Network Configuration Tear Sheet - network topology explanation & diagram Testing Matrix: had 43 options * (transport + tunnel) * (initial + rekey) = 172 tests. Rodney Thayer's draft IPSec certificate profile IPSec Rekeying Issues powerpoint slides, by Tim Jenkins of Timestep Working copy of Draft-ietf-ipsec-ldap-schema.txt Powerpoint slides presented at IETF Policy BOF explaining draft-ietf-ipsec-ldap-schema.txt Microsoft Directory Enabled Networking Powerpoint slides by Steve Judd Microsoft Public Key Infrastructure Powerpoint slides by Rick Johnson Windows NT5.0 Beta2 walkthrough guide for creating IPSec policy Debriefing Survey On Wed and Thursday, I surveyed 8 companies with the following questions, saying that I would compile a list of responses without indicating vendors and post the compiled report to the IETF IPSec mailing list. Here are the results. I have attempted to reduce duplication by indicating in parentheses how many of the respondants indicated a similar response, eg (4) means 4 out of 8 vendors. There is no priority or ordering on these listings, other than popular reponses appear first. What did you fix? Policy mgmt bugs. Modification on end-to-end policy configuration (3) Fragmentation on large packet (2) Vendor id payload support 3DES key generation Multiple MM proposals are not draft compliant Initial contact handling Additional padding that expands payload in IKE MM Construction of id payload of type ID FQDN and ID USER NAME during RSA Signatures Fixed the parsing of pulling out the SubjectAltName out of the cert. Problems handling multiple proposals Problems handling the payload when 2 lifetypes were being sent, for example seconds and bytes. Better understanding of what is in main mode Circular cert chain signature handling Draft change to support initial contact Make sure that if peer sends back invalid ids, that they do not overwrite the initiators ids Ignore empty cert request payload Wrong checksum in inner payload header. Other implementations were not checking Empty payload of cert caused AV Cert signed circular chain handling ISAKMP config mode- hashing incorrectly RSA encryption mode- not encrypting all that we should AH + ESP negotiated for tunnel mode Nothing If we didn't receive proxy IDs during QM when negotiating transport mode, we would fail. Most vendors don't send these. IOS and NT do this to support protocol and port based filters. We need to add a test case to do this regularly. If we did not receive the encapsulation attribute, we would send it back. Wrongly padding the Oakley header length to 4 byte boundaries Bug found in test tools Where and HOW to encode v3 extensions in PKCS10 requests. Mostly due to how old BCERT toolkits used to do it which is not what RSA actually spec'd. What did you not fix - what still needs to be worked on? PKI usage: Cert subject altname comparison with MM id payload, Certificate chain processing, CRL support, Cross-certification, DN in certs, Every (CA?) vendor had different cert request format (5) Using DSS/DSA - only supported by HiFn, CA vendors MS & Entrust & GTE (2) Fragmented TCP packets failing auth checks Need to send deletes for all of the SPIs when doing an AND proposal Initiating SAs Commit bit handling Rekey issues: Initiator switching to responder because original responder hit lifetime timeout first and visa-versa. Responder changing attributes in transform. The PKCS10 requests with v3 extensions. Currently MS puts then in a proprietary attribute (said they would change), the 'standard' attribute to put them in is the rsaExtensionsAttribute, however RSA BCERT and TIPEM toolkits add an extra level of encoding and encode the sequence of extension as a T61String which is NOT the documented format. The cure is to have CA vendors try to decode from both and have all new clients only do rsaExtensionsAttribute as Seq of Ext. What are the open IPSec design issues? PKI usage, cert formats, CA enrollment, deployment model for cert-based trust, supporting CRLs, supporting cert request payload (5) Peer Recovery, stale/Inactive SAs which linger when peer has lost state. Orphaned phase2 SA. This can be due to a missed delete (since deletes are not reliable) or a system crash of a peer (4) ISAKMP header not authenticated. Initial contact & all notifications are not authenticated (4) Commit bit. Since it is unauthenticated if it is present in the IKE header. Is it still a MUST? (2) Version#s not authenticated in IKE header Common policy configuration & distribution for multiple vendor devices that a single manager can use. Mobile clients - preshared key per user? Lose identity protection with aggressive mode Rekey mechanism that doesn't lose traffic by design When tunneling traffic, do you reassemble packet first, then filter, then forward to tunnel? Configuration problems, ISAKMP config needs further work Support in drafts for authentication method per selector conflicts with using MM with QM. Applications can't use their own trust system for their traffic - must be manually configured out-of-band between machines (IP addresses). This is why MM with QM protection is abandoned by vendors in favor of aggressive mode, so that QM parameters, and also identities, can be known first to succeed with authentication. Race conditions when have multiple SAs to same box from one source, rekeying MM over multiple QM Multiple QM proposals How to get tunnels set up Mismatch filters in policy. When initiator should propose both the full filter breadth, as well as the specific packet protocol type/ports to the responder, so the responder can pick the widest clean match. Need some kind of model for using SNMP MIB for reporting and management of IPSec enabled devices. Think IKE is open to denial of service attack because anyone can provoke DH computation in MM. Should only create state when get cookie back to reduce denial of service. IKE over non-IP Disagreement on how AH with ESP in transport or tunnel mode should be expressed in policy, negotiated, or have their separate SAs managed Need full client-side configuration to support simultaneous tunnels from one client to different gateways Need "Credential Request Payload" more general than just certificate request payload, to support retry for authentication when both systems participate in multiple trust models. What are the open IPSec interop issues? If products shipped today, what problems would customers encounter with multiple IPSec products? Policy expression, configuration for interop (5) Peer recovery of SAs, with mobile users, between two gateways (2) US export IPSec interop- no support at all in drafts for what products have to implement for ESP. Custom DH group for export not supported in drafts (2) Understanding why proposals failed- Error messages to detail why proposal not chosen (Michael Richardson going to collect error codes & messages from vendors) Multiple proposals for export not supported Policy distribution Client interop because clients haven't been tested much, mostly GW/FW Real world application usage/admin, where systems are taken up/down, address changes, etc. Biggest challenge is to cover all aspects/combinations Hard to balance tolerance of variance among IPSec implementations which is necessary for interop with strictness of checks to fulfill security and draft requirements. Scalability Some/many vendors not installing SA parameters which were negotiated, using what filter policy specified. Cert encoding for CRP, most people understand X.509 Key usage flags in cert, what you expect to get back for generic or specific for data encryperment. Maybe define another type of cert field encoding, have 1-9, need 10. How to process Subject Altname Nobody else is doing encrypted nonces Enforcing check that traffic sent through IPSec format matches filter which was negotiated. This must be agreed upon by other vendors. Not covering this in bakeoff testing because people mostly ping and ftp test, not multi-protocol or multi-port through same SA. Having certificate storage and key signing operations on smartcards, where they don't provide a signature without the OID What was good about the bakeoff? Small size, good working time (4) Organized well (2) Providing PCs, cables (2) Beer (2) Having a preplanned test matrix Having several CA vendors, ability to discuss and try CRLs, different certs Plenty of space, good friendly atmosphere. Microsoft people being very helpful Timing was good The network was setup when we got there. More than one network allocated for each vendor to allow gateway testing What wasn't so good about bakeoff? Had to reconfigure because test net was not on Internet which for many caused a reboot. Only really need 4-5 class C addresses with preplanned private net space. Should have DHCP on external net. NAT from private to public wouldn't work using IPSec, of course, because using IPSec to get back home to company net. (3) Power failure Monday morning (2) Internet access via ISDN 128Kb was very slow (2) Didn't seem that anyone could cover the test matrix with another vendor even 50%. Everyone still ping testing, not real traffic, limited ftp transfers for those who tried rekeying No T-shirts Clients were not really tested, mostly vendor's gateway/Firewall products. Not testing CRLs, not testing cert expirations Hard to understand why two systems would not interoperate Need phones at each station Network addressing plan was hard to read and understand what is needed. Need picture of topology. Impossible to design comprehensive test matrix, don't have time in a bakeoff to test all of these No time to get into real situation test Test matrix too confusing. Rather see list of topologies with spec of "to reach my network do this MM proposal and these different policies for telnet and http" For next bakeoff at IBM, what should be done? Test rekey in each direction under stress (4). Use FTP for this. Huge payload to test fragmentation & reassembly in IPSec ESP, AH under load (2) Seat vendors together who more advanced in their IPSEC/IKE implementations. Otherwise it will be n-X-n testing matrix which is impossible with 60 vendors present. Post test matrix to the IPSec list before the event to get comments on it's completeness Make sure real world topology is tested: static IP client -> GW -- internal net -- servers on PCs ICSA should say more about rekeying issues, or allow vendors out of their NDA signed during certification testing to discuss rekeying issues Not relying on non-mandatory messages Peer recovery testing Negotiating and maintaining many SAs Need next NT5.0 post-beta2 release to test with Need denial of service and IPSec knowlegable attack tests Need a complete implementation of all IPSec capabilities to test against, Need an attacker box to test against All CA vendors should support Subject Altname Need telephone at desk Need vendors capabilities listed and what they want to test in advance Test nested tunnels Test transport over tunnel mode Test random IP addresses to simulate mobility Have bakeoff at the same place where you stay, in hotel Attack testing End of Report From owner-ipsec Tue Sep 15 13:55:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11764 for ipsec-outgoing; Tue, 15 Sep 1998 13:54:55 -0400 (EDT) Message-ID: <3C3175FCC945D211B65100805F158089C2E070@RED-MSG-07> From: William Dixon To: "'ipsec@tis.com'" Subject: Redmond Bakeoff Summary Report (long) - TXT Date: Tue, 15 Sep 1998 11:12:02 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk IPSec Interoperability Workshop Aug 31st- Sept 3 1998 Summary Report Location: Microsoft Campus, Redmond WA Attending: 60 people, 19 companies. Axent/Raptor, Cisco IOS, Checkpoint, Intel, HiFn, Interlink, IRE, Microsoft NT5, Netscreen, Redcreek, SSH, Timestep, Worldcom/ANS, IRE, Free SWAN Verisign, Entrust, Worldcom Advanced Networks - James Matheke, Digital Signature Trust Company, Microsoft PKI & Directory reps L2TP/IPSec: Microsoft NT5 and Cisco IOS Handouts: (I will get these on a public web site ASAP. Stay tuned for pointer) Network Configuration Tear Sheet - network topology explanation & diagram Testing Matrix: had 43 options * (transport + tunnel) * (initial + rekey) = 172 tests. Rodney Thayer's draft IPSec certificate profile IPSec Rekeying Issues powerpoint slides, by Tim Jenkins of Timestep Working copy of Draft-ietf-ipsec-ldap-schema.txt Powerpoint slides presented at IETF Policy BOF explaining draft-ietf-ipsec-ldap-schema.txt Microsoft Directory Enabled Networking Powerpoint slides by Steve Judd Microsoft Public Key Infrastructure Powerpoint slides by Rick Johnson Windows NT5.0 Beta2 walkthrough guide for creating IPSec policy Debriefing Survey ================= On Wed and Thursday, I surveyed 8 companies with the following questions, saying that I would compile a list of responses without indicating vendors and post the compiled report to the IETF IPSec mailing list. Here are the results. I have attempted to reduce duplication by indicating in parentheses how many of the respondants indicated a similar response, eg (4) means 4 out of 8 vendors. There is no priority or ordering on these listings, other than popular reponses appear first. What did you fix? =========================================================== Policy mgmt bugs. Modification on end-to-end policy configuration (3) Fragmentation on large packet (2) Vendor id payload support 3DES key generation Multiple MM proposals are not draft compliant Initial contact handling Additional padding that expands payload in IKE MM Construction of id payload of type ID FQDN and ID USER NAME during RSA Signatures Fixed the parsing of pulling out the SubjectAltName out of the cert. Problems handling multiple proposals Problems handling the payload when 2 lifetypes were being sent, for example seconds and bytes. Better understanding of what is in main mode Circular cert chain signature handling Draft change to support initial contact Make sure that if peer sends back invalid ids, that they do not overwrite the initiators ids Ignore empty cert request payload Wrong checksum in inner payload header. Other implementations were not checking Empty payload of cert caused AV Cert signed circular chain handling ISAKMP config mode- hashing incorrectly RSA encryption mode- not encrypting all that we should AH + ESP negotiated for tunnel mode Nothing If we didn't receive proxy IDs during QM when negotiating transport mode, we would fail. Most vendors don't send these. IOS and NT do this to support protocol and port based filters. We need to add a test case to do this regularly. If we did not receive the encapsulation attribute, we would send it back. Wrongly padding the Oakley header length to 4 byte boundaries Bug found in test tools Where and HOW to encode v3 extensions in PKCS10 requests. Mostly due to how old BCERT toolkits used to do it which is not what RSA actually spec'd. What did you not fix - what still needs to be worked on? ========================================================= PKI usage: Cert subject altname comparison with MM id payload, Certificate chain processing, CRL support, Cross-certification, DN in certs, Every (CA?) vendor had different cert request format (5) Using DSS/DSA - only supported by HiFn, CA vendors MS & Entrust & GTE (2) Fragmented TCP packets failing auth checks Need to send deletes for all of the SPIs when doing an AND proposal Initiating SAs Commit bit handling Rekey issues: Initiator switching to responder because original responder hit lifetime timeout first and visa-versa. Responder changing attributes in transform. The PKCS10 requests with v3 extensions. Currently MS puts then in a proprietary attribute (said they would change), the 'standard' attribute to put them in is the rsaExtensionsAttribute, however RSA BCERT and TIPEM toolkits add an extra level of encoding and encode the sequence of extension as a T61String which is NOT the documented format. The cure is to have CA vendors try to decode from both and have all new clients only do rsaExtensionsAttribute as Seq of Ext. What are the open IPSec design issues? ======================================================== PKI usage, cert formats, CA enrollment, deployment model for cert-based trust, supporting CRLs, supporting cert request payload (5) Peer Recovery, stale/Inactive SAs which linger when peer has lost state. Orphaned phase2 SA. This can be due to a missed delete (since deletes are not reliable) or a system crash of a peer (4) ISAKMP header not authenticated. Initial contact & all notifications are not authenticated (4) Commit bit. Since it is unauthenticated if it is present in the IKE header. Is it still a MUST? (2) Version#s not authenticated in IKE header Common policy configuration & distribution for multiple vendor devices that a single manager can use. Mobile clients - preshared key per user? Lose identity protection with aggressive mode Rekey mechanism that doesn't lose traffic by design When tunneling traffic, do you reassemble packet first, then filter, then forward to tunnel? Configuration problems, ISAKMP config needs further work Support in drafts for authentication method per selector conflicts with using MM with QM. Applications can't use their own trust system for their traffic - must be manually configured out-of-band between machines (IP addresses). This is why MM with QM protection is abandoned by vendors in favor of aggressive mode, so that QM parameters, and also identities, can be known first to succeed with authentication. Race conditions when have multiple SAs to same box from one source, rekeying MM over multiple QM Multiple QM proposals How to get tunnels set up Mismatch filters in policy. When initiator should propose both the full filter breadth, as well as the specific packet protocol type/ports to the responder, so the responder can pick the widest clean match. Need some kind of model for using SNMP MIB for reporting and management of IPSec enabled devices. Think IKE is open to denial of service attack because anyone can provoke DH computation in MM. Should only create state when get cookie back to reduce denial of service. IKE over non-IP Disagreement on how AH with ESP in transport or tunnel mode should be expressed in policy, negotiated, or have their separate SAs managed Need full client-side configuration to support simultaneous tunnels from one client to different gateways Need "Credential Request Payload" more general than just certificate request payload, to support retry for authentication when both systems participate in multiple trust models. What are the open IPSec interop issues? If products shipped today, what problems would customers encounter with multiple IPSec products? ================================================================ Policy expression, configuration for interop (5) Peer recovery of SAs, with mobile users, between two gateways (2) US export IPSec interop- no support at all in drafts for what products have to implement for ESP. Custom DH group for export not supported in drafts (2) Understanding why proposals failed- Error messages to detail why proposal not chosen (Michael Richardson going to collect error codes & messages from vendors) Multiple proposals for export not supported Policy distribution Client interop because clients haven't been tested much, mostly GW/FW Real world application usage/admin, where systems are taken up/down, address changes, etc. Biggest challenge is to cover all aspects/combinations Hard to balance tolerance of variance among IPSec implementations which is necessary for interop with strictness of checks to fulfill security and draft requirements. Scalability Some/many vendors not installing SA parameters which were negotiated, using what filter policy specified. Cert encoding for CRP, most people understand X.509 Key usage flags in cert, what you expect to get back for generic or specific for data encryperment. Maybe define another type of cert field encoding, have 1-9, need 10. How to process Subject Altname Nobody else is doing encrypted nonces Enforcing check that traffic sent through IPSec format matches filter which was negotiated. This must be agreed upon by other vendors. Not covering this in bakeoff testing because people mostly ping and ftp test, not multi-protocol or multi-port through same SA. Having certificate storage and key signing operations on smartcards, where they don't provide a signature without the OID What was good about the bakeoff? ========================================================= Small size, good working time (4) Organized well (2) Providing PCs, cables (2) Beer (2) Having a preplanned test matrix Having several CA vendors, ability to discuss and try CRLs, different certs Plenty of space, good friendly atmosphere. Microsoft people being very helpful Timing was good The network was setup when we got there. More than one network allocated for each vendor to allow gateway testing What wasn't so good about bakeoff? ======================================================== Had to reconfigure because test net was not on Internet which for many caused a reboot. Only really need 4-5 class C addresses with preplanned private net space. Should have DHCP on external net. NAT from private to public wouldn't work using IPSec, of course, because using IPSec to get back home to company net. (3) Power failure Monday morning (2) Internet access via ISDN 128Kb was very slow (2) Didn't seem that anyone could cover the test matrix with another vendor even 50%. Everyone still ping testing, not real traffic, limited ftp transfers for those who tried rekeying No T-shirts Clients were not really tested, mostly vendor's gateway/Firewall products. Not testing CRLs, not testing cert expirations Hard to understand why two systems would not interoperate Need phones at each station Network addressing plan was hard to read and understand what is needed. Need picture of topology. Impossible to design comprehensive test matrix, don't have time in a bakeoff to test all of these No time to get into real situation test Test matrix too confusing. Rather see list of topologies with spec of "to reach my network do this MM proposal and these different policies for telnet and http" For next bakeoff at IBM, what should be done? ======================================================== Test rekey in each direction under stress (4). Use FTP for this. Huge payload to test fragmentation & reassembly in IPSec ESP, AH under load (2) Seat vendors together who more advanced in their IPSEC/IKE implementations. Otherwise it will be n-X-n testing matrix which is impossible with 60 vendors present. Post test matrix to the IPSec list before the event to get comments on it's completeness Make sure real world topology is tested: static IP client -> GW -- internal net -- servers on PCs ICSA should say more about rekeying issues, or allow vendors out of their NDA signed during certification testing to discuss rekeying issues Not relying on non-mandatory messages Peer recovery testing Negotiating and maintaining many SAs Need next NT5.0 post-beta2 release to test with Need denial of service and IPSec knowlegable attack tests Need a complete implementation of all IPSec capabilities to test against, Need an attacker box to test against All CA vendors should support Subject Altname Need telephone at desk Need vendors capabilities listed and what they want to test in advance Test nested tunnels Test transport over tunnel mode Test random IP addresses to simulate mobility Have bakeoff at the same place where you stay, in hotel Attack testing End of Report From owner-ipsec Tue Sep 15 15:31:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11943 for ipsec-outgoing; Tue, 15 Sep 1998 15:29:56 -0400 (EDT) Message-ID: <35FEC1FF.633C5CFF@ire-ma.com> Date: Tue, 15 Sep 1998 15:37:35 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <199809111748.KAA09458@dharkins-ss20.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Question to IPsec implementors: What is the "proper" behaviour of the IPsec implementation upon receiving an IPsec-transformed packet for which there is no IPsec SA, but there is an SPD entry and/or IKE SA for the IP address of the sender (or the associated IP Range or IP Subnet)? I couldn't find anything in the standards on this. - Should the packet be discarded? - Should it trigger MM (or QM) initiation? - may be good for some recovery cases , but bad for denial-of-service or other attacks. - Should the sending end be notified? I think this is an important interoperability issue. . -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Tue Sep 15 15:40:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11973 for ipsec-outgoing; Tue, 15 Sep 1998 15:39:55 -0400 (EDT) Message-Id: <199809151956.MAA12801@chip.cisco.com> To: Bronislav Kavsan cc: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Tue, 15 Sep 1998 15:37:35 EDT." <35FEC1FF.633C5CFF@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12799.905889415.1@cisco.com> Date: Tue, 15 Sep 1998 12:56:55 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Slava, Section 5.2.1 of draft-ietf-ipsec-arch-sec-07.txt states: Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error. Dan. On Tue, 15 Sep 1998 15:37:35 EDT you wrote > Question to IPsec implementors: > > What is the "proper" behaviour of the IPsec implementation upon receiving an > IPsec-transformed packet for which there is no IPsec SA, but there is an SPD > entry and/or IKE SA for the IP address of the sender (or the associated IP > Range or IP Subnet)? I couldn't find anything in the standards on this. > > - Should the packet be discarded? > - Should it trigger MM (or QM) initiation? - may be good for some recovery > cases , but bad for denial-of-service or other attacks. > - Should the sending end be notified? > > I think this is an important interoperability issue. > . > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com From owner-ipsec Tue Sep 15 16:01:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12046 for ipsec-outgoing; Tue, 15 Sep 1998 16:00:54 -0400 (EDT) Message-ID: <35FEC935.DF4AB143@ire-ma.com> Date: Tue, 15 Sep 1998 16:08:21 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <199809151956.MAA12801@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Thanks for pointing out this statement in the standard, but.....what will be the connection recovery logic for an IPsec Client, which rebooted in the middle of receiving IPsec traffic? If IPsec Client keeps silent - tt make take sender hours before figuring out what happened. Daniel Harkins wrote: > Slava, > > Section 5.2.1 of draft-ietf-ipsec-arch-sec-07.txt states: > > Use the packet's destination address (outer IP header), IPsec > protocol, and SPI to look up the SA in the SAD. If the SA > lookup fails, drop the packet and log/report the error. > > Dan. > > On Tue, 15 Sep 1998 15:37:35 EDT you wrote > > Question to IPsec implementors: > > > > What is the "proper" behaviour of the IPsec implementation upon receiving an > > IPsec-transformed packet for which there is no IPsec SA, but there is an SPD > > entry and/or IKE SA for the IP address of the sender (or the associated IP > > Range or IP Subnet)? I couldn't find anything in the standards on this. > > > > - Should the packet be discarded? > > - Should it trigger MM (or QM) initiation? - may be good for some recovery > > cases , but bad for denial-of-service or other attacks. > > - Should the sending end be notified? > > > > I think this is an important interoperability issue. > > . > > -- > > Bronislav Kavsan > > IRE Secure Solutions, Inc. > > 100 Conifer Hill Drive Suite 513 > > Danvers, MA 01923 > > voice: 978-739-2384 > > http://www.ire.com -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Tue Sep 15 16:09:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12100 for ipsec-outgoing; Tue, 15 Sep 1998 16:08:56 -0400 (EDT) Message-Id: <199809152026.NAA14560@chip.cisco.com> To: Bronislav Kavsan cc: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Tue, 15 Sep 1998 16:08:21 EDT." <35FEC935.DF4AB143@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14558.905891199.1@cisco.com> Date: Tue, 15 Sep 1998 13:26:40 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk There is no recovery logic in IPSec, I guess. This sounds like an IPSecond issue (and is also not really IKE-specific). Dan. On Tue, 15 Sep 1998 16:08:21 EDT you wrote > Dan, > > Thanks for pointing out this statement in the standard, but.....what will be >the > connection recovery logic for an IPsec Client, which rebooted in the middle o >f > receiving IPsec traffic? If IPsec Client keeps silent - tt make take sender h >ours > before figuring out what happened. > > Daniel Harkins wrote: > > > Slava, > > > > Section 5.2.1 of draft-ietf-ipsec-arch-sec-07.txt states: > > > > Use the packet's destination address (outer IP header), IPsec > > protocol, and SPI to look up the SA in the SAD. If the SA > > lookup fails, drop the packet and log/report the error. > > > > Dan. From owner-ipsec Tue Sep 15 21:20:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA13019 for ipsec-outgoing; Tue, 15 Sep 1998 21:18:57 -0400 (EDT) Date: Tue, 15 Sep 1998 21:35:46 -0400 (EDT) From: Henry Spencer To: Bronislav Kavsan cc: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-Reply-To: <35FEC1FF.633C5CFF@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > What is the "proper" behaviour of the IPsec implementation upon receiving an > IPsec-transformed packet for which there is no IPsec SA, but there is an SPD > entry and/or IKE SA for the IP address of the sender... > - Should the packet be discarded? > - Should it trigger MM (or QM) initiation? - may be good for some recovery > cases , but bad for denial-of-service or other attacks. > - Should the sending end be notified? I think the preferred answer is "yes". That is, the architecture document's basic recommendation "drop packet and report this" is right, but "report this" may well mean that other software hears about it and initiates action (negotiation or notification) depending on local policy. That said, there may be some issues here of interest to IPSECond. For example, if notification is desirable, how is it done? Do we need a new ICMP destination-unreachable subcode that means "SA Unreachable"? There is "Protocol Unreachable", but that's not really right. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Wed Sep 16 03:47:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA14198 for ipsec-outgoing; Wed, 16 Sep 1998 03:44:01 -0400 (EDT) Message-Id: <199809160753.LAA04502@relay2.elvis.ru> Comments: Authenticated sender is From: "Valery Smyslov" Organization: Elvis+ To: Daniel Harkins Date: Wed, 16 Sep 1998 11:53:08 +3 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Question about New Group mode CC: ipsec@tis.com X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Dan, I have a question regarding New Group mode. Is it possible for ISAKMP responder to initiate New Group mode after performing phase 1 negotiating? (Imagine two hosts, A and B; if local policy on host A dictates that it must use private DH group with host B, and host B initiated phase 1 not offering that group, what should host A do: wait in hope that host be B will sometime negotiate that group or try to do it by itself?). Draft doesn't explicitly prohibit this, it only states that New Group mode MUST only follow phase 1 (section 5.6). Regards, Valery Smyslov. From owner-ipsec Wed Sep 16 04:20:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA14281 for ipsec-outgoing; Wed, 16 Sep 1998 04:19:01 -0400 (EDT) From: Gabriel.Montenegro@Eng.Sun.Com Date: Wed, 16 Sep 1998 01:36:14 -0700 Message-Id: <199809160836.BAA08003@hsmpka.eng.sun.com> To: ipsec@tis.com Reply-To: gab@Eng.Sun.Com X-Mailer: Sun NetMail 2.1.6 Subject: ike source port (was: issues with IKE that need resolution) Sender: owner-ipsec@ex.tis.com Precedence: bulk The issue is: Is it ok for the source port for IKE to be something other than port 500? Hopefully it is ok, as this eases ipsec across NAT boxes, for example. I asked several ipsec-ers this question in Chicago, but there seems to be no clear answer. ISAKMP specifies that 500 must be supported on both source and destination. However, it does not say that 500 is the only port number possible. Allowing the source port to vary does not seem to have security implications, because source and destination ports are already included in the hash. What do most implementations do when they get an ike packet whose source port is not 500? Of course, the same question applies to the destination port, but at least in the soho scenario, an unconstrained source port is what's important (assuming the clients behind the "nat" box are the initiators of ike sessions with legacy ike responders out on the internet). Requiring source port to always be set to 500 means that the "nat/nar" box would have to have a pool of addresses to lend out to internal clients. The very common soho case in which the "nat/nar" box has only one ip address (perhaps obtained dynamically from its ISP) would not be supported. ------------------ More info: I've been thinking about enabling IPSEC (and others) across intermediate boxes (NATs, proxies, gateways, whatever). My proposal on how to do it is called NAR (negotiated address reuse): draft-montenegro-aatn-nar-00.txt The chicago presentation is available as http://playground.sun.com/~gab/talks/nar-ietf42.{PDF,ppt} -gabriel From owner-ipsec Wed Sep 16 05:05:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA14513 for ipsec-outgoing; Wed, 16 Sep 1998 05:01:03 -0400 (EDT) From: Gabriel.Montenegro@Eng.Sun.Com Date: Wed, 16 Sep 1998 02:17:11 -0700 Message-Id: <199809160917.CAA11408@hsmpka.eng.sun.com> To: "Bryan Gleeson" , "Henry Spencer" , "Juha Heinanen" Cc: ipsec@tis.com Reply-To: gab@Eng.Sun.Com X-Mailer: Sun NetMail 2.1.6 Subject: RE: null encryption Sender: owner-ipsec@ex.tis.com Precedence: bulk "Bryan Gleeson" wrote: >As used with VPNs, there are a lot of requirements for a >generic tunneling protocol, over and above the need to >encapsulate data packets. For example to reduce the >configuration burden of setting up lots of tunnels, a >signalling protocol that allows the establishment and >negotiation of tunnel attributes is very useful. IPSEC >(IKE) and L2TP have such a signalling protocol. GRE >and IP/IP (RFC2003) do not. That's not the right comparison. If you were to compare apples to apples you'd have to compare ESP or AH with GRE and IP/IP (they're just encapsulation schemes, not signalling protocols). Signalling in all of these cases is a separate protocol. For ESP/AH it is IKE. Similarly, Mobile IP (rfc2002) defines a registration protocol which set up tunnels using IP/IP or GRE or Minimal Encapsulation. However, mobile ip does not address all that one needs to set up general tunnels. We proposed a superset called TEP (draft-ietf-mobileip-calhoun-tep-01.txt) for that reason. >...Also a multiplexing field >that allows multiple tunnels to be set up between the same >two endpoints is very useful (to support different VPNs >for example). Again IPSEC (via the SPI field) and L2TP >(via the tunnel-id, call-id fields) have such a >multiplexing field, but GRE and IP/IP do not. GRE has a 32 bit key field that can be used for this purpose. TEP allows its negotiation via the tunnel id. > The ability >to send opaque and multiprotocol frames across an >IP backbone is also not addressed by IP/IP. that's what gre is for. -gabriel From owner-ipsec Wed Sep 16 09:29:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15283 for ipsec-outgoing; Wed, 16 Sep 1998 09:26:37 -0400 (EDT) Message-Id: <199809161343.IAA29153@gungnir.fnal.gov> To: ipsec@tis.com From: "Matt Crawford" Subject: Re: ike source port (was: issues with IKE that need resolution) In-reply-to: Your message of Wed, 16 Sep 1998 01:36:14 PDT. <199809160836.BAA08003@hsmpka.eng.sun.com> Date: Wed, 16 Sep 1998 08:43:41 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk > Is it ok for the source port for IKE to be something other than > port 500? > > Hopefully it is ok, as this eases ipsec across NAT boxes Whoa! Cognitive dissonance! From owner-ipsec Wed Sep 16 10:40:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15666 for ipsec-outgoing; Wed, 16 Sep 1998 10:38:42 -0400 (EDT) Message-Id: <199809161456.KAA21935@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-pki-req-01.txt Date: Wed, 16 Sep 1998 10:56:00 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : PKI Requirements for IP Security Author(s) : R. Thayer Filename : draft-ietf-ipsec-pki-req-01.txt Pages : 23 Date : 15-Sep-98 The IP Security (IPSec) protocol set now being defined in the IETF uses public key cryptography for authentication in its key management protocol. This document defines the requirements that IPSec has for Public Key Infrastructure (PKI) protocols, formats, and services. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-pki-req-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-pki-req-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980915135850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980915135850.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Sep 16 10:40:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA15643 for ipsec-outgoing; Wed, 16 Sep 1998 10:36:39 -0400 (EDT) Message-Id: <199809161453.HAA11434@chip.cisco.com> To: "Valery Smyslov" cc: ipsec@tis.com Subject: Re: Question about New Group mode In-reply-to: Your message of "Wed, 16 Sep 1998 11:53:08." <199809160753.LAA04502@relay2.elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11432.905957603.1@cisco.com> Date: Wed, 16 Sep 1998 07:53:23 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Privyet Valery, Yes, this is permissible since the IKE SA is bidirectional. Once it's established either party can use it to initiate another exchange. Dan. On Wed, 16 Sep 1998 11:53:08 you wrote > Hi, Dan, > > I have a question regarding New Group mode. > > Is it possible for ISAKMP responder to initiate New Group mode > after performing phase 1 negotiating? (Imagine two hosts, A and B; > if local policy on host A dictates that it must use private DH group > with host B, and host B initiated phase 1 not offering that group, > what should host A do: wait in hope that host be B will sometime > negotiate that group or try to do it by itself?). > > Draft doesn't explicitly prohibit this, it only states that New Group > mode MUST only follow phase 1 (section 5.6). > > Regards, Valery Smyslov. From owner-ipsec Wed Sep 16 11:13:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15766 for ipsec-outgoing; Wed, 16 Sep 1998 11:11:38 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809161530.IAA19404@kc.livingston.com> Subject: Re: ike source port (was: issues with IKE that need resolution) To: crawdad@fnal.gov (Matt Crawford) Date: Wed, 16 Sep 1998 08:30:06 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199809161343.IAA29153@gungnir.fnal.gov> from "Matt Crawford" at Sep 16, 98 08:43:41 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > Is it ok for the source port for IKE to be something other than > > port 500? > > > > Hopefully it is ok, as this eases ipsec across NAT boxes > > Whoa! Cognitive dissonance! > To be clear, the NAT box Gabriel is refering to is a Host NAT server. Host NAT server does not perform any address or port translation. Hope this helps. cheers, suresh From owner-ipsec Wed Sep 16 11:34:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15821 for ipsec-outgoing; Wed, 16 Sep 1998 11:32:38 -0400 (EDT) From: bmanning@isi.edu Posted-Date: Wed, 16 Sep 1998 08:45:13 -0700 (PDT) Message-Id: <199809161545.AA01645@zed.isi.edu> Subject: Re: ike source port (was: issues with IKE that need resolution) To: suresh@livingston.com (Pyda Srisuresh) Date: Wed, 16 Sep 1998 08:45:13 -0700 (PDT) Cc: crawdad@fnal.gov, ipsec@tis.com In-Reply-To: <199809161530.IAA19404@kc.livingston.com> from "Pyda Srisuresh" at Sep 16, 98 08:30:06 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > Is it ok for the source port for IKE to be something other than > > > port 500? > > > > > > Hopefully it is ok, as this eases ipsec across NAT boxes > > > > Whoa! Cognitive dissonance! > > > To be clear, the NAT box Gabriel is refering to is a Host NAT server. > Host NAT server does not perform any address or port translation. > Hope this helps. > > cheers, > suresh If so, then whence the term "NAT"? Per RFC 1631 a NAT does address/port translation. --bill From owner-ipsec Wed Sep 16 12:02:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16052 for ipsec-outgoing; Wed, 16 Sep 1998 11:59:41 -0400 (EDT) Message-Id: <3.0.32.19980916114146.00a045c0@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 16 Sep 1998 11:41:48 -0400 To: Gabriel.Montenegro@Eng.Sun.Com From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: ike source port (was: issues with IKE that need resolution) Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk > Is it ok for the source port for IKE to be something other than > port 500? One thing to keep in mind is that ISAKMP is a peer-to-peer protocol that isn't restricted to just client-to-server types of interaction. In host- to-host or gateway-to-gateway scenarios, typically either peer can be either the initiator or the responder. If Host A is sitting behind a NAT box, and that NAT box does dynamic address and port translation, and Host B wants to establish an SA with Host A, how is Host B going to know the address and port number to which it should send that first ISAKMP message? My biggest concern is that making a "fix" to allow any source port to initiate ISAKMP traffic - make that a change to mandate that ISAKMP responders respond to ports other than 500, which isn't a requirement currently - is going to give people the false impression that doing so magically fixes the "IPSEC/NAT problem" across the board, when in fact it only addresses part of the problem for only a subset of the possible scenarios where IPSEC can be used - the subset where there is a strict client-to-server, initiator-to-responder assignment of roles that doesn't ever change. I don't want to have to try to explain to someone why the NAT box they just installed breaks IPSEC communications in some cases but not in others. >[...] Allowing the source port to vary does not >seem to have security implications, because source and destination >ports are already included in the hash. [...] Actually, source and destination ports (those in the UDP header at least) aren't included in any of the IKE hash calculations. -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Wed Sep 16 12:02:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16051 for ipsec-outgoing; Wed, 16 Sep 1998 11:59:40 -0400 (EDT) From: ark@eltex.ru Date: Wed, 16 Sep 1998 13:16:00 +0400 Message-Id: <199809160916.NAA15122@paranoid.eltex.spb.ru> In-Reply-To: <199809151649.LAA24702@gungnir.fnal.gov> from ""Matt Crawford" " Organization: "Klingon Imperial Intelligence Service" Subject: Re: Redmond Bakeoff Summary Report (long) To: crawdad@fnal.gov Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- nuqneH, "Matt Crawford" said : > Mr. Chairman, I move that the house consider censure of the gentleman > from Redmond on the grounds of blatant disregard for established > standards. > > His email had an invalid message-id (no FQDN). > > His email contained an inline uuencoded file instead of using MIME. Nothing wrong with it. uuencode was de-facto standard long before MIME appeared and many people still continue to use it. My MUA is not MIME-aware and i don't miss anything. The strangest thing with it is that i have not seen any uue or html - there were 2 messages one of which declared to be RTF but both were plaintext. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNf+By6H/mIJW9LeBAQGQ0gP+LtpgoCNKSMLQVzOKk84D7p4+9dC/CVPC bGCD+yrj8TjhIxBsNN4SYYPDpdvU5MveTL65gA6Fvh1M7TiI1ofwroF2/H1Plgyh PfAUsGnC+pLQHDIIUqxxkeTJ+Fz3PkeXjYi8QY48w2+qAORYRevC0QVZiJ+ayMNG yhNJOGVM8iw= =vzvK -----END PGP SIGNATURE----- From owner-ipsec Wed Sep 16 12:03:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16108 for ipsec-outgoing; Wed, 16 Sep 1998 12:01:40 -0400 (EDT) Date: Wed, 16 Sep 1998 09:13:27 -0700 From: Pat.Calhoun@Eng.Sun.Com (Patrice Calhoun) Message-Id: <199809161613.JAA18560@hsmpka.eng.sun.com> To: bmanning@isi.edu, "Pyda Srisuresh" Cc: crawdad@fnal.gov, ipsec@tis.com Reply-To: Pat.Calhoun@Eng.Sun.Com X-Mailer: Sun NetMail 2.1.6 Subject: Re: ike source port (was: issues with IKE that need resolution) Sender: owner-ipsec@ex.tis.com Precedence: bulk >> > > Is it ok for the source port for IKE to be something other than >> > > port 500? >> > > >> > > Hopefully it is ok, as this eases ipsec across NAT boxes >> > >> > Whoa! Cognitive dissonance! >> > >> To be clear, the NAT box Gabriel is refering to is a Host NAT server. >> Host NAT server does not perform any address or port translation. >> Hope this helps. >> >> cheers, >> suresh > >If so, then whence the term "NAT"? Per RFC 1631 a NAT does address/port >translation. Actually, to be really clear :) Gabriel was talking about Address Translation, but not using traditional NAT. What he had in mind was making use of SOCKS for address translation. Gabriel has a proposal to make use of SOCKS to achieve end-to-end security WITH address translation. However, I suppose I should not be assuming what he meant. This is what I think he meant. PatC > >--bill From owner-ipsec Wed Sep 16 12:11:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16157 for ipsec-outgoing; Wed, 16 Sep 1998 12:09:41 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809161627.JAA21753@kc.livingston.com> Subject: Re: ike source port (was: issues with IKE that need resolution) To: bmanning@isi.edu Date: Wed, 16 Sep 1998 09:27:34 -0700 (PDT) Cc: suresh@livingston.com, crawdad@fnal.gov, ipsec@tis.com In-Reply-To: <199809161545.AA01645@zed.isi.edu> from "bmanning@ISI.EDU" at Sep 16, 98 08:45:13 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > > > Is it ok for the source port for IKE to be something other than > > > > port 500? > > > > > > > > Hopefully it is ok, as this eases ipsec across NAT boxes > > > > > > Whoa! Cognitive dissonance! > > > > > To be clear, the NAT box Gabriel is refering to is a Host NAT server. > > Host NAT server does not perform any address or port translation. > > Hope this helps. > > > > cheers, > > suresh > > If so, then whence the term "NAT"? Per RFC 1631 a NAT does address/port > translation. > > --bill > It is Host-NAT, not NAT. A host in a private network, when connecting to end-hosts outside its realm, could adapt Host Network Address Translation to avoid network address translation of end-to-end packets. Such a host is termed "Host NAT client". For details, I suggest, you refer NAR draft by Gabriel or the soon-to-be-posted draft-ietf-nat-terminology-01.txt. Thanks. cheers, suresh From owner-ipsec Wed Sep 16 12:16:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16193 for ipsec-outgoing; Wed, 16 Sep 1998 12:14:42 -0400 (EDT) From: bmanning@isi.edu Posted-Date: Wed, 16 Sep 1998 09:27:28 -0700 (PDT) Message-Id: <199809161627.AA02290@zed.isi.edu> Subject: Re: ike source port (was: issues with IKE that need resolution) To: suresh@livingston.com (Pyda Srisuresh) Date: Wed, 16 Sep 1998 09:27:28 -0700 (PDT) Cc: bmanning@isi.edu, suresh@livingston.com, crawdad@fnal.gov, ipsec@tis.com In-Reply-To: <199809161627.JAA21753@kc.livingston.com> from "Pyda Srisuresh" at Sep 16, 98 09:27:34 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > To be clear, the NAT box Gabriel is refering to is a Host NAT server. > > > Host NAT server does not perform any address or port translation. > > > Hope this helps. > > > > > If so, then whence the term "NAT"? Per RFC 1631 a NAT does address/port > > translation. > > --bill > > It is Host-NAT, not NAT. A host in a private network, when connecting to > end-hosts outside its realm, could adapt Host Network Address Translation > to avoid network address translation of end-to-end packets. Such a host > is termed "Host NAT client". > > For details, I suggest, you refer NAR draft by Gabriel or the > soon-to-be-posted draft-ietf-nat-terminology-01.txt. Thanks. > suresh For some reason, I am having trouble pulling a local copy of the "soon-to-be-posted" draft-ietf-nat-terminology-01.txt :) --bill From owner-ipsec Wed Sep 16 12:21:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16231 for ipsec-outgoing; Wed, 16 Sep 1998 12:19:44 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809161637.JAA21839@kc.livingston.com> Subject: Re: ike source port (was: issues with IKE that need resolution) To: bmanning@isi.edu Date: Wed, 16 Sep 1998 09:37:54 -0700 (PDT) Cc: suresh@livingston.com, crawdad@fnal.gov, ipsec@tis.com In-Reply-To: <199809161627.AA02290@zed.isi.edu> from "bmanning@ISI.EDU" at Sep 16, 98 09:27:28 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > > > To be clear, the NAT box Gabriel is refering to is a Host NAT server. > > > > Host NAT server does not perform any address or port translation. > > > > Hope this helps. > > > > > > > If so, then whence the term "NAT"? Per RFC 1631 a NAT does address/port > > > translation. > > > --bill > > > > It is Host-NAT, not NAT. A host in a private network, when connecting to > > end-hosts outside its realm, could adapt Host Network Address Translation > > to avoid network address translation of end-to-end packets. Such a host > > is termed "Host NAT client". > > > > For details, I suggest, you refer NAR draft by Gabriel or the > > soon-to-be-posted draft-ietf-nat-terminology-01.txt. Thanks. > > suresh > > For some reason, I am having trouble pulling a local copy of the > "soon-to-be-posted" draft-ietf-nat-terminology-01.txt :) > > --bill > It is not posted yet. It will be soon (in a couple of days). Some minor editorial work is still under way. Thanks. cheers, suresh From owner-ipsec Thu Sep 17 10:31:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00479 for ipsec-outgoing; Thu, 17 Sep 1998 10:19:04 -0400 (EDT) Message-Id: <199809170330.UAA13705@chip.cisco.com> To: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) cc: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Wed, 16 Sep 1998 14:58:16 EDT." <3.0.32.19980916145815.00a09680@bl-mail1.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13703.906003015.1@cisco.com> Date: Wed, 16 Sep 1998 20:30:15 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 16 Sep 1998 14:58:16 EDT you wrote > > 3. Clarification of use of the commit bit in IKE. This will constrain > > the freeform (and confusing) verbage in the base ISAKMP document. > > For IKE the commit bit only makes sense in Quick Mode. Most people > > I spoke to said that they return a "INVALID_FLAGS" notify message > > if the peer tries to set it in any other mode. They also only use it > > to extend Quick Mode by a single message-- from the responder back > > to the initiator. This was its intended use anyway. Also, most > > people send this message as a final Quick Mode exchange message > > and not an Informational. The only person I spoke to who did > > otherwise said Quick Mode made more sense and was going to change. > > So that final Quick Mode message would presumably include the "CONNECTED" > Notify payload, right? Would there also be a Hash payload to authenticate > it? If so, what goes in that hash? If people are already implementing > this, it'd be nice to know how it's done... Yes, it would contain the CONNECTED message. And all Quick Mode messages are authenticated with an hmac which is keyed with SKEYID_a (and they're all encrypted with SKEYID_e). > Also, is the initiator required to send the commit bit in the third Quick > Mode message if it requires the fourth "CONNECTED" message, or does the > responder always need to keep an eye out for it earlier on in the exchange > (perhaps even as early as Phase 1?)? What do other people think? I imagine either party could set it and it could be set in any message. Dan. From owner-ipsec Thu Sep 17 10:31:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00315 for ipsec-outgoing; Thu, 17 Sep 1998 10:18:29 -0400 (EDT) Message-Id: <199809171208.OAA20406@zap.celocom.se> X-Sender: valentin@zap.celocom.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.49 (Beta) Date: Thu, 17 Sep 1998 14:07:15 +0200 To: ipsec@tis.com From: Valentin Oprean Subject: SA Attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello! I am workin with a project and I wonder if I can have some clarification: In ISAKMP/IKE, Phase I, suppose you are the initiator and you have to send to B 2 different Security Association offers. Since in Phase I there can be just one SA Payload with just one Proposal Payload, I think I have to put the 2 offers as 2 Transform Payloads one immediately after the other-with Transform_# 1 and 2 respectively and without nothing in between. Is that correct? Moreover, inside each Transform, how must I put the SA attributes? If I look at page 25, draft:"The Internet Key Exchange", I understand I must choose some of the attribute classes and then build up each Tranform Payload in this way: Generic header |transform 1 | key-ike | reserved | attr_class_id X | relative chosen class_value Y | attr_class_id XX | relative chosen class_value YY | ..... Generic header | transform 2 | key-ike | reserved | attr_class_id X | relative chosen class_value Z | attr_class_id XX | relative chosen class_value WW | ..... Is that correct? Thank you. Elisabetta From owner-ipsec Thu Sep 17 10:31:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00438 for ipsec-outgoing; Thu, 17 Sep 1998 10:18:55 -0400 (EDT) Message-Id: <199809170719.JAA18872@zap.celocom.se> X-Sender: valentin@zap.celocom.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.49 (Beta) Date: Thu, 17 Sep 1998 09:18:31 +0200 To: ipsec@tis.com From: Valentin Oprean Subject: AH in NAT device Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi! If one uses a Network Address Translator (NAT) to translate ones private IP address into Internet legitimate addresses, can one use AH in tunneling mode (ipsec) from the NAT device? /.Valentin From owner-ipsec Thu Sep 17 10:44:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01017 for ipsec-outgoing; Thu, 17 Sep 1998 10:41:34 -0400 (EDT) Message-Id: <199809171457.KAA02153@postal.research.att.com> To: Valentin Oprean cc: ipsec@tis.com Subject: Re: AH in NAT device Date: Thu, 17 Sep 1998 10:57:07 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199809170719.JAA18872@zap.celocom.se>, Valentin Oprean writes: > Hi! > > If one uses a Network Address Translator (NAT) to translate ones private IP > address into Internet legitimate addresses, can one use AH in tunneling mode > (ipsec) from the NAT device? I'm not certain exactly what you're asking. However, in general the NAT box must terminate the ipsec association. That is, some internal host using a net 10 address can send a packet towards the Internet. A border box translates the address into something legitimate, then applies AH or ESP. That will work. From owner-ipsec Thu Sep 17 11:06:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01154 for ipsec-outgoing; Thu, 17 Sep 1998 11:02:40 -0400 (EDT) Message-Id: <3.0.32.19980916145815.00a09680@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 16 Sep 1998 14:58:16 -0400 To: Daniel Harkins From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk > 3. Clarification of use of the commit bit in IKE. This will constrain > the freeform (and confusing) verbage in the base ISAKMP document. > For IKE the commit bit only makes sense in Quick Mode. Most people > I spoke to said that they return a "INVALID_FLAGS" notify message > if the peer tries to set it in any other mode. They also only use it > to extend Quick Mode by a single message-- from the responder back > to the initiator. This was its intended use anyway. Also, most > people send this message as a final Quick Mode exchange message > and not an Informational. The only person I spoke to who did > otherwise said Quick Mode made more sense and was going to change. So that final Quick Mode message would presumably include the "CONNECTED" Notify payload, right? Would there also be a Hash payload to authenticate it? If so, what goes in that hash? If people are already implementing this, it'd be nice to know how it's done... Also, is the initiator required to send the commit bit in the third Quick Mode message if it requires the fourth "CONNECTED" message, or does the responder always need to keep an eye out for it earlier on in the exchange (perhaps even as early as Phase 1?)? -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Thu Sep 17 11:19:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01411 for ipsec-outgoing; Thu, 17 Sep 1998 11:18:45 -0400 (EDT) Message-Id: <3.0.32.19980917112557.009fca80@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Sep 1998 11:26:01 -0400 To: Daniel Harkins From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >> So that final Quick Mode message would presumably include the "CONNECTED" >> Notify payload, right? Would there also be a Hash payload to authenticate >> it? If so, what goes in that hash? If people are already implementing >> this, it'd be nice to know how it's done... > > Yes, it would contain the CONNECTED message. And all Quick Mode messages >are authenticated with an hmac which is keyed with SKEYID_a (and they're >all encrypted with SKEYID_e). Am I right in assuming that the fourth message looks like this (using IKE draft notation): Initiator Responder ----------- ----------- <-- HDR*, HASH(4), Notify where HASH(4) = prf(SKEYID_a, M-ID | Notify) That would be what I'd expect, but some of the other Quick Mode hashes require Nonce data from previous messages. Just want to make it all explicit, that's all... -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Thu Sep 17 11:30:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01477 for ipsec-outgoing; Thu, 17 Sep 1998 11:29:43 -0400 (EDT) Message-Id: <199809171543.IAA25977@chip.cisco.com> To: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) cc: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Thu, 17 Sep 1998 11:26:01 EDT." <3.0.32.19980917112557.009fca80@bl-mail1.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25975.906047025.1@cisco.com> Date: Thu, 17 Sep 1998 08:43:45 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, that's right. Do you think it should contain the nonces? Dan. On Thu, 17 Sep 1998 11:26:01 EDT you wrote > Am I right in assuming that the fourth message looks like this (using > IKE draft notation): > > Initiator Responder > ----------- ----------- > <-- HDR*, HASH(4), Notify > where > HASH(4) = prf(SKEYID_a, M-ID | Notify) > > That would be what I'd expect, but some of the other Quick Mode hashes > require Nonce data from previous messages. Just want to make it all > explicit, that's all... From owner-ipsec Thu Sep 17 14:35:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02284 for ipsec-outgoing; Thu, 17 Sep 1998 14:33:57 -0400 (EDT) Message-Id: <3.0.5.32.19980917134819.00993b00@mailhost.sctc.com> X-Sender: markham@mailhost.sctc.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 17 Sep 1998 13:48:19 -0500 To: Daniel Harkins , Shawn_Mamros@BayNetworks.COM (Shawn Mamros) From: Tom Markham Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com In-Reply-To: <199809170330.UAA13705@chip.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >On Wed, 16 Sep 1998 14:58:16 EDT you wrote >> > 3. Clarification of use of the commit bit in IKE. This will constrain >> > the freeform (and confusing) verbage in the base ISAKMP document. >> > For IKE the commit bit only makes sense in Quick Mode. Most people >> > I spoke to said that they return a "INVALID_FLAGS" notify message >> > if the peer tries to set it in any other mode. They also only use it >> > to extend Quick Mode by a single message-- from the responder back >> > to the initiator. This was its intended use anyway. Also, most >> > people send this message as a final Quick Mode exchange message >> > and not an Informational. The only person I spoke to who did >> > otherwise said Quick Mode made more sense and was going to change. At 08:30 PM 9/16/98 -0700, Daniel Harkins wrote: > What do other people think? I imagine either party could set it and it >could be set in any message. I think the approach Dan suggests will provide a more extensible protocol. Based on the definition of the commit bit, I also assumed it could be set by either party in any message. Finally, Section 2 of the IKE ID talks about using IKE in client mode. I ASSUME the commit bit could be set by either IKE entity to hold off use of the SA until IKE transfers the SA information to its client. Tom Markham From owner-ipsec Thu Sep 17 15:54:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02638 for ipsec-outgoing; Thu, 17 Sep 1998 15:52:57 -0400 (EDT) Date: Thu, 17 Sep 1998 13:14:02 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: ike source port (was: issues with IKE that need resolution) To: bmanning@isi.edu Cc: Pyda Srisuresh , crawdad@fnal.gov, ipsec@tis.com In-Reply-To: "Your message with ID" <199809161545.AA01645@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > > Is it ok for the source port for IKE to be something other than > > > > port 500? > > > > > > > > Hopefully it is ok, as this eases ipsec across NAT boxes > > > > > > Whoa! Cognitive dissonance! > > > > > To be clear, the NAT box Gabriel is refering to is a Host NAT server. > > Host NAT server does not perform any address or port translation. > > Hope this helps. > > > > cheers, > > suresh > > If so, then whence the term "NAT"? Per RFC 1631 a NAT does address/port > translation. Ok, wrong terminology. I should've said across some boxes. I was actually referring to a NAR (negotiated address reuse) server. I agree with Bill Manning that what Suresh describes above as Host "NAT" is not NAT at all, because, as he describes it, it performs no translation. The mechanism itself is tunneling based. This is very similar to what a co-located mobile node does when sending packets back via a reverse tunnel in mobileip. Nothing new there, certainly no network address translation. Having said that, it is possible to still retain some translation of the outermost IP header (and NAR allows this), but only if the traffic being shuttled through the border device (NAR server, whatever you wish to call it) is tunnel mode ESP. No translation is possible if the traffic is AH (any mode) or transport mode ESP, as these cryptographically protect the outer IP header from being modified. -gabriel From owner-ipsec Thu Sep 17 16:16:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02751 for ipsec-outgoing; Thu, 17 Sep 1998 16:15:56 -0400 (EDT) Date: Thu, 17 Sep 1998 13:37:31 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: ike source port (was: issues with IKE that need resolution) To: Shawn Mamros Cc: ipsec@tis.com In-Reply-To: "Your message with ID" <3.0.32.19980916114146.00a045c0@bl-mail1.corpeast.baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Is it ok for the source port for IKE to be something other than > > port 500? > ... > > My biggest concern is that making a "fix" to allow any source port to > initiate ISAKMP traffic - make that a change to mandate that ISAKMP > responders respond to ports other than 500, which isn't a requirement > currently - is going to give people the false impression that doing > so magically fixes the "IPSEC/NAT problem" across the board, when in > fact it only addresses part of the problem for only a subset of the > possible scenarios where IPSEC can be used - the subset where there is > a strict client-to-server, initiator-to-responder assignment of roles > that doesn't ever change. I don't want to have to try to explain to > someone why the NAT box they just installed breaks IPSEC communications > in some cases but not in others. That's a valid concern, but, as with all hooks in general, they are not claimed to be a fix. They're only what makes a fix possible. If deemed necessary the appropriate provisos could accompany any changed text. Besides, relaxing the port constraint is beneficial for other things as well, such as testing (see below). What's MUCH more important is figuring out what security issues arise (if any) by allowing source port (and destination port, for that matter) to be different from 500. Given that the hash covers it, perhaps it is already taken care of. > > >[...] Allowing the source port to vary does not > >seem to have security implications, because source and destination > >ports are already included in the hash. [...] > > Actually, source and destination ports (those in the UDP header at > least) aren't included in any of the IKE hash calculations. according to section 5 of IKE: The entire ID payload (including ID type, port, and protocol but excluding the generic header) is hashed into both HASH_I and HASH_R. However, I looked at the DOI, and it does impose severe constraints on the port number used: During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. If an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable. By the way, allowing port numbers to be something other than 500 also helps testing. The SSH Communications test facility uses ports other than 500: http://isakmp-test.ssh.fi/cgi-bin/nph-isakmp-test Of course, that practice is wrong, according to the DOI paragraph above. Maybe the DOI (and IKE) should not limit it to source port 500 (and destination as well, for that matter)? -gabriel From owner-ipsec Thu Sep 17 16:27:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02796 for ipsec-outgoing; Thu, 17 Sep 1998 16:27:03 -0400 (EDT) Date: Thu, 17 Sep 1998 13:51:21 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: ike source port (was: issues with IKE that need resolution) To: Thomas Narten Cc: ipsec@tis.com In-Reply-To: "Your message with ID" <199809161617.MAA20404@cichlid.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk "Thomas Narten" wrote: > If I read this correctly, some of the IKE payloads include the source > port in the cryptographic hash. If so, seems like IKE will have > problems running through a NAT box. When NAT changes the source port, > its value at the receiver will not be correct relative to the hash, > and the receiver will toss the packet as invalid. > > Or am I missing something? It's kinda tricky, I think it would not break because the hash uses the value of the port reported in the ID payload. Notice that the hash does not actually use the real port number out on the IP header. But the port number in the ID payload should really agree with the port number in the IP header. In order to do this, the client and the N-- box negotiate a port number that is agreeable to both in advance. The client would then compose the packet using an address borrowed from the N-- box (perhaps N--'s own ip address) and the negotiated port. So by preparing the right packet in advance, there is no need for translation at the N-- box (it's no longer a NAT box, as there is no translation). However, current IKE/DOI only allow port 500 (or 0) in the id payload. -gabriel From owner-ipsec Thu Sep 17 16:47:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02942 for ipsec-outgoing; Thu, 17 Sep 1998 16:47:00 -0400 (EDT) Message-Id: <199809172103.OAA21372@gallium.network-alchemy.com> To: Daniel Harkins cc: Shawn_Mamros@BayNetworks.COM (Shawn Mamros), ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Thu, 17 Sep 1998 08:43:45 PDT." <199809171543.IAA25977@chip.cisco.com> Date: Thu, 17 Sep 1998 14:03:54 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, that's right. Do you think it should contain the nonces? I don't think it's necessary in this case. I'd prefer that it be the same computation as a regular notify/delete hash (i.e. prf(SKEYID_a, M-ID | Notify)). Derrell From owner-ipsec Thu Sep 17 18:26:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03365 for ipsec-outgoing; Thu, 17 Sep 1998 18:25:00 -0400 (EDT) Message-ID: <360190E9.D9D0852@redcreek.com> Date: Thu, 17 Sep 1998 15:44:57 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <199809111748.KAA09458@dharkins-ss20.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk This sort of relates to IKE, but it's really more of a DOI issue. Nonetheless, it will impact IKE implementations, so I'll toss it out. At one of the Chicago IETF focus groups someone tossed out a the idea that in some cases, lists of ID types in the ID payload would be useful. I had an off-list exchange with Derrell Piper about this way back in April, and decided to wait until ipsecond was official to bring it up on the list. The time is upon us. We would like to be able to specify a list of subnets, addresss ranges, or individual ip addresses in the ID payload without having to send multiple payloads if possible. One idea we've come up with for doing this which seems appropriate would be to add a couple of new ID types: ID type Value ------- ----- RESERVED 0 ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 ------- SUGGESTED ------- ID_IPV4_ADDR_LIST 12 ID_IPV4_ADDR_SUBNET_LIST 13 ID_IPV4_ADDR_RANGE_LIST 14 The number of entries in the list(s) is easily derivable using the payload length along with the type, and this would provide some added functionality that we could certainly use. These would look like this: ID_IPV4_ADDR_LIST with N address: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol | Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address N ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID_IPV4_SUBNET_LIST with N subnets: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol | Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Netmask 1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Netmask 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address N ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Netmask N ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID_IPV4_ADDR_RANGE_LIST with N subnets: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol | Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 1 Low ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 1 High ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 2 Low ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address 2 High ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address N Low ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address N High ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Any comments on this? Scott From owner-ipsec Thu Sep 17 20:25:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA03781 for ipsec-outgoing; Thu, 17 Sep 1998 20:24:02 -0400 (EDT) Message-Id: <199809172339.TAA04108@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 17 Sep 1998 17:39:27 -0700 To: "Scott G. Kelly" From: Rodney Thayer Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com In-Reply-To: <360190E9.D9D0852@redcreek.com> References: <199809111748.KAA09458@dharkins-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk What do you want certificates to contain for these other ID types? People have asked me, off and on, about subnets having their own certificates and other cases. Sounds reasonable to me, but I can just see some PKI service provider blanching at the notion of issuing a certificate for an entire class A subnetwork. At 03:44 PM 9/17/98 -0700, you wrote: >This sort of relates to IKE, but it's really more of a DOI issue. >Nonetheless, it will impact IKE implementations, so I'll toss it out. At >one of the Chicago IETF focus groups someone tossed out a the idea that >in some cases, lists of ID types in the ID payload would be useful. I >had an off-list exchange with Derrell Piper about this way back in >April, and decided to wait until ipsecond was official to bring it up on >the list. The time is upon us. > > >We would like to be able to specify a list of subnets, addresss ranges, >or individual ip addresses in the ID payload without having to send >multiple payloads if possible. One idea we've come up with for doing >this which seems appropriate would be to add a couple of new ID types: > > ID type Value > ------- ----- > RESERVED 0 > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_USER_FQDN 3 > ID_IPV4_ADDR_SUBNET 4 > ID_IPV6_ADDR 5 > ID_IPV6_ADDR_SUBNET 6 > ID_IPV4_ADDR_RANGE 7 > ID_IPV6_ADDR_RANGE 8 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 > ------- SUGGESTED ------- > ID_IPV4_ADDR_LIST 12 > ID_IPV4_ADDR_SUBNET_LIST 13 > ID_IPV4_ADDR_RANGE_LIST 14 > >The number of entries in the list(s) is easily derivable using the >payload length along with the type, and this would provide some added >functionality that we could certainly use. These would look like this: > >ID_IPV4_ADDR_LIST with N address: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! Next Payload ! RESERVED ! Payload Length ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! ID Type ! Protocol | Port ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 1 ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 2 ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >~ ~ >~ ~ >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address N ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >ID_IPV4_SUBNET_LIST with N subnets: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! Next Payload ! RESERVED ! Payload Length ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! ID Type ! Protocol | Port ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 1 ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! Netmask 1 ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 2 ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! Netmask 2 ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >~ ~ >~ ~ >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address N ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! Netmask N ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >ID_IPV4_ADDR_RANGE_LIST with N subnets: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! Next Payload ! RESERVED ! Payload Length ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! ID Type ! Protocol | Port ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 1 Low ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 1 High ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 2 Low ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address 2 High ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >~ ~ >~ ~ >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address N Low ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >! IP Address N High ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Any comments on this? > >Scott > From owner-ipsec Thu Sep 17 21:39:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA04072 for ipsec-outgoing; Thu, 17 Sep 1998 21:38:08 -0400 (EDT) Message-ID: <3601BE2A.D62C5B5@redcreek.com> Date: Thu, 17 Sep 1998 18:58:02 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Saroop Mathur CC: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Saroop Mathur wrote: > > It will be useful to make the port number also a list of numbers and a list > of ranges. Of course, you are right. Lists of ports would be useful, but maybe not in all cases presented. For example, the (practical) usefulness of a port list for a list of subnets seems debatable, although I suppose the argument could be made. I guess the bottom line is that this will require some more thought. I know we would like a mechanism for protocol and port lists/ranges, because the current mechanism requires a separate SA for each port/protocol pair unless you'll accept '0' as a wildcard protocol, and assume a non-zero port value modifies the '0' to mean TCP|UDP. This is a hack, though, and not a very useful one at that. Any suggestions for constructing and differentiating these port lists? From owner-ipsec Thu Sep 17 23:55:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA04273 for ipsec-outgoing; Thu, 17 Sep 1998 23:54:14 -0400 (EDT) Message-Id: <199809180411.VAA26312@chip.cisco.com> To: Rodney Thayer cc: "Scott G. Kelly" , ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Thu, 17 Sep 1998 17:39:27 PDT." <199809172339.TAA04108@2gn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26310.906091903.1@cisco.com> Date: Thu, 17 Sep 1998 21:11:43 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there a point in identifying yourself as "198.31.2.0/24"? What does that mean? "I speak for this network"? Without something like the KX record in DNS to delegate that authority why should I belive it? Chances are he'd probably be making this statement through another interface anyway so what should I do if 198.31.1.18 says "I'm 198.31.2.0/24"? Also, what are you going to do about the ID_KEY_ID identity? A certificate that certifies that my identity is an intentionally incomprehensible blob is not going to be all that useful. It seems to me that we have identities that are only useful in phase 1 and some of those should have ways to be encoded into a cert. There are others that really only make sense in phase 2 because their purpose is to constrain use of an IPSec SA. As an example, a gateway product receiving phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr = "ID_FQDN dharkins@cisco.com" would not be particularly useful. What does "dharkins@cisco.com" mean? There is no machine cisco.com and there sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and a way to encode it in a cert is good. But passing it in phase 2 would not make much sense. Similarly, a list of subnets is not a very good phase 1 identity and I don't see much value in defining a way to encode that in a cert but as a phase 2 identity it may be quite useful. Or am I missing something here? Addressing Scott's point: the ID payload is woefully overloaded. We're trying to express SPD policy in it and that was not its original purpose. If I remember correctly Steve Kent removed some selector types from the Architecture Draft because IKE was unable to express them. It would not only be nice to have lists of address ranges, it would be nice to express the "everything but" construct: "this SA is to be used for all TCP except port 80". But I'm not sure the poor ID payload is the place to do it. Anybody have any ideas on how to express policy _right_? At the TrustMgt BOF in Chicago KeyNote was presented and that seems like a good start. Actions are described as attribute-value pairs. IKE expresses attribute-value pairs quite well. If we had a good way to define desired actions ("I'd like to access your ftp server on machine A and your http server on machine B and C") we could apply a request for those actions-- a series of attribute-value pairs in some new payload-- to the collection of assertions we have that define our local policy ("only may access our ftp server and all other TCP ports except telnet can be accessed by anyone except and RIP goes in the clear"). I think the whole phase 2 identity stuff needs some serious revisiting and alot more than just defining new types. Dan. On Thu, 17 Sep 1998 17:39:27 PDT you wrote > What do you want certificates to contain for these other ID types? People > have asked me, off and on, about subnets having their own certificates and > other cases. Sounds reasonable to me, but I can just see some PKI service > provider blanching at the notion of issuing a certificate for an entire > class A subnetwork. > > >We would like to be able to specify a list of subnets, addresss ranges, > >or individual ip addresses in the ID payload without having to send > >multiple payloads if possible. One idea we've come up with for doing > >this which seems appropriate would be to add a couple of new ID types: > > > > ID type Value > > ------- ----- > > RESERVED 0 > > ID_IPV4_ADDR 1 > > ID_FQDN 2 > > ID_USER_FQDN 3 > > ID_IPV4_ADDR_SUBNET 4 > > ID_IPV6_ADDR 5 > > ID_IPV6_ADDR_SUBNET 6 > > ID_IPV4_ADDR_RANGE 7 > > ID_IPV6_ADDR_RANGE 8 > > ID_DER_ASN1_DN 9 > > ID_DER_ASN1_GN 10 > > ID_KEY_ID 11 > > ------- SUGGESTED ------- > > ID_IPV4_ADDR_LIST 12 > > ID_IPV4_ADDR_SUBNET_LIST 13 > > ID_IPV4_ADDR_RANGE_LIST 14 From owner-ipsec Fri Sep 18 02:53:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA04822 for ipsec-outgoing; Fri, 18 Sep 1998 02:52:10 -0400 (EDT) Date: Fri, 18 Sep 1998 10:09:28 +0300 (EET DST) From: Markku Savela Message-Id: <199809180709.KAA04817@anise.tte.vtt.fi> To: dharkins@cisco.com CC: rodney@tillerman.nu, skelly@redcreek.com, ipsec@tis.com In-reply-to: <199809180411.VAA26312@chip.cisco.com> (message from Daniel Harkins on Thu, 17 Sep 1998 21:11:43 -0700) Subject: Re: issues with IKE that need resolution Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk As I have not much followed the IKE and only doing the IPSEC/PFKEY, the following comes to me as a kind of surprise... > From: Daniel Harkins > > Addressing Scott's point: the ID payload is woefully overloaded. We're > trying to express SPD policy in it and that was not its original purpose. .... > Anybody have any ideas on how to express policy _right_? At the TrustMgt > BOF in Chicago KeyNote was presented and that seems like a good > start. ... I have had the impression that SPD contents is totally local to host and configured by means outside of IPSEC. In what situations would people want to change the SPD dynamically based on the IKE negotiations? I thought the SPD was kind of "static" in respect to IKE/IPSEC, and works as an activator of the negotiation sequences (PFKEY ACQUIRE), and whatever the IKE does, the SPD doesn't change as a result of it. Is this (original purpose of SPD) being changed now? As to expressing SPD, for me it is just a static file that describes what kind of SA bundles are applied to packets matching a selector. (ps. Any chance that there would be a RFC or some specification for the format of this file? So that admins could just deliver their policy files to the client machines without having different versions for different implementations.) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Fri Sep 18 03:28:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA04975 for ipsec-outgoing; Fri, 18 Sep 1998 03:28:10 -0400 (EDT) Message-Id: <199809180745.LAA08647@relay2.elvis.ru> Comments: Authenticated sender is From: "Valery Smyslov" Organization: Elvis+ To: Daniel Harkins Date: Fri, 18 Sep 1998 11:44:32 +3 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: issues with IKE that need resolution CC: ipsec@tis.com In-reply-to: <199809180411.VAA26312@chip.cisco.com> References: Your message of "Thu, 17 Sep 1998 17:39:27 PDT." <199809172339.TAA04108@2gn.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk On 17 Sep 98 at 21:11, Daniel Harkins wrote: Hi, Dan, I'm sorry to interrupt, but the discussion is important for me. > It seems to me that we have identities that are only useful in phase 1 and > some of those should have ways to be encoded into a cert. There are others > that really only make sense in phase 2 because their purpose is to > constrain use of an IPSec SA. As an example, a gateway product receiving > phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr = > "ID_FQDN dharkins@cisco.com" would not be particularly useful. What > does "dharkins@cisco.com" mean? There is no machine cisco.com and there > sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and > a way to encode it in a cert is good. But passing it in phase 2 would not > make much sense. Similarly, a list of subnets is not a very good phase 1 > identity and I don't see much value in defining a way to encode that in a > cert but as a phase 2 identity it may be quite useful. Or am I missing > something here? I agreed with you. It would be great if applicability of every ID type to phase 1 or 2 were explicitly stated somewhere in the drafts. > Addressing Scott's point: the ID payload is woefully overloaded. We're > trying to express SPD policy in it and that was not its original purpose. What is the purpose of ID payloads in phase 2 other than policy negotiating? We authenticate ISAKMP peer in phase 1 and it is where ID payload plays its identification role. But once phase 1 is successfully finished, it is only local policy that links IPSEC peer with authenticated ISAKMP peer. Even the way that ID payloads are included in phase 2 (there always must be two of them) doesn't look like simple identification ("That is host A"), instead it implies policy exchange semantic ("Host A wishes to communicate with host B"). Please, correct me if I'm missing something here. > If I remember correctly Steve Kent removed some selector types from the > Architecture Draft because IKE was unable to express them. It would not > only be nice to have lists of address ranges, it would be nice to express > the "everything but" construct: "this SA is to be used for all TCP except > port 80". But I'm not sure the poor ID payload is the place to do it. > > Anybody have any ideas on how to express policy _right_? At the TrustMgt > BOF in Chicago KeyNote was presented and that seems like a good start. > Actions are described as attribute-value pairs. IKE expresses attribute-value > pairs quite well. If we had a good way to define desired actions ("I'd > like to access your ftp server on machine A and your http server on machine > B and C") we could apply a request for those actions-- a series of > attribute-value pairs in some new payload-- to the collection of assertions > we have that define our local policy ("only may > access our ftp server and all other TCP ports except telnet can be accessed > by anyone except and RIP goes in the clear"). What will ID payloads in phase 2 mean in this case? And another question - how peers will agree upon mutually acceptable policy? It seemes that general ISAKMP approach (initiator sends a list of proposals and responder must choose one of them or refuse all) doesn't work in this case. It seemes that responder must be able to return something different from initiator's proposal, something like responder's proposal (its own policy or its intersection with initiator's proposal). What should initiator do in case the returned proposal is unacceptable for him? Or, more general, how should they construct mutually acceptable policy? Just make an intersection? > I think the whole phase 2 identity stuff needs some serious revisiting > and alot more than just defining new types. Agreed. > Dan. Regards, Valery Smyslov. From owner-ipsec Fri Sep 18 08:56:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA05757 for ipsec-outgoing; Fri, 18 Sep 1998 08:49:08 -0400 (EDT) Message-Id: <199809181306.JAA17359@ghostwheel.ncsl.nist.gov> Date: Fri, 18 Sep 1998 09:06:58 -0400 (EDT) To: ipsec@ans.net From: rob.glenn@nist.gov Subject: New source release available - PLEASE READ X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I put 3 new tar files on snad in ~ipng/src/Linux linux.091898.tgz - 2.1.108 kernel with latest Cerberus code contains support for PlutoPlus. You need to create a second netlink device to work with PlutoPlus (mknod /dev/ike c 36 15) sadb.091898.tgz - latest user interface code - will no longer work with old script files. o No UID field o Only accepts a single key for each algorithm o New X based, TCL/TK script for nice GUI management tool - xsadb plutoplus.091898.tgz - Based from ~ipng/src/Linux/plutoplus.091598.tgz (Sheila's last upload) - changed the kernel_comm code to use /dev/ike, changed the makefile to not compile for WIT & DEBUG. Don't put any of this code on WIT - it will require a significant amount of changes to the test cases because of the changes to the user interface. This snapshot contains any/all major modifications prior to the next release. In the next 2 weeks I will be doing the following to get the code out the door: 1) Document the changes to the kernel code and the command line sadb interface. 2) Develop a man page and documentation for xsadb 3) Port the kernel code to the latest 2.1 kernel (only if the changes are minor). 4) Produce kernel diffs and modify the Cerberus installation script. 5) Update the Cerberus WWW page. 6) Develop some example scripts and document how to setup Cerberus to use PlutoPlus. 7) Change the distribution letter to mention the Cerberus mailing list and market WIT. 8) Find a local company that will make 100-200 floppies at time with labels. For the plutoplus code, we need the following 1) A WWW page that talks about the internal details (i.e. architecture) with some nice graphics of PlutoPlus 2) Modifications to the Cerberus installation script that helps the user install the code (I'll take care of this). 3) A PlutoPlus man page (nroff format) (I'll help someone with this). 4) Some example scripts on different ways of running plutoplus. 5) A list of changes from the original Pluto code. 6) A prioritized TBD list. 7) Any last minute minor changes you may want to make before we ship the code. My goal is to announce the release on 10/5/98. If you have a chance, please pull down this code and give it a shot. I need feedback on it RSN. Rob G. rob.glenn@nist.gov From owner-ipsec Fri Sep 18 09:32:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05848 for ipsec-outgoing; Fri, 18 Sep 1998 09:32:10 -0400 (EDT) Message-Id: <199809181248.IAA07227@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 18 Sep 1998 06:47:08 -0700 To: Daniel Harkins From: Rodney Thayer Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com, skelly@redcreek.com In-Reply-To: <199809180411.VAA26312@chip.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The requirement is -- we want one SA for multiple purposes The problem is -- expressing what we want gets complex, ugly, and possibly unworkable. I note also that rough consensus is that rfc822name and fqdn are, for all intents and purposes, a slab of printable characters. Why don't we add ONE ID type, LABEL, which is an "arbitrary printable string"? It's meaning gets defined outside of IKE (but within bounds of the archtecture or something). So then we'd say something like "id=banktellers" which means "telnet between 9 and 5 local time to host-a and FTP between 4 and 5 local time to host-b". These labels could be Policy Language (program names) or (gasp!) email addresses or driver's licence numbers or whatever you want. THEN, building on that, the ideas that Scott mentioned could be dealt with as specially defined labels. This would be done in the previously-invented style of host "localhost" or email address "postmaster@cisco.com". This does not get the information itself (the list of subnets or ports, etc.) transmitted over the IKE data path but it lets you say something more sophisticated than "ugh, let me talk to 10.0.0.1". At 09:11 PM 9/17/98 -0700, you wrote: > Is there a point in identifying yourself as "198.31.2.0/24"? (... remainder of fowarded message removed...) From owner-ipsec Fri Sep 18 09:39:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05886 for ipsec-outgoing; Fri, 18 Sep 1998 09:39:10 -0400 (EDT) From: Anne Anderson - Sun Microsystems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Sep 1998 11:43:20 -0400 (EDT) To: ipsec@tis.com Subject: Network World article on IPSec Reply-To: aha@East.Sun.COM X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13825.10238.405302.938512@saguaro> Sender: owner-ipsec@ex.tis.com Precedence: bulk An 8/24/98 article by Ellen Messmer in Network World titled "The remaking of IPSec" claims that IPSec and IKE are not ready for prime time, and that productization needs to wait for IPSecond. This is not the impression I have gotten from talking to vendors and from following the ipsec mailing list. Can anyone fill me in on details of some of the following claims from the article? Please reply directly to me (aha@East.sun.com), and I will summarize the responses to the list. 1. "The harder IPSec change will be standardizing on an IPSec remote client. The goal of the IETF meeting is to define a client that can support IP address changes automatically." [Anne] To what extent is this a barrier to deployment of the existing IPSec? Only in NAT environments? 2. "Another difficult item on this week's agenda will be redefining the core IKE protocol. Security experts recently uncovered a flaw related to the improper exposure of information." [Anne] Is this referring the discussion about exposure of identities during IKE negotiation in Pre-Shared-Key-Auth Main Mode? Is this really a barrier to deployment? 3. "And IKE, as it now exists, handles time-expiration of session keys in a way that could cause one gateway not to understand another." [Anne] Is this referring to the use of kbytes-based lifetime payloads versus seconds-based lifetime payloads? To what extent is this a barrier to deployment? Does it just cause a delay, or is it a Big Problem? -- Anne Anderson Email: aha@east.sun.com Sun Microsystems Laboratories or: aha@acm.org 2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928 Chelmsford, MA 01824 USA Fax: (978) 250-5067 From owner-ipsec Fri Sep 18 09:40:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05908 for ipsec-outgoing; Fri, 18 Sep 1998 09:40:12 -0400 (EDT) Message-Id: <3.0.32.19980917120102.00a1a100@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Sep 1998 12:01:09 -0400 To: Daniel Harkins From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, that's right. Do you think it should contain the nonces? I'm not sure if adding the nonces would "help" in any way or not; I don't consider myself an expert in this area. If others have implemented it without them, that's fine by me; I just want to know what to expect of other implementations out there... -Shawn From owner-ipsec Fri Sep 18 09:40:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05907 for ipsec-outgoing; Fri, 18 Sep 1998 09:40:11 -0400 (EDT) Date: Thu, 17 Sep 1998 14:54:20 -0400 (EDT) From: "H.Krawczyk" To: Daniel Harkins Cc: Shawn Mamros , ipsec@tis.com Subject: Re: issues with IKE that need resolution In-Reply-To: <199809171543.IAA25977@chip.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Nonces are always needed to preserve freshness of authentication (i.e., to protect against replay attacks). If you ASSUME M-ID to be random and unique, that may suffice (though I personally do not like basing security in fields such as M-ID or SPI which do not hve an obvious or intrinsic security functionality) Hugo On Thu, 17 Sep 1998, Daniel Harkins wrote: > Yes, that's right. Do you think it should contain the nonces? > > Dan. > > On Thu, 17 Sep 1998 11:26:01 EDT you wrote > > Am I right in assuming that the fourth message looks like this (using > > IKE draft notation): > > > > Initiator Responder > > ----------- ----------- > > <-- HDR*, HASH(4), Notify > > where > > HASH(4) = prf(SKEYID_a, M-ID | Notify) > > > > That would be what I'd expect, but some of the other Quick Mode hashes > > require Nonce data from previous messages. Just want to make it all > > explicit, that's all... > > From owner-ipsec Fri Sep 18 09:41:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05937 for ipsec-outgoing; Fri, 18 Sep 1998 09:41:11 -0400 (EDT) Message-ID: <1F35B0C06D22D211AE0F00A0C99D759B036621@va-exchange1.nai.com> From: "Mason, David" To: Daniel Harkins Cc: ipsec@tis.com Subject: RE: issues with IKE that need resolution Date: Thu, 17 Sep 1998 12:58:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> > For IKE the commit bit only makes sense in Quick Mode. Most people > Is it possible that someone somewhere at sometime might want to use the commit bit in phase 1 for Aggressive Mode? -dmason From owner-ipsec Fri Sep 18 09:41:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05938 for ipsec-outgoing; Fri, 18 Sep 1998 09:41:11 -0400 (EDT) Message-Id: <199809172342.TAA07099@relay.hq.tis.com> From: "Saroop Mathur" To: "Scott G. Kelly" , "Daniel Harkins" Cc: Subject: Re: issues with IKE that need resolution Date: Thu, 17 Sep 1998 16:46:12 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk It will be useful to make the port number also a list of numbers and a list of ranges. - Saroop ---------- > From: Scott G. Kelly > To: Daniel Harkins > Cc: ipsec@tis.com > Subject: Re: issues with IKE that need resolution > Date: Thursday, September 17, 1998 3:44 PM > > This sort of relates to IKE, but it's really more of a DOI issue. > Nonetheless, it will impact IKE implementations, so I'll toss it out. At > one of the Chicago IETF focus groups someone tossed out a the idea that > in some cases, lists of ID types in the ID payload would be useful. I > had an off-list exchange with Derrell Piper about this way back in > April, and decided to wait until ipsecond was official to bring it up on > the list. The time is upon us. > > > We would like to be able to specify a list of subnets, addresss ranges, > or individual ip addresses in the ID payload without having to send > multiple payloads if possible. One idea we've come up with for doing > this which seems appropriate would be to add a couple of new ID types: > > ID type Value > ------- ----- > RESERVED 0 > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_USER_FQDN 3 > ID_IPV4_ADDR_SUBNET 4 > ID_IPV6_ADDR 5 > ID_IPV6_ADDR_SUBNET 6 > ID_IPV4_ADDR_RANGE 7 > ID_IPV6_ADDR_RANGE 8 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 > ------- SUGGESTED ------- > ID_IPV4_ADDR_LIST 12 > ID_IPV4_ADDR_SUBNET_LIST 13 > ID_IPV4_ADDR_RANGE_LIST 14 > > The number of entries in the list(s) is easily derivable using the > payload length along with the type, and this would provide some added > functionality that we could certainly use. These would look like this: > > ID_IPV4_ADDR_LIST with N address: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ID Type ! Protocol | Port ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ID_IPV4_SUBNET_LIST with N subnets: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ID Type ! Protocol | Port ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Netmask 1 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Netmask 2 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Netmask N ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ID_IPV4_ADDR_RANGE_LIST with N subnets: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ID Type ! Protocol | Port ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 Low ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 High ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 Low ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 High ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N Low ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N High ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Any comments on this? > > Scott From owner-ipsec Fri Sep 18 09:44:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA06032 for ipsec-outgoing; Fri, 18 Sep 1998 09:44:13 -0400 (EDT) Message-Id: <199809181359.JAA24327@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Rodney Thayer cc: Daniel Harkins , ipsec@tis.com, skelly@redcreek.com Subject: Re: UBE/medium: Re: issues with IKE that need resolution Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Sep 1998 09:59:55 -0400 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199809181248.IAA07227@2gn.com>, Rodney Thayer writes: >The requirement is -- we want one SA for multiple purposes > >The problem is -- expressing what we want gets complex, ugly, >and possibly unworkable. > >I note also that rough consensus is that rfc822name and fqdn >are, for all intents and purposes, a slab of printable characters. > >Why don't we add ONE ID type, LABEL, which is an "arbitrary printable >string"? It's meaning gets defined outside of IKE (but within bounds >of the archtecture or something). So then we'd say something like >"id=banktellers" which means "telnet between 9 and 5 local time to >host-a and FTP between 4 and 5 local time to host-b". These >labels could be Policy Language (program names) or (gasp!) email addresses >or driver's licence numbers or whatever you want. I see your point, but I don't think that gets us where we need to be. The fundamental problem is that users connect by name, IPsec operates on addresses, and -- in some cases -- both of those are variable. There is a higher-level concept of "that machine", but it's not in the protocol suite. Adding a new label that nothing refers to doesn't solve the problem; users still can't ask for it. From owner-ipsec Fri Sep 18 10:04:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06084 for ipsec-outgoing; Fri, 18 Sep 1998 10:02:11 -0400 (EDT) Message-Id: <199809181419.KAA18035@ghostwheel.ncsl.nist.gov> Date: Fri, 18 Sep 1998 10:19:19 -0400 (EDT) To: sommerfeld@orchard.arlington.ma.us Cc: ipsec@tis.com From: rob.glenn@nist.gov Subject: Re[2]: New source release available - PLEASE READ In-Reply-To: <199809181416.OAA16915@orchard.arlington.ma.us> X-Mailer: Ishmail 1.3.2-970722-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Whoops! D**N aliases! Yes - I didn't mean for that to go the list. Sorry folks. Rob G. rob.glenn@nist.gov Bill Sommerfeld wrote: > > My goal is to announce the release on 10/5/98. > > Somehow I don't think you intended to send that to the ipsec WG > mailing list.. > > - Bill From owner-ipsec Fri Sep 18 11:14:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06753 for ipsec-outgoing; Fri, 18 Sep 1998 11:09:14 -0400 (EDT) Message-Id: <199809172342.TAA07099@relay.hq.tis.com> From: "Saroop Mathur" To: "Scott G. Kelly" , "Daniel Harkins" Cc: Subject: Re: issues with IKE that need resolution Date: Thu, 17 Sep 1998 16:46:12 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk It will be useful to make the port number also a list of numbers and a list of ranges. - Saroop ---------- > From: Scott G. Kelly > To: Daniel Harkins > Cc: ipsec@tis.com > Subject: Re: issues with IKE that need resolution > Date: Thursday, September 17, 1998 3:44 PM > > This sort of relates to IKE, but it's really more of a DOI issue. > Nonetheless, it will impact IKE implementations, so I'll toss it out. At > one of the Chicago IETF focus groups someone tossed out a the idea that > in some cases, lists of ID types in the ID payload would be useful. I > had an off-list exchange with Derrell Piper about this way back in > April, and decided to wait until ipsecond was official to bring it up on > the list. The time is upon us. > > > We would like to be able to specify a list of subnets, addresss ranges, > or individual ip addresses in the ID payload without having to send > multiple payloads if possible. One idea we've come up with for doing > this which seems appropriate would be to add a couple of new ID types: > > ID type Value > ------- ----- > RESERVED 0 > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_USER_FQDN 3 > ID_IPV4_ADDR_SUBNET 4 > ID_IPV6_ADDR 5 > ID_IPV6_ADDR_SUBNET 6 > ID_IPV4_ADDR_RANGE 7 > ID_IPV6_ADDR_RANGE 8 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 > ------- SUGGESTED ------- > ID_IPV4_ADDR_LIST 12 > ID_IPV4_ADDR_SUBNET_LIST 13 > ID_IPV4_ADDR_RANGE_LIST 14 > > The number of entries in the list(s) is easily derivable using the > payload length along with the type, and this would provide some added > functionality that we could certainly use. These would look like this: > > ID_IPV4_ADDR_LIST with N address: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ID Type ! Protocol | Port ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ID_IPV4_SUBNET_LIST with N subnets: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ID Type ! Protocol | Port ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Netmask 1 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Netmask 2 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Netmask N ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ID_IPV4_ADDR_RANGE_LIST with N subnets: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ID Type ! Protocol | Port ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 Low ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 1 High ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 Low ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address 2 High ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N Low ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! IP Address N High ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Any comments on this? > > Scott From owner-ipsec Fri Sep 18 11:14:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06736 for ipsec-outgoing; Fri, 18 Sep 1998 11:08:14 -0400 (EDT) Message-Id: <199809181525.IAA06096@chip.cisco.com> To: Rodney Thayer cc: ipsec@tis.com, skelly@redcreek.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Fri, 18 Sep 1998 06:47:08 PDT." <199809181248.IAA07227@2gn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6094.906132322.1@cisco.com> Date: Fri, 18 Sep 1998 08:25:22 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 18 Sep 1998 06:47:08 PDT you wrote > The requirement is -- we want one SA for multiple purposes But do the IDs that are used to express our desires need to be encoded in a certificate? There's IDs used to identify ourselves (phase 1) and IDs used to constrain IPSec SAs (phase 2). They're not necessarily interchangable. And the IDs used to identify ourselves should be encoded in a cert (well some. I don't see ID_KEY_ID being too useful) but the IDs used to constrain the IPSec SAs don't need to be. At least I don't see why. Can anyone enlighten me? > The problem is -- expressing what we want gets complex, ugly, > and possibly unworkable. > > I note also that rough consensus is that rfc822name and fqdn > are, for all intents and purposes, a slab of printable characters. Well, yes, but a well-defined subset of the possible characters that can fit in a slab. I'm not arguing with the consensus for rfc822names and fqdn. They have a place as a phase 1 identity and it makes sense to encode them into a cert for identification purposes, but what's the point of sending an rfc822name as in phase 2? What's the point of encoding a list of subnets in a cert for a phase 1 identity? > Why don't we add ONE ID type, LABEL, which is an "arbitrary printable > string"? It's meaning gets defined outside of IKE (but within bounds > of the archtecture or something). So then we'd say something like > "id=banktellers" which means "telnet between 9 and 5 local time to > host-a and FTP between 4 and 5 local time to host-b". These > labels could be Policy Language (program names) or (gasp!) email addresses > or driver's licence numbers or whatever you want. I can't tell if your serious or being sarcastic here. I think the later. > THEN, building on that, the ideas that Scott mentioned could be > dealt with as specially defined labels. This would be done in the > previously-invented style of host "localhost" or email address > "postmaster@cisco.com". > > This does not get the information itself (the list of subnets or ports, etc.) > transmitted over the IKE data path but it lets you say something more > sophisticated than "ugh, let me talk to 10.0.0.1". We can already say that. We can even say "let me speak ftp to all hosts on 10.10.10.0/24". But that's about it. We can't express things like "let me speak UDP with a port higher than 1024 to 10.10.10.1". We can't say "let me speak to 10.10.10.0/24 and 10.10.8.23" etc. And the ID payload wasn't designed to express these things anyway. We can try to make it express these things (square pegs do fit in round holes with enough effort) or we can say that the ID payload is already too overloaded and we should define a new way of expressing our desires to the other party. Dan. From owner-ipsec Fri Sep 18 11:23:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06818 for ipsec-outgoing; Fri, 18 Sep 1998 11:22:17 -0400 (EDT) Message-Id: <199809181539.IAA03432@gallium.network-alchemy.com> To: aha@East.Sun.COM cc: ipsec@tis.com Subject: Re: Network World article on IPSec In-reply-to: Your message of "Thu, 17 Sep 1998 11:43:20 EDT." <13825.10238.405302.938512@saguaro> Date: Fri, 18 Sep 1998 08:39:56 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Maybe Bob would like to address your email as well, since he says he was badly misquoted/misrepresented in that article. I avoid interviews like the plague for precisely this reason. Perhaps there are still lessons to be learned all around... In my opinion, the article was editorially irresponsible. Either the author set out to write a negative article or else the author never bothered to check her facts with anyone who's actually fielded an implementation of IKE/IPSEC. >1. "The harder IPSec change will be standardizing on an IPSec remote > client. The goal of the IETF meeting is to define a client that > can support IP address changes automatically." > > [Anne] To what extent is this a barrier to deployment of the > existing IPSec? Only in NAT environments? You're right, it's not. NAT is a known issue. For more information on NAT, see Steve Bellovin's many lucid posting on this issue in this archive. It's on the agenda for IPsecond. >2. "Another difficult item on this week's agenda will be redefining > the core IKE protocol. Security experts recently uncovered a > flaw related to the improper exposure of information." > > [Anne] Is this referring the discussion about exposure of > identities during IKE negotiation in Pre-Shared-Key-Auth Main > Mode? Is this really a barrier to deployment? Yes, that would be a difficult issue, had it been true. No one I spoke with seemed to know which "flaw" we're talking about. The general consensus was that the author incorrectly linked the PKCS encoding problem (i.e. the recent "SSL/RSA" bug) with IPSEC. As written however, that statement is completely unjustifiable and irresponsible. >3. "And IKE, as it now exists, handles time-expiration of session > keys in a way that could cause one gateway not to understand > another." > > [Anne] Is this referring to the use of kbytes-based lifetime > payloads versus seconds-based lifetime payloads? To what extent > is this a barrier to deployment? Does it just cause a delay, or > is it a Big Problem? Again, utter crap. There are some incomplete implementations which do not currently include support for the mandatory lifetime attributes. As a result, certain other gateways will refuse to negotiate with them because of security policy which says that lifetime negotiation is required. This is hardly a problem with the protocol. It is true that from an implementation perspective, getting rekey right is somewhat complicated in this architecture. There is work underway in IPsecond to write some guidelines about how to do rekey correctly. However, as someone who has written code, it certainly can be done interoperably. Derrell From owner-ipsec Fri Sep 18 12:27:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA07070 for ipsec-outgoing; Fri, 18 Sep 1998 12:24:18 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF3DD126@exchange> From: Tim Jenkins To: "Mason, David" , Daniel@newbridge.com, Harkins@newbridge.com, Cc: ipsec@tis.com Subject: Commit Bit (Was RE: issues with IKE that need resolution ) Date: Fri, 18 Sep 1998 12:38:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDE322.BBD1D770" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDE322.BBD1D770 Content-Type: text/plain; charset="iso-8859-1" Was it not decided earlier somewhere that the commit bit makes implementations susceptible to denial of services attacks? It seems an attacker can intercept a packet from the responder (or the other way, for that matter), set the bit and make the intended receiver then wait for the connected notification that will never come. Is this correct? If so, then perhaps that concept created by the commit bit should be replaced by a "please wait" notification payload or the like that causes the recipient to wait for the connected notification. A similar concept would also be necessary if implementations want to stop the race condition in aggressive mode... --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Thursday, September 17, 1998 3:58 PM To: Daniel Harkins Cc: ipsec@tis.com Subject: RE: issues with IKE that need resolution > >> > For IKE the commit bit only makes sense in Quick Mode. Most people > Is it possible that someone somewhere at sometime might want to use the commit bit in phase 1 for Aggressive Mode? -dmason ------_=_NextPart_001_01BDE322.BBD1D770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Commit Bit (Was RE: issues with IKE that need resolution = )

Was it not decided earlier somewhere that the commit = bit makes implementations susceptible to denial of services attacks? It = seems an attacker can intercept a packet from the responder (or the = other way, for that matter), set the bit and make the intended receiver = then wait for the connected notification that will never come. Is this = correct?

If so, then perhaps that concept created by the = commit bit should be replaced by a "please wait" notification = payload or the like that causes the recipient to wait for the connected = notification.

A similar concept would also be necessary if = implementations want to stop the race condition in aggressive = mode...

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


-----Original Message-----
From: Mason, David [mailto:David_Mason@nai.com]
Sent: Thursday, September 17, 1998 3:58 PM
To: Daniel Harkins
Cc: ipsec@tis.com
Subject: RE: issues with IKE that need resolution =


> >> >  For IKE the commit bit only = makes sense in Quick Mode. Most people
>
        Is it = possible that someone somewhere at sometime might want to use
the commit bit in phase 1 for Aggressive = Mode?

        -dmason


------_=_NextPart_001_01BDE322.BBD1D770-- From owner-ipsec Fri Sep 18 12:59:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA07139 for ipsec-outgoing; Fri, 18 Sep 1998 12:57:23 -0400 (EDT) From: CryptoNEWS@aol.com Message-ID: <5138a3e3.36029512@aol.com> Date: Fri, 18 Sep 1998 13:14:58 EDT To: aha@East.Sun.COM, ipsec@tis.com Mime-Version: 1.0 Subject: Re: Network World article on IPSec Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 224 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is an important subject, may be it is better to have the discussion direct on the mailing list. CryptoNEWS In a message dated 9/18/98 8:32:48 AM Pacific Daylight Time, aha@East.Sun.COM writes: << An 8/24/98 article by Ellen Messmer in Network World titled "The remaking of IPSec" claims that IPSec and IKE are not ready for prime time, and that productization needs to wait for IPSecond. This is not the impression I have gotten from talking to vendors and from following the ipsec mailing list. Can anyone fill me in on details of some of the following claims from the article? Please reply directly to me (aha@East.sun.com), and I will summarize the responses to the list. 1. "The harder IPSec change will be standardizing on an IPSec remote client. The goal of the IETF meeting is to define a client that can support IP address changes automatically." [Anne] To what extent is this a barrier to deployment of the existing IPSec? Only in NAT environments? 2. "Another difficult item on this week's agenda will be redefining the core IKE protocol. Security experts recently uncovered a flaw related to the improper exposure of information." [Anne] Is this referring the discussion about exposure of identities during IKE negotiation in Pre-Shared-Key-Auth Main Mode? Is this really a barrier to deployment? 3. "And IKE, as it now exists, handles time-expiration of session keys in a way that could cause one gateway not to understand another." [Anne] Is this referring to the use of kbytes-based lifetime payloads versus seconds-based lifetime payloads? To what extent is this a barrier to deployment? Does it just cause a delay, or is it a Big Problem? -- Anne Anderson Email: aha@east.sun.com Sun Microsystems Laboratories or: aha@acm.org 2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928 Chelmsford, MA 01824 USA Fax: (978) 250-5067 >> From owner-ipsec Fri Sep 18 13:15:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07212 for ipsec-outgoing; Fri, 18 Sep 1998 13:13:24 -0400 (EDT) Message-Id: <199809181628.MAA08098@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 18 Sep 1998 10:24:00 -0700 To: Daniel Harkins From: Rodney Thayer Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com In-Reply-To: <199809181525.IAA06096@chip.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:25 AM 9/18/98 -0700, you wrote: >But do the IDs that are used to express our desires need to be encoded >in a certificate? No but we need to describe in the documentation the algorithm that allows you to figure out which cert to use based on phase one ID, right? If the Phase I ID changes (wrt IP addresses) then the statement I wrote that the IP address represents exactly one IPv4 address becomes incorrect and I need to change my draft. Also, is it true that we expect one certificate to represent exactly one IKE entity? [and yes I was serious about labels, but there's not enough room in that rat hole for all of us so I'll sit back and watch the rest of you.] From owner-ipsec Fri Sep 18 13:17:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07240 for ipsec-outgoing; Fri, 18 Sep 1998 13:16:25 -0400 (EDT) Message-ID: <36029A3D.AAD41A78@redcreek.com> Date: Fri, 18 Sep 1998 10:37:01 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <199809180411.VAA26312@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me preface this by saying that I agree that the whole thing needs more thought, and that my original proposal is probably not the best approach. Daniel Harkins wrote: > > Addressing Scott's point: the ID payload is woefully overloaded. We're > trying to express SPD policy in it and that was not its original purpose. > If I remember correctly Steve Kent removed some selector types from the > Architecture Draft because IKE was unable to express them. It would not > only be nice to have lists of address ranges, it would be nice to express > the "everything but" construct: "this SA is to be used for all TCP except > port 80". But I'm not sure the poor ID payload is the place to do it. > That the ID payload is overloaded when used as a policy selector has been stated in previous discussions, but I can't quite get on top of the argument. I respect the people who have presented the argument, so I assume I'm missing something. Please indulge me by elaborating on this. Regarding the everything-but construct, this is covered by lists of ranges, although a more succinct expression would be nice. Scott From owner-ipsec Fri Sep 18 13:22:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07267 for ipsec-outgoing; Fri, 18 Sep 1998 13:21:30 -0400 (EDT) Message-ID: <36029B6F.96D5CA4C@redcreek.com> Date: Fri, 18 Sep 1998 10:42:07 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <199809181248.IAA07981@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > > I have a better suggestion: > ID_LIST > and just put multiple ID payloads inside... why complicate things? Actually, we considered this - or something similar to this. Instead, we discussed just sending multiple ID payloads in the message. The arguments against (that we were able to come up with) pertain to the complexity of the parsing mechanism, and to the added overhead of the payload headers. Your technique simplifies the parsing mechanism by forcing the grouping of the payloads, but doesn't eliminate the additional headers. I guess for relatively infrequent exchanges, though, the additional bits would not be as strong a consideration. Hmmm... From owner-ipsec Fri Sep 18 13:51:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07439 for ipsec-outgoing; Fri, 18 Sep 1998 13:48:31 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199809172339.TAA04108@2gn.com> References: <360190E9.D9D0852@redcreek.com> <199809111748.KAA09458@dharkins-ss20.cisco.com> Date: Fri, 18 Sep 1998 14:07:00 -0400 To: Rodney Thayer From: Stephen Kent Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, >What do you want certificates to contain for these other ID types? People >have asked me, off and on, about subnets having their own certificates and >other cases. Sounds reasonable to me, but I can just see some PKI service >provider blanching at the notion of issuing a certificate for an entire >class A subnetwork. As it turn out, we are working on a DARPA program to deploy certificate issuance capabilities to the IANA and it's designees (ARIN, RIPE, APNIC), that would result in issuing certificates that align exactly with portions of the IPaddress space. The PKI for this would have IANA as the root and would exactly align with current (and historical) practice for assignment of IP (v4) address space allocations. The focus of the program is BGP security and thus would not go so far as to hand out certificates to those who do not run BGP. However, if there is a demand for such certs due to IPsec, it would be well within the ability of this PKI to issue certs to address space owners who request them, even though they are not BGP users. What is needed to make this work is a pull from ISPs who hear from their clients that the existance of this PKI would benefit the clients who are working to establish VPNs. Comments? Steve From owner-ipsec Fri Sep 18 14:37:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07603 for ipsec-outgoing; Fri, 18 Sep 1998 14:35:41 -0400 (EDT) Message-Id: <199809181853.OAA08490@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Fri, 18 Sep 1998 14:07:00 EDT." Date: Fri, 18 Sep 1998 14:53:02 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> As it turn out, we are working on a DARPA program to deploy Stephen> certificate issuance capabilities to the IANA and it's designees Stephen> (ARIN, RIPE, APNIC), that would result in issuing certificates Stephen> that align exactly with portions of the IPaddress space. The Stephen> PKI for this would have IANA as the root and would exactly align This is an exciting development. Presumeably using name constraints? Maybe this will force various PKI vendors to actually implement this part of PKIX? Is there somewhere that I can refer my ISP contacts to to get more information? I'm been asked to transition one local ISP to BGP, so I'd be very happy to participate on an experimental basis. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgKsDdiXVu0RiA21AQFx3AL+IUkL+PtbvZlGGFGdTp/hhuzLpkVaTmP+ 3gKoUp0jZHmB/pPUYJLeUqjYdDWza/oaWOL+UGRz0PvBiKIk4z2ZNAD6rSmUj3So /SJFQrYL1l4mi9XIsSKpw3mAqfbx2EQs =3Grb -----END PGP SIGNATURE----- From owner-ipsec Fri Sep 18 17:31:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08248 for ipsec-outgoing; Fri, 18 Sep 1998 17:28:50 -0400 (EDT) Message-Id: <199809182043.QAA09095@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 18 Sep 1998 14:44:13 -0700 To: mcr@sandelman.ottawa.on.ca From: Rodney Thayer Subject: Fwd: Re: issues with IKE that need resolution Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I like this. What would you want the cert to have in it? (Again, all I'm asking is how you want people to decide which cert to use given this payload...) >Date: Fri, 18 Sep 1998 10:42:07 -0700 >From: "Scott G. Kelly" >Organization: RedCreek Communications >X-Mailer: Mozilla 4.06 [en] (Win95; U) >To: "Michael C. Richardson" >CC: ipsec@tis.com >Subject: Re: issues with IKE that need resolution >Sender: owner-ipsec@ex.tis.com > >Michael C. Richardson wrote: >> >> I have a better suggestion: >> ID_LIST >> and just put multiple ID payloads inside... why complicate things? > >Actually, we considered this - or something similar to this. Instead, we >discussed just sending multiple ID payloads in the message. The >arguments against (that we were able to come up with) pertain to the >complexity of the parsing mechanism, and to the added overhead of the >payload headers. Your technique simplifies the parsing mechanism by >forcing the grouping of the payloads, but doesn't eliminate the >additional headers. I guess for relatively infrequent exchanges, though, >the additional bits would not be as strong a consideration. > >Hmmm... > From owner-ipsec Fri Sep 18 17:45:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08326 for ipsec-outgoing; Fri, 18 Sep 1998 17:43:50 -0400 (EDT) Message-Id: <199809182200.SAA08862@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: multiple payloads via "ID_LIST" In-reply-to: Your message of "Fri, 18 Sep 1998 14:44:13 PDT." <199809182043.QAA09095@2gn.com> Date: Fri, 18 Sep 1998 18:00:53 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rodney" == Rodney Thayer writes: Rodney> I like this. What would you want the cert to have in it? Rodney> (Again, all I'm asking is how you want people to decide which Rodney> cert to use given this payload...) Rodney, you ask such difficult questions. In my mind, this is useful only during phase II. That should eliminate the need for this question since the ID field to be compared to the certificate would be the one used in phase I. If you want to use this in phase I, then I think you need Kent's work on delegating ownership of IP address ranges. The things in the list much all be covered by one or more certificates. [i.e. if I ask for a list of ports that I wish to protect, then I can do it with a certificate that only has my IP address in it. Asking for a list of ports would be quite reasonable for FTP-like applications, although perhaps not FTP itself] :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgLYE9iXVu0RiA21AQERCgL/Y0djVSU4N2JdRa/X2i70AbfYIQH3wbGc vm1Ms5122aoIgctLFd1cfb0e4MDykvuFxZqq4q/Yqc3wv7W35m+BGl9SJ9O/RlpX bwB0WyjP/FpKVa5QJutSpHAHAa9XsVKB =z5zD -----END PGP SIGNATURE----- From owner-ipsec Sun Sep 20 14:13:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA14296 for ipsec-outgoing; Sun, 20 Sep 1998 14:13:31 -0400 (EDT) Message-ID: <36054918.ED8E9FA5@ix.netcom.com> Date: Sun, 20 Sep 1998 11:27:36 -0700 From: "Scott G. Kelly" Reply-To: skelly@redcreek.com X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" References: <199809182200.SAA08862@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > >>>>> "Rodney" == Rodney Thayer writes: > > Rodney> I like this. What would you want the cert to have in it? > Rodney> (Again, all I'm asking is how you want people to decide which > Rodney> cert to use given this payload...) I'm still thinking about your proposal, and while I like the simplicity, there is one remaining issue: neither my nor your proposal addresses port/protocol lists. This is a difficult issue, because these are currently tied to the other address type payloads. My thinking up to this point uncovers no simple, clean way to add these without either altering existing payloads (which is almost certain to provoke strong resistance), or adding new ones. Have you considered this problem? Scott From owner-ipsec Sun Sep 20 17:15:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA14516 for ipsec-outgoing; Sun, 20 Sep 1998 17:15:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199809181853.OAA08490@istari.sandelman.ottawa.on.ca> References: Your message of "Fri, 18 Sep 1998 14:07:00 EDT." Date: Sun, 20 Sep 1998 17:27:07 -0400 To: "Michael C. Richardson" From: Stephen Kent Subject: Re: issues with IKE that need resolution Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, At this stage we are not ready to sign up trial participants, but you can point folks to us if they want to learn about the project and keep pace with its progress. I'm an appropriate POC for this, for now. The details of the initial design will be released shortly and an (informational) RFC will be published later, under the auspices of the IDR WG. Steve From owner-ipsec Mon Sep 21 11:24:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA17431 for ipsec-outgoing; Mon, 21 Sep 1998 11:12:35 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF3DD53F@exchange> From: Roy Pereira To: "Michael C. Richardson" , ipsec@tis.com Subject: RE: multiple payloads via "ID_LIST" Date: Mon, 21 Sep 1998 11:31:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDE574.F6DBDA50" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDE574.F6DBDA50 Content-Type: text/plain; charset="iso-8859-1" The idea was to have the ability of setting up one SA for multiple source and destinations instead of having to setup multiple SAs for these combinations that would all have the same SA parameters. If you consider a group of non-adjacent nodes part of the same entity, then why can't we identify these nodes in an ID payload? For example: If in my policy I had placed (a) 10.0.0.1, (b) 10.0.1.*, (c) 10.0.2.* all in the same object (O1) and I had (d) 11.0.0.*, (e) 11.0.1.* in another object (O2) and I want to set up a tunnel between those two objects. Right now I would have to setup 6 SAs (a->d, a->e, b->d, d->e, c->d, c->e), even though that only one policy rule exists between these two objects (O1->O2). A better approach would be to have a MetaID type that can accomodate multiple ID types. Then I could setup one SA per (logical) policy rule instead of the physical network layout. When you add ports to this picture, it seams even more important to create a MetaID type. > -----Original Message----- > From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Friday, September 18, 1998 6:01 PM > To: ipsec@tis.com > Subject: multiple payloads via "ID_LIST" > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Rodney" == Rodney Thayer writes: > > Rodney> I like this. What would you want the cert to have in it? > Rodney> (Again, all I'm asking is how you want people to > decide which > Rodney> cert to use given this payload...) > > Rodney, you ask such difficult questions. > > In my mind, this is useful only during phase II. > That should eliminate the need for this question since the ID field > to be compared to the certificate would be the one used in phase I. > > If you want to use this in phase I, then I think you need Kent's > work on delegating ownership of IP address ranges. The things > in the list > much all be covered by one or more certificates. > > [i.e. if I ask for a list of ports that I wish to protect, > then I can do it > with a certificate that only has my IP address in it. Asking > for a list of > ports would be quite reasonable for FTP-like applications, > although perhaps > not FTP itself] > > > :!mcr!: | Network and security > consulting/contract programming > Michael Richardson | Firewalls, TCP/IP and Unix > administration > Personal: > http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bi o.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgLYE9iXVu0RiA21AQERCgL/Y0djVSU4N2JdRa/X2i70AbfYIQH3wbGc vm1Ms5122aoIgctLFd1cfb0e4MDykvuFxZqq4q/Yqc3wv7W35m+BGl9SJ9O/RlpX bwB0WyjP/FpKVa5QJutSpHAHAa9XsVKB =z5zD -----END PGP SIGNATURE----- ------_=_NextPart_001_01BDE574.F6DBDA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: multiple payloads via "ID_LIST"

The idea was to have the ability of setting up one SA = for multiple source and destinations instead of having to setup = multiple SAs for these combinations that would all have the same SA = parameters.  If you consider a group of non-adjacent nodes part of = the same entity, then why can't we identify these nodes in an ID = payload?

For example:

If in my policy I had placed (a) 10.0.0.1, (b) = 10.0.1.*, (c) 10.0.2.* all in the same object (O1) and I had (d) = 11.0.0.*, (e) 11.0.1.* in another object (O2) and I want to set up a = tunnel between those two objects. 

Right now I would have to setup 6 SAs (a->d, = a->e, b->d, d->e, c->d, c->e), even though that only one = policy rule exists between these two objects (O1->O2).  =

A better approach would be to have a MetaID type that = can accomodate multiple ID types.  Then I could setup one SA per = (logical) policy rule instead of the physical network = layout.

When you add ports to this picture, it seams even = more important to create a MetaID type.

> -----Original Message-----
> From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.o= n.ca]
> Sent: Friday, September 18, 1998 6:01 PM
> To: ipsec@tis.com
> Subject: multiple payloads via = "ID_LIST"
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Rodney" =3D=3D = Rodney Thayer <rodney@tillerman.nu> writes:
>
>     Rodney> I like = this.  What would you want the cert to have in it?
>     Rodney> (Again, all = I'm asking is how you want people to
> decide which
>     Rodney> cert to use = given this payload...)
>
>   Rodney, you ask such difficult = questions.
>
>   In my mind, this is useful only = during phase II.
>   That should eliminate the need for = this question since the ID field
> to be compared to the certificate would be the = one used in phase I.
>
>   If you want to use this in phase I, = then I think you need Kent's
> work on delegating ownership of IP address = ranges. The things
> in the list
> much all be covered by one or more = certificates.
>
>   [i.e. if I ask for a list of ports = that I wish to protect,
> then I can do it
> with a certificate that only has my IP address = in it. Asking
> for a list of
> ports would be quite reasonable for FTP-like = applications,
> although perhaps
> not FTP itself]
>
>
>    = :!mcr!:           = ; |  Network and security
> consulting/contract programming
>    Michael Richardson = |         Firewalls, TCP/IP and = Unix
> administration
>  Personal:
> http://www.sandelman.ottawa.on.ca/People/Michael_Richa= rdson/Bi
o.html
 Corporate: http://www.sandelman.ottawa.on.ca/SSW/
        ON = HUMILITY: To err is human, to moo bovine.






-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP = interface

iQB1AwUBNgLYE9iXVu0RiA21AQERCgL/Y0djVSU4N2JdRa/X2i70AbfYIQH3wbG= c
vm1Ms5122aoIgctLFd1cfb0e4MDykvuFxZqq4q/Yqc3wv7W35m+BGl9SJ9O/Rlp= X
bwB0WyjP/FpKVa5QJutSpHAHAa9XsVKB
=3Dz5zD
-----END PGP SIGNATURE-----

------_=_NextPart_001_01BDE574.F6DBDA50-- From owner-ipsec Mon Sep 21 17:32:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA18794 for ipsec-outgoing; Mon, 21 Sep 1998 17:30:56 -0400 (EDT) Message-ID: <3606CA41.A9DEAD54@redcreek.com> Date: Mon, 21 Sep 1998 14:50:57 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" References: <199809182200.SAA08862@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Somehow this never made it to the list yesterday, so I'm re-posting in a slightly altered form: Michael C. Richardson wrote: > I have a better suggestion: > ID_LIST > and just put multiple ID payloads inside... why complicate things? > I'm still thinking about your proposal, and while I like the simplicity, there is one remaining issue: neither my nor your proposal addresses port/protocol lists. This is a difficult issue, because these are currently tied to the other address type payloads. My thinking up to this point uncovers no simple, clean way to add these without either altering existing payloads (which is almost certain to provoke strong resistance), or adding new ones. Have you considered this problem? Scott From owner-ipsec Tue Sep 22 09:44:07 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21302 for ipsec-outgoing; Tue, 22 Sep 1998 09:40:41 -0400 (EDT) Message-Id: <199809220941.CAA05240@fusebox.pgp.com> X-Sender: wprice@enigma.cyphers.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 22 Sep 1998 02:44:31 -0700 To: ipsec@tis.com From: Will Price Subject: Quick Mode For Multiple SAs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm puzzled over the various descriptions throughout the IPSEC documents with regards to negotiating multiple SAs simultaneously. The IKE document says (5.5): Using Quick Mode, multiple SA's and keys can be negotiated with one exchange as follows: [exchange with each packet containing multiple SA payloads] Yet a page or two before that it says: The message ID in the ISAKMP header identifies a Quick Mode in progress for a particular ISAKMP SA which itself is identified by the cookies in the ISAKMP header. And: it is possible to have multiple simultaneous Quick Modes, based off a single ISAKMP SA, in progress at any one time. Yet, in a seemingly contradictory statement, the ISAKMP document says (4.2): If the SA establishment negotiation is for a combined protection suite consisting of multiple protocols, then there MUST be multiple Proposal payloads each with the same Proposal number. These proposals MUST be considered as a unit and MUST NOT be separated by a proposal with a different proposal number. So, based on the above, there are now three somewhat contradictory ways of negotiating multiple SAs at roughly the same time: 1] Perform multiple Quick Mode exchanges 2] Transmit multiple SA payloads in each packet [violating the ISAKMP requirement] 3] Use multiple proposals with the same proposal number in one SA payload (IMHO, the logical choice...) And so, I suppose it really comes down to what the implementations are actually doing. If someone wants to negotiate ESP with IPCOMP, do we use 1, 2, or 3? Using number 1 seems fairly non-functional since it results in timing confusion as to which protocol is layered on top of the other in addition to simply being much slower to negotiate. Number 2 violates ISAKMP and makes packet parsing more difficult. Number 3 is logical, but since the IKE document seems to recommend number 2, it remains unclear what to do. -Will From owner-ipsec Tue Sep 22 10:57:07 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA21632 for ipsec-outgoing; Tue, 22 Sep 1998 10:55:36 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809221514.IAA24029@kc.livingston.com> Subject: Re: Network World article on IPSec To: aha@East.Sun.COM Date: Tue, 22 Sep 1998 08:14:03 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <13825.10238.405302.938512@saguaro> from "Anne Anderson - Sun Microsystems" at Sep 17, 98 11:43:20 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > An 8/24/98 article by Ellen Messmer in Network World titled "The > remaking of IPSec" claims that IPSec and IKE are not ready for prime > time, and that productization needs to wait for IPSecond. This is > not the impression I have gotten from talking to vendors and from > following the ipsec mailing list. > I havent looked at the article. But, my comments below based on the items you list. > Can anyone fill me in on details of some of the following claims > from the article? Please reply directly to me (aha@East.sun.com), > and I will summarize the responses to the list. > > 1. "The harder IPSec change will be standardizing on an IPSec remote > client. The goal of the IETF meeting is to define a client that > can support IP address changes automatically." > > [Anne] To what extent is this a barrier to deployment of the > existing IPSec? Only in NAT environments? If you make the assumption that Internet owes its current popularity to wide deployment of remote access, it is perhaps not unreasonable for the editor to state that Statdardizing on IPsec for remote accesss clients (in IPsecond) is a big step forward. Below are a couple of issues that need to be looked into in IPsecond. A. Use of existing Auth. data bases. IKE needs to support existing authentication mechanisms for remote clients. Also, IKE needs to support asymmetrical authentications for edge devices and remote users. B. Ability to support clients (IDs) that change IP addresses. A remote access client may have the same ID, but may assume a different IP address each time the client connects to the network. So, it is important to remove ties between client's ID and the IP address it may assume. (So far as I know, this is an issue only with [PSK + main mode]) > > 2. "Another difficult item on this week's agenda will be redefining > the core IKE protocol. Security experts recently uncovered a > flaw related to the improper exposure of information." > > [Anne] Is this referring the discussion about exposure of > identities during IKE negotiation in Pre-Shared-Key-Auth Main > Mode? Is this really a barrier to deployment? I am not sure what this is about. I dont believe, it has to do with PSK and main mode. [PSK and main mode] exposes the IP address of the ID (that is one-to-one tied to); not necessarily the ID itself. Even if it did, I dont see that as an issue with exposure of session info. There could be improper exposure (or unauthorised encryption) of information when policies on either end do not exactly match. But, I dont know if this is what the author is talking about. Addition of policy type payload and removing overloaded semantics of ID payload in Quick mode could possibly be conceived as redefining core protococol. Currently, there isnt a policy type payload defined in IKE. ID payload in quick mode is overloaded to imply policy info. Even that couldnt pass for a policy because at best it describe a portion of policy that pertains to source side or destination side. Policy has to be a combination of both source and destination set of selectors. I believe, IPsecond is expected to address this issue. > > 3. "And IKE, as it now exists, handles time-expiration of session > keys in a way that could cause one gateway not to understand > another." > > [Anne] Is this referring to the use of kbytes-based lifetime > payloads versus seconds-based lifetime payloads? To what extent > is this a barrier to deployment? Does it just cause a delay, or > is it a Big Problem? Lifetime issue is quite relevant to remote access. Remote access clients are prone to logging in frequently (as opposed to attached to the net all the time). The existing lifetime metrics do not guarantee that an SA established for one user does not get deleted when the user terminates the connection. Clearly, IKE on either end should clean up SAs when network-login is terminated. A new metric like "network-connected-time" would be useful for remote access users. Also, interoperability issues with regard to session rekeying upon lifetime expiry should be addressed independent of remote access clients. > -- > Anne Anderson Email: aha@east.sun.com > Sun Microsystems Laboratories or: aha@acm.org > 2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928 > Chelmsford, MA 01824 USA Fax: (978) 250-5067 > > > cheers, suresh From owner-ipsec Tue Sep 22 13:46:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA22202 for ipsec-outgoing; Tue, 22 Sep 1998 13:41:46 -0400 (EDT) Message-Id: <199809221751.NAA10291@istari.sandelman.ottawa.on.ca> From: mcr@solidum.com To: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Mon, 21 Sep 1998 14:50:57 PDT." <3606CA41.A9DEAD54@redcreek.com> Date: Tue, 22 Sep 1998 13:51:23 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> I'm still thinking about your proposal, and while I like the Scott> simplicity, there is one remaining issue: neither my nor your Scott> proposal addresses port/protocol lists. This is a difficult issue, I keep thinking we already have that. But, we don't have port/protocol in IKE yet, correct? Perhaps we need to have two types of ID_LIST: AND and OR. Add to that ID_IPV4_PROTOCOL, ID_IPV6_PROTOCOL, ID_TRANSPORT_PORT. Thus, to negotiate a secure Telnet session, one says gives one end as being: src: ID_AND_LIST: [ID_IPV4_ADDR: client, ID_IPV4_PROTOCOL: TCP, ID_TRANSPORT_PORT: 65418] dst: ID_AND_LIST: [ID_IPV4_ADDR: server, ID_IPV4_PROTOCOL: TCP, ID_TRANSPORT_PORT: 23] Scott> is almost certain to provoke strong resistance), or adding new Scott> ones. Have you considered this problem? I think we have to add new ones. { One alternative is a declarative packet description language (an internet draft describing ours will be published very soon): "ip4TcpConn(client, server, 65418, 23)" } :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgfjmNiXVu0RiA21AQEt0gL/cDyW1vYud0AWtOuK3EhJW+HbnZbuJacT eXyex18PVRYDfYou7Z/HI2ez9Y4EKTHdsIG39oEcgRMO3G6Ml0PPWyaGkGCl4sFx 8XJSYPbS6A/gE+gZQj+jWyfwkJknpVBX =bZ+Z -----END PGP SIGNATURE----- From owner-ipsec Tue Sep 22 14:58:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA22512 for ipsec-outgoing; Tue, 22 Sep 1998 14:55:53 -0400 (EDT) Message-ID: <3607F783.C86AB162@redcreek.com> Date: Tue, 22 Sep 1998 12:16:19 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: mcr@solidum.com CC: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk mcr writes: > >>>>> "Scott" == Scott G Kelly writes: > Scott> I'm still thinking about your proposal, and while I like the > Scott> simplicity, there is one remaining issue: neither my nor your > Scott> proposal addresses port/protocol lists. This is a difficult > > I keep thinking we already have that. But, we don't have > port/protocol > in IKE yet, correct? > We have them, but we only permit one port/protocol pair in the ID payload, e.g. the ID_IPV4_ADDR payload: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol | Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IP Address ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Perhaps we need to have two types of ID_LIST: AND and OR. > Add to that ID_IPV4_PROTOCOL, ID_IPV6_PROTOCOL, ID_TRANSPORT_PORT. > > Thus, to negotiate a secure Telnet session, one says gives one end as > being: > src: ID_AND_LIST: > [ID_IPV4_ADDR: client, ID_IPV4_PROTOCOL: TCP, > ID_TRANSPORT_PORT: 65418] > > dst: ID_AND_LIST: > [ID_IPV4_ADDR: server, ID_IPV4_PROTOCOL: TCP, > ID_TRANSPORT_PORT: 23] > > Scott> is almost certain to provoke strong resistance), or adding new > Scott> ones. Have you considered this problem? > > I think we have to add new ones. > > { One alternative is a declarative packet description language (an > internet draft describing ours will be published very soon): > "ip4TcpConn(client, server, 65418, 23)" > } The ID_AND_LIST + ID_TRANSPORT_PORT payloads may resolve this issue, but we should think a bit more about this. It could get a bit ugly if someone starts mixing these up with existing ID payloads that contain ports/protocols, and I'm not sure (without giving it a lot more thought) that we won't break something. As an aside, we're ignoring the overloaded-id-payload arguments here... From owner-ipsec Tue Sep 22 15:16:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA22591 for ipsec-outgoing; Tue, 22 Sep 1998 15:15:51 -0400 (EDT) Message-Id: <199809221933.PAA11998@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Tue, 22 Sep 1998 12:16:19 PDT." <3607F783.C86AB162@redcreek.com> Date: Tue, 22 Sep 1998 15:33:02 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> mcr writes: >> >>>>> "Scott" == Scott G Kelly writes: Scott> I'm still thinking about your proposal, and while I like the Scott> simplicity, there is one remaining issue: neither my nor your Scott> proposal addresses port/protocol lists. This is a difficult > >> I keep thinking we already have that. But, we don't have port/protocol >> in IKE yet, correct? >> Scott> We have them, but we only permit one port/protocol pair in the ID Scott> payload, e.g. the ID_IPV4_ADDR payload: 1 2 3 0 1 2 3 4 5 6 7 8 9 Right. That isn't clear from a quick read of ipsec-doi (which I did before posting to double check). I.e. if you read sections 4.6.2.1-9 then the word "port" and "protocol" do not appear. Only the diagram in 4.6.2 mentions it, which is reasonable, but I missed it. One thought: for protocol == ICMP, is it reasonable that the "port" field be in fact two octets: type and code? Do we really need port ranges? I.e. is there a situation where you want a range, but not all ports? The only situation I can think of is something like: A<------>B all ports, ESP with DES A<------>B port 23, ESP with 3DES And that can be negotiated just fine, since the specific port address should take priority in the SPD over the port wildcard. Scott> The ID_AND_LIST + ID_TRANSPORT_PORT payloads may resolve this Scott> issue, but we should think a bit more about this. It could get a Scott> bit ugly if someone starts mixing these up with existing ID Scott> payloads that contain ports/protocols, and I'm not sure (without Scott> giving it a lot more thought) that we won't break something. Agreed. Maybe the other types are not valid unless you set the protocol/port to wildcard. Do we have transports that require more than two bytes for "port"??? Hmm. YES! ESP/AH! Scott> As an aside, we're ignoring the overloaded-id-payload arguments Scott> here... Please elucidate, I don't follow. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgf7a9iXVu0RiA21AQH0nwL+L3ETP0g7rE2zOxj/J6YbRSxG7XyY79S5 hrVpHnRhPhIW47LAQCAxivSGlJmoWU9BL8YlJhtBtTyiN961a1MCQQNk9n4yjOLd gbyVq+LSYlDIuKNSGz0o2gfG/WXwqVgV =8CxA -----END PGP SIGNATURE----- From owner-ipsec Tue Sep 22 15:50:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA22685 for ipsec-outgoing; Tue, 22 Sep 1998 15:49:52 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809222008.NAA23312@kc.livingston.com> Subject: Re: issues with IKE that need resolution To: dharkins@cisco.com (Daniel Harkins) Date: Tue, 22 Sep 1998 13:08:38 -0700 (PDT) Cc: rodney@tillerman.nu, skelly@redcreek.com, ipsec@tis.com In-Reply-To: <199809180411.VAA26312@chip.cisco.com> from "Daniel Harkins" at Sep 17, 98 09:11:43 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Is there a point in identifying yourself as "198.31.2.0/24"? What > does that mean? "I speak for this network"? Without something like the KX > record in DNS to delegate that authority why should I belive it? Chances > are he'd probably be making this statement through another interface anyway > so what should I do if 198.31.1.18 says "I'm 198.31.2.0/24"? Also, what are > you going to do about the ID_KEY_ID identity? A certificate that certifies > that my identity is an intentionally incomprehensible blob is not going > to be all that useful. > I agree. I dont see much point in having IDs for address ranges and transport IDs and so forth. Single address (or multiple addresses for a multi-homed node) based IDs seem to be the only valid IDs (be it for phase I or phase II). Even then, it is interesting to note that some of the IDs (such as user name) are relevant only for IKE acting as a responder. ID types that may be used to initiate IKE session are only those for which there exists a way to match the ID to IP address (such as using DNS for FQDN ID and Certs to map a DN to IP address) It would be nice to have this documented. > It seems to me that we have identities that are only useful in phase 1 and > some of those should have ways to be encoded into a cert. There are others > that really only make sense in phase 2 because their purpose is to > constrain use of an IPSec SA. As an example, a gateway product receiving > phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr = > "ID_FQDN dharkins@cisco.com" would not be particularly useful. What > does "dharkins@cisco.com" mean? There is no machine cisco.com and there > sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and > a way to encode it in a cert is good. But passing it in phase 2 would not > make much sense. Similarly, a list of subnets is not a very good phase 1 > identity and I don't see much value in defining a way to encode that in a > cert but as a phase 2 identity it may be quite useful. Or am I missing > something here? > I agree, ID payload is predominantly useful in phase 1. However, there is need for ID payload in phase II as well. When the IP address of client for which IKE is negotiating is different from that of IKE itself, it is necessary for IKE to identify the client ID in phase II, (just as it specifies the ID for itself in phase I). What we need is a new type of policy payload in phase II. > Addressing Scott's point: the ID payload is woefully overloaded. We're > trying to express SPD policy in it and that was not its original purpose. > If I remember correctly Steve Kent removed some selector types from the > Architecture Draft because IKE was unable to express them. It would not > only be nice to have lists of address ranges, it would be nice to express > the "everything but" construct: "this SA is to be used for all TCP except > port 80". But I'm not sure the poor ID payload is the place to do it. > > Anybody have any ideas on how to express policy _right_? At the TrustMgt > BOF in Chicago KeyNote was presented and that seems like a good start. > Actions are described as attribute-value pairs. IKE expresses attribute-value > pairs quite well. If we had a good way to define desired actions ("I'd > like to access your ftp server on machine A and your http server on machine > B and C") we could apply a request for those actions-- a series of > attribute-value pairs in some new payload-- to the collection of assertions > we have that define our local policy ("only may > access our ftp server and all other TCP ports except telnet can be accessed > by anyone except and RIP goes in the clear"). > > I think the whole phase 2 identity stuff needs some serious revisiting > and alot more than just defining new types. > > Dan. > Once again, I generally agree with what is said here. I was at the Trust Mgmt BOF. But, I didnt come away with any definitive feeling of how the BOF was going to proceed and what the general aproach was going to be. >From the IKE stand point, I believe, we need to be able to do the following: (1) Identify one or more policies associated with an SA. Each Policy needs to be assigned an ID, to identify with during the lifetime of SA (or, its extended lifetime). Policy could be as simple as: PERMIT [] [] [] If there is rough consensus on this approach, I dont see a problem with coming up with a payload format to represent policies. (2) Ability to add/delete policies dynamically to an SA. This would be particularly useful when some applications require policy changes on the fly. Ex: Take a policy that requires encryption on H.323 application sessions. The signalling protocol in H.323 sets up sessions dynamically and these dynamic sessions need to be notified so that all such sessions are supported by IPsec. <... snip> cheers, suresh From owner-ipsec Tue Sep 22 16:39:00 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA22809 for ipsec-outgoing; Tue, 22 Sep 1998 16:37:53 -0400 (EDT) Message-ID: <36080F5C.5E886D02@redcreek.com> Date: Tue, 22 Sep 1998 13:58:04 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Michael C. Richardsom" CC: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" References: <3608096F.D5C56A69@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > Do we really need port ranges? I.e. is there a situation where you want > a range, but not all ports? The only situation I can think of is something > like: > A<------>B all ports, ESP with DES > A<------>B port 23, ESP with 3DES > > And that can be negotiated just fine, since the specific port address > should take priority in the SPD over the port wildcard. > It could be argued that you might have different policies (under some circumstances) for 'privileged' ports (for example). > Scott> As an aside, we're ignoring the overloaded-id-payload arguments > Scott> here... > > Please elucidate, I don't follow. > In an earlier email, Dan said > Addressing Scott's point: the ID payload is woefully overloaded. We're > trying to express SPD policy in it and that was not its original purpose. > If I remember correctly Steve Kent removed some selector types from the > Architecture Draft because IKE was unable to express them. It would not > only be nice to have lists of address ranges, it would be nice to express > the "everything but" construct: "this SA is to be used for all TCP except > port 80". But I'm not sure the poor ID payload is the place to do it. I think the general 'overload' argument may hinge on the fact that what's being represented in phase 1 by the ID payload is different than what's being represented in phase 2. While I think semantic arguments could be made on either side, I will point out that using the ID payload in phase 1 would appear to contradict the notion that DOI-specific issues only relate to phase 2. In the ISAKMP-10 doc, the following text appears on page 31: ------------ 3.8 Identification Payload The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authen- ticity of information. Figure 9 shows the format of the Identification Payload. ------------ This would tend to indicate a conflict with current usage, i.e. that the ID payload should not be used at all in phase 1. Scott From owner-ipsec Tue Sep 22 17:20:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA22968 for ipsec-outgoing; Tue, 22 Sep 1998 17:19:51 -0400 (EDT) Message-Id: <199809222137.RAA15943@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Tue, 22 Sep 1998 13:58:04 PDT." <36080F5C.5E886D02@redcreek.com> Date: Tue, 22 Sep 1998 17:37:12 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> In an earlier email, Dan said >> Addressing Scott's point: the ID payload is woefully overloaded. We're >> trying to express SPD policy in it and that was not its original >> purpose. If I remember correctly Steve Kent removed some selector >> types from the Architecture Draft because IKE was unable to express >> them. It would not only be nice to have lists of address ranges, it >> would be nice to express the "everything but" construct: "this SA is >> to be used for all TCP except port 80". But I'm not sure the poor ID >> payload is the place to do it. Scott> I think the general 'overload' argument may hinge on the fact that Scott> what's being represented in phase 1 by the ID payload is different Scott> than what's being represented in phase 2. While I think semantic Okay, I remember this discussion. Given this, I will change my opinion: we should leave the ID payload alone and define a new payload for phase II in ISAKMP version 1.1. If we need to define one or two additional payloads to solve actual problems that we honestly have *now*, that is fine, but I think we should think about a better solution. Perhaps we need to wait for some of the Policy WG people to advance a bit on admission policy to other things. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNggYhdiXVu0RiA21AQEqagL+OTGovxDtUvBco8h6+q+dQeI/NaH7S1Oh Rzxt5nII0zvpVWzHFROroT8CHeXeXZ8+O987WMcxAXO5EjEDsgZk3Yfkng9TM7Lj lBI1jsD6lG9yza5E+d6oJ5bpFESRQWdu =KjMk -----END PGP SIGNATURE----- From owner-ipsec Tue Sep 22 18:27:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA23160 for ipsec-outgoing; Tue, 22 Sep 1998 18:24:52 -0400 (EDT) Message-ID: <360827FB.BADFA2AB@redcreek.com> Date: Tue, 22 Sep 1998 15:43:07 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: Daniel Harkins , rodney@tillerman.nu, ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <199809222008.NAA23312@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > Dan Harkins wrote: > > > > Is there a point in identifying yourself as "198.31.2.0/24"? What > > does that mean? "I speak for this network"? Without something like the KX > > record in DNS to delegate that authority why should I belive it? Chances > > are he'd probably be making this statement through another interface anyway > > so what should I do if 198.31.1.18 says "I'm 198.31.2.0/24"? Also, what are > > you going to do about the ID_KEY_ID identity? A certificate that certifies > > that my identity is an intentionally incomprehensible blob is not going > > to be all that useful. > > > > I agree. I dont see much point in having IDs for address ranges and > transport IDs and so forth. Single address (or multiple addresses for > a multi-homed node) based IDs seem to be the only valid IDs (be it for > phase I or phase II). Disagree. Ranges of addresses (etc.) are extremely useful identifiers for a security gateway which is representing those within the range. As for Dan's question, > > Is there a point in identifying yourself as "198.31.2.0/24"? What > > does that mean? "I speak for this network"? Without something like Yes, "I speak for this network" is *exactly* what it means, and you don't need a kx record or anything like it to verify my veracity. Instead, you need a way to indicate in your policy entry that I am an authorized proxy in this case. I guess you *could* use a kx record if you want to, but that's an implementation detail. Dan wrote: > > It seems to me that we have identities that are only useful in phase 1 and > > some of those should have ways to be encoded into a cert. There are others > > that really only make sense in phase 2 because their purpose is to > > constrain use of an IPSec SA. As an example, a gateway product receiving > > phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr = > > "ID_FQDN dharkins@cisco.com" would not be particularly useful. What > > does "dharkins@cisco.com" mean? There is no machine cisco.com and there > > sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and > > a way to encode it in a cert is good. But passing it in phase 2 would not > > make much sense. Similarly, a list of subnets is not a very good phase 1 > > identity and I don't see much value in defining a way to encode that in a > > cert but as a phase 2 identity it may be quite useful. Or am I missing > > something here? > > > > I agree, ID payload is predominantly useful in phase 1. However, there > is need for ID payload in phase II as well. When the IP address of client > for which IKE is negotiating is different from that of IKE itself, it is > necessary for IKE to identify the client ID in phase II, (just as it > specifies the ID for itself in phase I). > > What we need is a new type of policy payload in phase II. I agree that we may need different payloads for the 2 phases, but think we need to reconcile the issue I raised in a related post, i.e. that the ID payload is, by definition, DOI-specific, and this (I think) means it's a phase 2 critter only. In that case, the new payload type would need to be in phase 1, or the appropriate language in the ISAKMP doc would need correcting. > >From the IKE stand point, I believe, we need to be able to do the following: > > (1) Identify one or more policies associated with an SA. > Each Policy needs to be assigned an ID, to identify with > during the lifetime of SA (or, its extended lifetime). Policy > could be as simple as: > > PERMIT > [] [] > [] > > If there is rough consensus on this approach, I dont see a problem > with coming up with a payload format to represent policies. > I strongly disagree with your assertion, if I understand it correctly. Individual policies are a local matter and should NEVER be sent across the link, but should be somehow indexable based on conversational context. We currently use either the ID payload or the IP header contents to index these. We may also use certificates, FQDNs, and whatever else is defined in for the ID payload, and this whole (sub)thread started as a result of the assertion that we need other indices. I still don't understand this resistance to using some sort of endpoint identifier to index policy - after all, we are using an identity-based security model, right? > (2) Ability to add/delete policies dynamically to an SA. > > This would be particularly useful when some applications > require policy changes on the fly. Ex: Take a policy that requires > encryption on H.323 application sessions. The signalling protocol > in H.323 sets up sessions dynamically and these dynamic sessions > need to be notified so that all such sessions are supported by > IPsec. > Again, I'm not sure I understand what you mean here, but will point out that it is possible to share an existing SA, and [ARCH] gives the details. However, difficulties arise if you negotiate the SA for 2 specific endpoints using IKE, then want to try to piggyback others (whose selectors will not match upon decryption) onto the session if both sides do not strictly comply with description in [ARCH]. Again, though, these are local implementation issues, I think. Scott From owner-ipsec Tue Sep 22 19:25:18 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA23349 for ipsec-outgoing; Tue, 22 Sep 1998 19:24:51 -0400 (EDT) Message-ID: <36083693.CD927E23@redcreek.com> Date: Tue, 22 Sep 1998 16:45:23 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" References: <199809222137.RAA15943@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > Okay, I remember this discussion. > Given this, I will change my opinion: we should leave the ID payload alone > and define a new payload for phase II in ISAKMP version 1.1. If we need to > define one or two additional payloads to solve actual problems that we > honestly have *now*, that is fine, but I think we should think about > a better solution. Perhaps we need to wait for some of the Policy WG people > to advance a bit on admission policy to other things. I agree that we should work on a more comprehensive solution. However, we need this capability yesterday, and I'm sure other vendors do as well. I guess I'm trying to prod some forward movement on this. This was tossed out as a work item for ipsecond, but no clear course of action was agreed upon. I guess the appropriate thing at this point is to look to our chairs for guidance/direction. Bob, Ted, what say ye? Scott From owner-ipsec Tue Sep 22 19:38:49 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA23385 for ipsec-outgoing; Tue, 22 Sep 1998 19:36:53 -0400 (EDT) Message-Id: <199809222354.TAA16116@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Tue, 22 Sep 1998 16:45:23 PDT." <36083693.CD927E23@redcreek.com> Date: Tue, 22 Sep 1998 19:54:45 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> I agree that we should work on a more comprehensive solution. However, Scott> we need this capability yesterday, and I'm sure other vendors do Okay, but tell us the policy you are currently unable to express, which you *need* to express *now*. (Ideally, have your customer tell us the policy) I'm trying to do: "if it ain't broke don't fix it" here, so we can get the time required to discuss a new payload and resolve whatever other issues that might need resolving for a 1.1 of ISAKMP. (No, I don't want to push a 1.1 any time soon) I should also point out that you can implement something custom: the vendor IDs and private payload space should provide for this. That way we'll have some experience in the field before we write something down as a standard. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgg4wtiXVu0RiA21AQH15QMAlrBcqget6fDLlPGOXZjw/EbEMdcsNm/X kzf2VMLcVqbEzO2YorH7HYt0DwV9hrJuRnmZoJNXPKYR0REWINoWSdTv3ZXV4jFl FfVWAgmO3RhHRiDQeFAuLvyPjIGu/r0v =ZsTs -----END PGP SIGNATURE----- From owner-ipsec Tue Sep 22 21:39:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA23573 for ipsec-outgoing; Tue, 22 Sep 1998 21:37:52 -0400 (EDT) Message-ID: <3608559C.ED0FC26C@redcreek.com> Date: Tue, 22 Sep 1998 18:57:48 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" References: <199809222354.TAA16116@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > > Okay, but tell us the policy you are currently unable to express, which > you *need* to express *now*. (Ideally, have your customer tell us the policy) > Here's an example from one of our customers: Z Y X W | | | | +=+ | | | | +=+ |a|-| | | |-|d| +=+ | +===+ | +=====+ +=====+ | +===+ | +=+ +-|RTR|-|--| SGW |------------| SGW |---|-|RTR|----| | +===+ | +=====+ +=====+ | +===+ | | | | | | | | | | +=+ | | +=+ |b|-| |-|c| +=+ | | +=+ Say Z and Y are subnets which can't be uniquely expressed together with a single bitmask, but which *can* be expressed with a range in the SPD. An example would be Z=10.3.0.0, Y=10.4.0.0, SPD source selector value = 10.3-4.0.0, however you choose to represent it. In this case, the subnet list is the only way to express both subnets in one payload, since there is no method for expressing such a range defined in the DOI. I guess an alternate solution to our proposals would be to try to come up with some way to express ranges and wildcards in the payload, but that seems even more complex... > I'm trying to do: "if it ain't broke don't fix it" here, so we can get > the time required to discuss a new payload and resolve whatever other issues > that might need resolving for a 1.1 of ISAKMP. > (No, I don't want to push a 1.1 any time soon) > > I should also point out that you can implement something custom: the vendor > IDs and private payload space should provide for this. That way we'll > have some experience in the field before we write something down as a > standard. I agree, and we are in the process of implementing the vendor payload/private payload solution. As I said, I'm just trying to give this issue a shove to the front burner... Scott From owner-ipsec Wed Sep 23 05:40:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA24635 for ipsec-outgoing; Wed, 23 Sep 1998 05:38:52 -0400 (EDT) Message-Id: <199809230956.CAA26172@chip.cisco.com> To: "Scott G. Kelly" cc: "Michael C. Richardson" , ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Tue, 22 Sep 1998 16:45:23 PDT." <36083693.CD927E23@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26170.906544570.1@cisco.com> Date: Wed, 23 Sep 1998 02:56:10 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Write a draft! Dan. On Tue, 22 Sep 1998 16:45:23 PDT you wrote > > I agree that we should work on a more comprehensive solution. However, > we need this capability yesterday, and I'm sure other vendors do as > well. I guess I'm trying to prod some forward movement on this. This was > tossed out as a work item for ipsecond, but no clear course of action > was agreed upon. I guess the appropriate thing at this point is to look > to our chairs for guidance/direction. Bob, Ted, what say ye? > > Scott From owner-ipsec Wed Sep 23 05:53:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA24651 for ipsec-outgoing; Wed, 23 Sep 1998 05:52:54 -0400 (EDT) Message-Id: <199809231010.DAA26303@chip.cisco.com> To: "Scott G. Kelly" cc: "Michael C. Richardson" , ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Tue, 22 Sep 1998 18:57:48 PDT." <3608559C.ED0FC26C@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26301.906545402.1@cisco.com> Date: Wed, 23 Sep 1998 03:10:02 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk If they needed it yesterday tell them to establish 2 SAs, one soley for X and the other soley for Y. It would be *nice* to be able to have a single one but I think this clearly falls in the "if it ain't broke..." category. It can be easily solved today (and yesterday too) using existing mechanisms. Dan. On Tue, 22 Sep 1998 18:57:48 PDT you wrote > Michael C. Richardson wrote: > > > > Okay, but tell us the policy you are currently unable to express, which > > you *need* to express *now*. (Ideally, have your customer tell us the polic >y) > > > > Here's an example from one of our customers: > > Z Y X W > | | | | > +=+ | | | | +=+ > |a|-| | | |-|d| > +=+ | +===+ | +=====+ +=====+ | +===+ | +=+ > +-|RTR|-|--| SGW |------------| SGW |---|-|RTR|----| > | +===+ | +=====+ +=====+ | +===+ | > | | | | > | | | | > | +=+ | | +=+ > |b|-| |-|c| > +=+ | | +=+ > > > Say Z and Y are subnets which can't be uniquely expressed together with > a single bitmask, but which *can* be expressed with a range in the SPD. > An example would be Z=10.3.0.0, Y=10.4.0.0, SPD source selector value = > 10.3-4.0.0, however you choose to represent it. In this case, the subnet > list is the only way to express both subnets in one payload, since there > is no method for expressing such a range defined in the DOI. I guess an > alternate solution to our proposals would be to try to come up with some > way to express ranges and wildcards in the payload, but that seems even > more complex... > > > I'm trying to do: "if it ain't broke don't fix it" here, so we can get > > the time required to discuss a new payload and resolve whatever other issue >s > > that might need resolving for a 1.1 of ISAKMP. > > (No, I don't want to push a 1.1 any time soon) > > > > I should also point out that you can implement something custom: the vend >or > > IDs and private payload space should provide for this. That way we'll > > have some experience in the field before we write something down as a > > standard. > > I agree, and we are in the process of implementing the vendor > payload/private payload solution. As I said, I'm just trying to give > this issue a shove to the front burner... > > Scott From owner-ipsec Wed Sep 23 10:09:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA25663 for ipsec-outgoing; Wed, 23 Sep 1998 10:06:53 -0400 (EDT) Message-Id: <199809231423.KAA10319@penelope.ve3tla.ampr.org> To: Will Price cc: ipsec@tis.com Subject: Re: Quick Mode For Multiple SAs References: <199809220941.CAA05240@fusebox.pgp.com> In-reply-to: Your message of "Tue, 22 Sep 1998 05:44:31 -0400". <199809220941.CAA05240@fusebox.pgp.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10314.906560629.1@penelope.ve3tla.ampr.org> Date: Wed, 23 Sep 1998 10:23:49 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199809220941.CAA05240@fusebox.pgp.com>, Will Price writes: > I'm puzzled over the various descriptions throughout the IPSEC documents > with regards to negotiating multiple SAs simultaneously. It sounds like you are confused by the difference between negotiating multiple separate SAs (i.e. two separate ESP SAs), and negotiating multiple, *linked* SAs (i.e. ESP and IPCOMP). > > So, based on the above, there are now three somewhat contradictory ways of > negotiating multiple SAs at roughly the same time: > > 1] Perform multiple Quick Mode exchanges This creates separate SAs, obviously. > 2] Transmit multiple SA payloads in each packet [violating the ISAKMP > requirement] This also creates separate SAs. This does not violate ISAKMP, btw. The ISAKMP requirement is that *linked* SAs must be listed together. So if you're negotiating ESP with IPCOMP, you must send a single SA, with two proposals that have the same proposal number; this is how the remote knows that you want the two SAs linked together. > 3] Use multiple proposals with the same proposal number in one SA payload > (IMHO, the logical choice...) Yep, for what you want. > And so, I suppose it really comes down to what the implementations are > actually doing. If someone wants to negotiate ESP with IPCOMP, do we use > 1, 2, or 3? You *must* use 3 for this case. The other two options create SAAs that are not related to each other in any way (i.e. two applications that want unique keying, or an implementation that wants to negotiate multiple SAs, where each SA is activated when a previous one expires). -- Harald From owner-ipsec Wed Sep 23 11:13:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA25886 for ipsec-outgoing; Wed, 23 Sep 1998 11:11:53 -0400 (EDT) From: Anne Anderson - Sun Microsystems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 Sep 1998 08:51:19 -0400 (EDT) To: ipsec@tis.com Subject: Summary of responses: Network World article on IPSec X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13832.60550.662248.344722@saguaro> Sender: owner-ipsec@ex.tis.com Precedence: bulk As promised, here is the summary of responses I received regarding the 8/24/98 article by Ellen Messmer in Network World titled "The Remaking of IPSec". I have abbreviated a few technical details that went beyond the scope, and omitted a few ad hominem comments. One responder asked not to be quoted, so that response is listed as "anonymous". Thank you all for your help. -Anne Anderson [Bob Moskowitz (ANX, ICSA), co-chair of IPSec WG]: I spent an hour with Ms. Messmer to help her 'get it right' and was seriously mis-quoted. So badly in fact, that I doubt I will ever speak to her again and perhaps her magazine (dispite what my company PR person says I should do). [Scott Kelly (RedCreek)]: I'm sure Bob Moskowitz will respond to you, but since Ellen interviewed me as well (and ignored what I said), I'll toss in my 2 cents worth. Let me preface this by saying that my impression was that Ellen's mind was made up as to the answers to the questions she asked me before she ever asked them, and her article reflects her mindset at that time. I'll also add that I was sitting near Bob at the PKIX meeting when he came upon the article, and he immediately made a phone call to disclaim the article. That said, I'll address your questions. Note that this is my personal take, but I think you'll find strong agreement with other responses you receive. >An 8/24/98 article by Ellen Messmer in Network World titled "The >remaking of IPSec" claims that IPSec and IKE are not ready for prime >time, and that productization needs to wait for IPSecond. This is >not the impression I have gotten from talking to vendors and from >following the ipsec mailing list. [Steven Bellovin (AT&T), co-chair of IPSec WG]: She's wrong, in my opinion. [Bob Moskowitz]: Total mis-representation on her part. I spent a lot of time hammering the point that IPsec baseline was done and a lot will be done with that, even hot-to-host. But that, yes, with any new protocol there was more work to iron out and some minor, non-trivial errata in IKE (nothing that would stop its use). [Michael Richardson, Sandelman]: Not only are there vendors that have been shipping for some *YEARS*, but there are numerous vendors that are ready now and have been shipping alphas and betas for some months. Dan McDonald told me that IPsec is ready to ship with Solaris 2.7 and select partners can get it for 2.6... [anonymous]: Has Ms. Messmer quoted any Microsoft people? It would be in Microsoft's interest to delay consumers from making choices until they are in the market with NT 5.0. [Derrell Piper (Network Alchemy)]: In my opinion, the article was editorially irresponsible. Either the author set out to write a negative article or else the author never bothered to check her facts with anyone who's actually fielded an implementation of IKE/IPSEC. >Can anyone fill me in on details of some of the following claims >from the article? Please reply directly to me (aha@East.sun.com), >and I will summarize the responses to the list. >------------------------------------------------------------------- >1. "The harder IPSec change will be standardizing on an IPSec remote > client. The goal of the IETF meeting is to define a client that > can support IP address changes automatically." > [Anne] To what extent is this a barrier to deployment of the > existing IPSec? Only in NAT environments? [Steven Bellovin]: It's important, but not critical, and can be handled by routine upgrades of products in the field. It's a DHCP-like issue -- do you have to assign static IP addresses to (say) telecommuters, or can they be assigned them dynamically. [Bob Moskowitz]: There are a number of 'features' that can be added to IKE (not IPsec) that will significantly strengthen its value for the remote client: Support of other authentication methods like Radius and challenge-response tokens (many companies wish to leverage off of existing identity infrastructure instead of first NEEDING to deploy X.509). Bootstrap or config, as Steve indicates. There is already an Internet Draft out on this which is say, 80% of what is needed and at least 3 companies have it in their product, it is so important to their customers. Standardizing this will not be particularly hard, depending on how much consensusing is done with the DIAMETER workers that are not as far along as us. Mobile IPsec (not quite mobile IP with security done right, but maybe all that is needed). This may well also address most if not all NAT items. [Michael Richardson]: Yes, we need to standardize this. It doesn't mean that you can't deploy product, only that the product won't be able to talk to multiple corporate firewalls at the same time and the client configuration may be more complicated at present. The result is that deploying 10000 clients in less than a year may be a challenge. Deploying 1000 won't be a problem. [Derrell Piper]: You're right, it's not. NAT is a known issue. For more information on NAT, see Steve Bellovin's many lucid posting on this issue in this archive. It's on the agenda for IPsecond. [Scott Kelly]: The remote client requires a different approach to policy description, in that the client's IP address is volatile and unpredictable in many cases. Currently under review are extensions to the authentication process which permit other identification mechanisms to be used in place of IP address. These include radius, certificates, and many other legacy authentication/authorization systems. This is not a barrier to deployment of ipsec, as my company has sold several large installations which include mobile clients at this time. It is a natural evolutionary process which may introduce interoperability issues periodically, pending completion of the design. It is a natural follow-on for the working group. [Pyda Srisuresh] If you make the assumption that Internet owes its current popularity to wide deployment of remote access, it is perhaps not unreasonable for the editor to state that Statdardizing on IPsec for remote accesss clients (in IPsecond) is a big step forward. Below are a couple of issues that need to be looked into in IPsecond. A. Use of existing Auth. data bases. IKE needs to support existing authentication mechanisms for remote clients. Also, IKE needs to support asymmetrical authentications for edge devices and remote users. B. Ability to support clients (IDs) that change IP addresses. A remote access client may have the same ID, but may assume a different IP address each time the client connects to the network. So, it is important to remove ties between client's ID and the IP address it may assume. (So far as I know, this is an issue only with [PSK + main mode]) >------------------------------------------------------------------- >2. "Another difficult item on this week's agenda will be redefining > the core IKE protocol. Security experts recently uncovered a > flaw related to the improper exposure of information." > > [Anne] Is this referring the discussion about exposure of > identities during IKE negotiation in Pre-Shared-Key-Auth Main > Mode? Is this really a barrier to deployment? [Bob Moskowitz]: No, but fixing it will result in a major revision change in IKE. Thus the next rev of IKE will be 2.0, not 1.1. [David Mason]: She might be referring, not to the improper exposure but, to the fact that the commit bit in the IKE header is not "protected" - it can be changed en route undetected which causes serious problems for the IKE negotiation. [Michael Richardson]: No. There are always improvements that can be made. That doesn't make the existing protocol insecure. [Derrell Piper]: Yes, that would be a difficult issue, had it been true. No one I spoke with seemed to know which "flaw" we're talking about. The general consensus was that the author incorrectly linked the PKCS encoding problem (i.e. the recent "SSL/RSA" bug) with IPSEC. As written however, that statement is completely unjustifiable and irresponsible. [Scott Kelly]: I think this refers to the fact that much of the IKE header is unprotected by the hash, i.e. unauthenticated, meaning that a highly skilled attacker with the ability to insert himself between you and the gateway during your IKE negotiation could modify IKE payloads, resulting in various denial-of-service attacks. Repairing this will introduce interoperability issues temporarily, but these should be minor and easily remedied. [Pyda Srisuresh] I am not sure what this is about. I dont believe, it has to do with PSK and main mode. [PSK and main mode] exposes the IP address of the ID (that is one-to-one tied to); not necessarily the ID itself. Even if it did, I dont see that as an issue with exposure of session info. There could be improper exposure (or unauthorised encryption) of information when policies on either end do not exactly match. But, I dont know if this is what the author is talking about. Addition of policy type payload and removing overloaded semantics of ID payload in Quick mode could possibly be conceived as redefining core protococol. Currently, there isnt a policy type payload defined in IKE. ID payload in quick mode is overloaded to imply policy info. Even that couldnt pass for a policy because at best it describe a portion of policy that pertains to source side or destination side. Policy has to be a combination of both source and destination set of selectors. I believe, IPsecond is expected to address this issue. >------------------------------------------------------------------- >3. "And IKE, as it now exists, handles time-expiration of session > keys in a way that could cause one gateway not to understand > another." > > [Anne] Is this referring to the use of kbytes-based lifetime > payloads versus seconds-based lifetime payloads? To what extent > is this a barrier to deployment? Does it just cause a delay, or > is it a Big Problem? [Steven Bellovin]: IKE will definitely need another round. And there's another issue -- as best I can tell, certificates don't interoperate between platforms. But both that and your point 3 won't affect people who use single-vendor solutions for now. [Bob Moskowitz]: No this islean up SAs when network-login is terminated. A new metric like "network-connected-time" would be useful for remote access users. Also, interoperability issues with regard to session rekeying upon lifetime expiry should be addressed independent of remote access clients. -- Anne Anderson Email: aha@east.sun.com Sun Microsystems Laboratories or: aha@acm.org 2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928 Chelmsford, MA 01824 USA Fax: (978) 250-5067 From owner-ipsec Wed Sep 23 13:13:50 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA26343 for ipsec-outgoing; Wed, 23 Sep 1998 13:10:54 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EE4A03@wade.reo.dec.com> From: Mark Gillott To: "'l2tp@zando.com'" , "'ipsec@tis.com'" Subject: VPN bakeoff in October & export licensing. Date: Wed, 23 Sep 1998 17:08:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there anyone out there from Europe that is planning to attend the VPN (IPsec/IKE/L2TP) bakeoff at Binghamption NY in October? A couple of us from the UK are planning to attend, but the question has been asked about U.S./U.K. export licensing. All our development is being done in the UK. Even though we're part of a U.S. company we're playing it safe and the code never leaves the UK - we're currently having discussions with the NSA as to how we can distribute the code within Cabletron. But what about the bakeoff? Does anyone have a view on what the NSA would say if we were to dial home (to the UK), fixed some bug or other and then copied a new image back to the workshop for further testing? From my understanding, the NSA are not concerned about importation (which this is). But what about the UK? Is the UK govt. going to get "upset" about us exporting from the UK? What about when we come to go home. Presumably we have remove all our test images from laptops/routers before we leave the US? Mark Gillott Cabletron Systems (DNPG) DTN: 831-3172, Phone: +44 191 497 3172 From owner-ipsec Wed Sep 23 14:30:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA26767 for ipsec-outgoing; Wed, 23 Sep 1998 14:30:56 -0400 (EDT) Message-Id: <3.0.5.32.19980923134737.009ddd50@mailhost.sctc.com> X-Sender: markham@mailhost.sctc.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 23 Sep 1998 13:47:37 -0500 To: Anne Anderson - Sun Microsystems , ipsec@tis.com From: Tom Markham Subject: Re: Summary of responses: Network World article on IPSec In-Reply-To: <13832.60550.662248.344722@saguaro> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:51 AM 9/23/98 -0400, Anne Anderson - Sun Microsystems wrote: SNIP > >[Bob Moskowitz (ANX, ICSA), co-chair of IPSec WG]: > >I spent an hour with Ms. Messmer to help her 'get it right' and was >seriously mis-quoted. So badly in fact, that I doubt I will ever >speak to her again and perhaps her magazine (dispite what my company >PR person says I should do). A number of years ago some general (I cannot remember his name) was quoted as saying: "Talking to the press is like mud wrestling with pigs. The pigs have a lot of fun and you get covered with mud." I guess Bob is not the first to be mis-quoted. Tom Markham From owner-ipsec Wed Sep 23 14:51:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA26875 for ipsec-outgoing; Wed, 23 Sep 1998 14:51:57 -0400 (EDT) Message-Id: <199809231909.PAA25948@istari.sandelman.ottawa.on.ca> To: Mark Gillott cc: "'l2tp@zando.com'" , "'ipsec@tis.com'" Subject: Re: VPN bakeoff in October & export licensing. In-reply-to: Your message of "Wed, 23 Sep 1998 17:08:25 BST." <250F9C8DEB9ED011A14D08002BE4F64C01EE4A03@wade.reo.dec.com> Date: Wed, 23 Sep 1998 15:09:15 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk Assuming you can get your code out of the UK, you can import it to the US. From the US it is legal to export printed (on paper) diffs. Yes, you need to wipe your code from your notebooks/routers. Note that there are usually phone booths with data ports after US customs when you are leaving, so you can download a fresh, unmodified copy, and start patching with your diff printouts back into your code on the transatlantic flight :-) [that might be illegal if you are flying a US airline] If you need to login to the UK to fix things, i.e. you can't bring a devel environment with you, then I suggest that you use the telephone to tell someone back home what to patch. Someone should organize a bakeoff in the Cayman or some other place with no laws. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Wed Sep 23 14:54:55 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA26923 for ipsec-outgoing; Wed, 23 Sep 1998 14:54:55 -0400 (EDT) Message-Id: <199809231912.PAA25959@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Summary of responses... In-reply-to: Your message of "Wed, 23 Sep 1998 10:57:42 PDT." <199809231757.KAA05476@kebe.eng.sun.com> Date: Wed, 23 Sep 1998 15:12:21 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >> Dan McDonald told me that IPsec is ready to ship with Solaris 2.7 >> and select partners can get it for 2.6... Turns out that I misunderstood Dan. Anne quoted me correctly. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Wed Sep 23 16:36:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27355 for ipsec-outgoing; Wed, 23 Sep 1998 16:28:56 -0400 (EDT) Date: Wed, 23 Sep 1998 16:45:53 -0400 (EDT) From: Henry Spencer To: Mark Gillott cc: IP Security List Subject: Re: VPN bakeoff in October & export licensing. In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EE4A03@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > But what about the bakeoff? Does anyone have a view on what the NSA would > say if we were to dial home (to the UK), fixed some bug or other and then > copied a new image back to the workshop for further testing? Beware: doing the bug fix on a UK machine from within the US exports the bug fix, i.e. it exports crypto code! Or at the very least, it exports technical advice on encryption. Probably not a good idea... > What about when we come to go home. Presumably we have remove all our test > images from laptops/routers before we leave the US? Correct. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Wed Sep 23 16:37:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27386 for ipsec-outgoing; Wed, 23 Sep 1998 16:35:55 -0400 (EDT) Message-ID: <36095D95.E49358AB@ire-ma.com> Date: Wed, 23 Sep 1998 16:44:05 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: QM/PFS/MultipleProposals/MultipleGroups question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Scenario: Initiator uses PFS and wants to make multiple proposals in QM, where each proposal offers different group. Therefore each proposal will contain different public key for each group proposed (e.g DH Group 1,2,3,....) Question: isn't it very wastefull to generate and send all these different public keys, while only one will be chosen by the responder? Wouldn't be much simpler to restrict Initiator to use only one group for all proposals it wants to make? -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Wed Sep 23 18:29:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27615 for ipsec-outgoing; Wed, 23 Sep 1998 18:28:00 -0400 (EDT) Date: Wed, 23 Sep 1998 18:51:19 -0700 (PDT) From: "Hilarie K. Orman" Message-Id: <199809240151.SAA18763@earth.hpc.org> To: ipsec@tis.com Subject: CFP: IEEE JSAC Network Security Issue Sender: owner-ipsec@ex.tis.com Precedence: bulk Call for Papers IEEE Journal on Selected Areas in Communications (JSAC) Special Issue on Network Security Publication date: January, 2000 Recent years have seen great advances in the availability of security technology for network users. The advances in standardization and implementation are accompanied by continuing activity in the research community to tackle the next generation of problems and to improve on prior technology. This special issue of JSAC will be devoted to recent research results that describe or forecast significant changes in the feasibility of delivering security solutions (such as major improvements in cryptographic efficiency), or describe progress in areas that have been especially difficult, or are relevant to newer technologies, such as optical or mobile wireless communication. Of special interest are papers that relate their results to use on the Internet today or to use on next generation networks. Papers are solicited in the following areas: Cryptography-based network systems, such as secure private networks transactional security Public-key infrastructures Applying new cryptographic methods to network communication New cryptographic protocols supporting secure network systems Anonymous communication Recent cryptographic theory advances Optical network security Mobile wireless network security Formal analysis of network security systems Trends in network-based attacks Secure group communication Policy expression and enforcement Papers in strongly related areas, especially those involving novel technologies, are also encouraged. The guest editors for this issue are Hilarie Orman, University of Arizona, Department of Computer Science Ueli Maurer, Swiss Federal Institue of Technology (ETH) Stephen Kent, BBN Technologies Stephen Bellovin, AT&T Laboratories The schedule for authors is as follows: February 5, 1999, manuscripts are due May 3, 1999, notification of acceptance August 5, 1999, final manuscripts are due Manuscripts to be considered for submission should be sent by email to Hilarie Orman (ho@cs.arizona.edu) by February 5, 1999. The manuscripts must be in Postscript, viewable in ghostscript. The manuscripts must be in Postscript, viewable in ghostscript, or six copies can be sent by mail; contact Hilarie Orman well prior to the deadline for the mailing address. Please note the IEEE formatting requirements; information for authors can be found at: http://gump.bellcore.com:5000/Guidelines/info.html The JSAC home page is at http://gump.bellcore.com:5000/. From owner-ipsec Wed Sep 23 18:52:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA27660 for ipsec-outgoing; Wed, 23 Sep 1998 18:51:56 -0400 (EDT) Date: Wed, 23 Sep 1998 19:09:18 -0400 Message-Id: <199809232309.TAA01067@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Minutes from the Chicago IETF meeting Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Enclosed please find meeting minutes from the Chicago IETF IPSEC working group meeting. My apologies for the delay in getting these out. I'd appreciate getting any comments on this within the next week (earlier if possible), so I can get these submitted to the IETF Secretariat as soon as possible. Thanks!! - Ted P.S. This is also available on the web as: http://web.mit.edu/tytso/www/ipsec/chicago/ which includes the Luis Sanchez's slide presentation on Security Policy Management. Chicago IETF (August, 1998) IPsec Working Group Meeting Minutes The WG met on Tuesday at the IETF meeting in Chicago, from 14:15 to 15:15. Approximately 120 people attended. This was MBONE broadcast. The Agenda was: * Workgroup status * Workshop announcement * Charter revision * Discovered problems with Ipsec/IKE based on current implementation experience --- Lifetime discussion * ICMP messages, standardized error codes, and MIBs * Policy/tunnel endpoint discovery * Policy-based Security Management Workgroup status ================ Ted gave a report on the status of the IPSEC working group. The full suite of Internet Drafts have been approved by the IESG. They are currently being processed by the RFC editor and should be published shortly. It is now time to revisit the IPSEC charter since we have met almost all of the goals and milstones in the original charter. Workshop announcement ===================== Microsoft will be sponsoring an IPSEC interoperability testing workshop in Redmond on Aug 31 -- Sep 3rd. Approximately 20-25 companies have signed up for the workshop. William Dixon (wdixon@microsoft.com) is the contact person for this workshop. IBM is also sponsoring another round of interoperability testing in Binghamtom, NY on October 27--30. This test will also include L2TP. The $300 fee has been waived by IBM. Charter revision ================ Bob Moskowitz led a discussion on new items for work goals for revising the charter. These items included:
  • address errors and improvements; errata to be maintained on MIT web site
  • add functionality
  • remote client support
  • policy and tunnel endpoint discovery (Bill Simpson votes to remove, since this is a complex non-security issue already being dealt with elsewhere)
  • complex tunnel management
  • ICMP messages, error codes, MIBs
  • Additional algorithms
  • IPsec over non-IP protocols (IPX? "Running shoes?")
  • Key recovery: excluded to the sound of cheers and hisses
  • Integration of IPsec and certificate frameworks, DNSsec
  • Cleaning up the host-host (non-VPN) case; not sure what's missing
  • results implemented from Secure Multicast IRTF activity
The working group chairs will compose a new proposed charter based on these suggestions, and present it to the working group. Lifetime discussion =================== Although there is a default value established for Phase 2 lifetimes, there is no similar default for Phase 1 lifetimes. There is unfortunately is conflicting interpretations regarding how to proceed in the absence of an explicitly specified PHase 1 lifetime. There is an optional notification facility, but it's unclear what happens if the notified value ins't acceptable. There is an interoperability impact caused by this underspecification. (This will need to be corrected in a protocol errata.) ICMP messages, standardized error codes, and MIB's ================================================== Michael Richardson gave a presentation on a two problems which he has been concentrating on. One is the issue of Path MTU discovery across a IPSEC tunnel; which could be ignored in IPV4, but not in IPV6. (Since IPV6 drops packets greater than the MTU, instead of fragmenting them; on the other hand, the IPV6 minimum MTU is also much bigger, so perhaps the problem can be ignored). The other area of concern is ICMP messages and IPSEC, to support diagnostic tools such as traceroute and PING. Policy/tunnel endpoint discovery ================================ Roy Perieira has some drafts forthcoming which will cover IPSEC policy and tunnel endpoint discovery issues. These include how a new machine on the network bootstraps itself by obtaining its first policy, and secure route discovery in the face of complex topologies and multiple secure paths for load-balancing and/or redundancy. Policy-based Security Management ================================ Luis Sanchez gave a presentation on some Security Policy Management going on at BBN. From owner-ipsec Wed Sep 23 19:41:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA27744 for ipsec-outgoing; Wed, 23 Sep 1998 19:38:55 -0400 (EDT) Message-ID: <70C20C1647EBD11183F800805FA67B4329E1F4@vpnet.com> From: Sumit Vakil To: ipsec@tis.com Subject: RE: QM/PFS/MultipleProposals/MultipleGroups question Date: Wed, 23 Sep 1998 16:55:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk What you are recommending is already in IKE. From section 5.5 of IKE, All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST apply to every SA in the negotiation. So you'd have only one KE payload, and the group for that payload would be present in all the proposals of all the SA payloads. Sumit A. Vakil VPNet Technologies, Inc. (408) 445-6600 x264 > -----Original Message----- > From: Bronislav Kavsan [SMTP:bkavsan@ire-ma.com] > Sent: Wednesday, September 23, 1998 1:44 PM > To: ipsec@tis.com > Subject: QM/PFS/MultipleProposals/MultipleGroups question > > Scenario: Initiator uses PFS and wants to make multiple proposals in QM, > where each proposal offers different group. Therefore each proposal will > contain different public key for each group proposed (e.g DH Group > 1,2,3,....) > > Question: isn't it very wastefull to generate and send all these > different public keys, while only one will be chosen by the responder? > Wouldn't be much simpler to restrict Initiator to use only one group for > all proposals it wants to make? > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-739-2384 > http://www.ire.com > > From owner-ipsec Wed Sep 23 20:40:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27921 for ipsec-outgoing; Wed, 23 Sep 1998 20:38:55 -0400 (EDT) Message-Id: <199809232355.TAA18939@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 23 Sep 1998 20:54:41 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Fwd: Re: VPN bakeoff in October & export licensing. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Why do you think some of us get so militant about making sure you have printers capable of printing listings at these things? >Date: Wed, 23 Sep 1998 16:45:53 -0400 (EDT) >From: Henry Spencer >To: Mark Gillott >cc: IP Security List >Subject: Re: VPN bakeoff in October & export licensing. >Sender: owner-ipsec@ex.tis.com > >> But what about the bakeoff? Does anyone have a view on what the NSA would >> say if we were to dial home (to the UK), fixed some bug or other and then >> copied a new image back to the workshop for further testing? > >Beware: doing the bug fix on a UK machine from within the US exports the >bug fix, i.e. it exports crypto code! Or at the very least, it exports >technical advice on encryption. Probably not a good idea... > >> What about when we come to go home. Presumably we have remove all our test >> images from laptops/routers before we leave the US? > >Correct. > > Henry Spencer > henry@spsystems.net > (henry@zoo.toronto.edu) > From owner-ipsec Thu Sep 24 04:56:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA29235 for ipsec-outgoing; Thu, 24 Sep 1998 04:47:03 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB58E4@wade.reo.dec.com> From: Stephen Waters To: Henry Spencer Cc: l2tp@zando.com, ipsec@tis.com Subject: RE: VPN bakeoff in October & export licensing. Date: Thu, 24 Sep 1998 10:01:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk I thought the US has relaxed the export stuff to allow DES56-bit now - since that's the extent of what we'll be testing, maybe we don't have a problem? In any case, it is VERY unlikely we'll be fixing core crypto code - it will be fixes to L2TP and IPSEC signally code if anything so no crypto-code fixes will be exported from the US. The images we build in the UK will contain crypto-code, but that's import. We're going to check with the UK export bods as well. Cheers, Steve. -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Wednesday, September 23, 1998 9:46 PM To: Mark Gillott Cc: IP Security List Subject: Re: VPN bakeoff in October & export licensing. > But what about the bakeoff? Does anyone have a view on what the NSA would > say if we were to dial home (to the UK), fixed some bug or other and then > copied a new image back to the workshop for further testing? Beware: doing the bug fix on a UK machine from within the US exports the bug fix, i.e. it exports crypto code! Or at the very least, it exports technical advice on encryption. Probably not a good idea... > What about when we come to go home. Presumably we have remove all our test > images from laptops/routers before we leave the US? Correct. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Thu Sep 24 08:22:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA29814 for ipsec-outgoing; Thu, 24 Sep 1998 08:18:58 -0400 (EDT) Message-ID: <19980924100959.19457.qmail@hotmail.com> X-Originating-IP: [202.190.130.42] From: "Robert Cosme" To: jis@MIT.EDU Cc: ipsec@tis.com Subject: IPsec vs SKIP Protocol Content-Type: text/plain Date: Thu, 24 Sep 1998 03:09:58 PDT Sender: owner-ipsec@ex.tis.com Precedence: bulk Sir, Currently, I am working on a project and this has certain portion that deals with encryption. The specification requires encryption and key management SKIP. I'm not a guru of encryption although I know some basics. Please explain to me SKIP and how do we contrast this with IPSec. I am proposing a Cisco products which I know use IPSec - 40-DES and 56-DES. Is there a 144-bit encryption? Again, excuse me for being not aware of the details of encryption. Please help me. I don't even know if the subject I put is correct. Hoping for your immediate response. Many thanks & rgds, Robert ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec Thu Sep 24 10:04:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00585 for ipsec-outgoing; Thu, 24 Sep 1998 10:00:58 -0400 (EDT) Date: Thu, 24 Sep 1998 10:18:32 -0400 (EDT) From: Henry Spencer To: Stephen Waters cc: l2tp@zando.com, ipsec@tis.com Subject: RE: VPN bakeoff in October & export licensing. In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EB58E4@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > I thought the US has relaxed the export stuff to allow DES56-bit now - since > that's the extent of what we'll be testing, maybe we don't have a problem? Maybe. I hadn't heard about that change (although I might not have, since our project has no further interest in DES56 except to laugh at it), and I would suggest double-checking. I also suggest checking for footnotes like "but you still have to fill out form 12345 for each item exported". It only takes one slip to get your code contaminated. > In any case, it is VERY unlikely we'll be fixing core crypto code - it will > be fixes to L2TP and IPSEC signally code if anything... It doesn't *have* to be the core crypto code; remember that "enabling technology" is export-controlled too, and the bureaucrats have often taken a broad view of what that encompasses. I'm sure anything labelled IPSEC would count. I think much depends on just how unquestionably clean you want your code to be. If you want to be really sure, don't touch it at all from the US. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Thu Sep 24 12:39:35 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA01527 for ipsec-outgoing; Thu, 24 Sep 1998 12:35:04 -0400 (EDT) Date: Thu, 24 Sep 1998 09:37:13 -0700 From: jimg@mentat.com (Jim Gillogly) Message-Id: <199809241637.JAA10163@zendia.mentat.com> To: henry@spsystems.net Subject: RE: VPN bakeoff in October & export licensing. Cc: l2tp@zando.com, ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters wrote: > > I thought the US has relaxed the export stuff to allow DES56-bit now - since > > that's the extent of what we'll be testing, maybe we don't have a problem? Henry Spencer wrote: > Maybe. I hadn't heard about that change (although I might not have, since > our project has no further interest in DES56 except to laugh at it), and I > would suggest double-checking. I also suggest checking for footnotes like > "but you still have to fill out form 12345 for each item exported". I can't hit www.bxa.doc.gov at the moment, but the White House press release says "Prior to export, products are subject to a one-time product technical review." I assume this is the "form #####" footnote you (Henry) expected. Bottom line appears to be: BXA still wants you to get permission before you take or send it out of the US. I assume they'll be looking for assurances that it can't be converted to 3DES or DESX by the end user and the usual bumf. Don't count on getting to take your source code back home, Stephen. :) Jim Gillogly From owner-ipsec Thu Sep 24 12:39:35 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA01545 for ipsec-outgoing; Thu, 24 Sep 1998 12:37:02 -0400 (EDT) Message-Id: <3.0.32.19980924124752.0096b690@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 24 Sep 1998 12:48:01 -0400 To: Daniel Harkins From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: multiple payloads via "ID_LIST" Cc: "Scott G. Kelly" , "Michael C. Richardson" , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Pardon me for coming into this discussion a bit late... > If they needed it yesterday tell them to establish 2 SAs, one soley >for X and the other soley for Y. It would be *nice* to be able to have a >single one but I think this clearly falls in the "if it ain't broke..." >category. It can be easily solved today (and yesterday too) using existing >mechanisms. What if, instead of there being only two subnets behind a security gateway, there were a hundred or more? All disjoint, non-combinable, etc. It becomes a serious resource utilization issue, not to mention that negotiating all those Quick Modes takes time (especially when you're doing PFS), and it seems a waste when you're applying the same security policy to all of them. And yes, I've had customers (plural) that have cited this as an issue. -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Thu Sep 24 12:43:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA01650 for ipsec-outgoing; Thu, 24 Sep 1998 12:43:04 -0400 (EDT) Message-ID: <360A7B65.66B62490@redcreek.com> Date: Thu, 24 Sep 1998 10:03:33 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Shawn Mamros CC: Daniel Harkins , "Michael C. Richardson" , ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" References: <3.0.32.19980924124752.0096b690@bl-mail1.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn Mamros wrote: > > Pardon me for coming into this discussion a bit late... > What if, instead of there being only two subnets behind a security > gateway, there were a hundred or more? All disjoint, non-combinable, > etc. It becomes a serious resource utilization issue, not to mention > that negotiating all those Quick Modes takes time (especially when > you're doing PFS), and it seems a waste when you're applying the same > security policy to all of them. > > And yes, I've had customers (plural) that have cited this as an issue. I don't think there's really any question that your point is correct. I think we (the participants thus far) have finally agreed on the following, and I'm sure I'll be corrected if I'm wrong :-) (1) This functionality is needed (2) Much other such functionality may be needed, and at least 'would be nice to have' (3) Resolution of this is more complex than just throwing in a new payload, and involves at least thinking about whether we need to change the way we represent identities for indexing into the SPD. This being the case, perhaps it is best to use the vendor ID payload + private ID lists in the interim, while also moving forward toward resolution. The bottom line is (I think) that there is rough consensus among the participants thus far that this issue requires a good deal more thought, and that we ought not to act in haste. Scott From owner-ipsec Thu Sep 24 13:46:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA01811 for ipsec-outgoing; Thu, 24 Sep 1998 13:44:07 -0400 (EDT) Date: Sat, 24 Oct 1998 21:11:24 +0000 (GMT) From: Torok Attila To: ipsec@tis.com Subject: algorithms processing time In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello! We are interested in the processing time needed for encoding/decoding data conforming to the DES, IDEA, RSA, MD5 algorithms. Any hints are welcomed. Thanks. Torok ATTI > From owner-ipsec Thu Sep 24 13:57:52 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA01872 for ipsec-outgoing; Thu, 24 Sep 1998 13:57:09 -0400 (EDT) Message-ID: <360A8982.5EE4@semaphorecom.com> Date: Thu, 24 Sep 1998 11:03:46 -0700 From: Shih-ho Chen Organization: Semaphore Communications X-Mailer: Mozilla 3.0Gold (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ipsec@tis.com Subject: X.509 Spec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Everyone, Would someone please tell me where can I find the latest X.509 spec (preferably from some web site)? Thanks. Shih-ho Chen From owner-ipsec Thu Sep 24 14:27:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA02058 for ipsec-outgoing; Thu, 24 Sep 1998 14:26:09 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809241844.LAA02731@kc.livingston.com> Subject: Re: issues with IKE that need resolution To: skelly@redcreek.com (Scott G. Kelly) Date: Thu, 24 Sep 1998 11:44:23 -0700 (PDT) Cc: suresh@livingston.com, dharkins@cisco.com, rodney@tillerman.nu, ipsec@tis.com In-Reply-To: <360827FB.BADFA2AB@redcreek.com> from "Scott G. Kelly" at Sep 22, 98 03:43:07 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Pyda Srisuresh wrote: > > Dan Harkins wrote: > > > > > > Is there a point in identifying yourself as "198.31.2.0/24"? What > > > does that mean? "I speak for this network"? Without something like the KX > > > record in DNS to delegate that authority why should I belive it? Chances > > > are he'd probably be making this statement through another interface anyway > > > so what should I do if 198.31.1.18 says "I'm 198.31.2.0/24"? Also, what are > > > you going to do about the ID_KEY_ID identity? A certificate that certifies > > > that my identity is an intentionally incomprehensible blob is not going > > > to be all that useful. > > > > > > > I agree. I dont see much point in having IDs for address ranges and > > transport IDs and so forth. Single address (or multiple addresses for > > a multi-homed node) based IDs seem to be the only valid IDs (be it for > > phase I or phase II). > > Disagree. Ranges of addresses (etc.) are extremely useful identifiers > for a security gateway which is representing those within the range. > Well, let me explain what I have in mind. IKE is supposed to help negotiate keys and establish SA bundle between IPsec peers. And, an SA bundle may be identified by the tuple of (, , , ). With that in mind, I am not sure how identifying the subnets or address list a VPN security gateway supports would help with IPsec processing, except in the context of policy verification. If you agree with the above reasoning, I would say that IDs for subnets is not required so long as there exists a policy payload. Does this make sense? > As for Dan's question, > > > > Is there a point in identifying yourself as "198.31.2.0/24"? What > > > does that mean? "I speak for this network"? Without something like > > > Yes, "I speak for this network" is *exactly* what it means, and you > don't need a kx record or anything like it to verify my veracity. > Instead, you need a way to indicate in your policy entry that I am an > authorized proxy in this case. I guess you *could* use a kx record if > you want to, but that's an implementation detail. > > > > > Dan wrote: > > > It seems to me that we have identities that are only useful in phase 1 and > > > some of those should have ways to be encoded into a cert. There are others > > > that really only make sense in phase 2 because their purpose is to > > > constrain use of an IPSec SA. As an example, a gateway product receiving > > > phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr = > > > "ID_FQDN dharkins@cisco.com" would not be particularly useful. What > > > does "dharkins@cisco.com" mean? There is no machine cisco.com and there > > > sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and > > > a way to encode it in a cert is good. But passing it in phase 2 would not > > > make much sense. Similarly, a list of subnets is not a very good phase 1 > > > identity and I don't see much value in defining a way to encode that in a > > > cert but as a phase 2 identity it may be quite useful. Or am I missing > > > something here? > > > > > > > I agree, ID payload is predominantly useful in phase 1. However, there > > is need for ID payload in phase II as well. When the IP address of client > > for which IKE is negotiating is different from that of IKE itself, it is > > necessary for IKE to identify the client ID in phase II, (just as it > > specifies the ID for itself in phase I). > > > > What we need is a new type of policy payload in phase II. > > I agree that we may need different payloads for the 2 phases, but think > we need to reconcile the issue I raised in a related post, i.e. that the > ID payload is, by definition, DOI-specific, and this (I think) means > it's a phase 2 critter only. In that case, the new payload type would > need to be in phase 1, or the appropriate language in the ISAKMP doc > would need correcting. > I agree, ID payload is DOI specific. I also believe, the new policy payload is relevant to phase II only. Why do you say the new policy payload needs to be in phase I? > > >From the IKE stand point, I believe, we need to be able to do the following: > > > > (1) Identify one or more policies associated with an SA. > > Each Policy needs to be assigned an ID, to identify with > > during the lifetime of SA (or, its extended lifetime). Policy > > could be as simple as: > > > > PERMIT > > [] [] > > [] > > > > If there is rough consensus on this approach, I dont see a problem > > with coming up with a payload format to represent policies. > > > > I strongly disagree with your assertion, if I understand it correctly. > Individual policies are a local matter and should NEVER be sent across > the link, but should be somehow indexable based on conversational > context. We currently use either the ID payload or the IP header > contents to index these. We may also use certificates, FQDNs, and > whatever else is defined in for the ID payload, and this whole > (sub)thread started as a result of the assertion that we need other > indices. > A policy that asserts what datagrams are allowed to be processed over an SA are not a local matter. Such a policy must be shared between the SA peers. Otherwise, what is stopping one end to use an SA to send any datgrams it chooses to forward to its peer, while the peer doesnt approve of these packets and simply drops or refuses to forward. > I still don't understand this resistance to using some sort of endpoint > identifier to index policy - after all, we are using an identity-based > security model, right? > See my comments earlier. Idenitities, in my mind, are relevant only to the extent of identifying IKE peers and Tunnel/transport IPSec end-nodes. > > (2) Ability to add/delete policies dynamically to an SA. > > > > This would be particularly useful when some applications > > require policy changes on the fly. Ex: Take a policy that requires > > encryption on H.323 application sessions. The signalling protocol > > in H.323 sets up sessions dynamically and these dynamic sessions > > need to be notified so that all such sessions are supported by > > IPsec. > > > > Again, I'm not sure I understand what you mean here, but will point out > that it is possible to share an existing SA, and [ARCH] gives the > details. However, difficulties arise if you negotiate the SA for 2 > specific endpoints using IKE, then want to try to piggyback others > (whose selectors will not match upon decryption) onto the session if > both sides do not strictly comply with description in [ARCH]. Again, > though, these are local implementation issues, I think. > > Scott > My point is simply that the negotiating peers must know the policy they agree on for an SA. As for policy negoitiation in QM, IKE could pursue an approach similar to what it does for SA negotiation. For example, the initiator could identify the policy it intends to pursue for an SA and the responder would identify a subset of the orginal policy it is agreeable to and responds with that policy. There, you have a common agreeable policy between IPsec peers. Hope this helps. cheers, suresh From owner-ipsec Thu Sep 24 14:31:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA02121 for ipsec-outgoing; Thu, 24 Sep 1998 14:31:10 -0400 (EDT) Message-Id: <199809241848.LAA26426@gallium.network-alchemy.com> To: Anne Anderson - Sun Microsystems cc: ipsec@tis.com Subject: Re: Summary of responses: Network World article on IPSec In-reply-to: Your message of "Wed, 23 Sep 1998 08:51:19 EDT." <13832.60550.662248.344722@saguaro> Date: Thu, 24 Sep 1998 11:48:57 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk [I swear I saw the horse move...] The fact that the IKE header is unprotected has been recognized by its designers since day one. If you're worried about active attacks on an IKE exchange, all you really need to do is eat the last packet of any QM or MM. Why worry about changing a bit? But, if you've got active attacks going on, the same attacker could just as easily eat the resulting AH/ESP traffic... Frankly, I'm not worried about this right now. Yet, none of this constitutes what was claimed in the article: ">2. "Another difficult item on this week's agenda will be redefining > the core IKE protocol. Security experts recently uncovered a > flaw related to the improper exposure of information." Derrell >[David Mason]: > >She might be referring, not to the improper exposure but, to the >fact that the commit bit in the IKE header is not "protected" - it >can be changed en route undetected which causes serious problems for >the IKE negotiation. > >[Scott Kelly]: > >I think this refers to the fact that much of the IKE header is >unprotected by the hash, i.e. unauthenticated, meaning that a highly >skilled attacker with the ability to insert himself between you and >the gateway during your IKE negotiation could modify IKE payloads, >resulting in various denial-of-service attacks. Repairing this will >introduce interoperability issues temporarily, but these should be >minor and easily remedied. From owner-ipsec Thu Sep 24 15:24:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA02413 for ipsec-outgoing; Thu, 24 Sep 1998 15:22:24 -0400 (EDT) Message-Id: <199809220941.CAA05240@fusebox.pgp.com> X-Sender: wprice@enigma.cyphers.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 22 Sep 1998 02:44:31 -0700 To: ipsec@tis.com From: Will Price Subject: Quick Mode For Multiple SAs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm puzzled over the various descriptions throughout the IPSEC documents with regards to negotiating multiple SAs simultaneously. The IKE document says (5.5): Using Quick Mode, multiple SA's and keys can be negotiated with one exchange as follows: [exchange with each packet containing multiple SA payloads] Yet a page or two before that it says: The message ID in the ISAKMP header identifies a Quick Mode in progress for a particular ISAKMP SA which itself is identified by the cookies in the ISAKMP header. And: it is possible to have multiple simultaneous Quick Modes, based off a single ISAKMP SA, in progress at any one time. Yet, in a seemingly contradictory statement, the ISAKMP document says (4.2): If the SA establishment negotiation is for a combined protection suite consisting of multiple protocols, then there MUST be multiple Proposal payloads each with the same Proposal number. These proposals MUST be considered as a unit and MUST NOT be separated by a proposal with a different proposal number. So, based on the above, there are now three somewhat contradictory ways of negotiating multiple SAs at roughly the same time: 1] Perform multiple Quick Mode exchanges 2] Transmit multiple SA payloads in each packet [violating the ISAKMP requirement] 3] Use multiple proposals with the same proposal number in one SA payload (IMHO, the logical choice...) And so, I suppose it really comes down to what the implementations are actually doing. If someone wants to negotiate ESP with IPCOMP, do we use 1, 2, or 3? Using number 1 seems fairly non-functional since it results in timing confusion as to which protocol is layered on top of the other in addition to simply being much slower to negotiate. Number 2 violates ISAKMP and makes packet parsing more difficult. Number 3 is logical, but since the IKE document seems to recommend number 2, it remains unclear what to do. -Will From owner-ipsec Thu Sep 24 15:27:41 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA02479 for ipsec-outgoing; Thu, 24 Sep 1998 15:27:18 -0400 (EDT) From: Anne Anderson - Sun Microsystems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 Sep 1998 13:50:43 -0400 (EDT) To: ipsec@tis.com Subject: correction: Summary of responses: Network World article on IPSec X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13833.12827.943644.278044@saguaro> Sender: owner-ipsec@ex.tis.com Precedence: bulk There was an indirect quote in my summary of responses giving releases for IPSec on Solaris. The quote was not correct: Sun has not announced release vehicles for IPSec. I apologize for any confusion (and especially to Dan McDonald for ruining his day and interrupting his work!) Somehow, this error was not caught by any of the Sun people who reviewed the information prior to my publishing the summary. -Anne -- Anne Anderson Email: aha@east.sun.com Sun Microsystems Laboratories or: aha@acm.org 2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928 Chelmsford, MA 01824 USA Fax: (978) 250-5067 From owner-ipsec Thu Sep 24 16:09:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA02715 for ipsec-outgoing; Thu, 24 Sep 1998 16:08:30 -0400 (EDT) Message-ID: <360AAB78.99B1BBE5@redcreek.com> Date: Thu, 24 Sep 1998 13:28:40 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <199809241844.LAA02731@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [recipient list pruned...] Pyda Srisuresh wrote: > > IKE is supposed to help negotiate keys and establish SA bundle between > IPsec peers. And, an SA bundle may be identified by the tuple of > (, , , ). > > With that in mind, I am not sure how identifying the subnets or address > list a VPN security gateway supports would help with IPsec processing, > except in the context of policy verification. > > If you agree with the above reasoning, I would say that IDs for subnets > is not required so long as there exists a policy payload. Does this make > sense? > I guess I'm not sure I agree with the above reasoning, although I don't necessarily disagree with the conclusion, depending upon what the 'policy' payload contains. In terms of your reasoning, have you considered that we may use IKE to establish *multiple* SA bundles between hosts/gateways, and that the individual SAs might have differing security requirements, and that a sorting mechanism for such individual connections vs security requirements may be realized using ports, protocols, addresses, etc? Also, consider asymmetric security requirements... > > I agree that we may need different payloads for the 2 phases, but think > > we need to reconcile the issue I raised in a related post, i.e. that the > > ID payload is, by definition, DOI-specific, and this (I think) means > > it's a phase 2 critter only. In that case, the new payload type would > > need to be in phase 1, or the appropriate language in the ISAKMP doc > > would need correcting. > > > > I agree, ID payload is DOI specific. > I also believe, the new policy payload is relevant to phase II only. > > Why do you say the new policy payload needs to be in phase I? > Didn't say that, only said that by the current language, the ID payload belongs in phase 2 only, so maybe we need a payload with a different name in phase 1. After sending that off, I came to believe that it makes more sense to change the language in the doc, and add a new payload (as you suggest) to phase 2. > A policy that asserts what datagrams are allowed to be processed over > an SA are not a local matter. Such a policy must be shared between > the SA peers. The minimum/maximum acceptable levels of security I am willing to apply for the datagrams I send to you is a local policy matter (mine). The minimum/maximum levels of security you are willing to accept for the datagrams I send to you is also a local policy matter with respect to you. That's why we negotiate, to find the middle ground. > Otherwise, what is stopping one end to use an SA to send > any datgrams it chooses to forward to its peer, while the peer doesnt > approve of these packets and simply drops or refuses to forward. The fact that the originator of the packets correctly identified their source(s) in the ID payload precludes the possibility that they would be inappropriately (and unknown to the originator) dropped at the destination peer. The SA would not have been established had their source(s) not been acceptable to the target gw. In that case, if the originator sends inappropriate packets, they will be dropped, and rightly so. > > I still don't understand this resistance to using some sort of endpoint > > identifier to index policy - after all, we are using an identity-based > > security model, right? > > > > See my comments earlier. Idenitities, in my mind, are relevant only to > the extent of identifying IKE peers and Tunnel/transport IPSec end-nodes. Identities are of central importance to an identity-based policy model. It dawns on me that you may be thinking of some mechanism in which the gateways agree on some sort of policy which is independent of identities, and then any packet which comes down the SA is presumed to be of acceptable origin, and not subjected to any further validation (beyond decryption/authentication). Is this correct? > My point is simply that the negotiating peers must know the policy they > agree on for an SA. As for policy negoitiation in QM, IKE could pursue an > approach similar to what it does for SA negotiation. > > For example, the initiator could identify the policy it intends to pursue > for an SA and the responder would identify a subset of the orginal policy > it is agreeable to and responds with that policy. There, you have a common > agreeable policy between IPsec peers. Hope this helps. > Okay, but how do you represent the policy? How do you select variable levels of security, and based upon what? Scott From owner-ipsec Thu Sep 24 16:15:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA02738 for ipsec-outgoing; Thu, 24 Sep 1998 16:15:29 -0400 (EDT) From: CryptoNEWS@aol.com Message-ID: <544a28e5.360aab2c@aol.com> Date: Thu, 24 Sep 1998 16:27:24 EDT To: schen@semaphorecom.com, ipsec@tis.com Mime-Version: 1.0 Subject: Re: X.509 Spec Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 224 Sender: owner-ipsec@ex.tis.com Precedence: bulk On the server that Denis pointed to, you'll find the final text of the 1997 edition of X.509 (as submitted to the ITU and ISO for publication) at: ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc (the primary reason this is not yet available for purchase from either ITU or ISO is that they will not publish or sell it until all the other parts of the 1997 X.500 Series are also ready (soon we're told by the editor). As for current work underway in X.509, there is a Working Document which is currently being revised to reflect the outcome of the September meeting. The previous version of that document is available at: ftp://ftp.bull.com/pub/OSIdirectory/Phoenix98Output/CertificateExtensionsWD. doc When the revisions are complete (within 2 months) the new version will likely be found in: ftp://ftp.bull.com/pub/OSIdirectory/Beijing98/Vancouver98/ These two documents provide a complete picture of the X.509 activity except of course for defect reports. These are recorded together with the defects on the other parts of the X.500 Series at the bull.com site, but at present it is somewhat out of date (should be updated within 2 months as well). Hope this helps. Sharon From owner-ipsec Thu Sep 24 16:35:07 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA02771 for ipsec-outgoing; Thu, 24 Sep 1998 16:29:32 -0400 (EDT) Message-ID: <360AB052.DB1191CB@redcreek.com> Date: Thu, 24 Sep 1998 13:49:22 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: dharkins@cisco.com, ipsec@tis.com, lsanchez@bbn.com Subject: Policy instantiation/negotiation (was Re: issues with IKE that need resolution) References: <199809241844.LAA02731@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk It occurs to me, looking back on my notes from Chicago, that BBN is working on something very closely related to this discussion. If so, much (if not all) of this exchange could be a waste of time. Specifically, I'm referring to Luis Sanchez' presentation on 'Policy Based Security Management for IPSec'. Any comments? From owner-ipsec Thu Sep 24 16:46:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA02819 for ipsec-outgoing; Thu, 24 Sep 1998 16:44:36 -0400 (EDT) From: dbastien@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com, Torok Attila Message-ID: <85256689.00733513.00@gotlib.galea.com> Date: Thu, 24 Sep 1998 17:01:54 -0400 Subject: Re: algorithms processing time Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk > Hello! > We are interested in the processing time needed for encoding/decoding > data conforming to the DES, IDEA, RSA, MD5 algorithms. > Any hints are welcomed. Thanks. > Torok ATTI > see, [Schneier] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471- 12845-7 or [Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a Pentium." February 1997, http://www.counterpane.com/speed.html From owner-ipsec Thu Sep 24 16:47:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA02834 for ipsec-outgoing; Thu, 24 Sep 1998 16:46:35 -0400 (EDT) Date: Thu, 24 Sep 1998 17:03:36 -0400 Message-Id: <199809242103.RAA07204@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: suresh@livingston.com Cc: ipsec@tis.com Subject: Re: issues with IKE that need resolution References: <360827FB.BADFA2AB@redcreek.com> <199809241844.LAA02731@kc.livingston.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Pyda" == Pyda Srisuresh writes: Pyda> A policy that asserts what datagrams are allowed to be Pyda> processed over an SA are not a local matter. Such a policy must Pyda> be shared between the SA peers. Otherwise, what is stopping one Pyda> end to use an SA to send any datgrams it chooses to forward to Pyda> its peer, while the peer doesnt approve of these packets and Pyda> simply drops or refuses to forward. That doesn't justify making the policy shared state. If at my end I have a policy that datagrams containing X aren't allowed, it doesn't make any difference end to end whether I communicate that fact to the other security gateway or not. If I don't communicate it, I end up discarding packets containing X at my end. If I *do* communicate it, then the other security gateway may do the discarding for me. (But I may not want to count on that, so it doesn't eliminate my own policy enforcement.) In either case, packets containing X are discarded, so to the users of those packets the result is the same -- no throughput. Which is what the policy intended, so the right things happened. If the only effect of communicating policy to the other end of the SA is to move the point of discarding, it's clear to me that this should not be done since it adds complexity to no purpose. paul -- !----------------------------------------------------------------------- ! Paul Koning, NI1D, D-20853 ! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA ! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090 ! email: pkoning@xedia.com ! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75 !----------------------------------------------------------------------- ! "Among the many misdeeds of the British rule in India, history ! will look upon the Act depriving a whole nation of Arms, as ! the blackest" --- Mahatma Gandhi From owner-ipsec Thu Sep 24 17:07:18 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA02902 for ipsec-outgoing; Thu, 24 Sep 1998 17:06:38 -0400 (EDT) From: Joe Touch Date: Thu, 24 Sep 1998 14:23:30 -0700 (PDT) Message-Id: <199809242123.OAA24166@rum.isi.edu> To: ipsec@tis.com, stdtc16@hermes.ee.utt.ro Subject: Re: algorithms processing time X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk "Performance Analysis of MD5" http://www.isi.edu/touch/pubs/sigcomm95.html J. Touch, Proc. Sigcomm '95, Boston, pp. 77-86. also in postscript at: ftp://ftp.isi.edu/pub/hpcc-papers/touch/sigcomm95.ps.Z Here are the web pages for the project, with additional information on in-situ performance (in IPv4). There is a toolset there for measuring the performance of algorithms, too. http://www.isi.edu/atomic2/security/ Joe From owner-ipsec Thu Sep 24 18:12:24 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA03127 for ipsec-outgoing; Thu, 24 Sep 1998 18:09:36 -0400 (EDT) Message-ID: From: Rodney Thayer To: Shih-ho Chen Cc: ipsec@tis.com Subject: RE: X.509 Spec Date: Thu, 24 Sep 1998 18:27:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Use the PKIX specs. get them via www.ietf.org. If the PKIX specs are not sufficient and you really needed the X.509 spec, then PKIX is broken and you should bring this up. The X.509 stuff really is around somewhere. I don't happen to have the URL handy at the moment. If I find it before someone else tells you I'll post it. It's on some Bull site in Massachusetts. -----Original Message----- From: Shih-ho Chen [mailto:schen@semaphorecom.com] Sent: Thursday, September 24, 1998 2:04 PM To: ipsec@tis.com Subject: X.509 Spec Hi Everyone, Would someone please tell me where can I find the latest X.509 spec (preferably from some web site)? Thanks. Shih-ho Chen From owner-ipsec Thu Sep 24 18:43:22 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA03196 for ipsec-outgoing; Thu, 24 Sep 1998 18:42:36 -0400 (EDT) Message-Id: <199809242259.SAA10481@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com CC: lsanchez@bbn.com Subject: Re: Policy instantiation/negotiation (was Re: issues with IKE that need resolution) In-reply-to: Your message of "Thu, 24 Sep 1998 13:49:22 PDT." <360AB052.DB1191CB@redcreek.com> Date: Thu, 24 Sep 1998 18:59:27 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> It occurs to me, looking back on my notes from Chicago, that BBN is Scott> working on something very closely related to this discussion. If so, Scott> much (if not all) of this exchange could be a waste of time. I don't know that this is the case. It is certainly true that it is important to get a clear set of requirements for an extended ID payload and other things. Scott> Specifically, I'm referring to Luis Sanchez' presentation on 'Policy Scott> Based Security Management for IPSec'. I'm still hoping for lots and lots more details about the policy discovery work of Luis. Luis, will a paper or something be forthcoming? :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgrOstiXVu0RiA21AQEzdwMAngkveFt7j0sjIxJI4+cOVLq3TBn3VtzV DOMkdDZ+PMJLmmjcYmqS04CXXbrb8pFPcm5hojfWdUehpHjHirQIL0hOaRHxfBWO RNvt1ukR9ckaSlr2drJNAtXM6w4Ar2ZP =WbJm -----END PGP SIGNATURE----- From owner-ipsec Thu Sep 24 18:48:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA03212 for ipsec-outgoing; Thu, 24 Sep 1998 18:48:35 -0400 (EDT) Message-Id: <199809242306.TAA10497@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: issues with IKE that need resolution In-reply-to: Your message of "Thu, 24 Sep 1998 17:03:36 EDT." <199809242103.RAA07204@tonga.xedia.com> Date: Thu, 24 Sep 1998 19:06:21 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pyda" == Pyda Srisuresh writes: Pyda> A policy that asserts what datagrams are allowed to be Pyda> processed over an SA are not a local matter. Such a policy must Pyda> be shared between the SA peers. Otherwise, what is stopping one Pyda> end to use an SA to send any datgrams it chooses to forward to Pyda> its peer, while the peer doesnt approve of these packets and Pyda> simply drops or refuses to forward. >>>>> "Paul" == Paul Koning writes: Paul> That doesn't justify making the policy shared state. Paul> If at my end I have a policy that datagrams containing X aren't Paul> allowed, it doesn't make any difference end to end whether I Paul> communicate that fact to the other security gateway or not. While this applies to things that you want to discard (negative policy), it does not apply to things that you want to be transmitted (positive policy). Since most of us security types start with *no* traffic of any kind passing and then enable it bit by bit, being able to communicate positive protocol is of utmost importance. I'd say that the it sums up the ICMP work completely. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNgrP1diXVu0RiA21AQE2HwL+JQwYuRaWKg6deEhrFeJavWJWUFKn14b+ JEzhlvGhVIkJZo+BvIGuOzyf/0lhjCK6Zy3vC6Aihgqi6Vk9eAlD4q+Bvu010hqI i8u1EnKFpPHJS61I7ILFmkKd/iayVX4b =t8GN -----END PGP SIGNATURE----- From owner-ipsec Thu Sep 24 19:12:20 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA03251 for ipsec-outgoing; Thu, 24 Sep 1998 19:11:36 -0400 (EDT) Message-Id: <199809242329.TAA10529@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: algorithms processing time In-reply-to: Your message of "Thu, 24 Sep 1998 14:23:30 PDT." <199809242123.OAA24166@rum.isi.edu> Date: Thu, 24 Sep 1998 19:29:25 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk Also... @inproceedings{Nahum1996, AUTHOR="Erich Nahum and David J. Yates and Sean O'Malley and Hilarie Orman and Richard Schroeppel", TITLE="Parallelized Network Security Protocols", BOOKTITLE="Proceedings of the 1996 Symposium on Network and Distributed Systems Security", YEAR=1996, note = "NDSS online proceedings \htmladdnormallink{http://bilbo.isu.edu/sndss/nahum.ps}{http://bilbo.isu.edu/sndss/nahum.ps}", } @inproceedings{Nahum1994, AUTHOR="Erich Nahum and David J. Yates and James F. Kurose and Don Rowsley", TITLE="Performance Issues in Parallized Network Protocols", BOOKTITLE="First USENIX Symposium on Operating System Design and Implementation", YEAR=1994, MONTH="November", PAGES="125-137" } From owner-ipsec Fri Sep 25 08:20:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05140 for ipsec-outgoing; Fri, 25 Sep 1998 08:17:51 -0400 (EDT) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Fri, 25 Sep 1998 15:34:27 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: dbastien@galea.com cc: ipsec@tis.com, Torok Attila Subject: Re: algorithms processing time In-Reply-To: <85256689.00733513.00@gotlib.galea.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 24 Sep 1998 dbastien@galea.com wrote: > > We are interested in the processing time needed for encoding/decoding > > data conforming to the DES, IDEA, RSA, MD5 algorithms. > > [Schneier] B. Schneier, "Applied Cryptography Second Edition", > John Wiley & Sons, New York, NY, 1995. ISBN 0-471- > 12845-7 This book has _very_ outdated performance figures. > [Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a > Pentium." February 1997, > http://www.counterpane.com/speed.html While mostly the data in this paper is (almost) correct, they base on estimations. In particular, IDEA's performance is strongly overestimated. For the symmetric cryptosystems (incl hash functions), the best available performance data for Pentium is available from Bart Preneel and Vincent Rijmen and Antoon Bosselaers, "Recent Developments in the Design of Conventional Algorithms", Computer Security and Industrial Cryptography, State of the Art and Evolution, LNCS 1528 (to appear). The figures are also available from http://www.esat.kuleuven.ac.be/~bosselae/fast.html On Pentium 2 or even on Pentium MMX, the speed of some cryptosystems may boost. See for example my paper "IDEA: A Cipher for Multimedia Architectures?" in the proceedings of SAC '98, LNCS (to appear). The speed figures are available from http://home.cyber.ee/helger/fastidea/. And last but not least, Eric Young's libeay has P2 optimized code for several ciphers. Helger From owner-ipsec Fri Sep 25 08:20:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05149 for ipsec-outgoing; Fri, 25 Sep 1998 08:18:39 -0400 (EDT) Message-ID: <360BB978.5AD4@phase2net.com> Date: Fri, 25 Sep 1998 08:40:41 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: in which doc? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I am looking for how to turn IKE QM KEYMAT info into: encryption key, initial iv and auth key to be used by ESP. Can anyone direct me to what document and where in the doc this information resides? Thanks, jeff From owner-ipsec Fri Sep 25 08:28:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05257 for ipsec-outgoing; Fri, 25 Sep 1998 08:28:40 -0400 (EDT) From: Anne Anderson - Sun Microsystems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Sep 1998 17:23:15 -0400 (EDT) To: ipsec@tis.com Subject: Part II: Summary of responses: Network World article on IPSec X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13834.46904.698344.199065@saguaro> Sender: owner-ipsec@ex.tis.com Precedence: bulk The set of responses was corrupted/truncated. Here is the set of all responses to Question 3: >------------------------------------------------------------------- >3. "And IKE, as it now exists, handles time-expiration of session > keys in a way that could cause one gateway not to understand > another." > > [Anne] Is this referring to the use of kbytes-based lifetime > payloads versus seconds-based lifetime payloads? To what extent > is this a barrier to deployment? Does it just cause a delay, or > is it a Big Problem? [Steven Bellovin]: IKE will definitely need another round. And there's another issue -- as best I can tell, certificates don't interoperate between platforms. But both that and your point 3 won't affect people who use single-vendor solutions for now. [Bob Moskowitz]: No this is perhaps the REAL problem. We have implementations that are to spec that will not interoperate, ie we have some challenges in the spec. Problem is that phase I lifetime operations are NOT spelled out in any of the documents, and some vendors have used the phase II rules. This appears to be incorrect. We have seen two products, that out of the bos will not work together. To get interoperation, we have to configure one for infinite phase I lifetimes and count on the other's local policy to force the deletion of the ISAKMP SAs on both sides according to its phase I lifetime. Phase II so far has not been a problem, but there is a potential problem there. Exactly true [commenting on Steven Bellovin's response]. IKE will be cycled at level due to enhancements. Cert usage is only now being well defined. Some multi-vendor situations work, not all. [David Mason]: This is a more serious problem than just lifetime expiration ... Deletion of SAs due to one side rebooting has been somewhat addressed by the initial contact message but there are still some serious problems in this area as well. Corporations are already deploying IPSec/IKE so I guess neither of these obstacles are considered big drawbacks by everybody. [Michael Richardson]: No, it refers to some minor, unclear text. In this case it meant that two products would not communicate out of the box. That isn't to say that they couldn't be configured to communicate. That is why we have a proposed standard stage that requires actual use. That way we discover the problems now. If we didn't deploy, then we wouldn't find the problems. [Derrell Piper]: Again, utter crap. There are some incomplete implementations which do not currently include support for the mandatory lifetime attributes. As a result, certain other gateways will refuse to negotiate with them because of security policy which says that lifetime negotiation is required. This is hardly a problem with the protocol. It is true that from an implementation perspective, getting rekey right is somewhat complicated in this architecture. There is work underway in IPsecond to write some guidelines about how to do rekey correctly. However, as someone who has written code, it certainly can be done interoperably. [Scott Kelly]: I think this refers to the so-called 'rekey problem'. That problem exists due to an unforseen complication introduced due to a design simplification. SAs are, by definition, unidirectional, meaning that in order for us to have a 2-way conversation, 2 SAs are required: one from me to you (over which I send data), and one from you to me (over which you send data). Technically, these 2 SAs should be negotiated in separate IKE exchanges, but as a matter of convenience, they have been combined into one negotiation, effectively rendering the SA bidirectional. For unidirectional SAs, rekeying (i.e. negotiating a new SA because the first one is expiring) is simple: for the SA extending from me to you, if I want to continue, I renegotiate a new SA, and delete the old one once I'm finished. The same applies to you, if you wish to continue protecting packets on the return path. For bidirectional SAs, it's a bit more involved, i.e. how do we decide who is responsible for rekeying? The problem arises here, when both sides attempt to rekey at almost exactly the same time. A quick fix that was proposed was to introduce random jitter into the SA timer, meaning to store a value that is less than the negotiated value by some small random amount, thus lessening the probability of a rekey collision. However, some vendors still have problems with the logistics of this, so a mechanism needs to be agreed upon and formalized. Hardly earth-shaking... [Pyda Srisuresh] Lifetime issue is quite relevant to remote access. Remote access clients are prone to logging in frequently (as opposed to attached to the net all the time). The existing lifetime metrics do not guarantee that an SA established for one user does not get deleted when the user terminates the connection. Clearly, IKE on either end should clean up SAs when network-login is terminated. A new metric like "network-connected-time" would be useful for remote access users. Also, interoperability issues with regard to session rekeying upon lifetime expiry should be addressed independent of remote access clients. -- Anne Anderson Email: aha@east.sun.com Sun Microsystems Laboratories or: aha@acm.org 2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928 Chelmsford, MA 01824 USA Fax: (978) 250-5067 From owner-ipsec Fri Sep 25 08:30:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05275 for ipsec-outgoing; Fri, 25 Sep 1998 08:30:38 -0400 (EDT) Message-ID: <5F6AA2CAD4A4D1119C3D00A0C99D6AC6C6CC18@static-5-91.dhcp.nai.com> From: "Jones, Michael" To: ipsec@tis.com Subject: Location of ICSA IPSEC 1.1 certification criteria Date: Thu, 24 Sep 1998 16:41:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Where can I get a list of the ICSA IPSEC 1.1 certification criteria? ICSA's website only has the 1.0 spec listed. Thanks, Mike Michael K. Jones Sr. Product Manager, VPN/PKI/Active Security Network Associates, Inc. mjones@nai.com Direct: 408-346-3179 FAX: 408-346-3650 Pager: 888-916-8048 "Who's watching your network?" http://www.nai.com/ From owner-ipsec Fri Sep 25 11:44:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA06011 for ipsec-outgoing; Fri, 25 Sep 1998 11:41:44 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809251600.JAA17908@kc.livingston.com> Subject: Re: issues with IKE that need resolution To: skelly@redcreek.com (Scott G. Kelly) Date: Fri, 25 Sep 1998 09:00:14 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: <360AAB78.99B1BBE5@redcreek.com> from "Scott G. Kelly" at Sep 24, 98 01:28:40 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > [recipient list pruned...] > > Pyda Srisuresh wrote: > > > > > IKE is supposed to help negotiate keys and establish SA bundle between > > IPsec peers. And, an SA bundle may be identified by the tuple of > > (, , , ). > > > > With that in mind, I am not sure how identifying the subnets or address > > list a VPN security gateway supports would help with IPsec processing, > > except in the context of policy verification. > > > > If you agree with the above reasoning, I would say that IDs for subnets > > is not required so long as there exists a policy payload. Does this make > > sense? > > > > I guess I'm not sure I agree with the above reasoning, although I don't > necessarily disagree with the conclusion, depending upon what the > 'policy' payload contains. In terms of your reasoning, have you > considered that we may use IKE to establish *multiple* SA bundles > between hosts/gateways, and that the individual SAs might have differing > security requirements, and that a sorting mechanism for such individual > connections vs security requirements may be realized using ports, > protocols, addresses, etc? Also, consider asymmetric security > requirements... > Yes to all your questions. As for asymetric security requirements, is there something specific you have in mind? > > > I agree that we may need different payloads for the 2 phases, but think > > > we need to reconcile the issue I raised in a related post, i.e. that the > > > ID payload is, by definition, DOI-specific, and this (I think) means > > > it's a phase 2 critter only. In that case, the new payload type would > > > need to be in phase 1, or the appropriate language in the ISAKMP doc > > > would need correcting. > > > > > > > I agree, ID payload is DOI specific. > > I also believe, the new policy payload is relevant to phase II only. > > > > Why do you say the new policy payload needs to be in phase I? > > > Didn't say that, only said that by the current language, the ID payload > belongs in phase 2 only, so maybe we need a payload with a different > name in phase 1. After sending that off, I came to believe that it makes > more sense to change the language in the doc, and add a new payload (as > you suggest) to phase 2. > The ID payload in phase 1 is DOI specific (ie, DOI as specified in SA payload). Refer sec 3.8 in ISAKMP ver 10 draft for ID payload usage. I dont see a problem with the ID payload remaining unchanged for phase I and phase II. > > A policy that asserts what datagrams are allowed to be processed over > > an SA are not a local matter. Such a policy must be shared between > > the SA peers. > > The minimum/maximum acceptable levels of security I am willing to apply > for the datagrams I send to you is a local policy matter (mine). The > minimum/maximum levels of security you are willing to accept for the > datagrams I send to you is also a local policy matter with respect to > you. That's why we negotiate, to find the middle ground. > OK. > > Otherwise, what is stopping one end to use an SA to send > > any datgrams it chooses to forward to its peer, while the peer doesnt > > approve of these packets and simply drops or refuses to forward. > > The fact that the originator of the packets correctly identified their > source(s) in the ID payload precludes the possibility that they would be > inappropriately (and unknown to the originator) dropped at the > destination peer. The SA would not have been established had their > source(s) not been acceptable to the target gw. In that case, if the > originator sends inappropriate packets, they will be dropped, and > rightly so. > Well, it is simply that the source identification alone is not sufficient. You need to verify aginst policies that include both source and destination parameters. > > > I still don't understand this resistance to using some sort of endpoint > > > identifier to index policy - after all, we are using an identity-based > > > security model, right? > > > > > > > See my comments earlier. Idenitities, in my mind, are relevant only to > > the extent of identifying IKE peers and Tunnel/transport IPSec end-nodes. > > Identities are of central importance to an identity-based policy model. > It dawns on me that you may be thinking of some mechanism in which the > gateways agree on some sort of policy which is independent of > identities, and then any packet which comes down the SA is presumed to > be of acceptable origin, and not subjected to any further validation > (beyond decryption/authentication). Is this correct? > Yes, I do see policies and IDs as serving 2 different purposes. yet, the second half of your assumption is not correct. A packet that comes down an SA is verified against the policies the SA is allowed to accept. > > My point is simply that the negotiating peers must know the policy they > > agree on for an SA. As for policy negoitiation in QM, IKE could pursue an > > approach similar to what it does for SA negotiation. > > > > For example, the initiator could identify the policy it intends to pursue > > for an SA and the responder would identify a subset of the orginal policy > > it is agreeable to and responds with that policy. There, you have a common > > agreeable policy between IPsec peers. Hope this helps. > > > > Okay, but how do you represent the policy? How do you select variable > levels of security, and based upon what? > I did make a straw-man proposal a couple of days of back for policy representation. As for how you associate different level of security (i.e., SA bundle parameters) to different policies is a local policy matter on either end. Only a common ground between both ends will end up being agreed upon for SA and Policy. > Scott > cheers, suresh From owner-ipsec Fri Sep 25 12:18:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA06100 for ipsec-outgoing; Fri, 25 Sep 1998 12:17:42 -0400 (EDT) From: bmanning@isi.edu Posted-Date: Fri, 25 Sep 1998 09:29:42 -0700 (PDT) Message-Id: <199809251629.AA05928@zed.isi.edu> Subject: Re: Policy instantiation/negotiation (was Re: issues with IKE that need resolution) To: skelly@redcreek.com (Scott G. Kelly) Date: Fri, 25 Sep 1998 09:29:42 -0700 (PDT) Cc: suresh@livingston.com, dharkins@cisco.com, ipsec@tis.com, lsanchez@bbn.com In-Reply-To: <360AB052.DB1191CB@redcreek.com> from "Scott G. Kelly" at Sep 24, 98 01:49:22 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 > > It occurs to me, looking back on my notes from Chicago, that BBN is > working on something very closely related to this discussion. If so, > much (if not all) of this exchange could be a waste of time. > > Specifically, I'm referring to Luis Sanchez' presentation on 'Policy > Based Security Management for IPSec'. > > Any comments? For those of us who were not in Chicago, is this presentation online? --bill From owner-ipsec Fri Sep 25 12:34:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA06139 for ipsec-outgoing; Fri, 25 Sep 1998 12:32:41 -0400 (EDT) Message-ID: <360BCA7A.4469FF54@redcreek.com> Date: Fri, 25 Sep 1998 09:53:14 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: bmanning@isi.edu CC: ipsec@tis.com Subject: Re: Policy instantiation/negotiation (was Re: issues with IKE that need resolution) References: <199809251629.AA05928@zed.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk bmanning@ISI.EDU wrote: > > > Specifically, I'm referring to Luis Sanchez' presentation on 'Policy > > Based Security Management for IPSec'. > > > > Any comments? > > For those of us who were not in Chicago, is this presentation online? > > --bill Yes, I found it on Ted's wg minutes page at http://web.mit.edu/tytso/www/ipsec/chicago/ and click on 'Policy-based Security Management'. From owner-ipsec Fri Sep 25 12:58:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA06237 for ipsec-outgoing; Fri, 25 Sep 1998 12:55:44 -0400 (EDT) Message-ID: <1F35B0C06D22D211AE0F00A0C99D759B03662D@va-exchange1.nai.com> From: "Mason, David" To: "'ipsec@tis.com'" Subject: FW: Summary of responses: Network World article on IPSec Date: Fri, 25 Sep 1998 09:32:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > >The fact that the IKE header is unprotected has been recognized by its > >designers since day one. If you're worried about active attacks on an > IKE > >exchange, all you really need to do is eat the last packet of any QM or > MM. > >Why worry about changing a bit? But, if you've got active attacks going > on, > >the same attacker could just as easily eat the resulting AH/ESP > traffic... > >Frankly, I'm not worried about this right now. > > Active attacks aside, unlike a lost last packet in an IKE exchange, the > setting of the commit bit by a glitch in the wire, however improbable, > will break the negotiation. In the lost packet case, the retransmission > timer should generally enable the negotiation to recover. Retransmitting > in the commit bit glitch case does not recover since one side is expecting > an IE connect message and the other side doesn't believe it needs to send > it. > > Until the flags and version fields of the ISAKMP header are authenticated > (that you Tero Kivinen for catching this) commit bit implemenations need > to keep > this problem in mind. One way to recover is described in the note under > the > commit bit description in ISAKMP. This method only works if the side that > didn't see the glitch needs to send an IPSec packet. For the case where > only one side currently needs to send an IPSec packet and it is the side > that received the glitch, it needs to have a retransmission timer while > waiting > for the IE connected message. The IE connected message will never come > but > at least the retry counter will eventually reach the retry limit and a new > QM > exchange can be initiated. > > By the way, what was the general consensus for the connected message? > ISAKMP states that it MUST go in an IE that has the same message id as > the QM it pertains to and IKE states that the message id MUST NOT be > the same as the QM it pertains to (or any other phase 2 exchange). There > was also some talk of not using IE but extending QM instead. If IE with > the same message id is used, is the IE IV generated via the normal IE IV > method (that is it would be the same as the initial IV that was used for > the > associate QM) or does it use the last ciphertext block of the QM instead > (seeing as it's using the same message id)? > > -dmason > > > > From owner-ipsec Fri Sep 25 12:58:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA06206 for ipsec-outgoing; Fri, 25 Sep 1998 12:54:42 -0400 (EDT) From: Anne Anderson - Sun Microsystems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Sep 1998 17:23:15 -0400 (EDT) To: ipsec@tis.com Subject: Part II: Summary of responses: Network World article on IPSec X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13834.46904.698344.199065@saguaro> Sender: owner-ipsec@ex.tis.com Precedence: bulk The set of responses was corrupted/truncated. Here is the set of all responses to Question 3: >------------------------------------------------------------------- >3. "And IKE, as it now exists, handles time-expiration of session > keys in a way that could cause one gateway not to understand > another." > > [Anne] Is this referring to the use of kbytes-based lifetime > payloads versus seconds-based lifetime payloads? To what extent > is this a barrier to deployment? Does it just cause a delay, or > is it a Big Problem? [Steven Bellovin]: IKE will definitely need another round. And there's another issue -- as best I can tell, certificates don't interoperate between platforms. But both that and your point 3 won't affect people who use single-vendor solutions for now. [Bob Moskowitz]: No this is perhaps the REAL problem. We have implementations that are to spec that will not interoperate, ie we have some challenges in the spec. Problem is that phase I lifetime operations are NOT spelled out in any of the documents, and some vendors have used the phase II rules. This appears to be incorrect. We have seen two products, that out of the bos will not work together. To get interoperation, we have to configure one for infinite phase I lifetimes and count on the other's local policy to force the deletion of the ISAKMP SAs on both sides according to its phase I lifetime. Phase II so far has not been a problem, but there is a potential problem there. Exactly true [commenting on Steven Bellovin's response]. IKE will be cycled at level due to enhancements. Cert usage is only now being well defined. Some multi-vendor situations work, not all. [David Mason]: This is a more serious problem than just lifetime expiration ... Deletion of SAs due to one side rebooting has been somewhat addressed by the initial contact message but there are still some serious problems in this area as well. Corporations are already deploying IPSec/IKE so I guess neither of these obstacles are considered big drawbacks by everybody. [Michael Richardson]: No, it refers to some minor, unclear text. In this case it meant that two products would not communicate out of the box. That isn't to say that they couldn't be configured to communicate. That is why we have a proposed standard stage that requires actual use. That way we discover the problems now. If we didn't deploy, then we wouldn't find the problems. [Derrell Piper]: Again, utter crap. There are some incomplete implementations which do not currently include support for the mandatory lifetime attributes. As a result, certain other gateways will refuse to negotiate with them because of security policy which says that lifetime negotiation is required. This is hardly a problem with the protocol. It is true that from an implementation perspective, getting rekey right is somewhat complicated in this architecture. There is work underway in IPsecond to write some guidelines about how to do rekey correctly. However, as someone who has written code, it certainly can be done interoperably. [Scott Kelly]: I think this refers to the so-called 'rekey problem'. That problem exists due to an unforseen complication introduced due to a design simplification. SAs are, by definition, unidirectional, meaning that in order for us to have a 2-way conversation, 2 SAs are required: one from me to you (over which I send data), and one from you to me (over which you send data). Technically, these 2 SAs should be negotiated in separate IKE exchanges, but as a matter of convenience, they have been combined into one negotiation, effectively rendering the SA bidirectional. For unidirectional SAs, rekeying (i.e. negotiating a new SA because the first one is expiring) is simple: for the SA extending from me to you, if I want to continue, I renegotiate a new SA, and delete the old one once I'm finished. The same applies to you, if you wish to continue protecting packets on the return path. For bidirectional SAs, it's a bit more involved, i.e. how do we decide who is responsible for rekeying? The problem arises here, when both sides attempt to rekey at almost exactly the same time. A quick fix that was proposed was to introduce random jitter into the SA timer, meaning to store a value that is less than the negotiated value by some small random amount, thus lessening the probability of a rekey collision. However, some vendors still have problems with the logistics of this, so a mechanism needs to be agreed upon and formalized. Hardly earth-shaking... [Pyda Srisuresh] Lifetime issue is quite relevant to remote access. Remote access clients are prone to logging in frequently (as opposed to attached to the net all the time). The existing lifetime metrics do not guarantee that an SA established for one user does not get deleted when the user terminates the connection. Clearly, IKE on either end should clean up SAs when network-login is terminated. A new metric like "network-connected-time" would be useful for remote access users. Also, interoperability issues with regard to session rekeying upon lifetime expiry should be addressed independent of remote access clients. -- Anne Anderson Email: aha@east.sun.com Sun Microsystems Laboratories or: aha@acm.org 2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928 Chelmsford, MA 01824 USA Fax: (978) 250-5067 From owner-ipsec Fri Sep 25 12:58:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA06239 for ipsec-outgoing; Fri, 25 Sep 1998 12:55:46 -0400 (EDT) Message-ID: <5F6AA2CAD4A4D1119C3D00A0C99D6AC6C6CC18@static-5-91.dhcp.nai.com> From: "Jones, Michael" To: ipsec@tis.com Subject: Location of ICSA IPSEC 1.1 certification criteria Date: Thu, 24 Sep 1998 16:41:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Where can I get a list of the ICSA IPSEC 1.1 certification criteria? ICSA's website only has the 1.0 spec listed. Thanks, Mike Michael K. Jones Sr. Product Manager, VPN/PKI/Active Security Network Associates, Inc. mjones@nai.com Direct: 408-346-3179 FAX: 408-346-3650 Pager: 888-916-8048 "Who's watching your network?" http://www.nai.com/ From owner-ipsec Fri Sep 25 14:31:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA06478 for ipsec-outgoing; Fri, 25 Sep 1998 14:24:48 -0400 (EDT) From: "Luis A. Sanchez" Message-Id: <199809251443.OAA00727@nutmeg.bbn.com> Subject: Re: Policy instantiation/negotiation (was Re: issues with IKE that need resolution) In-Reply-To: <199809242259.SAA10481@istari.sandelman.ottawa.on.ca> from "Michael C. Richardson" at "Sep 24, 98 06:59:27 pm" To: mcr@sandelman.ottawa.on.ca (Michael C. Richardson) Date: Fri, 25 Sep 1998 14:43:53 +0000 (GMT) Cc: ipsec@tis.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'm still hoping for lots and lots more details about the policy > discovery work of Luis. > Luis, will a paper or something be forthcoming? > Michael, We hope to have 2 IDs ready by next week. One defines a Security Policy Specification Language (SPSL) and the other one describes a Security Policy System (SPS) that manages security policies, provides inter-domain policy resolution for complex topologies, provides security gateway discovery, etc. I will post the drafts as soon as they are ready. We are also releasing the code next week so stay tuned. Luis From owner-ipsec Fri Sep 25 15:01:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA06674 for ipsec-outgoing; Fri, 25 Sep 1998 14:59:52 -0400 (EDT) Message-Id: <199809251917.MAA15311@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: ipsec@tis.com Subject: Re: IPsec vs SKIP Protocol In-reply-to: Your message of "Thu, 24 Sep 1998 03:09:58 PDT." <19980924100959.19457.qmail@hotmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15309.906751052.1@cisco.com> Date: Fri, 25 Sep 1998 12:17:32 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Just for the record: Cisco does not and will not support 40bit IPSec. Dan. On Thu, 24 Sep 1998 03:09:58 PDT Robert Cosme wrote > > Currently, I am working on a project and this has certain portion that > deals with encryption. The specification requires encryption and key > management SKIP. I'm not a guru of encryption although I know some > basics. Please explain to me SKIP and how do we contrast this with > IPSec. I am proposing a Cisco products which I know use IPSec - 40-DES > and 56-DES. Is there a 144-bit encryption? From owner-ipsec Fri Sep 25 15:04:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA06709 for ipsec-outgoing; Fri, 25 Sep 1998 15:02:52 -0400 (EDT) Date: Fri, 25 Sep 1998 15:19:09 -0400 Message-Id: <199809251919.PAA01300@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: bmanning@isi.edu Cc: skelly@redcreek.com, suresh@livingston.com, dharkins@cisco.com, ipsec@tis.com, lsanchez@bbn.com In-Reply-To: bmanning@isi.edu's message of Fri, 25 Sep 1998 09:29:42 -0700 (PDT), <199809251629.AA05928@zed.isi.edu> Subject: Re: Policy instantiation/negotiation (was Re: issues with IKE that need resolution) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: bmanning@isi.edu Date: Fri, 25 Sep 1998 09:29:42 -0700 (PDT) For those of us who were not in Chicago, is this presentation online? Yes, it's available along with the Chicago IPSEC minutes: http://web.mit.edu/tytso/www/ipsec/chicago/lsanchez.ps http://web.mit.edu/tytso/www/ipsec/chicago/ (The first is Luis Sanchez's presentation, the second is the draft version of the Chicago minutes. Please send any comments on the minutes soon! I plan to submit them to the secretariat for publication in the proceedings on Monday.) Note that the postscript may cause some versions of ghostview to croak. I haven't figured out whether this is Microsoft's fault or ghostview's fault. Ghostview 3.1 does work, as does viewing the postscript file using ghostscript directly. (Why oh why does postscript files generated by MS-products cause so many problems? Sigh...) - Ted From owner-ipsec Fri Sep 25 15:10:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA06733 for ipsec-outgoing; Fri, 25 Sep 1998 15:08:51 -0400 (EDT) From: bmanning@isi.edu Posted-Date: Fri, 25 Sep 1998 12:20:59 -0700 (PDT) Message-Id: <199809251920.AA08510@zed.isi.edu> Subject: Re: Policy instantiation/negotiation (was Re: issues with IKE that need resolution) To: tytso@MIT.EDU (Theodore Y. Ts'o) Date: Fri, 25 Sep 1998 12:20:59 -0700 (PDT) Cc: bmanning@isi.edu, skelly@redcreek.com, suresh@livingston.com, dharkins@cisco.com, ipsec@tis.com, lsanchez@bbn.com In-Reply-To: <199809251919.PAA01300@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Sep 25, 98 03:19:09 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 > Yes, it's available along with the Chicago IPSEC minutes: > > http://web.mit.edu/tytso/www/ipsec/chicago/lsanchez.ps > http://web.mit.edu/tytso/www/ipsec/chicago/ Thanks. > Note that the postscript may cause some versions of ghostview to croak. > I haven't figured out whether this is Microsoft's fault or ghostview's > fault. Ghostview 3.1 does work, as does viewing the postscript file > using ghostscript directly. (Why oh why does postscript files generated > by MS-products cause so many problems? Sigh...) Croaks for me.. :( > > - Ted --bill From owner-ipsec Fri Sep 25 16:08:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA06929 for ipsec-outgoing; Fri, 25 Sep 1998 16:04:52 -0400 (EDT) Message-ID: From: Greg Carter To: ca-talk@icsa.net Cc: "'ipsec@tis.com'" Subject: Update to ipsec.entrust.com Date: Fri, 25 Sep 1998 16:16:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Some of you have been using ipsec.entrust.com to get certificates for testing with IPSEC. The marketing people and lawyers finally found out I set up the site and so the site has changed a lot, even the address: http://freecerts.entrust.com, then follow the VPN links. Development changes include: - rsaExtensionsAttribute - Will now accept either Extensions encoding or T61String as per BCERT. - DSA (CA's key is RSA though, DSA CA coming soon) - can now accept requests with the -----BEGIN.., END----- tags. - new CA key so you have to get the CA cert again. Test away, if you have any problems email the error code you get along with your PKCS10 request and I'll check it out. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec Fri Sep 25 17:01:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA07150 for ipsec-outgoing; Fri, 25 Sep 1998 16:56:54 -0400 (EDT) Message-Id: <199809252114.RAA04327@istari.sandelman.ottawa.on.ca> To: internet-drafts@ietf.org cc: ipsec-errors@sandelman.ottawa.on.ca, ipsec@tis.com Subject: new ICMP error drafts MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4325.906758064.1@istari.sandelman.ottawa.on.ca> Date: Fri, 25 Sep 1998 17:14:25 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk ID Editor, two new drafts can be retrieved from http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec-icmp-handle-v4-01.txt and http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec-icmp-options-01.txt They should be published as: draft-ietf-ipsec-icmp-handle-v4-01.txt draft-ietf-ipsec-icmp-options-01.txt Thank you. From owner-ipsec Mon Sep 28 08:58:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA15221 for ipsec-outgoing; Mon, 28 Sep 1998 08:48:53 -0400 (EDT) X-Authentication-Warning: khercs.chipware.net: maxinux owned process doing -bs Date: Sun, 27 Sep 1998 20:00:14 -0700 (PWT) From: Max Inux X-Sender: maxinux@khercs.chipware.net To: Mark Gillott cc: "'l2tp@zando.com'" , "'ipsec@tis.com'" Subject: Re: VPN bakeoff in October & export licensing. In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EE4A03@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 23 Sep 1998, Mark Gillott wrote: >Date: Wed, 23 Sep 1998 17:08:25 +0100 >From: Mark Gillott >To: "'l2tp@zando.com'" , "'ipsec@tis.com'" >Subject: VPN bakeoff in October & export licensing. > >Is there anyone out there from Europe that is planning to attend the VPN >(IPsec/IKE/L2TP) bakeoff at Binghamption NY in October? A couple of us from >the UK are planning to attend, but the question has been asked about >U.S./U.K. export licensing. All our development is being done in the UK. >Even though we're part of a U.S. company we're playing it safe and the code >never leaves the UK - we're currently having discussions with the NSA as to >how we can distribute the code within Cabletron. > >But what about the bakeoff? Does anyone have a view on what the NSA would >say if we were to dial home (to the UK), fixed some bug or other and then >copied a new image back to the workshop for further testing? From my >understanding, the NSA are not concerned about importation (which this is). >But what about the UK? Is the UK govt. going to get "upset" about us >exporting from the UK? > >What about when we come to go home. Presumably we have remove all our test >images from laptops/routers before we leave the US? > >Mark Gillott > >Cabletron Systems (DNPG) >DTN: 831-3172, Phone: +44 191 497 3172 > > Actually from what i have heard, seen, read, you are allowed to export (and import (duh))crypto on your palm/laptop, as long as it stays on your palm/laptop. -- Max Inux Hey Christy!!! KeyID 0x8907E9E5 Kinky Sex makes the world go round O R Strong crypto makes the world safe If crypto is outlawed only outlaws will have crypto Fingerprint(Photo Also): 259D 59F7 D98C CD73 1ACD 54Ea 6C43 4877 8907 E9E5 From owner-ipsec Mon Sep 28 10:05:47 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA15595 for ipsec-outgoing; Mon, 28 Sep 1998 10:04:00 -0400 (EDT) Message-Id: <199809281421.KAA28290@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-mib-00.txt Date: Mon, 28 Sep 1998 10:21:47 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec MIB Author(s) : T. Jenkins Filename : draft-ietf-ipsec-mib-00.txt Pages : 32 Date : 25-Sep-98 This document defines monitoring and status MIBs for IPSec. It does not define MIBs that may be used for configuring IPSec implementations or for providing low-level diagnostic or debugging information. Those MIBs may be defined in later versions of this document or in other documents. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPSec portion of their network. Statistics are provided as well. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-mib-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-mib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980925155438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980925155438.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Sep 28 10:59:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA15933 for ipsec-outgoing; Mon, 28 Sep 1998 10:58:58 -0400 (EDT) Message-Id: <199809281507.LAA29922@ietf.org> To: "Michael C. Richardson" cc: Cynthia Clark , ipsec-errors@sandelman.ottawa.on.ca, ipsec@tis.com Subject: RE: new ICMP error drafts Date: Mon, 28 Sep 1998 11:07:47 -0400 From: Cynthia Clark Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, Thank you for these two Internet-Draft submissions. Since they are brand new drafts, it's a normal procedure for me making these filename version number changes from "draft-ietf-ipsec-icmp-handle-v4-01.txt" to "draft-ietf-ipsec-icmp-handle-v4-00.txt" and from "draft-ietf-ipsec-icmp-options-01.txt" to "draft-ietf-ipsec-icmp-options-00.txt" Since this remote site is no longer in service, I've also corrected and changed from "ds.internic.net" to "ftp.ietf.org" in the Status of this Memo section. Please make a note of this for your future drafts. I'll send the announcements to the entire ietf sometime tomorrow or next work day. If you have any concerns about any drafts anytime, please contact me directly at as I'm in charge of all new and revised drafts. Kind Regards, Cynthia ------------------------------------------------------ Cynthia Clark, IETF Internet-Drafts Publisher E-mail Address preference: ------------------------------------------------------- ------- Forwarded Message Return-Path: owner-internet-drafts Delivery-Date: Fri, 25 Sep 1998 17:14:45 -0400 Return-Path: owner-internet-drafts Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16193 for ; Fri, 25 Sep 1998 17:14:43 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA15364; Fri, 25 Sep 1998 17:14:26 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca ([[UNIX: localhost]]) by istari.sandelman.ottawa.on.ca (8.8.7/8.7.3) with ESMTP id RAA04327; Fri, 25 Sep 1998 17:14:25 -0400 (EDT) Message-Id: <199809252114.RAA04327@istari.sandelman.ottawa.on.ca> To: internet-drafts@ietf.org cc: ipsec-errors@sandelman.ottawa.on.ca, ipsec@tis.com Subject: new ICMP error drafts MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4325.906758064.1@istari.sandelman.ottawa.on.ca> Date: Fri, 25 Sep 1998 17:14:25 -0400 From: "Michael C. Richardson" ID Editor, two new drafts can be retrieved from http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec-icmp-handle-v4-01.txt and http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec-icmp-options-01.txt They should be published as: draft-ietf-ipsec-icmp-handle-v4-01.txt draft-ietf-ipsec-icmp-options-01.txt Thank you. ------- End of Forwarded Message From owner-ipsec Mon Sep 28 11:07:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA15969 for ipsec-outgoing; Mon, 28 Sep 1998 11:05:58 -0400 (EDT) Date: Mon, 28 Sep 1998 11:22:55 -0400 Message-Id: <199809281522.LAA00658@brill.shiva.com> From: John Shriver To: maxinux@bigfoot.com CC: Mark.Gillott@digital.com, l2tp@zando.com, ipsec@tis.com In-reply-to: (message from Max Inux on Sun, 27 Sep 1998 20:00:14 -0700 (PWT)) Subject: Re: VPN bakeoff in October & export licensing. Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Sun, 27 Sep 1998 20:00:14 -0700 (PWT) From: Max Inux To: Mark Gillott cc: "'l2tp@zando.com'" , "'ipsec@tis.com'" Subject: Re: VPN bakeoff in October & export licensing. Actually from what i have heard, seen, read, you are allowed to export (and import (duh))crypto on your palm/laptop, as long as it stays on your palm/laptop. What you are thinking of is 15CFR740.9(a)(2)(i)"Tools of the trade". But it may not apply to source code, just executeables. From owner-ipsec Mon Sep 28 11:08:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA15983 for ipsec-outgoing; Mon, 28 Sep 1998 11:08:00 -0400 (EDT) Date: Mon, 28 Sep 1998 18:25:19 +0300 (EET DST) From: Markku Savela Message-Id: <199809281525.SAA01912@anise.tte.vtt.fi> To: ipsec@tis.com Subject: IPSEC testing between implementation over Internet? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk I *did* saw someone mention about a IPSEC testing possibility, but I failed to find the mail from archives (I guess I am blind or the topic is not such that I recognized it). At some point fairly soon I would like to check if my version of IPSEC would actually work with anyone else. My "picture" is as follows "my client machine H1" ----> PPP dialup (dynamic address from [130.188.150.*]) ---> some test destination? I don't have IKE, only manual keys. What I would really love, is following configurations H1* -> (internet) --> H2* (with a local Web server) e.g. I would use Web browser over IPSEC link to server on H2. or even more ambitious combination (tunnel variations) H1* -> (internet) --> SG2* <---> some web servers But, any simple way to find out if my packet munging code is working correctly, will do equally well (except I hate to read hexdumps) ------- ps. In this latter configuration, it seems that it will work with standard internet service hosts only if for some reason the packets destined to H1 are routed by default to SG2? (e.g. SG2 is also a normal router for the subnet). This is somewhat worrying as the normal situation would be at this stage (it is unlikely for R1 to have IPSEC) H1* <--> (internet) <--> R1/Firewall <--> SG2* <--> H2 If H2 is standard PC or host inside company network, it will by default route packets destined to H1 to R1, and not to SG2? Does this mean that any IPSEC testing with this type of configs need a change in H2's routing info (or do we have SG2's that automaticly request routing by IGMP or what?) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Mon Sep 28 11:22:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16057 for ipsec-outgoing; Mon, 28 Sep 1998 11:21:59 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EE4A16@wade.reo.dec.com> From: Mark Gillott To: "'John Shriver'" , maxinux@bigfoot.com Cc: l2tp@zando.com, ipsec@tis.com Subject: RE: VPN bakeoff in October & export licensing. Date: Mon, 28 Sep 1998 16:30:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk That sounds good. Maybe I didn't make myself clear. We only intend to "import" (new) binary images (from the UK) onto a laptop and thence onto a router. Once we have finished testing, we'll delete all images from laptops/routers prior to shipping everything back to the UK. At no point does the source code "leave" the UK. Thanks to all those that have replied, we're in touch with the NSA... -----Original Message----- From: John Shriver [mailto:jas@shiva.com] Sent: 28 September 1998 16:23 To: maxinux@bigfoot.com Cc: Mark Gillott; l2tp@zando.com; ipsec@tis.com Subject: Re: VPN bakeoff in October & export licensing. Date: Sun, 27 Sep 1998 20:00:14 -0700 (PWT) From: Max Inux To: Mark Gillott cc: "'l2tp@zando.com'" , "'ipsec@tis.com'" Subject: Re: VPN bakeoff in October & export licensing. Actually from what i have heard, seen, read, you are allowed to export (and import (duh))crypto on your palm/laptop, as long as it stays on your palm/laptop. What you are thinking of is 15CFR740.9(a)(2)(i)"Tools of the trade". But it may not apply to source code, just executeables. From owner-ipsec Mon Sep 28 11:46:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16191 for ipsec-outgoing; Mon, 28 Sep 1998 11:46:00 -0400 (EDT) From: dbastien@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com Message-ID: <8525668D.00575991.00@gotlib.galea.com> Date: Mon, 28 Sep 1998 12:03:45 -0400 Subject: who is right ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk I saw in the draft-ietf-ipsec-esp-v2-06.txt : > typical IPv4 packet, on a "before and after" basis. (The "ESP > trailer" encompasses any Padding, plus the Pad Length, and Next > Header fields.) > BEFORE APPLYING ESP > ---------------------------- > IPv4 |orig IP hdr | | | > |(any options)| TCP | Data | > ---------------------------- > > AFTER APPLYING ESP > ------------------------------------------------- > IPv4 |orig IP hdr | ESP | | | ESP | ESP| > |(any options)| Hdr | TCP | Data | Trailer |Auth| > ------------------------------------------------- > |<----- encrypted ---->| > |<------ authenticated ----->| and i read in the draft-ietf-ipsec-arch-sec-06.txt : > 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode > > <-- How Outer Hdr Relates to Inner Hdr --> > Outer Hdr at Inner Hdr at > IPv4 Encapsulator Decapsulator > Header fields: -------------------- ------------ > version 4 (1) no change > header length constructed no change > TOS copied from inner hdr (5) no change > total length constructed no change > ID constructed no change > flags (DF,MF) constructed, DF (4) no change > fragmt offset constructed no change > TTL constructed (2) decrement (2) > protocol AH, ESP, routing hdr no change > checksum constructed constructed (2) > src address constructed (3) no change > dest address constructed (3) no change > Options never copied no change who is right ? The arch draft or the esp draft ? Thanks, Dominique dbastien@galea.com From owner-ipsec Mon Sep 28 12:13:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA16302 for ipsec-outgoing; Mon, 28 Sep 1998 12:12:03 -0400 (EDT) Message-Id: <199809281629.LAA24210@gungnir.fnal.gov> To: dbastien@galea.com Cc: ipsec@tis.com From: "Matt Crawford" Subject: Re: who is right ? In-reply-to: Your message of Mon, 28 Sep 1998 12:03:45 EDT. <8525668D.00575991.00@gotlib.galea.com> Date: Mon, 28 Sep 1998 11:29:02 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not a "real" expert, but it looks to me like you're comparing transport mode ine one document to tunnel mode in another. From owner-ipsec Mon Sep 28 12:32:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA16444 for ipsec-outgoing; Mon, 28 Sep 1998 12:31:59 -0400 (EDT) From: dbastien@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com Message-ID: <8525668D.005C51E7.00@gotlib.galea.com> Date: Mon, 28 Sep 1998 12:49:44 -0400 Subject: who is right ? (take 2) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm really sorry guys. The first one (cut and paste) is suppose to be the tunnel mode : I saw in the draft-ietf-ipsec-esp-v2-06.txt : > -------------------------------------------------------- --- > IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| > |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| > -------------------------------------------------------- --- > |<--------- encrypted ---------->| > |<----------- authenticated ---------->| and i read in the draft-ietf-ipsec-arch-sec-06.txt : > 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode > > <-- How Outer Hdr Relates to Inner Hdr --> > Outer Hdr at Inner Hdr at > IPv4 Encapsulator Decapsulator > Header fields: -------------------- ------------ > version 4 (1) no change > header length constructed no change > TOS copied from inner hdr (5) no change > total length constructed no change > ID constructed no change > flags (DF,MF) constructed, DF (4) no change > fragmt offset constructed no change > TTL constructed (2) decrement (2) > protocol AH, ESP, routing hdr no change > checksum constructed constructed (2) > src address constructed (3) no change > dest address constructed (3) no change > Options never copied no change I just want to know how to process the option in the outter IP header. I remove them ? or I let them unchange (from IP1)? Thanks, Dominique dbastien@galea.com From owner-ipsec Mon Sep 28 12:59:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA16622 for ipsec-outgoing; Mon, 28 Sep 1998 12:59:01 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81326@RED-MSG-50> From: Richard Draves To: "'dbastien@galea.com'" Cc: ipsec@tis.com Subject: RE: who is right ? (take 2) Date: Mon, 28 Sep 1998 10:17:01 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't see this as an inconsistency. You should not copy the options from the inner header to the outer header. But the outer header may contain options, depending on the local node's configuration. Rich > -----Original Message----- > From: dbastien@galea.com [mailto:dbastien@galea.com] > Sent: Monday, September 28, 1998 9:50 AM > To: ipsec@tis.com > Subject: who is right ? (take 2) > > > > I'm really sorry guys. > > The first one (cut and paste) is suppose to be the tunnel mode : > > I saw in the draft-ietf-ipsec-esp-v2-06.txt : > > > > -------------------------------------------------------- > --- > > IPv4 | new IP hdr* | | orig IP hdr* | | > | ESP | > ESP| > > |(any options)| ESP | (any options) > |TCP|Data|Trailer|Auth| > > > -------------------------------------------------------- > --- > > |<--------- encrypted > ---------->| > > |<----------- authenticated > ---------->| > > and i read in the draft-ietf-ipsec-arch-sec-06.txt : > > > 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode > > > > <-- How Outer Hdr Relates to > Inner Hdr --> > > Outer Hdr at > Inner Hdr at > > IPv4 Encapsulator > Decapsulator > > Header fields: -------------------- > ------------ > > version 4 (1) no change > > header length constructed no change > > TOS copied from inner hdr (5) no change > > total length constructed no change > > ID constructed no change > > flags (DF,MF) constructed, DF (4) no change > > fragmt offset constructed no change > > TTL constructed (2) > decrement (2) > > protocol AH, ESP, routing hdr no change > > checksum constructed > constructed (2) > > src address constructed (3) no change > > dest address constructed (3) no change > > Options never copied no change > > > > I just want to know how to process the option in the outter IP header. > > I remove them ? or I let them unchange (from IP1)? > > Thanks, > > Dominique > dbastien@galea.com > > > > From owner-ipsec Mon Sep 28 14:35:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA17135 for ipsec-outgoing; Mon, 28 Sep 1998 14:34:02 -0400 (EDT) Date: Mon, 28 Sep 1998 14:50:52 -0400 (EDT) From: Henry Spencer To: Mark Gillott cc: l2tp@zando.com, ipsec@tis.com Subject: RE: VPN bakeoff in October & export licensing. In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EE4A16@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Thanks to all those that have replied, we're in touch with the NSA... Be sure you get it in writing. :-) More seriously, do remember that although NSA is influential in this area, they do *not* actually set -- or more important, enforce -- export policy. They're not the ones you need written reassurance from. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Mon Sep 28 16:46:14 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA17967 for ipsec-outgoing; Mon, 28 Sep 1998 16:43:59 -0400 (EDT) From: dletendr@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com Message-ID: <8525668D.0073347A.00@gotlib.galea.com> Date: Mon, 28 Sep 1998 17:01:04 -0400 Subject: IPSec Client Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk I am looking for an IPSec client under NT capable of opening a tunnel between a host and a security gateway. This tunnel would enable me to do encrypted transactions between myself and the gateway(FTP or TELnet). Anyone knows of a client easily available??? Daniel Letendre dletendr@galea.com From owner-ipsec Mon Sep 28 18:58:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA18418 for ipsec-outgoing; Mon, 28 Sep 1998 18:57:05 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81334@RED-MSG-50> From: Richard Draves To: "'IPsec'" Subject: inbound policy verification Date: Mon, 28 Sep 1998 16:14:10 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk [I just joined the ipsec list. I've skimmed the minutes from the August IETF and the last month's archives. I'm reading the July '98 security architecture draft. I understand this draft was just approved by the IESG. I'm working on an implementation: http://research.microsoft.com/msripv6. My questions stem from a recent group discussion with Aaron Griggs, Maryann Maher, Allison Mankin, and Brian Zill.] I don't understand an aspect of the inbound processing specified in section 5.2.1 of the security architecture spec. As specified, the processing would seem to create a security problem. As I understand it, the basic idea is that a) the headers are processed and list of SAs used are collected, then b) the selectors from the packet are used to locate a security policy in the inbound SPD/SAD, then c) check that the SAs that were used match the SAs that are specified by the policy. The part I don't understand is the provision that if the SAs don't match, then the implementation should continue searching the inbound SPD until it either finds a policy that accepts the packet, or it's checked all the policies in the inbound SPD. This would seem to make it impossible to enforce a more-restrictive policy in the inbound SPD when there is also a more general policy. For example, suppose I'm a host H1 and I expect to receive packets from a network N2, but there's a particular host H2 in N2 for which I have different security requirements. So I create two policies in my inbound SPD - first one with source address selector H2, and the second one with source address selector N2 (an address prefix or range). The first policy results in a SAD entry with security association SA1, and the second results in a SAD entry with security association SA2. Now suppose I receive a packet from H2 with the "wrong" security headers. I process the packet and discover SA2 from the destination address/SPI/protocol triple and do the required authentication/decryption. Now I search the SPD. The packet's selectors match the first policy but the wrong SA was used to receive the packet. I want to reject this packet. However this provision says I should continue searching the inbound SPD. I find the second policy; the packet's selectors match it also. SA2 is the right SA for this policy, so I accept the packet. Surely this can't be right? What am I missing? Thanks, Rich From owner-ipsec Mon Sep 28 20:21:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA18673 for ipsec-outgoing; Mon, 28 Sep 1998 20:20:07 -0400 (EDT) Message-ID: <36102B9E.FD39A982@cs.umass.edu> Date: Mon, 28 Sep 1998 20:36:46 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: Richard Draves , IPsec WG List CC: Lewis McCarthy Subject: Re: inbound policy verification References: <4D0A23B3F74DD111ACCD00805F31D8100AF81334@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Rich, > The part I don't understand is the provision that if the SAs don't match, > then the implementation should continue searching the inbound SPD until it > either finds a policy that accepts the packet, or it's checked all the > policies in the inbound SPD. > > This would seem to make it impossible to enforce a more-restrictive policy > in the inbound SPD when there is also a more general policy. I suspect you're confused about the general semantics of the IPsec policy assertions. The basic conservative security principle is that everything is prohibited unless it is explicitly allowed. In the absence of policy assertions, nothing is allowed. Each policy assertion makes a purely *positive* statement -- some particular set of actions is allowed. Negative statements aren't needed in this framework because anything not explicitly mentioned by the policy assertions is banned by default. > For example, suppose I'm a host H1 and I expect to receive packets from a > network N2, but there's a particular host H2 in N2 for which I have > different security requirements. So I create two policies in my inbound SPD > - first one with source address selector H2, and the second one with source > address selector N2 (an address prefix or range). The first policy results > in a SAD entry with security association SA1, and the second results in a > SAD entry with security association SA2. The policy entries you're creating in this hypothetical example don't mean what I think you intend. The policy using N2 as a selector allows certain kinds of security associations to be established with any host matching the N2 selector, *regardless* of what other policy assertions are in the SPD. Meanwhile the policy that selects on H2 allows certain other kinds of security associations to be set up with H2, *in addition to* any other kinds of security associations that may be allowed by other policies in the SPD. > Now suppose I receive a packet from H2 with the "wrong" security headers. I > process the packet and discover SA2 from the destination > address/SPI/protocol triple and do the required authentication/decryption. > Now I search the SPD. The packet's selectors match the first policy but the > wrong SA was used to receive the packet. I want to reject this packet. > > However this provision says I should continue searching the inbound SPD. I > find the second policy; the packet's selectors match it also. SA2 is the > right SA for this policy, so I accept the packet. Your policy entry for N2 needs to be narrowed to achieve the exclusion you want. Instead of a policy entry that specifies that the "wrong" parameters can be used in communicating with *any* host in network N2, that entry needs to specify that the "wrong" parameters can be used in communicating with hosts X2, Y2, Z2, etc. (Recently there's been some discussion on the list about increasing the expressiveness of the ID syntax to make it simpler to specify policies covering nontrivial combinations of hosts, subnets, etc.) Hope this helps, -Lewis From owner-ipsec Mon Sep 28 23:22:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA19151 for ipsec-outgoing; Mon, 28 Sep 1998 23:20:05 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <8525668D.005C51E7.00@gotlib.galea.com> Date: Mon, 28 Sep 1998 23:27:20 -0400 To: dbastien@galea.com From: Stephen Kent Subject: Re: who is right ? (take 2) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dominique, Tunnel mode processing calls for discarding any options from the outer header, upon receipt at the destination, because of security concerns. Inner header options are not copied to the outer header. The options in the figure in the outer header might be statically determined for this SA or all SAs. This processing restrictioon may change in later editions of the arch doc, based on some issues that have been raised. Steve From owner-ipsec Tue Sep 29 02:20:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA19769 for ipsec-outgoing; Tue, 29 Sep 1998 02:16:05 -0400 (EDT) Message-Id: <199809290633.KAA12743@relay2.elvis.ru> Comments: Authenticated sender is From: "Valery Smyslov" Organization: Elvis+ To: lmccarth@cs.umass.edu, ipsec@tis.com Date: Tue, 29 Sep 1998 10:32:53 +3 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: inbound policy verification In-reply-to: <36102B9E.FD39A982@cs.umass.edu> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk On 28 Sep 98 at 20:36, Lewis McCarthy wrote: Hi, > > For example, suppose I'm a host H1 and I expect to receive packets from a > > network N2, but there's a particular host H2 in N2 for which I have > > different security requirements. So I create two policies in my inbound SPD > > - first one with source address selector H2, and the second one with source > > address selector N2 (an address prefix or range). The first policy results > > in a SAD entry with security association SA1, and the second results in a > > SAD entry with security association SA2. > > The policy entries you're creating in this hypothetical example don't mean > what I think you intend. The policy using N2 as a selector allows certain > kinds of security associations to be established with any host matching the > N2 selector, *regardless* of what other policy assertions are in the SPD. > Meanwhile the policy that selects on H2 allows certain other kinds of > security associations to be set up with H2, *in addition to* any other > kinds of security associations that may be allowed by other policies in the > SPD. So, if I have policy with some SPD entries that demand secure communication with some number of specific hosts/networks and with last entry, that allows insecure communication with the rest of the internet, does this mean, that such policy will allow *any* host, including those specific, to communicate with me insecurely? > > Now suppose I receive a packet from H2 with the "wrong" security headers. I > > process the packet and discover SA2 from the destination > > address/SPI/protocol triple and do the required authentication/decryption. > > Now I search the SPD. The packet's selectors match the first policy but the > > wrong SA was used to receive the packet. I want to reject this packet. > > > > However this provision says I should continue searching the inbound SPD. I > > find the second policy; the packet's selectors match it also. SA2 is the > > right SA for this policy, so I accept the packet. > > Your policy entry for N2 needs to be narrowed to achieve the exclusion you > want. Instead of a policy entry that specifies that the "wrong" parameters can > be used in communicating with *any* host in network N2, that entry needs to > specify that the "wrong" parameters can be used in communicating with hosts > X2, Y2, Z2, etc. (Recently there's been some discussion on the list about > increasing the expressiveness of the ID syntax to make it simpler to specify > policies covering nontrivial combinations of hosts, subnets, etc.) In this case, what is the purpose of total ordering of SPD entries (which architecture draft requires), if we still need to look through all of them? > Hope this helps, > -Lewis > Regards, Valery Smyslov. From owner-ipsec Tue Sep 29 10:03:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21439 for ipsec-outgoing; Tue, 29 Sep 1998 09:58:13 -0400 (EDT) Message-Id: <199809291415.KAA10747@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-icmp-options-00.txt Date: Tue, 29 Sep 1998 10:15:34 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Options for handling ICMP messages that must be forwarded Author(s) : M. Richardson Filename : draft-ietf-ipsec-icmp-options-00.txt Pages : 7 Date : 28-Sep-98 This document discusses three options for securely communicating ICMP messages from one IPsec security gateway to another. This document expands upon section 6 of the IPsec architecture draft. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-icmp-options-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-icmp-options-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-icmp-options-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980928110216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-icmp-options-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-icmp-options-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980928110216.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Sep 29 10:03:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21438 for ipsec-outgoing; Tue, 29 Sep 1998 09:58:11 -0400 (EDT) Message-Id: <199809291415.KAA10729@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-icmp-handle-v4-00.txt Date: Tue, 29 Sep 1998 10:15:29 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPv4 ICMP messages and IPsec security gateways Author(s) : M. Richardson Filename : draft-ietf-ipsec-icmp-handle-v4-00.txt Pages : 16 Date : 28-Sep-98 This document enumerates the list of ICMP messages that a security gate- way may receive and provides an analysis of if and how a gateway should handle them. Three options types of behaviour are enumerated: discard, MAY be forwarded, and MUST be forwarded. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-icmp-handle-v4-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-icmp-handle-v4-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-icmp-handle-v4-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980928105907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-icmp-handle-v4-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-icmp-handle-v4-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980928105907.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Sep 29 15:05:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA22822 for ipsec-outgoing; Tue, 29 Sep 1998 15:03:44 -0400 (EDT) Message-ID: <36113326.4EF60AA4@cs.umass.edu> Date: Tue, 29 Sep 1998 15:21:10 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: Valery Smyslov , IPsec WG List Subject: Re: inbound policy verification References: <199809290633.KAA12743@relay2.elvis.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Valery, > So, if I have policy with some SPD entries that demand secure > communication with some number of specific hosts/networks and with > last entry, that allows insecure communication with the rest of the > internet, does this mean, that such policy will allow *any* host, > including those specific, to communicate with me insecurely? If the matching entry specifying strong security parameters for particular hosts/nets precedes the wildcard bypass-IPsec entry, then the SPD lookup settles on that matching entry (strong security with specific hosts). In Rich's example the incoming packet's selector did not match the selector for the host-specific SPD entry. So the lookup dropped through to the later entry (for a whole network) in the SPD. IMHO having a very permissive wildcarded entry at the end of the SPD can be slightly risky, from a s/w engineering perspective. A small error in a host/net-specific entry might cause that specific entry not to match in some situation when it should have. So instead the wildcarded bypass entry matches, and traffic on that connection transparently bypasses IPsec processing. (Packets are sent in the clear and no alarm bells ring....) If there had been no wildcarded bypass entry at the end of the SPD, then the connection would have failed and (presumably) someone would notice the communication failure relatively quickly. [...] > > > However this provision says I should continue searching the inbound SPD. I > > > find the second policy; the packet's selectors match it also. SA2 is the > > > right SA for this policy, so I accept the packet. > > > > Your policy entry for N2 needs to be narrowed to achieve the exclusion you > > want. Instead of a policy entry that specifies that the "wrong" parameters can > > be used in communicating with *any* host in network N2, that entry needs to > > specify that the "wrong" parameters can be used in communicating with hosts > > X2, Y2, Z2, etc. (Recently there's been some discussion on the list about > > increasing the expressiveness of the ID syntax to make it simpler to specify > > policies covering nontrivial combinations of hosts, subnets, etc.) > > In this case, what is the purpose of total ordering of SPD entries > (which architecture draft requires), if we still need to look > through all of them? (See my comment above about Rich's example.) You need to keep looking until you find one that matches (or you run out of entries to examine). More than one entry might have a selector that matches the packet -- the first matching entry (if any) in the SPD is used. -Lewis From owner-ipsec Tue Sep 29 18:30:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA23529 for ipsec-outgoing; Tue, 29 Sep 1998 18:29:53 -0400 (EDT) Date: Tue, 29 Sep 1998 18:46:26 -0400 (EDT) From: Henry Spencer To: Lewis McCarthy cc: IPsec WG List Subject: Re: inbound policy verification In-Reply-To: <36113326.4EF60AA4@cs.umass.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > IMHO having a very permissive wildcarded entry at the end of the SPD can be > slightly risky, from a s/w engineering perspective. And as was pointed out in one of the "trust" sessions at the Chicago IETF, such non-monotonic specifications ("everybody except Joe gets to change the file") are also relatively difficult to formally reason about, because adding a credential can reduce permissions. They are, unfortunately, also very useful. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Tue Sep 29 20:09:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA23845 for ipsec-outgoing; Tue, 29 Sep 1998 20:07:57 -0400 (EDT) Message-Id: <199809300024.RAA03721@chip.cisco.com> To: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) cc: "Scott G. Kelly" , "Michael C. Richardson" , ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Thu, 24 Sep 1998 12:48:01 EDT." <3.0.32.19980924124752.0096b690@bl-mail1.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3719.907115078.1@cisco.com> Date: Tue, 29 Sep 1998 17:24:38 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk This may be an issue but is it a problem? Do your customers actually want to do this? (As opposed to just wanting to raise it "as an issue"). By doing IPSec on such a network aggregation point you're saying that all those hundred+ networks share the same policy and are not mutually suspicious. This seems unrealistic to me. Does this aggregations point's IPSec peer also have a hundred+ disjoint, non-combinable networks behind it? Can you explain what it is these people are trying to do? Dan. On Thu, 24 Sep 1998 12:48:01 EDT you wrote > > If they needed it yesterday tell them to establish 2 SAs, one soley > >for X and the other soley for Y. It would be *nice* to be able to have a > >single one but I think this clearly falls in the "if it ain't broke..." > >category. It can be easily solved today (and yesterday too) using existing > >mechanisms. > > What if, instead of there being only two subnets behind a security > gateway, there were a hundred or more? All disjoint, non-combinable, > etc. It becomes a serious resource utilization issue, not to mention > that negotiating all those Quick Modes takes time (especially when > you're doing PFS), and it seems a waste when you're applying the same > security policy to all of them. > > And yes, I've had customers (plural) that have cited this as an issue. From owner-ipsec Wed Sep 30 00:40:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id AAA24436 for ipsec-outgoing; Wed, 30 Sep 1998 00:37:59 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81369@RED-MSG-50> From: Richard Draves To: "'Lewis McCarthy'" Cc: IPsec WG List Subject: RE: inbound policy verification Date: Tue, 29 Sep 1998 21:55:16 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Your policy entry for N2 needs to be narrowed to achieve the > exclusion you > want. Instead of a policy entry that specifies that the > "wrong" parameters can > be used in communicating with *any* host in network N2, that > entry needs to > specify that the "wrong" parameters can be used in > communicating with hosts > X2, Y2, Z2, etc. (Recently there's been some discussion on > the list about > increasing the expressiveness of the ID syntax to make it > simpler to specify > policies covering nontrivial combinations of hosts, subnets, etc.) So let me state my current understanding: The outbound SPD is ordered and it must be searched in order for the first policy whose selectors match the outbound packet. The inbound SPD is effectively not ordered and it is searched until either a policy is found to accept the incoming packet or until all policies have been checked. So there's an asymmetry here in the semantics, and a real difference in the expressiveness of the outbound and inbound SPDs. In the outbound SPD, an administrator can put a more-specific policy ahead of a more-general policy and have the more-specific policy enforced. But in the inbound SPD, the combination of a more-specific policy and a more-general policy will not be enforced. Lewis, I don't understand one aspect of your proposed work-around for my example. If the administrator creates separate policies in the inbound SPD for each of the hosts X2, Y2, Z2, etc in network N2, then won't this mean that each of the hosts will need a different SA to send packets to H1? Whereas in my example, all the hosts in N2 (except H2) could share an SA. (Using "take-from-policy" for the source address selector with value N2 in the second policy in the inbound SPD.) Thanks, Rich From owner-ipsec Wed Sep 30 02:50:14 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA24882 for ipsec-outgoing; Wed, 30 Sep 1998 02:48:01 -0400 (EDT) Message-Id: <199809300705.LAA00445@relay2.elvis.ru> Comments: Authenticated sender is From: "Valery Smyslov" Organization: Elvis+ To: lmccarth@cs.umass.edu, ipsec@tis.com Date: Wed, 30 Sep 1998 11:05:05 +3 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: inbound policy verification In-reply-to: <36113326.4EF60AA4@cs.umass.edu> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk On 29 Sep 98 at 15:21, Lewis McCarthy wrote: Hi Lewis, > > So, if I have policy with some SPD entries that demand secure > > communication with some number of specific hosts/networks and with > > last entry, that allows insecure communication with the rest of the > > internet, does this mean, that such policy will allow *any* host, > > including those specific, to communicate with me insecurely? > > If the matching entry specifying strong security parameters for particular > hosts/nets precedes the wildcard bypass-IPsec entry, then the SPD lookup > settles on that matching entry (strong security with specific hosts). Yes this is true for outgoing packets processing, but for incoming packets processing, security architecture draft says (section 5.2.1), that we must verify that the applied SA's match the "kind and order of SAs required by the policy found" (this check failed in my example) and if it "failed continue searching SPD until all policy entries have been checked or until the check succeeds" (in my example this check succeeds with the last entry, that permits insecure communication). > In Rich's example the incoming packet's selector did not match the selector for > the host-specific SPD entry. So the lookup dropped through to the later entry > (for a whole network) in the SPD. As far as I understand Rich's example, they match. He described SPD with two entries - host specific and network specific (the network includes the host) with different security requirements for each and the situation, when incoming packet from that host is encrypted/authenticated according to network specific policy, not to host specific. As far as I understand, this packet matches both entries and even if host specific entry precedes network specific, the latter will be selected instead of discarding that packet (if we follow architecture draft). That was his problem in my understanding. Maybe I missed something and Richard himself will clarify what he mean? > IMHO having a very permissive wildcarded entry at the end of the SPD can be > slightly risky, from a s/w engineering perspective. A small error in a > host/net-specific entry might cause that specific entry not to match in some > situation when it should have. So instead the wildcarded bypass entry matches, > and traffic on that connection transparently bypasses IPsec processing. > (Packets are sent in the clear and no alarm bells ring....) > If there had been no wildcarded bypass entry at the end of the SPD, then the > connection would have failed and (presumably) someone would notice the > communication failure relatively quickly. I agree, but it is very useful (not to say inescapable), until most of the Internet becomes secure. [...] > You need to keep looking until you find one that matches (or you run out of > entries to examine). More than one entry might have a selector that matches > the packet -- the first matching entry (if any) in the SPD is used. Yes, but its again true for outgoing packets. For incoming packets architecture draft explicitly states (5.2.1): NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. >From my own point of view, the problem resides in this note. As far as I understand security architecture, every SPD entry points to zero or more SA bundles, associated with it (let's call it list of bundles). Every outgoing packet, that match this SPD entry will be processed by one of this bundle or a new one will be created and added to this list. The decision what bundle to use (or to create a new one) is made upon comparing packet with bundle selectors. For incoming packets we apply all IPsec processing, collecting SA's used, and then check whether we did it right. From my point of view, we must find first matching entry in SPD (as with outgoing packet) and check if applied SA's match one of bundle in this entry's list of bundles. If we find matching bundle, it's OK, if not - packet must be discarded. If that note mean this behaviour, it is slightly misleading, because it requires to look for another matching entry in SPD, not for another matching bundle in this entry's list. Please, correct me if I missed something. > -Lewis Regards, Valery Smyslov. From owner-ipsec Wed Sep 30 09:49:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA26470 for ipsec-outgoing; Wed, 30 Sep 1998 09:45:09 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF404ECA@exchange.timestep.com> From: Roy Pereira To: Daniel Harkins , Shawn_Mamros@BayNetworks.COM Cc: "Scott G. Kelly" , "Michael C. Richardson" , ipsec@tis.com Subject: RE: multiple payloads via "ID_LIST" Date: Wed, 30 Sep 1998 10:04:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDEC7B.392DBE80" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDEC7B.392DBE80 Content-Type: text/plain; charset="iso-8859-1" Sorry Dan, but I have to agree with Shawn on this one. Policy isn't based on just the IKE ID types. Policy is usually based on groups of such objects so it make sense to set up one SA on that logical policy group on not is individual pieces. I don't think this is a major problem, but it would 'be nice to have' the ability to set up one SA instead of multiple for the exact same policy. Instead of waiting for 'x' * 'y' seconds to establish 'y' SAs, the user would only have to wait 'x' seconds. The key is that the exact same policy is being used, so the subsequent QuickModes are superfluous because they are negotiating the exact same policy. If policy is based on logical objects that may contain other objects, then it makes sense for the IKE negotiation to emulate this. > -----Original Message----- > From: Daniel Harkins [mailto:dharkins@cisco.com] > Sent: Tuesday, September 29, 1998 8:25 PM > To: Shawn_Mamros@BayNetworks.COM > Cc: Scott G. Kelly; Michael C. Richardson; ipsec@tis.com > Subject: Re: multiple payloads via "ID_LIST" > > > This may be an issue but is it a problem? Do your customers actually > want to do this? (As opposed to just wanting to raise it "as > an issue"). By > doing IPSec on such a network aggregation point you're saying > that all those > hundred+ networks share the same policy and are not mutually > suspicious. > This seems unrealistic to me. Does this aggregations point's > IPSec peer also > have a hundred+ disjoint, non-combinable networks behind it? > > Can you explain what it is these people are trying to do? > > Dan. > > On Thu, 24 Sep 1998 12:48:01 EDT you wrote > > > If they needed it yesterday tell them to establish 2 > SAs, one soley > > >for X and the other soley for Y. It would be *nice* to be > able to have a > > >single one but I think this clearly falls in the "if it > ain't broke..." > > >category. It can be easily solved today (and yesterday > too) using existing > > >mechanisms. > > > > What if, instead of there being only two subnets behind a security > > gateway, there were a hundred or more? All disjoint, > non-combinable, > > etc. It becomes a serious resource utilization issue, not > to mention > > that negotiating all those Quick Modes takes time (especially when > > you're doing PFS), and it seems a waste when you're > applying the same > > security policy to all of them. > > > > And yes, I've had customers (plural) that have cited this > as an issue. > ------_=_NextPart_001_01BDEC7B.392DBE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: multiple payloads via "ID_LIST"

Sorry Dan, but I have to agree with Shawn on this = one.  Policy isn't based on just the IKE ID types.  Policy is = usually based on groups of such objects so it make sense to set up one = SA on that logical policy group on not is individual pieces.  =

I don't think this is a major problem, but it would = 'be nice to have' the ability to set up one SA instead of multiple for = the exact same policy.  Instead of waiting for 'x' * 'y' seconds = to establish 'y' SAs, the user would only have to wait 'x' = seconds.  The key is that the exact same policy is being used, so = the subsequent QuickModes are superfluous because they are negotiating = the exact same policy.  If policy is based on logical objects that = may contain other objects, then it makes sense for the IKE negotiation = to emulate this.

> -----Original Message-----
> From: Daniel Harkins [mailto:dharkins@cisco.com]=
> Sent: Tuesday, September 29, 1998 8:25 = PM
> To: Shawn_Mamros@BayNetworks.COM
> Cc: Scott G. Kelly; Michael C. Richardson; = ipsec@tis.com
> Subject: Re: multiple payloads via = "ID_LIST"
>
>
>   This may be an issue but is it a = problem? Do your customers actually
> want to do this? (As opposed to just wanting to = raise it "as
> an issue"). By
> doing IPSec on such a network aggregation point = you're saying
> that all those
> hundred+ networks share the same policy and are = not mutually
> suspicious.
> This seems unrealistic to me. Does this = aggregations point's
> IPSec peer also
> have a hundred+ disjoint, non-combinable = networks behind it?
>
>   Can you explain what it is these = people are trying to do?
>
>   Dan.
>
> On Thu, 24 Sep 1998 12:48:01 EDT you = wrote
> > >  If they needed it yesterday = tell them to establish 2
> SAs, one soley
> > >for X and the other soley for Y. It = would be *nice* to be
> able to have a
> > >single one but I think this clearly = falls in the "if it
> ain't broke..."
> > >category. It can be easily solved = today (and yesterday
> too) using existing
> > >mechanisms.
> >
> > What if, instead of there being only two = subnets behind a security
> > gateway, there were a hundred or = more?  All disjoint,
> non-combinable,
> > etc.  It becomes a serious resource = utilization issue, not
> to mention
> > that negotiating all those Quick Modes = takes time (especially when
> > you're doing PFS), and it seems a waste = when you're
> applying the same
> > security policy to all of them.
> >
> > And yes, I've had customers (plural) that = have cited this
> as an issue.
>

------_=_NextPart_001_01BDEC7B.392DBE80-- From owner-ipsec Wed Sep 30 10:36:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA26665 for ipsec-outgoing; Wed, 30 Sep 1998 10:31:09 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199809301449.HAA16064@kc.livingston.com> Subject: Re: inbound policy verification To: richdr@microsoft.com (Richard Draves) Date: Wed, 30 Sep 1998 07:49:47 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81334@RED-MSG-50> from "Richard Draves" at Sep 28, 98 04:14:10 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > [I just joined the ipsec list. I've skimmed the minutes from the August IETF > and the last month's archives. I'm reading the July '98 security > architecture draft. I understand this draft was just approved by the IESG. > I'm working on an implementation: http://research.microsoft.com/msripv6. My > questions stem from a recent group discussion with Aaron Griggs, Maryann > Maher, Allison Mankin, and Brian Zill.] > > > I don't understand an aspect of the inbound processing specified in section > 5.2.1 of the security architecture spec. As specified, the processing would > seem to create a security problem. > > As I understand it, the basic idea is that a) the headers are processed and > list of SAs used are collected, then b) the selectors from the packet are > used to locate a security policy in the inbound SPD/SAD, then c) check that > the SAs that were used match the SAs that are specified by the policy. > > The part I don't understand is the provision that if the SAs don't match, > then the implementation should continue searching the inbound SPD until it > either finds a policy that accepts the packet, or it's checked all the > policies in the inbound SPD. > > This would seem to make it impossible to enforce a more-restrictive policy > in the inbound SPD when there is also a more general policy. Where do you find this provision? It does seem inconsistent if true. I looked up section 5.2.1. Step 2, which refers to inbound policy enforcement. In particular, the following statement seems to contradict the provision you refer to. In general, a packet's source address MUST match the SA selector value. In the above statement, the author assumes the packet is subject to successful authorization and decryption per receiving SA terms, prior to policy verification. Also, the packet above refers to the inner packet, if the received packet is tunnelled. > > For example, suppose I'm a host H1 and I expect to receive packets from a > network N2, but there's a particular host H2 in N2 for which I have > different security requirements. So I create two policies in my inbound SPD > - first one with source address selector H2, and the second one with source > address selector N2 (an address prefix or range). The first policy results > in a SAD entry with security association SA1, and the second results in a > SAD entry with security association SA2. > > Now suppose I receive a packet from H2 with the "wrong" security headers. I > process the packet and discover SA2 from the destination > address/SPI/protocol triple and do the required authentication/decryption. > Now I search the SPD. The packet's selectors match the first policy but the > wrong SA was used to receive the packet. I want to reject this packet. > Unfortunately, I believe, what you describe is a real possibility, unless there is a strict enforcement of policy ordering/priority during IKE negotiation. The example you describe should be a good reference to use in IPsecond as we pursue policy enforcement. For brevity, let us assume SA1 and SA2 you describe are bi-directional. I believe, the following policy ordering on H1 and H2 could cause the above mishap to happen on a regular basis with the current approach. Policy ordering on H1: --------------------- 1. Permit all IP traffic from H1 to H2 using SA1 2. Permit all IP traffic from H1 to N2 using SA2 Policy ordering on H2: --------------------- 1. Permit all IP traffic from N2 to H1 using SA2 2. Permit all IP traffic from H2 to H1 using SA1 H1 would use SA1 to send packes to H2, whereas H2 would use SA2 to packets to H1. > However this provision says I should continue searching the inbound SPD. I > find the second policy; the packet's selectors match it also. SA2 is the > right SA for this policy, so I accept the packet. > > Surely this can't be right? What am I missing? > It does seem inconsistent if true. > Thanks, > Rich > cheers, suresh From owner-ipsec Wed Sep 30 11:18:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA26837 for ipsec-outgoing; Wed, 30 Sep 1998 11:17:12 -0400 (EDT) Message-ID: From: "Linn, John" To: "'ipsec@tis.com'" Subject: draft-ietf-ipsec-pki-req-01: critical Extended Key Usage? Date: Wed, 30 Sep 1998 11:36:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I noticed the following statement in Section 3.3 (Validation) of pki-req-01: "3. ExtendedKeyUsage SHOULD be checked to ensure the certificate is valid for the system in question, including the criticality fields. This extension MUST be treated as critical." Later, in Sec. 3.4.3 (IPsec validity checking), it's stated that: "4. if extendedKeyUsage is present it must contain either iKEIntermediate or iKEEnd. If additional EKU object identifiers are present then their use is a locally defined matter." As a goal, I'd like to avoid declaring a need to proliferate large numbers of per-protocol certificates for a single principal unless there's a compelling need to do so. It seems natural that a user might obtain a certificate initially for use with one protocol (which might or might not be IPsec) and then want to use it with additional protocols without re-registering (assuming that this is consistent with CA-specified policy), and ability to satisfy this goal depends on the profiles involved. The flexibility in 3.4.3 seems like a reasonable compromise: IPsec components can use a certificate with no EKU, but if the CA inserts an EKU, that EKU must list an IPsec OID as one of the intended usages. I'm not sure how to interpret the text in 3.3, and would recommend removing or clarifying the references to criticality. In particular, I believe that IPsec components should be willing to accept certificates with non-critical ExtendedKeyUsage extensions. If this weren't the case (i.e., if only critical EKU extensions were acceptable), this would unnecessarily restrict the PKIX profile (which permits either critical or non-critical EKUs). --jl From owner-ipsec Wed Sep 30 11:28:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA26898 for ipsec-outgoing; Wed, 30 Sep 1998 11:28:16 -0400 (EDT) Message-Id: <3.0.32.19980930113016.00992680@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 30 Sep 1998 11:30:17 -0400 To: Daniel Harkins From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: multiple payloads via "ID_LIST" Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk > This may be an issue but is it a problem? Do your customers actually >want to do this? (As opposed to just wanting to raise it "as an issue"). By >doing IPSec on such a network aggregation point you're saying that all those >hundred+ networks share the same policy and are not mutually suspicious. >This seems unrealistic to me. Does this aggregations point's IPSec peer also >have a hundred+ disjoint, non-combinable networks behind it? > > Can you explain what it is these people are trying to do? Loosely speaking, the scenario is a large company with lots of branch offices located throughout the country (or world), and one (or more) large central offices. They want to run their private network (and private data) over the public "capital-I" Internet, rather than spending lots of money for leased lines. Their IP network has grown by bits and pieces over time, such that they don't have one nice, neat, organized IP address space, but rather lots of little address spaces, possibly obtained from a wide variety of geographically-dispersed ISPs. Renumbering is not an acceptable solution. For better or worse, they want to do it with a star configuration, with tunnels from the branch offices all going to the central office, and with branch-to-branch communications all going through the CO rather than directly to one another. This isn't necessarily the way I'd configure things if I were the one doing the network planning, but I'm not. They have their reasons for wanting to go with the star - perhaps to ease network monitoring, perhaps to enforce additional controls on the allowable traffic. Whatever. It's their network, so I'm not going to dictate their policy; if I tried, they'd find another vendor who will provide them what they want. Because it's all the same company, they're not going to be mutually suspicious of one another (again, for better or worse), and they want just one policy as far as encryption strength, rekey parameters, etc. goes. This shouldn't be an unfamiliar situation; the only difference perhaps is the scale. Again, as Roy said, we may see it as a "nice to have", but in the eyes of some of these customers, it's a "must have". In their eyes, there are definite issues with scaling otherwise. I'd much rather go with a standard solution so that we can all interoperate, but I'll do what I have to do... -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Wed Sep 30 11:48:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA27003 for ipsec-outgoing; Wed, 30 Sep 1998 11:48:14 -0400 (EDT) Message-Id: <199809301552.IAA21393@chip.cisco.com> To: Roy Pereira cc: Shawn_Mamros@BayNetworks.COM, "Scott G. Kelly" , "Michael C. Richardson" , ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Wed, 30 Sep 1998 10:04:20 EDT." <319A1C5F94C8D11192DE00805FBBADDF404ECA@exchange.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21391.907170736.1@cisco.com> Date: Wed, 30 Sep 1998 08:52:17 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, I'm not talking about what policy is, I'm saying why would one want to do IPSec at such a network aggregation point? How many disjoint, non- combinable networks does TimeStep have? 2? 5? Probably less than 10. If you go a few hops away from TimeStep into your service provider cloud there'll probably be a network aggregation point at which there are a hundred. But I don't think you want to do IPSec there. Most customers are suspicious of the other people who are also routed to through that aggregation point. Maybe some ISP would try to sell IPSec as a service in this fasion, but I don't see any businesses purchasing that service. It seems to me that you want to do IPSec as close as possible to you and do it on a box that you manage. You want to do it on your gateway(s) or do it end-to-end. And then the number of disjoint, non-combinable networks is manageable, it's 2 or 5 or zero and you can just establish individual SAs to handle them. Assuming TimeStep does have hundreds of disjoint, non-combinable networks that a single (TimeStep owned and managed) gateway can route to this also seems like an inflexible, unextensible, management nightmare. There's a one-size-fits-all policy for every single resource on those hundreds of networks. Yeech. You're right that it would be nice to have the capability to express a list of networks, and then manage a single SA pair instead of 2 pairs or 5 pairs or whatever. But I don't see this as one of the "needed it yesterday" problems (as was mentioned earlier in this thread). I think it fits more into the "if it ain't broke" catagory since there is a way to solve this problem. It's a tad annoying but it's not that bad. I think this can wait. Dan. On Wed, 30 Sep 1998 10:04:20 EDT you wrote > > Sorry Dan, but I have to agree with Shawn on this one. Policy isn't based > on just the IKE ID types. Policy is usually based on groups of such objects > so it make sense to set up one SA on that logical policy group on not is > individual pieces. > > I don't think this is a major problem, but it would 'be nice to have' the > ability to set up one SA instead of multiple for the exact same policy. > Instead of waiting for 'x' * 'y' seconds to establish 'y' SAs, the user > would only have to wait 'x' seconds. The key is that the exact same policy > is being used, so the subsequent QuickModes are superfluous because they are > negotiating the exact same policy. If policy is based on logical objects > that may contain other objects, then it makes sense for the IKE negotiation > to emulate this. > > > -----Original Message----- > > From: Daniel Harkins [mailto:dharkins@cisco.com] > > Sent: Tuesday, September 29, 1998 8:25 PM > > To: Shawn_Mamros@BayNetworks.COM > > Cc: Scott G. Kelly; Michael C. Richardson; ipsec@tis.com > > Subject: Re: multiple payloads via "ID_LIST" > > > > > > This may be an issue but is it a problem? Do your customers actually > > want to do this? (As opposed to just wanting to raise it "as > > an issue"). By > > doing IPSec on such a network aggregation point you're saying > > that all those > > hundred+ networks share the same policy and are not mutually > > suspicious. > > This seems unrealistic to me. Does this aggregations point's > > IPSec peer also > > have a hundred+ disjoint, non-combinable networks behind it? > > > > Can you explain what it is these people are trying to do? > > > > Dan. > > > > On Thu, 24 Sep 1998 12:48:01 EDT you wrote > > > > If they needed it yesterday tell them to establish 2 > > SAs, one soley > > > >for X and the other soley for Y. It would be *nice* to be > > able to have a > > > >single one but I think this clearly falls in the "if it > > ain't broke..." > > > >category. It can be easily solved today (and yesterday > > too) using existing > > > >mechanisms. > > > > > > What if, instead of there being only two subnets behind a security > > > gateway, there were a hundred or more? All disjoint, > > non-combinable, > > > etc. It becomes a serious resource utilization issue, not > > to mention > > > that negotiating all those Quick Modes takes time (especially when > > > you're doing PFS), and it seems a waste when you're > > applying the same > > > security policy to all of them. > > > > > > And yes, I've had customers (plural) that have cited this > > as an issue. > > > > ------_=_NextPart_001_01BDEC7B.392DBE80 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Diso-8859-1"> > 5.5.2232.0"> > RE: multiple payloads via "ID_LIST" > > > >

Sorry Dan, but I have to agree with Shawn on this = > one.  Policy isn't based on just the IKE ID types.  Policy is = > usually based on groups of such objects so it make sense to set up one = > SA on that logical policy group on not is individual pieces.  = >

> >

I don't think this is a major problem, but it would = > 'be nice to have' the ability to set up one SA instead of multiple for = > the exact same policy.  Instead of waiting for 'x' * 'y' seconds = > to establish 'y' SAs, the user would only have to wait 'x' = > seconds.  The key is that the exact same policy is being used, so = > the subsequent QuickModes are superfluous because they are negotiating = > the exact same policy.  If policy is based on logical objects that = > may contain other objects, then it makes sense for the IKE negotiation = > to emulate this.

> >

> -----Original Message----- >
> From: Daniel Harkins [ HREF=3D"mailto:dharkins@cisco.com">mailto:dharkins@cisco.com]= > >
> Sent: Tuesday, September 29, 1998 8:25 = > PM >
> To: Shawn_Mamros@BayNetworks.COM >
> Cc: Scott G. Kelly; Michael C. Richardson; = > ipsec@tis.com >
> Subject: Re: multiple payloads via = > "ID_LIST" >
> >
> >
>   This may be an issue but is it a = > problem? Do your customers actually >
> want to do this? (As opposed to just wanting to = > raise it "as >
> an issue"). By >
> doing IPSec on such a network aggregation point = > you're saying >
> that all those >
> hundred+ networks share the same policy and are = > not mutually >
> suspicious. >
> This seems unrealistic to me. Does this = > aggregations point's >
> IPSec peer also >
> have a hundred+ disjoint, non-combinable = > networks behind it? >
> >
>   Can you explain what it is these = > people are trying to do? >
> >
>   Dan. >
> >
> On Thu, 24 Sep 1998 12:48:01 EDT you = > wrote >
> > >  If they needed it yesterday = > tell them to establish 2 >
> SAs, one soley >
> > >for X and the other soley for Y. It = > would be *nice* to be >
> able to have a >
> > >single one but I think this clearly = > falls in the "if it >
> ain't broke..." >
> > >category. It can be easily solved = > today (and yesterday >
> too) using existing >
> > >mechanisms. >
> > >
> > What if, instead of there being only two = > subnets behind a security >
> > gateway, there were a hundred or = > more?  All disjoint, >
> non-combinable, >
> > etc.  It becomes a serious resource = > utilization issue, not >
> to mention >
> > that negotiating all those Quick Modes = > takes time (especially when >
> > you're doing PFS), and it seems a waste = > when you're >
> applying the same >
> > security policy to all of them. >
> > >
> > And yes, I've had customers (plural) that = > have cited this >
> as an issue. >
> >

> > > > ------_=_NextPart_001_01BDEC7B.392DBE80-- From owner-ipsec Wed Sep 30 11:57:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA27045 for ipsec-outgoing; Wed, 30 Sep 1998 11:56:19 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF42DE15@exchange.timestep.com> From: Roy Pereira To: Daniel Harkins Cc: Shawn_Mamros@BayNetworks.COM, "Scott G. Kelly" , "Michael C. Richardson" , ipsec@tis.com Subject: RE: multiple payloads via "ID_LIST" Date: Wed, 30 Sep 1998 12:15:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDEC8D.96E0C880" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDEC8D.96E0C880 Content-Type: text/plain; charset="iso-8859-1" > You're right that it would be nice to have the capability to express > a list of networks, and then manage a single SA pair instead > of 2 pairs or > 5 pairs or whatever. But I don't see this as one of the > "needed it yesterday" > problems (as was mentioned earlier in this thread). I think > it fits more into > the "if it ain't broke" catagory since there is a way to > solve this problem. > It's a tad annoying but it's not that bad. I think this can wait. I agree with your above statement. It would be nice to have for IPSecond though and I think it is a small thing that makes this technology more usable to users. ------_=_NextPart_001_01BDEC8D.96E0C880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: multiple payloads via "ID_LIST"

>   You're right that it would be nice = to have the capability to express
> a list of networks, and then manage a single SA = pair instead
> of 2 pairs or
> 5 pairs or whatever. But I don't see this as = one of the
> "needed it yesterday"
> problems (as was mentioned earlier in this = thread). I think
> it fits more into
> the "if it ain't broke" catagory = since there is a way to
> solve this problem.
> It's a tad annoying but it's not that bad. I = think this can wait.

I agree with your above statement.  It would be = nice to have for IPSecond though and I think it is a small thing that = makes this technology more usable to users.

------_=_NextPart_001_01BDEC8D.96E0C880-- From owner-ipsec Wed Sep 30 12:43:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA27285 for ipsec-outgoing; Wed, 30 Sep 1998 12:42:22 -0400 (EDT) Message-Id: <199809301649.MAA15906@istari.sandelman.ottawa.on.ca> From: mcr@solidum.com To: ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" In-reply-to: Your message of "Wed, 30 Sep 1998 10:04:20 EDT." <319A1C5F94C8D11192DE00805FBBADDF404ECA@exchange.timestep.com> Date: Wed, 30 Sep 1998 12:49:20 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Roy" == Roy Pereira writes: Roy> I don't think this is a major problem, but it would 'be nice to Roy> have' the ability to set up one SA instead of multiple for the exact Roy> same policy. Instead of waiting for 'x' * 'y' seconds to establish Roy> 'y' SAs, the user would only have to wait 'x' seconds. The key is Roy> that the exact same policy is being used, so the subsequent Roy> QuickModes are superfluous because they are negotiating the exact As such, we should define this. However, we should realize that this isn't important enough to justify rev'ing IKE for it. We have extension mechanisms to deal with this. So, let's agree that it is desireable, and try and figure out how to create a new IKE payload that can be used for this kind of thing. I think that the following requirements may outline the problem: 1. filter on source address+mask 2. filter on destination address+mask 3. filter on protocol field/next-header 4. filter on TCP port number, > = < 5. filter on UDP port number, > = < 6. filter on ICMP type and code 7. filter on AH SPI# 8. filter on ESP SPI# 9. filter on IPComp CPI# 10. take the complement of 1-9 11. take the intersection of 1-10 12. take the union of 1-11 things that might be missing: - IP options/extension headers, presence/absense of any, or presence of a specific one - Now, some of these may in fact be missing from the [Arch] document. I know that ICMP is, as is ranges on port numbers, and also the SPI/CPI stuff. One way to form a more general solution is to go for a more generic solution and use some kind of statement like "byte offset 4 > 5", but that gets messy, and if you want to go that route, you might as well use a full Packet Description Language. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNhJhDtiXVu0RiA21AQHSjQL/Xkfy7KnlX47AmW0v/60WMOJfUbUZ12dL te50gBMh5mY68Vke6DNX6hQ00uPaCZbz8VZervXT2zdzChQBh+99yhoIcLOGquC1 ejCc0f7IuxtyLIqqc+lId04lQqucka9i =maIi -----END PGP SIGNATURE----- From owner-ipsec Wed Sep 30 13:38:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA27495 for ipsec-outgoing; Wed, 30 Sep 1998 13:38:23 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8136D@RED-MSG-50> From: Richard Draves To: "'Valery Smyslov'" Cc: lmccarth@cs.umass.edu, ipsec@tis.com Subject: RE: inbound policy verification Date: Wed, 30 Sep 1998 10:55:44 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk Valery, I think you understand perfectly my example & issue with the "NOTE" in section 5.2.1. Thanks, Rich From owner-ipsec Wed Sep 30 14:20:59 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA27737 for ipsec-outgoing; Wed, 30 Sep 1998 14:19:23 -0400 (EDT) Message-Id: <199809301733.NAA23909@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 30 Sep 1998 14:34:01 -0400 To: "Linn, John" From: Rodney Thayer Subject: Re: draft-ietf-ipsec-pki-req-01: critical Extended Key Usage? Cc: ipsec@tis.com, rodney@tillerman.nu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The two sections were meant to be consistent, I'll pull the criticiality reference. I hear a variety of opinions about multi-usage certificates. The CA people seem to dislike it, the IPSec implementors seem to think it's theologically acceptable but unnecessarily complex, and users seem to sometimes actually want it. I meant to make the document allow this possibility, because I don't see an IPSec reason to preclude it. At 11:36 AM 9/30/98 -0400, you wrote: >I noticed the following statement in Section 3.3 (Validation) of pki-req-01: > >"3. ExtendedKeyUsage SHOULD be checked to ensure the certificate is valid >for the system in question, including the criticality fields. This >extension MUST be treated as critical." > >Later, in Sec. 3.4.3 (IPsec validity checking), it's stated that: > >"4. if extendedKeyUsage is present it must contain either iKEIntermediate or >iKEEnd. If additional EKU object identifiers are present then their use is >a locally defined matter." > >As a goal, I'd like to avoid declaring a need to proliferate large numbers >of per-protocol certificates for a single principal unless there's a >compelling need to do so. It seems natural that a user might obtain a >certificate initially for use with one protocol (which might or might not be >IPsec) and then want to use it with additional protocols without >re-registering (assuming that this is consistent with CA-specified policy), >and ability to satisfy this goal depends on the profiles involved. > >The flexibility in 3.4.3 seems like a reasonable compromise: IPsec >components can use a certificate with no EKU, but if the CA inserts an EKU, >that EKU must list an IPsec OID as one of the intended usages. I'm not sure >how to interpret the text in 3.3, and would recommend removing or clarifying >the references to criticality. In particular, I believe that IPsec >components should be willing to accept certificates with non-critical >ExtendedKeyUsage extensions. If this weren't the case (i.e., if only >critical EKU extensions were acceptable), this would unnecessarily restrict >the PKIX profile (which permits either critical or non-critical EKUs). > >--jl > From owner-ipsec Wed Sep 30 15:04:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA27991 for ipsec-outgoing; Wed, 30 Sep 1998 15:04:23 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF42DF12@exchange.timestep.com> From: Tim Jenkins To: ipsec@icsa.net, "'ipsec@tis.com'" Subject: Re-keying Issues Document Date: Wed, 30 Sep 1998 15:13:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BDECA6.5C0DCED0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BDECA6.5C0DCED0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDECA6.5C0DCED0" ------_=_NextPart_001_01BDECA6.5C0DCED0 Content-Type: text/plain; charset="iso-8859-1" Greetings, This is an informational document that describes issues associated with re-keying and makes recommendations to solve those issues, both within the context of the existing IPSec documents, and for IPSecond. Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 ------_=_NextPart_001_01BDECA6.5C0DCED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-keying Issues Document

Greetings,

This is an informational document that describes = issues associated with re-keying and makes recommendations to solve = those issues, both within the context of the existing IPSec documents, = and for IPSecond.

Tim



---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617

  ------_=_NextPart_001_01BDECA6.5C0DCED0-- ------_=_NextPart_000_01BDECA6.5C0DCED0 Content-Type: text/plain; name="draft-jenkins-ipsec-rekeying-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-jenkins-ipsec-rekeying-00.txt" Content-Location: ATT-0-10130A306F58D211932B00104B6AA8D8-D RAFT-%7E1.TXT Internet Engineering Task Force Tim Jenkins IP Security Working Group TimeStep Corporation Internet Draft September 28, 1998 IPSec Re-keying Issues Status of this Memo Informational This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) Tim Jenkins (1998). All Rights Reserved. IPSec Working Group [Page 1] =0C Internet Draft IPSec Re-keying Issues September 1998 Table of Contents 1. Introduction...................................................3 2. Phase 2 SA Re-keying...........................................3 2.1 Phase 2 Re-keying Issues......................................3 2.1.1 Inconsistent SA Use Recommendation..........................4 2.1.2 Observed Behaviours.........................................5 2.1.3 SA Set-up Race Condition....................................5 2.1.4 Commit Bit Interaction......................................7 2.2 Solution Examination..........................................7 2.2.1 Responder Pre-Set Up........................................7 2.2.1.1 Normal Conditions.........................................8 2.2.1.2 Dropped Packet Conditions................................10 2.2.1.3 Failed Negotiation.......................................11 2.2.1.4 Responder Pre-Set Up Security Hole.......................11 2.2.2 Recommended Re-keying Method...............................11 2.2.2.1 Dropped Quick Mode 3 Message.............................13 2.2.2.2 Absence of Traffic.......................................13 2.2.2.3 Compatibility With Observed Behaviours...................14 2.2.2.4 Compatibility with Commit Bit............................14 2.2.2.5 Implementation Notes.....................................16 2.3 Conclusions..................................................16 3. Phase 1 Re-keying.............................................16 3.1 Phase 1 Re-keying Requirements...............................16 3.1.1 Initial Contact Notification...............................18 3.1.2 Delete Notification........................................18 3.1.3 Re-keying Timing...........................................19 4. IPSecond Recommendations......................................19 4.1 Re-transmission Rules........................................20 4.1.1 Aggressive Mode Re-Transmission Rules......................20 4.1.2 Quick Mode Re-Transmission Rules...........................20 4.2 SA Delete Mode...............................................21 4.3 Phase 1 Re-keying for IPSecond...............................22 4.4 Phase 2 Re-keying for IPSecond...............................23 4.4.1 Oldest Phase 2 SA First....................................23 4.4.2 Phase 2 Re-keying Illustration.............................24 5. Acknowledgements..............................................27 6. References....................................................27 Revision History September 23, 1998 Initial Release IPSec Working Group [Page 2] =0C Internet Draft IPSec Re-keying Issues September 1998 1. Introduction For a number of reasons, re-keying in IPSec has become problematic, such that packets can get dropped by IPSec implementations during re-keying. Worse, there exists the possibility that IPSec implementations from different vendors may not be interoperable because of the way they re-key. The purpose of this paper is to propose methods of performing both phase 1 and phase 2 re-keying for IPSec implementations in such a way to to minimize packet loss and to maximize compatibility. The initial focus in on phase 2 re-keying; it is then extended to phase 1 re-keying. The need for this document in each case is initially discussed, followed by a recommendation for re-keying within the protocol framework established by version 1.0 of the IPSec documents. Finally, recommendations for IPSecond are made to best solve the re- keying problems in a manner that is not possible within the constraints of the existing IPSec documents. 2. Phase 2 SA Re-keying This section discusses phase 2 re-keying issues and makes recommendations to minimize the impact of these issues. 2.1 Phase 2 Re-keying Issues The issues associated with phase 2 re-keying listed below. Some of the points are expanded upon later. 1) There is no specification how re-keying is to be done. 2) The existing drafts appear contradictory in their recommendations on the usage of multiple phase 2 SAs. 3) Some recent implementations have shipped with a method of re- keying that will not perform reliably under real world network conditions. 4) The use of the Delete notification is not required. 5) A variety of re-keying behaviours have been observed, some of which are incompatible. IPSec Working Group [Page 3] =0C Internet Draft IPSec Re-keying Issues September 1998 6) The commit bit is not yet widely implemented, and its use as described is confusing. Further, while the documentation requires its support, its use is not required. 7) A race condition exists at SA set up, exacerbating re-keying issues. 2.1.1 Inconsistent SA Use Recommendation The issue of inconsistent SA usage recommendations is examined further here. From paragraph 2 of Section 9 of [IKE]: An implementation may wish to negotiate a range of SAs when performing Quick Mode. By doing this they can speed up the "re- keying". Quick Mode defines how KEYMAT is defined for a range of SAs. When one peer feels it is time to change SAs they simply use the next one within the stated range. A range of SAs can be established by negotiating multiple Sas (identical attributes, different SPIs) with one Quick Mode. While the document does not define what "... the next one ..." means, this paragraph strongly implies that there is no required order for the use of phase 2 SAs that have been negotiated in a phase 1 SA, or that multiple SAs may be pre-negotiated and used at will. However, this appears to be contradicted by paragraph 3 of section 4.3 of [ISAKMP]: Modification of a Protocol SA (phase 2 negotiation) follows the same procedure as creation of a Protocol SA. The creation of a new SA is protected by the existing ISAKMP SA. There is no relationship between the two Protocol SAs. A protocol implementation SHOULD begin using the newly created SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy. Many implementations have interpreted this to mean that the new SA should be used for outbound in preference to the old SA. In other words, the old SA should be abandoned as soon as possible. IPSec Working Group [Page 4] =0C Internet Draft IPSec Re-keying Issues September 1998 2.1.2 Observed Behaviours The following behaviours have been observed by various vendors' implementations when devices have set up a second phase 2 SA. 1) The device continues to use the old SA until it naturally expires, then switches to the new SA. 2) The device immediately begins using the new SA. 3) The device immediately drops the old SA. 4) The device never sends a Delete notification. 5) The device always sends a Delete notification. 6) The device deletes the old SA some time after re-keying, but before the end of its natural lifetime. 7) A device wants to keep more than one SA up all the time. All of these behaviours are permitted under the current documents. However, even when phase 2 exchange packets are not lost, it can be seen that interoperability is not always possible due the combinations of behaviours listed above. 2.1.3 SA Set-up Race Condition Further, behaviour 2 above is not a good behaviour, as illustrated below. In this example, the initiator is a gateway capable of handling full T3 bandwidth rates, while the responder is a PC running a software IPSec implementation, and it is overloaded. In the illustration, QM1 refers to the first quick mode message, QM2 to the second quick mode message and QM3 to the third. IPSec Working Group [Page 5] =0C Internet Draft IPSec Re-keying Issues September 1998 Initiator Responder QM1 sent ---- ------- ------------- ---------------> QM1 received | | | QM1 processed | | ---------------- QM2 sent ------------- ------- QM2 rec. <---- process | QM3 sent ----- * ------- packet on new SA ------------- _____ ---------------> QM3 received _______ | _____________ | QM3 processing _______________| | packet dropped | * new SA set up Figure 2-1 Race Condition Sequence Chart By the time the responder has set up the new SA, packets protected by that SA have already started arriving from the initiator. This causes them to be dropped by the responder. This case is further complicated by the possibility of packets taking different paths through the network, so theoretically, the third quick mode message could arrive after packets protected by the new SA. Additionally, since all IKE packets are based on UDP, there is no guarantee that QM3 even arrives at the peer, so making assumptions about new SA use based on the transmission time of a packet will still lead to failures in the field. To reduce the effects of packet loss, some implementations were observed to blindly transmit QM3 multiple times, back to back. This can reduce the probability that the peer does not get QM3, but cannot eliminate it. IPSec Working Group [Page 6] =0C Internet Draft IPSec Re-keying Issues September 1998 If the behaviour of the initiator was to delay usage of the new SA for outbound traffic, this would cause failures for those implementations that immediately delete the old SA. Therefore, the behaviour of delaying use of the new SA and immediately deleting the old SA are incompatible. 2.1.4 Commit Bit Interaction The use of the commit bit can solve the race condition illustrated in the previous section when asserted by the responder during quick mode. However, it suffers from the following problems: 1) Use of the commit bit is not well defined. The present documentation specifies its used for phase 1 and phase 2, but mentions phase 2 specific details. There are also issues related to how the subsequent Connected notification fits in with the quick mode exchange. 2) While its support is required, its use is not. Current indications are that its use is not widespread. 3) Its use may make implementations susceptible to a denial of service attack by forcing initiators to wait for a Connected notification that may never come. While this is only one of many very basic possible denial of service attacks on IKE, this is not an excuse to leave the existing implementation as it is. 2.2 Solution Examination This section details the operation of some possible behaviours, with the intent of arriving at a best possible phase 2 re-keying mechanism under the constraints of the existing documents. In all the examples, the term "sets up a new outbound SA" means that the new outbound SA will be chosen in favour of the old one. Whether the SA is actually created before that time or not is implementation dependent. 2.2.1 Responder Pre-Set Up As a starting point, the responder pre-set up method of re-keying is examined. Note that it will work with most of the behaviours observed in the field. IPSec Working Group [Page 7] =0C Internet Draft IPSec Re-keying Issues September 1998 In this method, SAs are treated separately as inbound and outbound, as well as old and new. Further, it takes advantage of the fact that the responder knows what the SA is going to be after the second quick mode message is sent. Implicit acknowledgement of the reception of the third quick mode message by the responder is provided by use of the new SA in the outbound direction. The initiator should not use the new outbound SA before that time. Additionally, it does not require use of the Delete notification. This is important since, even if it is always sent, it is an unacknowledged UDP packet and can be lost. 2.2.1.1 Normal Conditions The following is the operation under normal (successful) conditions. Initiator Responder Inbound Outbound Inbound Outbound | | | | 1 ----------------- | | | | ------------ | | | | -------------------> 2 | | | | | | | -------------------- 3 | | ------------ | *4 | 5 <--------------- | | | | | | | | | 6 ---------------- | | | | *7 | ------------ | | | | | | -------------------> 8 | | | | | | | | | | | | | * | | | | | | *9 | | | | | *10 | | | | | | | | *11 | | | | | | | *12 | | | | | *13 | | | | *14| | | | | | | | *15 | | | *16| | | | | | Figure 2-2 SA Pre-Set Up Sequence Chart IPSec Working Group [Page 8] =0C Internet Draft IPSec Re-keying Issues September 1998 Events 1) Initiator sends first quick mode message. 2) Responder receives first quick mode message. 3) Responder sends second quick mode message. 4) Responder sets up new inbound SA. This is to handle the case where the initiator starts transmitting on the new SA immediately after sending the third quick mode message. 5) Initiator receives second quick mode message. 6) Initiator sends third quick mode message. 7) Initiator sets up new inbound SA. 8) Responder receives third quick mode message. 9) Responder sets up new outbound SA. 10) Responder deletes old outbound SA. 11) Traffic from responder to initiator arrives at initiator on new SA. 12) Initiator sets up new outbound SA. 13) Initiator deletes old outbound SA. 14) Initiator deletes old inbound SA. 15) Traffic from initiator to responder arrives at responder on new SA. 16) Responder deletes old inbound SA. While appearing complicated, it enables the lossless transfer from one SA to another while supporting almost all other behaviours. Support for and use of the Delete notification is unchanged. IPSec Working Group [Page 9] =0C Internet Draft IPSec Re-keying Issues September 1998 2.2.1.2 Dropped Packet Conditions In this case, the event list is modified to show what happens when each packet is dropped once. The event numbers refer to those illustrated in Figure 2. 1) Initiator sends first quick mode message. e) Packet is dropped during transmission. 1b) Initiator times out waiting for second quick mode message. 1) Initiator re-sends first quick mode message. 2) Responder receives first quick mode message. 3) Responder sends second quick mode message. 4) Responder sets up new inbound SA. This is to handle the case where the initiator starts transmitting on the new SA immediately after sending the third quick mode message. e) Packet is dropped during transmission. 1b) or 7b) Responder times out waiting for third quick mode message. 1) or 3) Responder re-sends second quick mode message. 5) Initiator receives second quick mode message. 6) Initiator sends third quick mode message. 7) Initiator sets up new inbound SA. e) Packet is dropped during transmission. 7b) Responder times out waiting for third quick mode message. 3) Responder re-sends second quick mode message. 5) Initiator receives second quick mode message again. 6) Initiator re-sends third quick mode message. 8) Responder receives third quick mode message. and so on, as for normal operation. IPSec Working Group [Page 10] =0C Internet Draft IPSec Re-keying Issues September 1998 2.2.1.3 Failed Negotiation In this case, the second quick mode packet has an invalid hash, and the initiator sends the notification to the peer. Again, the event numbers refer to those illustrated in Figure 2. 1) Initiator sends first quick mode message. 2) Responder receives first quick mode message. 3) Responder sends second quick mode message. 4) Responder sets up new inbound SA. This is to handle the case where the initiator starts transmitting on the new SA immediately after sending the third quick mode message. 5) Initiator receives second quick mode message. e) Hash (or other parameter) fails. e1) Initiator sends notification to responder. e2) Responder receives notification. e3) Responder deletes new inbound SA. A similar operation would occur if retry counters expire for packet re-transmissions. 2.2.1.4 Responder Pre-Set Up Security Hole In the failed negotiation case, the need to delete the invalid inbound SA raises the issue of a temporary hole, in that the responder allows inbound packets while waiting for the third quick mode message. However, if the inbound SA is not set up ahead of time, initiators that immediately transmit on the new outbound SA will cause packets to be dropped. It also illustrates why the proposal above made the usage of the outbound SA by the initiator wait until there is an indication of the use of the SA by the responder. 2.2.2 Recommended Re-keying Method In this method, the previous method is modified to remove the risk of the security hole. It also simplifies the operation somewhat, but IPSec Working Group [Page 11] =0C Internet Draft IPSec Re-keying Issues September 1998 at the expense of lost packets if the initiator's behaviour is such that it immediately uses the new SA for its outbound traffic. Initiator Responder Inbound Outbound Inbound Outbound | | | | 1 ----------------- | | | | ------------ | | | | -------------------> 2 | | | | | | | -------------------- 3 | | ------------ | | 4 <--------------- | | | | | | | 5 ---------- | | | | *6 ------------------ | | | | | -------------------> 7 | | | | | | | | | | | * | | | | *8 | | | | | | | *9 | | | | | *10 | | | | | | | | *11 | | | | | | | *12 | | | | | *13 | | | | *14| | | | | | | | *15 | | | *16| | | | | | Figure 2-3 Recommended Phase 2 Re-key Sequence Chart 1) Initiator sends first quick mode message. 2) Responder receives first quick mode message. 3) Responder sends second quick mode message. 4) Initiator receives second quick mode message. 5) Initiator sends third quick mode message. 6) Initiator sets up new inbound SA. 7) Responder receives third quick mode message. IPSec Working Group [Page 12] =0C Internet Draft IPSec Re-keying Issues September 1998 8) Responder set up new inbound SA. 9) Responder sets up new outbound SA. 10) Responder deletes old outbound SA. 11) Traffic from responder to initiator arrives at initiator on new SA. 12) Initiator sets up new outbound SA. 13) Initiator deletes old outbound SA. 14) Initiator deletes old inbound SA. 15) Traffic from initiator to responder arrives at responder on new SA. 16) Responder deletes old inbound SA. Note that deletion of the old inbound SA by the initiator could be further delayed if protection against loss of packets on the old SA from different and slower network paths is desired. 2.2.2.1 Dropped Quick Mode 3 Message In cases where the third quick mode message is dropped, the responder must request re-transmission of it by re-sending the second quick mode message. The existence of traffic on the new inbound SA at the initiator should not be used as an implicit acknowledgement for the following reasons: 1) There may be no traffic for the responder to send. 2) The responder may be implemented to use the old SA until its natural expiration. 2.2.2.2 Absence of Traffic The proposed implementation uses the presence of traffic from the responder on new SAs to provide an implied acknowledgement for the purposes of switching to the new SA. However, if there is no traffic from the responder, the implied acknowledgement will not appear. A similar behaviour is exhibited by implementations that continue to use old SAs until their natural expiration. IPSec Working Group [Page 13] =0C Internet Draft IPSec Re-keying Issues September 1998 However, due to the number of implementations that delete old SAs 30 seconds after negotiating a new one, the same behaviour has the best chance of interoperability, and of not dropping packets when traffic does restart. Therefore, it is recommended that implementations delete old SAs and start using new SAs 30 seconds after negotiating new SAs. Use of the Delete notification is strongly recommended in cases where the peer implementation is continuing to use the old SA. 2.2.2.3 Compatibility With Observed Behaviours When operating with behaviours that use the new SA immediately, this method performs equivalently when this method is used by the responder. When used by the initiator, the performance will depend on when the responder deletes the old inbound SA. When operating with behaviours that continue to use the old SA, this method performs as described in the dropped quick mode three example above when used by the initiator. When used by the responder, there is no change in operation, since the responder will wait until the new SA is used before deleting the old SA. However, as stated in a previous section, it is recommended that the initiator keep the old SA (both inbound and outbound) for only 30 seconds after creation of the new SA in cases where traffic is not detected on the new SA. 2.2.2.4 Compatibility with Commit Bit As stated earlier, use of the commit bit as described in the drafts is confusing. For the purposes of this document, its use is interpreted to mean the following: "I have set the commit bit. Do not use the SA created by this negotiation until I send you the Connected notification." In other words, the purpose of the commit is to delay a peer's usage of its outbound SA until it has received the Connected notification. While sounding simple, this suffers from some of the same problems as the negotiation without the commit bit. When used as part of a quick mode negotiation, the effect is that the Connected notification is now similar to the third quick mode message with the IPSec Working Group [Page 14] =0C Internet Draft IPSec Re-keying Issues September 1998 roles of the initiator and responder reversed (or not reversed if set by the initiator). Specifically, the Connected notification can still be dropped. This will result in the intended receiver of the Connected notification never sending on the new SA. Also, if the intended receiver of the Connected notification does not set up the new SA until receiving the Connected notification, the same race condition exists if the sender of the notification starts using the new outbound SA immediately after sending the notification. This problem is further exacerbated by the lack of tight integration of the Connected notification with quick mode. In other words, it may not be possible to request re-transmission of the Connected notification by re-sending the third quick mode message. The impact of these effects can be eliminated by the following rules: 1) The initiator should set up its inbound SA immediately after sending the third quick mode message regardless of the state of the commit bit. 2) Traffic sense on the initiator's new inbound SA should trigger the use of the new outbound SA to detect cases when the Connected notification is dropped. The recommended proposal does not allow built-in support of the commit bit. It does allow responders that use the commit bit to detect reception of the Connected notification by the initiator due to the presence of traffic on the inbound SA. However, this works only if there is traffic, so it cannot be considered a usefull method to perform this function. The recommended proposal does cause the initiator to delay usage of a new SA until it is set up. This is the primary use of the commit bit, so use of this proposal makes the use of the commit bit unnecessary except for the setting up of the first phase 2 SA. However, other uses of the commit bit or its equivalent function may appear, such as delaying of SA use in key recovery implementations. In these cases, the re-keying method proposed here does not interfere with commit bit usage. IPSec Working Group [Page 15] =0C Internet Draft IPSec Re-keying Issues September 1998 2.2.2.5 Implementation Notes The presence of traffic on the new SA can be part of the expiration checking operation, and does not need to occur instantaneously, although it must occur before the 30 second no traffic SA deletion criteria. As long as the new SA is negotiated with enough time before the expiration of the old one, the detection of traffic on the new SA can be on the order of seconds with no ill effects. Since SAs will likely have traffic counters anyway, this method requires only the addition of a flag that indicates it is a new SA. When the expiration process checks for aging and expired SAs, it can also check for new SAs with a non-zero traffic count. When detected, the SA is marked as non-new, and the remaining operations can be performed. 2.3 Conclusions The final re-keying method is the best compromise between security and interoperability within the framework of the current IPSec documents. 3. Phase 1 Re-keying This section makes a proposal for main mode re-keying. This proposal is necessary for many of the same reasons a phase 2 re-keying proposal is necessary. 1) The rules for phase 1 re-keying are not specified in the drafts. 2) Adhoc implementations have lead to poor implementations and possible interoperability issues. The goal of the proposed phase 1 re-keying method is to provide secure, lossless communications. This means that there should be no dropped traffic during re-keying, but also that there should be no further traffic if re-keying fails. 3.1 Phase 1 Re-keying Requirements The two reasons for re-keying a phase 1 SA are for freshness (time or traffic) of the phase 1 keying material (affecting its ability to protect phase 2 negotiations) and for re-authentication of the encrypting devices. IPSec Working Group [Page 16] =0C Internet Draft IPSec Re-keying Issues September 1998 This implies that there is no inherent need to delete other SAs created by an expired phase 1 SA as long as an immediate attempt to create a new phase 1 SA is made to verify authentication. If this fails, then the SAs created within previous phase 1 SAs must be deleted. This provides the authentication protection of the original phase 1 SA. Note that this does not preclude any requirements for early termination of SAs due to certificate revocation, for example. However, the automatic re-keying of phase 1 SAs means that SAs could live independent of traffic, since re-keying of both phase 1 and phase 2 SAs takes place with no traffic triggers. In other words, SAs that are no longer necessary may never disappear. If an implementation waits until traffic starts using pre-existing phase 2 SAs before re-keying a phase 1 SA, that traffic could be allowed to pass unauthenticated for the time that it takes to negotiate. The difference between this case and the case of immediately renegotiating is that the traffic could be flowing at some arbitrary time after the phase 1 SA has expired (but before the phase 2 SA has expired) and outside the authenticated time, while in the other case, re-authentication of the SAs effectively happens at the end of their authenticated lifetime. This suggests that a traffic monitoring capability should be part of implementations that need to delete idle or unused SAs. As such, it is not given further consideration in this document, since it is beyond the scope of this document. A further implication of not deleting the phase 2 SAs is that there is no need to overlap phase 1 SAs. That is, the second phase 1 SA can be negotiated after the first phase 1 SA expires with no loss of traffic since the phase 2 SA is still in place. (There may be issues of simultaneous expiration of phase 1 and phase 2 SAs. Implementations should be able to handle this condition, although some traffic loss may be unavoidable under this condition.) Since the expiration times of the phase 1 SA at each end may not be the same, any device that gets a phase 1 negotiation should abandon the phase 1 SA that it already has with the peer, once the new SA has been authenticated. The authenticated ID information is necessary to determine if the new phase 1 SA is identical to an existing phase 1 SA. The existence of the Initial Contact notification determines whether it should delete any phase 2 SAs it has with the peer. IPSec Working Group [Page 17] =0C Internet Draft IPSec Re-keying Issues September 1998 Therefore, the rules for phase 1 re-keying are: Initial Phase 1 Negotiation: -responder deletes any pre-existing phase 1 SA with the peer when authentication of peer complete -initiator uses Initial Contact notification -responder may also use Initial Contact notification -responder deletes all phase 2 SAs with the peer Phase 1 Expiration: -Delete notification may be sent only if permanent deletion of the phase 1 SA (and all its phase 2 SAs) is intended New Phase 1 Negotiation: -responder deletes any pre-existing phase 1 SA with the peer when authentication of peer complete -no Initial Contact notification; phase 2 SAs are kept -if attempt fails, all other SAs are also deleted (no Delete notification is used, since there is no valid SA) -initiator should sent delete notification Maximum of one Phase 1 SA between peers (except during SA set-up) Note that any information that may be associated with pre-existing phase 1 SAs should be carried over into the new SA. Examples of this type of information are server addresses passed during using the Configuration Exchange mode. 3.1.1 Initial Contact Notification As stated above, the initial contact notification should be used only on the very first phase 1 that is negotiated between two peers. If used on subsequent negotiations, it means that all pre-existing SAs (phase 1 and phase 2) held between the peers should be deleted. This is the mechanism used to detect when an SA end point has crashed and is now alive again, for example. 3.1.2 Delete Notification As currently defined by the IPSec documents, this notification is an advisory only and is optional and unacknowledged. Given that it is optional, UDP based, and not used by some existing implementations, it should never be considered necessary. Further, IPSec Working Group [Page 18] =0C Internet Draft IPSec Re-keying Issues September 1998 its value is debatable, especially given that explicit SA re-keying rules are being used. Further, reception of a Delete notification for phase 1 should not be used before re-keying, since the phase 1 SA is being re-keyed, not deleted. It should be used only to indicate permanent deletion of a phase 1 SA and all phase 2 SAs created by it. Even though its use is of dubious value, it should be sent when permanent deletion of phase 1 SAs is intended, if only as a place- holder for the proposed Delete mode for IPSecond. 3.1.3 Re-keying Timing To reduce the probability of simultaneous re-keying, each device should re-key at a variable time with respect to the SA's expiration time, in case they are the same. These recommendations apply to both phase 1 and phase 2 SAs. Examples of this include: 1) Re-keying at a random percentage of the lifetime of the SA, such as 75% to 90%. 2) The end with the higher SPI re-keying at 95% of the lifetime, while the end with lower SPI re-keying at 85% of the lifetime. In any case, simultaneous attempts at re-keying should be supported in one form or another, since it can never be guaranteed that this will not happen. 4. IPSecond Recommendations The recommendations made in sections 2 and 3 of this document have limitations in their ability to provide lossless, reliable and interoperable SA re-keying due to restrictions of existing implementations and the existing IPSec documentation. This section makes recommendations for explicit re-transmission rules, phase 1 and phase 2 re-keying and introduces a new mode for reliable SA deletion in order to better provide reliable, lossless and interoperable re-keying. IPSec Working Group [Page 19] =0C Internet Draft IPSec Re-keying Issues September 1998 4.1 Re-transmission Rules In systems that use an even number of exchanges, the rules for re- transmission are relatively obvious. Simply put, a packet is re-sent if the expected response to it is not received within a certain period of time. However, IPSec has a number of modes that have an odd number of packets. This can lead to confusion as to when the re-transmission rules should be applied. This in turn can lead to the dropping of aggressive and quick modes' third messages. It is recommended that each of these modes have specific rules applied to them to avoid issues these issues. These rules will be applied based on request-response pairs. Packets are defined as a request or a response in an exchange. The requestor is responsible for re-sending the request in order to solicit the response. The responder (not to be confused with an SA negotiation responder) is responsible for re-sending the response as it receives the initial and subsequent transmissions of the request. In each of the cases of modes with an odd number of packets, the request-response pair must be applied across the odd number of packets. This means that at least one packet must be considered the response to the previous packet, and must also be considered the request of the next request-response pair. This means that an implementation must be able to perform re- transmission of packets after it normally would have considered itself to be done with an exchange or a mode. Further, any timers set by the transmission of the final message of an exchange should be reset when re-transmission occurs. 4.1.1 Aggressive Mode Re-Transmission Rules In aggressive mode, the second message is the message that is both a response and a request. Therefore, the responder in a phase 1 negotiation that uses aggressive mode must re-transmit the second aggressive mode message to solicit a third aggressive mode message that it perceives as lost. 4.1.2 Quick Mode Re-Transmission Rules In quick mode, the second message is the message that is both a response and a request. Therefore, the responder in a phase 1 IPSec Working Group [Page 20] =0C Internet Draft IPSec Re-keying Issues September 1998 negotiation must re-transmit the second quick mode message to solicit a third quick mode message that it perceives as lost. 4.2 SA Delete Mode The purpose of the SA Delete mode is to unambiguously delete SAs used as pairs. It is called a mode for syntactical consistency with quick mode, new group mode and so on. The Delete request notification's format is the same as the Delete notification, and may or may not refer to multiple SAs. It is interpreted to mean the following: "I am not sending anymore traffic on this SA pair (or these SA pairs). Would you please stop sending traffic on it (or them), and send me an Delete acknowledgement when you are done?" The receiver of the Delete request then switches his outbound traffic to another SA (the next oldest), deletes both inbound and outbound SAs and sends the Delete acknowledgement. This is interpreted to mean: "I am also not sending anymore traffic on this SA pair (or these SA pairs). You may delete it (or them)." The receiver of the Delete acknowledgement may then delete the inbound SA. The outbound SA should have already been deleted or somehow not used before the sending of the Delete request. Note that re-transmission rules apply to the request-acknowledge pair. That is, if the initiator of the Delete mode does not get the Delete acknowledgement, the Delete request should be re-transmitted. Similarly, if the responder of the Delete request receives multiple copies, multiple copies of the Delete acknowledgement should be sent. If the retry counter for the Delete request expires, the SAs indicated in the request should be unilaterally deleted. Both messages must be sent encrypted under the protection of a phase 1 SA. Note that there is a race condition for the Delete request and Delete acknowledgement notifications if an implementation sends them immediately after sending a packet on one of the SAs to be deleted. The race occurs if the packet order gets changed in the network and IPSec Working Group [Page 21] =0C Internet Draft IPSec Re-keying Issues September 1998 the notification packets arrive before packets sent on the SAs to which the notifications refer. The Delete request-acknowledgement pair should also be applied to phase 1 SAs. In this case, the phase 1 SA is not completely torn down until the reception of the Delete acknowledgement message. As a specific clarification, the binding between the inbound and the outbound SAs is not weakened. In the messages used, the SA specified in the Delete notification is that of the sender's inbound SA. In other words, the SPI sent to be deleted is the SPI that was generated by the sender. This is simply to be consistent with the format of the current Delete notification. It may be more reasonable to specify both inbound and outbound SPIs in the SA Delete mode messages. Additionally, the Delete mode is used to delete phase 1 SAs as well. In this case, the SPIs values used are the cookies of the phase 1 SA. The introduction of this mode does not eliminate the use for the existing Delete notification. It could still be used if an implementation determines it needs to immediately (and impolitely) delete an SA. Implementations must still recognise that it is sent over UDP and may be dropped. 4.3 Phase 1 Re-keying for IPSecond The phase 1 re-keying method described in Section 3 requires only one change for IPSecond. That is the required use of the new Delete mode. The Delete mode must be used in association with phase 1 when an implementation intends to permanently delete a phase 1 SA. This may happen due to adminstration shut-down, policy change, remote client session termination, re-keying failure or other reasons. When used after a phase 1 re-keying failure, it is sent by the initiator of the phase 1 negotiation. In this case, the Delete mode uses the cookies of the expired phase 1 SA, rather than the cookies of the SA negotiation that failed. It must also use the old phase 1 SA to protect the Delete mode. The reasons for this are that the responder's phase 1 may not have expired. The failure of the new phase 1 negotiation cannot be used by the responder to delete its old phase 1 SA since it is likely that authentication of the new phase 1 SA has not yet occurred. IPSec Working Group [Page 22] =0C Internet Draft IPSec Re-keying Issues September 1998 Because of this, there is a logical overlap of phase 1 SAs that implicitly ends upon successful negotiation of the new phase 1 SA. 4.4 Phase 2 Re-keying for IPSecond The phase 2 re-keying proposal described in Section 2, while necessary under the circumstances, is not the ideal method of re- keying. It forces the specific transfer times of SAs, thus making the intent of paragraph 2, section 9 of [IKE] impossible. This section describes proposals related to re-keying for the next version of the IPSec protocols. The purpose is to precisely define re-keying so that implementations are lossless and perfectly interoperable during re-keying. It also allows the spirit of paragraph 2, section 9 of [IKE] to be used. Further, it meets the requirements of paragraph 3 of section 4.3 of [ISAKMP]. A summary of the recommendations is: 1) Define and require that the normal procedure is to use the oldest phase 2 SA first, and to use it until its natural expiration. 2) Use the recommended re-transmission request rules for quick mode. 3) Make use of the Delete mode a requirement. 4.4.1 Oldest Phase 2 SA First The concept of using the oldest phase 2 SA first for outbound traffic allows the maximum use of negotiated keys and allows for the pre-negotiation of an arbitrary number of phase 2 SAs to be made available for later use. The oldest SA is also defined as the first negotiated of the available SAs. Additionally, it decouples new phase 2 SA negotiation from old phase 2 SA deletion, and the need to transfer to the new when the old SA is deleted. It also eliminates the race condition that occurs during SA set up during re-keying. This means that use of the commit bit to avoid the race condition is not necessary except when the very first phase 2 SA is set up. IPSec Working Group [Page 23] =0C Internet Draft IPSec Re-keying Issues September 1998 4.4.2 Phase 2 Re-keying Illustration This section illustrates the events when re-keying occurs using the above proposals. Note the simplifications due to the decoupling of SA negotiation and old SA deletion. Initiator Responder Inbound Outbound Inbound Outbound | | | | 1 ----------------- | | | | ------------ | | | | -------------------> 2 | | | | | | | -------------------- 3 | | ------------ | | 4 <--------------- | | | | | | | 5 ---------------- | | | *6 | ------------ | | | | | ------------------> 7 | | | | | | | | | *8 | | | | | | | 9 | | | | | | | | *10 *10 | | | 11 ----------------- | | | | | | ------------ | | | | | | -------------------> 12 | | | | | | | | | | | *13 * 13 | | | 14 * | | | | | | | | | | -------------------- 15 | | ------------ | | 16 <--------------- | | | | | | | | *17| | | | | | | | Figure 4-1 Recommended IPSecond Phase 2 Re-key Sequence Chart, Initiator Expiration 1) Initiator sends first quick mode message. 2) Responder receives first quick mode message. IPSec Working Group [Page 24] =0C Internet Draft IPSec Re-keying Issues September 1998 3) Responder sends second quick mode message. 4) Initiator receives second quick mode message. 5) Initiator sends third quick mode message. 6) Initiator sets up new inbound SA. Implementations may choose to set up the new outbound SA at this time, as long as they do not use it. 7) Responder receives third quick mode message. 8) Responder set up new inbound SA. Implementations may choose to set up the new outbound SA at this time, as long as they do not use it. 9) Initiator's old SA pair expires. 10) Initiator starts using new outbound SA and stops using old outbound SA. 11) Initiator sends first SA Delete mode message. 12) Responder receives first SA Delete mode message. 13) Responder sets up new outbound SA. 13) Responder deletes old outbound SA and starts using new outbound SA. 14) Responder deletes old inbound SA. 15) Responder sends second SA Delete mode message. 16) Initiator receives second SA Delete mode message. 17) Initiator deletes old inbound SA. If the responder's old SA expires first, the events are as follows. IPSec Working Group [Page 25] =0C Internet Draft IPSec Re-keying Issues September 1998 Initiator Responder Inbound Outbound Inbound Outbound | | | | | | 9 | | | | | | | | | | | *10 *10 | | | | | | | | | -------------------< 11 | | | ------------ | | | 12 <--------------- | | | | | | | | | | | *13 *13 | | | | | | | | | 14 * | | | | | | | | | | 15 >--------------- | | | | | ------------ | | | | | -------------------> 16 | | | | | | | 17 * | | | | | | Figure 4-2 Recommended IPSecond Phase 2 Re-key Sequence Chart, Responder Expiration 9) Responder's old SA pair expires. 10) Responder starts using new outbound SA and stops using old outbound SA. 11) Responder sends first SA Delete mode message. 12) Initiator receives first SA Delete mode message. 13) Initiator sets up new outbound SA. 13) Initiator deletes old outbound SA and starts using new outbound SA. 14) Initiator deletes old inbound SA. 15) Initiator sends second SA Delete mode message. 16) Responder receives second SA Delete mode message. 17) Responder deletes old inbound SA. IPSec Working Group [Page 26] =0C Internet Draft IPSec Re-keying Issues September 1998 5. Acknowledgements Some of the concepts presented in this memo are based on work done by TimeStep Corporation's engineering group. Others are taken from concepts discussed within the IPSec working group. 6. References [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," draft-ietf-ipsec-isakmp-oakley-08.txt. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-10.{ps,txt}. Security Considerations This document is associated with the IPSec family of documents. As such, security considerations permeate the document. Author's Address Tim Jenkins tjenkins@timestep.com TimeStep Corporation 362 Terry Fox Drive Kanata, ON Canada K2K 2P5 +1 (613) 599-3610 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: IPSec Working Group [Page 27] =0C Internet Draft IPSec Re-keying Issues September 1998 Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Massachusetts Institute of Technology IPSec Working Group [Page 28] =0C ------_=_NextPart_000_01BDECA6.5C0DCED0-- From owner-ipsec Wed Sep 30 18:32:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA28538 for ipsec-outgoing; Wed, 30 Sep 1998 18:30:27 -0400 (EDT) From: Armando Fratezi To: Cc: , Subject: VPN Inteoperability Workshop Message-ID: <5010400027398466000002L062*@MHS> Date: Wed, 30 Sep 1998 18:54:15 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=5010400027398466" Sender: owner-ipsec@ex.tis.com Precedence: bulk --Boundary=_0.0_=5010400027398466 Content-Type: text/plain The VPN Interoperability Workshop is filling up rapidly. A list of the attendees is in the attached PDF file. If you have already sent us your applications, check the PDF file to be sure your application is included. In the aftermath of a crashed hard disk I think I lost about one dozen email on the afternoon of Friday, September 19. Send your application to me again if it does not appear on this list. If you have not sent your application in yet, do so right away. I expect we will fill up by the end of the week. You can find an application and more information about the workshop at http://www.ciug.org. Contact me if you have any questions. Bob Larribeau -------------------------------------------------------------------------------- ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco -------------------------------------------------------------------------------- --Boundary=_0.0_=5010400027398466 Content-Type: application/octet-stream; name=PPP9cont.pdf Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTEwIDAgb2JqDTw8DS9MZW5ndGggMTEgMCBSDS9GaWx0ZXIgL0xa V0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0YiAYQYQQUbjYXDAcCAbDmGRIQCAqG0GweNC4ajAZCA5 GcQA0XkaDjIYQ0YDmHxYzA0WykYSuKlQxwaGjIbDWancQCgrFAnCArm85Gs5mg3nAQEE6HQym4yG UynMUxY1A0iwOUjcajIczivWCxV+wyGRjcZC4ZDQQDcYjUXDaHjQbDe2Q8Yi4cx85GUQS+BQQcjQ XDEbRAajmG26LESMwiUx2/SKSSaE3uZjXHFSXzIa4mLTeDxafCgkkSrlSsi0YjEcQ2H6UqEQQTGG jcby2bT8hm82nAwm486usjEaYyvwjHziPDEbzWbigjGk5HM6E4wm0y8YGjfDDjZzXbbiPDYZ9Kfk ww9jtdzva/GQvmbXbzIaDOeaPfcDhOI7ytu+ta2ogtQXBouq7ryhK2JAwCXwPAqdr2HC3LsvAZL1 BC3L+wIGsGgqNISEAZBkuTEhsGiPosjERoOtDLoKGKZBg5Kas+lTdPUFApDeNA0jo7zwBc8TXvq2 0arhHgrDKOQ2jC+IYvmGzYSQ5wYLvHgZt+NrvBaGUphcGb0PS2kkskjiPJAy0lPS/gUBzL4YrbIo YSnK7zBqGc3t6FEuOA+Lko5Ez0tcuU6PIySERjJSwzgJQyjMM0hvCHEjzPLD6TgIw3juNknSlKkr UzJUWN7GrkJ6n9ADaEDfjkOAXS/E1LBmt1SzSyk2JHNz1No08VznMUNVJRU9T5Lcu0E5VCtu5Eit 5NER0bHVTumIo7OHSto0xRVTR4IYwjsqtRBchdjObGobNFPwgiGIdaTq8VbyvF81MrXsdT66b9WG xlivG5rzBves4XfeKsIJQavhlQy4sPU9p0ZNsdILOAhDCN9uSNEVv2tHgoDRbeFPlc8q4E+110fV CVOhVYUKKOQ2DJLqmicKd5VtXFv11Ndqpngtf5hPl/rzdL7YJg13ZxZlCYdZ9LZ7amK6CzrpiIoz i4VImO3tHWWOmJgyjSM1Q5LMV0ZTJMdavLFEtMn4gjmMaojJV7gDaOo3DSMYwjoNI3jcq2FTBMUy WTXKN13oAYaE/lgJ+GM53nO6w0y8wZhk6OD7pu2nYbh9EYlRcYarx2wp/SNJr/rbWO/S1vXVfceC ON43jIO40jdc21a/oPOZamaHZhuY0VAPIQPYOq/jcOgWBAJI3DHWfCzCxnETNqaccZ0/H1RonKPD y08plGnU/MHL9io0/jeR5Qw+YqMhZLhlnNdqV1UXxvvtJmAUg0h6DuyR17XVLsedm0E3h0wmhhDY GyBzvWUO/ccu00jLnih4fmRYMoYw0BuDeGwN4Zw0lVBeFIMIcH6OvTAvMHC9XFPcZ+95fh9TTo0a MwF8pjQYPrOmEGDTznQP3Yg3BlT+3vQLPWGkOaUWuOxgQypHUFifhXDSGwNbuw5uCgk0htjQYqKp ZgxkNjgA2lGMAFSDsH4QwjDfCVwkLFarRhg9sycM19NBhq5EFBcYcqXbWfchqeGMQOjNGiIbUH8L RjsrwjKOkeBTZGHd3kT1uxRi+45HkDQ2hyDfHE47aYJqlbar9lypzTsZeSE4ModA7lGKQzqOjPH9 OLjxI+PTQ24x9BlH+Lymm3G4YceKMYYZVytleUeUDC1myKiK6RF8jklNuj49IqaT0fwEKzAZ2UUp cuQZcn004U3dhnDQCAJrggzxOdeyZ30pGrSmJnEaVMxgQSsldLCZcLWdr2Z8vmXDjo9tEBtL6QM0 z1TCBnMSXcqp7zIn1Ilh7+YjtUjylmajMAihtSgxyA8FEdpwgaHJwElZ2yil/QicE85UG+DCGJUA dJPBuBAFMPJ2AyhtDmCALgKAiBOChLJektKKwyoAr5yDMD80Gh2+ROC4qYStpnRJZ7o5Gv8ioCgJ rfWRhlDZR6bsmYlI9bJA910oVR0HlLStO9LQUBDiYGMN9NablQp1UKF9RGJx3qO7SpMu0NVMcwfh Gy4a4sbfrM2icjJasUouptPwQw0JODzV+SzXp4OOYun6BoZIt0mrQyelNa3hVtZhXBulc6bU4ru9 aF0dbG18mlX58EuwaA1sEsewjbq32HqoodiNV3TqXkiGENSQawSYmAjwITIw5hrDCHKbRBKUVqnj Wyeh/Q5u7MAl1vTfG/OAcFPt66Y0yz+ltX2b9tX2E/Bu+JOyeLBkNc1D67V3LfrQoZUV01j3gnTC gdYNd0Lk0gt4FCBxwAwxZi7dZx1/0sE0l2ERv4YQQBGq9CIO4c3oPSeorRw954Y2yf5QOXdBXCp0 fHfK3Ugz8o8woHQMOGIHqemWcixVVbg2xtnes6YRy/hnwLZmkNkbolQDlg2kGEEa4SvaCgIrzg5B 1OxByD0IIRQkXK9bELiY7L4x7QKXWTwcXwBw+S+Z577ZQyllSFZx37TOopXvMNkDpwADGGvIbH2g upBQFMMruoH5KyJGGDEuwjYaChG95zeFYlGb+4G0BMI51DvRUbOuJsnuatywN9Nmzp6JU9ot3eb5 mNPdFju/mdaso+DEk7U03LlKOdqk4OSQcb3VpBoaebMAjUzcAk7K0bMsxwbxXi2F/MwYlzGacGbk 8UrEkBU1E2oCf6/cFsHJNidUNRsZqt/lvAp3RduHDPcCXHZrgaHQNDzNCZ8eInBIAZtJz8lnpfEk NEeA0Bhp2b28U/bz0njjbtwIjZ0f4tc3yoDuaT1lgZHgSg6ndbRWnXc8k7swCRoGmIdAQYIzzdEM myK9Ol2Xvqv+T0T7+kyuxHgSKg7cdDt6/fCHvVZsldFUEy+H6FR4EtvYepytnpPxbIm1jUBCCbyT fHJ7Hw1j7iiFjJoddHR4EnpV+arY8f5mvX5w89WXo/kTNeFHd7v3QV7jCR5d9YCbo4OGkLxb10rX npr3en7NcknLaLANp9WTh26/Oc3S6ZZC/EFtkio7n3+kup9kw3ZC4raLB3arsWbNP24EAUiqhluj B4EARA0h2iZpLpmI+nUBf7DYn5KOWKa6R4LmUROt7ge9woFAQUnnDDJYiAsUKQVj6+VDoXaPG+x6 za6fvqO8eq6gTr16SvkdL9nnLb/NrH5rzwGjxkmTdshggG4OrgNc9G3h45P3so5Wv5Kvf5tSE/Ob +ixbq/yZ25x1TwfwtWEeau1g+6U03Uk+DWU8SCD0+M+89iCGCmCC9Oy+/etoOmI69eT0LI8DAXAa +qsW5q/25uk2q4DCq9AASUzWUipmDSjPAQU0iUyaN48yecq87g7k9M+U3u+Ylu/gf8sA746m2kl+ cyByz8ekKgss/uxy4MmgiQset4wo9I5G7ErC9gXCDeDxBURquI8DBgZmd27C/W+XAfBxAiJ+Bove 76aOkCPMNgqzCGScDZC48G+vA6v8uZBODmggDtBGR0zWCWPbDvCsim7WZgCSCkCKpqg6fkpqhC/G 0kvI/Y7vDCx89YBQYc/nEiNREI601U+w9Uz84kDcBaq4Os98m2+AyJCEDoR/D/EiVSnEJ+CWCCCb EKCgk8DUg61M3s0tBuvUzE5ShuBpEqSyrHD4PhA05oWlDk9Uqyq2g9BDCLFIku4uTgCWhE/K8opA vsVS8xFcCYCeCm2GywhGjgw6enActi9TBzEkNfGAztFdGpEy/0mi3CR4O0uku2DaZG4dFK/O9whQ nMXGumnclG/O144yl2CYDqbq0ajUyujay1EbC/HNAhFWZgBiBnAoJkc0t5IPIS1M4I5mkXA5Hie8 t4CUR/HzGgyI3FFQSfGqnfIHEDINIQg3IW2JHCy3C9BtDBF29Wj4Bq2hB679B/IwQKThI2fnEyTI uFCWkiKgXJDyaC6QN+DEDFFUccrHGWk8i2DNFu7q2Sr3HPDET+37DM6qxaTuBwz9Kwk+DfK3DhJD CVGS/7BADlCe9/JRH25e7A4o6LGs7I7XG0BQnwCmDGL+KjG/IajgxAewxFJ08NF6J+twxScqxY08 kGL7HmlbMHMK4G/wx1HhLgSUqyisgeDSO3KedQ8OjK6ItDJc7SmolOZgnwmSDWKaDYg8pyrO0pEd F1McvYhuzLLI7/LMJXBYkGQtNiogKPNrNuDbNzI8iI8JJFKXMep8XGDTLrGesw/O6Qgas/KqyKgu eGZYNPNklgKaDmi2DHNKKgw4eiemerJxFzMa2ZOoVvIuJUJ2nkLjMBPLOUbnPTPXJuKyQEMGIWNk Le9qMgJKIOMYJmBoM6JecyBw4UPMSrPGJ+3GDoeYDImMeg0AhUpy1eDkRKBsegSmJYO8BoNgTGI+ zSORQoJkBwXaNOwQDOMAILLYRKQCIGICDWVuZHN0cmVhbQ1lbmRvYmoNMTEgMCBvYmoNMzE5Ng1l bmRvYmoNNCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwN L0ZvbnQgPDwNL0YwIDYgMCBSIA0vRjEgOCAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250 ZW50cyAxMCAwIFINPj4NZW5kb2JqDTEzIDAgb2JqDTw8DS9MZW5ndGggMTQgMCBSDS9GaWx0ZXIg L0xaV0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0YjkaC4YjYQDcYDUXDOFCAqEQGjAQRYYC4ajAZCA 5GcQA0XkaLDEYi4YQ0aCCJGaKygaxEqGOLywqHcQCgkkQUxI1A0WyYcSgcTWJEQQC2MjAbjeixKa Cghm82nAwm48z0qT8YjQcxqOxajxeUDIYjebVEjGk5HM6E4wm0y1qfjeDjii2KJ0mljIbDO0zkmG G3XC5XSCQUXDeFXqkUqUDQZjXA1KqVasYgiwMbjIXDKVjcY0OijQbDfP0WTx05GUQS7O5+VjYc0O EiDTagZaoXDSV63Xg2BQSayUQDIZQ6FDa8Q+OxI2xXix6QSIjDEQDGljCvTaXdu7ZUpnU3GQwnLE XYXXiTUa9+DKVCclIwmrESav4zR+6kfDAu29qJJwFAnDKOg7jeOQ1okMo2DKOY8rcMo2jmxAWuQu 4cBmlbHOmjKNtY6rwMA+S9QG00LPw1L9w6yCUhqp6ZrIGCupXAScwLA8EwWKkGwfCI6QnCqfIIry wBkwCgwymz+umj6QvAtESptAYpjQMo0jYML0wy9sOyiyojDkq41wa+7FP0vMmRmpjnxlAgkimKkL Qw9cNQ5NaMLJEDqSglCmRJN4ZhxFLFN3Fk1xcGrdsqJ04znIiuq/RckKSGKHBjN0mz1J6XpTKU3i QMI3y5O0vTzP7RMqLA6zO/IbUQsbwJkqIoDqNg5rnIkLtBO0Nv5DyNI5PtPUAyrQUKr9DzUscXBo 7jK1tXFdK3ItJuRJNLoRTUPWI8DsPkFApDeNwyjdUr2OxL9U3BUIwjRc9IzRWFmPfdj/z/S8qPmI IiCOKogikIgWBAJg6DIF06V6vFfy+4thRDP1P0CmkTJyGYb2TFd6sevrJsqKV+3/gKeUjI1KWzTF uT0i1OzBcIpjGN46DpdAcVPWVUxiqIlwaNis3lV9Y3tid8JSGNAwGKQyjIIbWjLBapjaNryDSMYw joNNSV3OuGTxWWHz5l1U4o90T0JXcVWXYEXORUCo6XpunjW++T2xS0l7BTkRbJkA3jnIdqvVdNgP BG03ivK8fPRoLF3pwtUvjGUAXbpQ3jrII5Cu87XCSNwx4TrjFIgGbAYcjGIW9vspxuFAaRThcaBz tiloTyW4cvzI785utr0qoOVTzJ2+U/w6ovG1o5jRm2caIplaJyJYwjYNbySDV3HaG/tU+hAF9hRK w0jsMIQKmOQ4QTrGtXjateQzhvhdRsXiWN1ibpys2NbXFql2f25OXwvjd6kdbLeT3vDYkUx/4KEe hya24JLq6lUKfXaVEJq5FyLmewmlyCn03MVXy4dKoUwkPlKo1QNzVn1LkDmCAKa1CfvuV81+A78l htjaK/ZE7r20qGZuxxNgNnoPghJANlClngt6JrDhNplQqBpDa8yCTOVPxDCUuYNYaQ3OBK4vN7Sb Abv/co9+J5cgppBDhCZ876WsrkYU++Gim09w3foDdsrFgUHIf1D92hZQZNvJzGUMsZwyhwiM3dJS dn4xLjrAsIqDg3JbSI4Nm8U3nGdZAHkMIYg1wPi60KIB/kSr5crIEOQdS3BXR3C0KaQEhAgCEC4K zoX2tdTu4VsMdIEx2P+98s8e4voudtE6U8qZVyHd+tpTMi2Wx1iGEFBweIpQdiauEIgZQwsyfZJ9 7MoVUyABQFYMocg0hTDSGebZQJbPwiUh+XSxZeLhBmDmYEQG2qVXDOKck5p0TIgLIqdrqniniDqG 0NLNZJwRmoU4yoVgwxZDZBtx664PUNCgjmN8M5cQ2YjPBsrrgYz1j6dwGDOychWougaf0SFtzMoF NVN59DytAggqaSz26BrhCEgly4Zw0RcMTKChbxk2TLda5sOgYw0BHDqecMiDKlBuDeGwN4Zw0wwn UwuW7p450dRHL11pXqRP8JQQmkwKKkVKqZU6lciS8UuiZGEyoTAyrkrZQmm1C4FsxDQ7sOQdA9US i+rNoyNHvhYaYGl8j5n0JjjbOlC7oy/ummY6muMd3vgydgXd2VI3/KrsTJJapmzhGcBsUQhcSSJn WIsV8lJvjvFAKWoOD5fCUKwdm60KbWA6hyPMHlgkLw4JBDaGKcZxwbMEIKbUxANDRnOpGV22qLgc EyQGFAMIZzXEdDeGY45miBkBDWVuZHN0cmVhbQ1lbmRvYmoNMTQgMCBvYmoNMTU5MQ1lbmRvYmoN MTIgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250 IDw8DS9GMCA2IDAgUiANL0YxIDggMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMg MTMgMCBSDT4+DWVuZG9iag02IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlw ZQ0vTmFtZSAvRjANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuLEJvbGRJdGFsaWMNL0ZpcnN0Q2hh ciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNTEgMzcxIDU1MSA0OTEgNTAzIDgzOSA3Nzkg Mjc1IDMzNSAzMzUgNTAzIDU2MyAyNTEgMzM1IDI1MSAyNzUgDTUwMyA1MDMgNTAzIDUwMyA1MDMg NTAzIDUwMyA1MDMgNTAzIDUwMyAzMzUgMzM1IDU2MyA1NjMgNTYzIDUwMyANODI3IDY1OSA2NTkg NjU5IDcxOSA2NTkgNjU5IDcxOSA3NzkgMzgzIDUwMyA2NTkgNjExIDg4NyA3MTkgNzE5IA02MTEg NzE5IDY1OSA1NTEgNjExIDcxOSA2NTkgODg3IDY1OSA2MTEgNjExIDMzNSAyNzUgMzM1IDU2MyA1 MDMgDTMzNSA1MDMgNTAzIDQ0MyA1MDMgNDQzIDMzNSA1MDMgNTUxIDI3NSAyNzUgNTAzIDI3NSA3 OTEgNTUxIDUwMyANNTAzIDUwMyAzODMgMzgzIDI3NSA1NTEgNDQzIDY1OSA1MDMgNDQzIDM4MyAz NDcgMjE1IDM0NyA1NjMgNzc5IA03NzkgNzc5IDU2MyA1NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA1 NjMgNTYzIDU2MyA1NjMgNzc5IDc3OSA3NzkgDTc3OSA1NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA1 NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA3NzkgNzc5IDU2MyANMjUxIDM4MyA1MDMgNTAzIDQ5MSA1 MDMgMjE1IDUwMyAzMzUgNzU1IDI2MyA1MDMgNTk5IDMzNSA3MzEgNTAzIA0zOTUgNTUxIDI5OSAz MTEgMzM1IDU3NSA1MDMgMjUxIDMzNSAyOTkgMjk5IDUwMyA3NDMgNzQzIDc1NSA1MDMgDTY1OSA2 NTkgNjU5IDY1OSA2NTkgNjU5IDkzNSA2NTkgNjU5IDY1OSA2NTkgNjU5IDM4MyAzODMgMzgzIDM4 MyANNzE5IDcxOSA3MTkgNzE5IDcxOSA3MTkgNzE5IDU2MyA3MTkgNzE5IDcxOSA3MTkgNzE5IDYx MSA2MTEgNTAzIA01MDMgNTAzIDUwMyA1MDMgNTAzIDUwMyA3MTkgNDQzIDQ0MyA0NDMgNDQzIDQ0 MyAyNzUgMjc1IDI3NSAyNzUgDTUwMyA1NTEgNTAzIDUwMyA1MDMgNTAzIDUwMyA1NTEgNTAzIDU1 MSA1NTEgNTUxIDU1MSA0NDMgNTAzIDQ0MyANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0v Rm9udERlc2NyaXB0b3IgNyAwIFINPj4NZW5kb2JqDTcgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNj cmlwdG9yDS9Gb250TmFtZSAvVGltZXNOZXdSb21hbixCb2xkSXRhbGljDS9GbGFncyAxNjQ4Mg0v Rm9udEJCb3ggWyAtMjUwIC0yMTYgMTEyMyAxMDQwIF0NL01pc3NpbmdXaWR0aCAzMzYNL1N0ZW1W IDEzMQ0vU3RlbUggMTMxDS9JdGFsaWNBbmdsZSAtMTENL0NhcEhlaWdodCA4OTENL1hIZWlnaHQg NDQ2DS9Bc2NlbnQgODkxDS9EZXNjZW50IC0yMTYNL0xlYWRpbmcgMTQ5DS9NYXhXaWR0aCA5MzYN L0F2Z1dpZHRoIDQxMg0+Pg1lbmRvYmoNOCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAv VHJ1ZVR5cGUNL05hbWUgL0YxDS9CYXNlRm9udCAvQXJpYWwNL0ZpcnN0Q2hhciAzMg0vTGFzdENo YXIgMjU1DS9XaWR0aHMgWyAyODcgMzM1IDM1OSA1NTEgNTUxIDg4NyA2NzEgMTkxIDMzNSAzMzUg MzgzIDU5OSAyODcgMzM1IDI4NyAyODcgDTU1MSA1NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA1NTEg NTUxIDU1MSAyODcgMjg3IDU5OSA1OTkgNTk5IDU1MSANMTAzMSA2NzEgNjcxIDcxOSA3MTkgNjcx IDYyMyA3OTEgNzE5IDI4NyA1MDMgNjcxIDU1MSA4MzkgNzE5IDc5MSANNjcxIDc5MSA3MTkgNjcx IDYyMyA3MTkgNjcxIDEwMDcgNjQ3IDY3MSA2MjMgMjg3IDI4NyAyODcgNDU1IDU1MSANMzM1IDU1 MSA1NTEgNTAzIDU1MSA1NTEgMzExIDU1MSA1NTEgMjM5IDIzOSA1MDMgMjM5IDg2MyA1NTEgNTUx IA01NTEgNTUxIDMzNSA0NzkgMjg3IDU1MSA1NTEgNjk1IDUyNyA1MDMgNTAzIDMzNSAyNjMgMzM1 IDU5OSA3NjcgDTc2NyA3NjcgNTk5IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5 IDU5OSA3NjcgNzY3IDc2NyANNzY3IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5 IDU5OSA1OTkgNTk5IDc2NyA3NjcgNTk5IA0yODcgMzM1IDU1MSA1NTEgNTUxIDU1MSAyNjMgNTUx IDMzNSA3NDMgMzgzIDU1MSA1OTkgMzM1IDc0MyA1NTEgDTQwNyA1NTEgMzM1IDMzNSAzMzUgNTc1 IDU1MSAyODcgMzM1IDMzNSAzNTkgNTUxIDgzOSA4MzkgODM5IDYyMyANNjcxIDY3MSA2NzEgNjcx IDY3MSA2NzEgMTAwNyA3MTkgNjcxIDY3MSA2NzEgNjcxIDI4NyAyODcgMjg3IDI4NyANNzE5IDcx OSA3OTEgNzkxIDc5MSA3OTEgNzkxIDU5OSA3OTEgNzE5IDcxOSA3MTkgNzE5IDY3MSA2NzEgNjIz IA01NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA4ODcgNTAzIDU1MSA1NTEgNTUxIDU1MSAyODcgMjg3 IDI4NyAyODcgDTU1MSA1NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA1NTEgNjIzIDU1MSA1NTEgNTUx IDU1MSA1MDMgNTUxIDUwMyANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2Ny aXB0b3IgOSAwIFINPj4NZW5kb2JqDTkgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9G b250TmFtZSAvQXJpYWwNL0ZsYWdzIDMyDS9Gb250QkJveCBbIC0yNTAgLTIxMiAxMjM3IDEwNTUg XQ0vTWlzc2luZ1dpZHRoIDI4OA0vU3RlbVYgODANL1N0ZW1IIDgwDS9JdGFsaWNBbmdsZSAwDS9D YXBIZWlnaHQgOTA1DS9YSGVpZ2h0IDQ1Mw0vQXNjZW50IDkwNQ0vRGVzY2VudCAtMjEyDS9MZWFk aW5nIDE1MA0vTWF4V2lkdGggMTAzMQ0vQXZnV2lkdGggNDQxDT4+DWVuZG9iag0yIDAgb2JqDVsg L1BERiAvVGV4dCAgXQ1lbmRvYmoNNSAwIG9iag08PA0vS2lkcyBbNCAwIFIgMTIgMCBSIF0NL0Nv dW50IDINL1R5cGUgL1BhZ2VzDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NPj4NZW5kb2JqDTEg MCBvYmoNPDwNL0NyZWF0b3IgKCkNL0NyZWF0aW9uRGF0ZSAoRDoxOTk4MDkyNjEzMjE0NykNL1Rp dGxlIChQUFA5KQ0vQXV0aG9yIChBZG1pbmlzdHJhdG9yKQ0vUHJvZHVjZXIgKEFjcm9iYXQgUERG V3JpdGVyIDMuMDIgZm9yIFdpbmRvd3MgTlQpDS9LZXl3b3JkcyAoKQ0vU3ViamVjdCAoKQ0+Pg1l bmRvYmoNMyAwIG9iag08PA0vUGFnZXMgNSAwIFINL1R5cGUgL0NhdGFsb2cNPj4NZW5kb2JqDXhy ZWYNMCAxNQ0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMDgwOTIgMDAwMDAgbiANMDAwMDAwNzk3 MCAwMDAwMCBuIA0wMDAwMDA4MjcxIDAwMDAwIG4gDTAwMDAwMDMzMTIgMDAwMDAgbiANMDAwMDAw ODAwMSAwMDAwMCBuIA0wMDAwMDA1MjYxIDAwMDAwIG4gDTAwMDAwMDYzNTggMDAwMDAgbiANMDAw MDAwNjYzNiAwMDAwMCBuIA0wMDAwMDA3NzE3IDAwMDAwIG4gDTAwMDAwMDAwMTkgMDAwMDAgbiAN MDAwMDAwMzI5MSAwMDAwMCBuIA0wMDAwMDA1MTMwIDAwMDAwIG4gDTAwMDAwMDM0NDIgMDAwMDAg biANMDAwMDAwNTEwOSAwMDAwMCBuIA10cmFpbGVyDTw8DS9TaXplIDE1DS9Sb290IDMgMCBSDS9J bmZvIDEgMCBSDS9JRCBbPGUwOTg1NzEwNGI5Njk3MmY0ODAyOGYzMjBjYjFlYjY5PjxlMDk4NTcx MDRiOTY5NzJmNDgwMjhmMzIwY2IxZWI2OT5dDT4+DXN0YXJ0eHJlZg04MzIwDSUlRU9GDQ== --Boundary=_0.0_=5010400027398466-- From owner-ipsec Wed Sep 30 19:18:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA28680 for ipsec-outgoing; Wed, 30 Sep 1998 19:17:25 -0400 (EDT) Message-Id: <9809302314.AA25137@hpcc103.corp.hp.com> To: ipsec@tis.com Subject: Was Re: multiple payloads via "ID_LIST" Reply-To: yanfali@corp.hp.com Date: Wed, 30 Sep 1998 16:14:59 -0700 From: Yan-Fa LI Sender: owner-ipsec@ex.tis.com Precedence: bulk As a customer of VPN solutions, it appears what your talking about is exactly one of the problems we are facing with "VPN" based leased line replacement scenarios. I think Shawn put it quite nicely, and we actually have this problem. We've got this great big Class A network, which due to historical oversight did not get allocated as blocks. We have sites with dozens to hundreds of subnets which are not completely contiguous. So, now I've got this nice IPSec solution, but I have to define lists of hundreds of networks on each side of the SA in order to get the thing to work. And I have to do this on each IPSec Router/Gateway on my network being used as a leased line replacement. No I can't use a wild card selector because they may have firewall equipment beside the encryptor to allow external controlled traffic into their network. Yes we could renumber, but have you every tried renumbering 200K hosts ? It's not much fun. Oh and I didn't mention the hundreds of class C networks, also not contiguous, we route internally and even some GASP unrouteable (e.g. 10 - don't ask) networks and a couple of Class Bs we have too, which are naturally split up geographically (though thankfully as blocks). Whomever delivers the best solution to this problem is probably going to get the most business once everyone else, read the "mainstream" networkers, figure out what a mess it is to configure a VPN in a complex network. Actually, all this talk of Meta-IDs sounds like a really good idea to me, though I'll have to think on it a little more. One of the things I would like to see IPSecond work on is a standard "routing/exchange" like method for IPSec. Which either is based upon an existing routing protocol, or can get information from an existing routing protocol. This would ease configuration a lot in big networks. This may be orthogonal to security in some minds. For example, wouldn't it be nice if we could make use of External BGP for Encryption Gateways on the "RED"/Local/Trusted Side of a security gateway to list all the networks on one side of a VPN and securely share that information with the other side of the VPN link and vice versa. So now both gateways have a list of the networks on either side of the VPN, which BTW they are also propagating with their respective local network clouds. And if the encryptor goes down the traffic can take a different path rather than black hole the traffic due to the router interaction. Branch Site --- Encrypter --- Internet --- Encrypter --- Corporate Router EBGP SOME KIND OF EBGP ROUTER PROTOCOL Now I have a lot less configuration to do. And I've established security for a group of networks on either side of the link. Ah you say, well how do we get a link into a useable SPI then since we're not using destination/source addressing ? Well, it turns out there's this little used but interesting field called "community" in EBGP which could be used as a new selector. Then perhaps we could configure on the encryptor: Peer Gateway IP Address Authentication Required (PreShared/PK) Community The Community would then be an index into what Encryption algorithm for IPSec and even some basic Source/Dest Address filters and/or TCP/UDP ports for the collective range of networks. BTW, business partners could be in this mix, but they could get their own set of SPIs based on community string and route propagation and so wouldn't necessarily be using the same tunnels. So the idea a Meta-ID would be a way of exchanging this information between IPSec devices, now we need a standard way of getting this information in and out of the IPSec device in the first place and back to a router at either end. Of course if the IPSec device were a router, this might already be done ;P This idea isn't new, I think someone at cisco first proposed it. ___________________________________________________________________ | Bio-Routing: | Electronic Connectivity: | | | | | Yan-Fa LI | Phone: ( +1 ) - 650 236 3680 | | Hewlett-Packard Company | Fax: ( +1 ) - 650 236 3632 | | Mail Stop: 20CX | | | 3000 Hanover Street, | Telnet: 236 - 3680 | | Palo Alto, CA 94304 | Email: yanfali@corp.hp.com | | USA | | |____________________________|______________________________________|