From owner-ipsec@lists.tislabs.com Mon Oct 2 05:45:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13863; Mon, 2 Oct 2000 05:45:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA06677 Mon, 2 Oct 2000 06:51:43 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A97A8@eseis06nok> To: ipsec@lists.tislabs.com Subject: Notification payloads IV Date: Mon, 2 Oct 2000 14:02:27 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How is the IV computed for notification messages in IKE Phase I? I know in phase II it's computed: "using the hash of a concatenation of the last Phase I CBC block concatenated and the message id in the ISAKMP header" (RFC 2409 Apendic B) However, I'm not really sure how to do it for Phase I when encryption is applied (messages 5 and 6) and an error is found. Is it explained somewhere? Toni From owner-ipsec@lists.tislabs.com Mon Oct 2 06:50:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15158; Mon, 2 Oct 2000 06:50:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06940 Mon, 2 Oct 2000 08:37:03 -0400 (EDT) Message-ID: <20001002124753.20638.qmail@web3502.mail.yahoo.com> Date: Mon, 2 Oct 2000 05:47:53 -0700 (PDT) From: Eva Jencusova Subject: Diffie-Hellman and rfc 2409 To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I have this problem: In RFC 2409 - IKE is: g^xi , g^xr - are the Diffie-Hellman public values of the intiator and responder g^xy - is DH shared secret ---------------------------- Does it mean that: Initiator generates random number xi and responeder generates number xr and g^xy=g^xi*g^xr ? or does it mean that: Initiator generates number i , responder r and g^xi=g^i mod p g^xr=g^r mod p g^xy= ?? Thanks. Eva Jencusova __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Oct 2 07:11:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15514; Mon, 2 Oct 2000 07:11:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07161 Mon, 2 Oct 2000 09:16:57 -0400 (EDT) Date: Sun, 1 Oct 2000 18:28:30 -0700 (PDT) From: Avram Shacham X-Sender: shacham@zev.net To: ippcp@external.cisco.com, royp@cisco.com cc: ipsec@lists.tislabs.com Subject: VPN Workshop - IPComp group meeting minutes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The town-hall meeting on IPComp took place in the VPN workshop in San Diego on September 20, 2000. The minutes of that meeting are detailed below. Of the issues discussed, only issue #4 -- and less likely #3 -- should be reflected in rfc2393bis. I plan to issue the next version of the rfc2393bis I-D soon, following the discussion on those issues on the lists. Your prompt comments and suggestions are solicited. Regards, avram (1) IPComp Interoperability Report With about 30 IPv4 and two IPv6 IPComp implementations present in the bakeoff, the time seems ripe for preparing the IPComp Interoperability Report, which should be submitted to the IESG as part of the move to Draft Standard. Several IPComp implementations, who successfully interoperated, already expressed interest in being included in the report, but, for sure, the more the better. Please email me if you are interested in joining the report, thanks. (2) CPI size in IPComp proposal (2/4 bytes) Several implementations are yet to incorporate the consensus reached in the January 2000 VPN workshop for the CPI (SPI) field size. A typical interoperability problem occurred when an implementation that supports only a proposal with 32-bit CPI field rejected a proposal with CPI defined in a 16-bit (2 octet) field. In conversation with those implementors, I understood that they plan to modify their code ASAP. The consensus, as defined in draft-shacham-ippcp-rfc2393bis-05.txt, was reiterated: 4.1. Use of IKE [...] The CPI is sent in the SPI field of the proposal, with the SPI size field set to match. The CPI SHOULD be sent as a 16-bit number, with the SPI size field set to 2. Alternatively, the CPI MAY be sent as a 32-bit value, with the SPI size field set to 4. In this case, the 16-bit CPI number MUST be placed in the two least significant octets of the SPI field, while the two most significant octets MUST be set to zero, and MUST be ignored by the receiving node. The receiving node MUST be able to process both forms of the CPI proposal. (3) Stand-alone IPComp negotiated via IKE The rfc2393bis I-D includes the following clarification, reflecting the discussions on the ippcp list: 4.1. Use of IKE [...] Using IKE, IPComp can be negotiated as stand-alone or in conjunction with other IPsec protocols. Several implementors objected to that clause on the ground that IPComp is not a security protocol. In a straw-poll, several implementors (more than 10, according to my count) pointed out that they already implemented negotiation of stand-alone IPComp via IKE. On the way to Draft Standard, where unused features of a protocol should be removed, that many implementations dictate -- imo -- that the above clause should stay. What is the opinion on the lists? (4) Use of well-known CPI in IKE negotiation IPCAs become non-unique in the following scenario: (a) Two or more IPComp session are established between two nodes. (b) A well-known CPI is used. Non-unique IPCAs pose problems in reaching attributes specific to each IPCA, either negotiated (e.g., lifetime) or internal (e.g., the counters of the adaptive algorithm for handling previously compressed payload). To be sure, when only a single session is established between two nodes, the IPCA is unique even when using a well-known CPI. In addition, the above scenario can be avoided by using the negotiated CPIs (256-61439). Several implementations, who chose to utilize the well-known CPIs in such scenarios, used extra information to identify the IPCA, such as the Protocol Suite (or bundle or enclosing) SA that includes that IPCA. In the town-hall discussion and a thread that followed on ipsec list, several suggestion were raised for the above scenario: (a) OK to negotiate with well-known CPI, but only when no other attributes are negotiated. (b) Identify the IPCA as part of the Protection Suite (bundle). (c) Use only negotiated CPIs when more than one session is established between two nodes. There was no conclusion to the town-hall discussion on that issue and the matter is now before the lists. I'd suggest to add an implementation note to rfc2393bis that identifies that problem and recommends (c). (5) DEFLATE (RFC 2394) The discussion on using DEFLATE header and Adler32 checksum, which started in the town-hall meeting in the VPN workshop in January 2000, continued. In a straw-poll, _all_ implementors indicated support for NOT including the extra information. Roy, could you please issue rfc2394bis that reflects that consensus? === eom === From owner-ipsec@lists.tislabs.com Mon Oct 2 07:12:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15552; Mon, 2 Oct 2000 07:12:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07038 Mon, 2 Oct 2000 09:02:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20001002082611.00b1f9e0@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Oct 2000 08:32:52 -0400 To: IP Security List From: Sheila Frankel Subject: AES draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk NIST is announcing the AES algorithm(s) today at 11 AM EST. In light of that fact, and since the AES draft expired on September 30, we will be updating it early next week. All past comments will be taken into account; additional comments and suggestions are welcome. Sheila Frankel sheila.frankel@nist.gov From owner-ipsec@lists.tislabs.com Mon Oct 2 07:27:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15877; Mon, 2 Oct 2000 07:27:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07136 Mon, 2 Oct 2000 09:14:55 -0400 (EDT) Date: Sun, 1 Oct 2000 18:28:30 -0700 (PDT) From: Avram Shacham X-Sender: shacham@zev.net To: ippcp@external.cisco.com, royp@cisco.com cc: ipsec@lists.tislabs.com Subject: VPN Workshop - IPComp group meeting minutes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The town-hall meeting on IPComp took place in the VPN workshop in San Diego on September 20, 2000. The minutes of that meeting are detailed below. Of the issues discussed, only issue #4 -- and less likely #3 -- should be reflected in rfc2393bis. I plan to issue the next version of the rfc2393bis I-D soon, following the discussion on those issues on the lists. Your prompt comments and suggestions are solicited. Regards, avram (1) IPComp Interoperability Report With about 30 IPv4 and two IPv6 IPComp implementations present in the bakeoff, the time seems ripe for preparing the IPComp Interoperability Report, which should be submitted to the IESG as part of the move to Draft Standard. Several IPComp implementations, who successfully interoperated, already expressed interest in being included in the report, but, for sure, the more the better. Please email me if you are interested in joining the report, thanks. (2) CPI size in IPComp proposal (2/4 bytes) Several implementations are yet to incorporate the consensus reached in the January 2000 VPN workshop for the CPI (SPI) field size. A typical interoperability problem occurred when an implementation that supports only a proposal with 32-bit CPI field rejected a proposal with CPI defined in a 16-bit (2 octet) field. In conversation with those implementors, I understood that they plan to modify their code ASAP. The consensus, as defined in draft-shacham-ippcp-rfc2393bis-05.txt, was reiterated: 4.1. Use of IKE [...] The CPI is sent in the SPI field of the proposal, with the SPI size field set to match. The CPI SHOULD be sent as a 16-bit number, with the SPI size field set to 2. Alternatively, the CPI MAY be sent as a 32-bit value, with the SPI size field set to 4. In this case, the 16-bit CPI number MUST be placed in the two least significant octets of the SPI field, while the two most significant octets MUST be set to zero, and MUST be ignored by the receiving node. The receiving node MUST be able to process both forms of the CPI proposal. (3) Stand-alone IPComp negotiated via IKE The rfc2393bis I-D includes the following clarification, reflecting the discussions on the ippcp list: 4.1. Use of IKE [...] Using IKE, IPComp can be negotiated as stand-alone or in conjunction with other IPsec protocols. Several implementors objected to that clause on the ground that IPComp is not a security protocol. In a straw-poll, several implementors (more than 10, according to my count) pointed out that they already implemented negotiation of stand-alone IPComp via IKE. On the way to Draft Standard, where unused features of a protocol should be removed, that many implementations dictate -- imo -- that the above clause should stay. What is the opinion on the lists? (4) Use of well-known CPI in IKE negotiation IPCAs become non-unique in the following scenario: (a) Two or more IPComp session are established between two nodes. (b) A well-known CPI is used. Non-unique IPCAs pose problems in reaching attributes specific to each IPCA, either negotiated (e.g., lifetime) or internal (e.g., the counters of the adaptive algorithm for handling previously compressed payload). To be sure, when only a single session is established between two nodes, the IPCA is unique even when using a well-known CPI. In addition, the above scenario can be avoided by using the negotiated CPIs (256-61439). Several implementations, who chose to utilize the well-known CPIs in such scenarios, used extra information to identify the IPCA, such as the Protocol Suite (or bundle or enclosing) SA that includes that IPCA. In the town-hall discussion and a thread that followed on ipsec list, several suggestion were raised for the above scenario: (a) OK to negotiate with well-known CPI, but only when no other attributes are negotiated. (b) Identify the IPCA as part of the Protection Suite (bundle). (c) Use only negotiated CPIs when more than one session is established between two nodes. There was no conclusion to the town-hall discussion on that issue and the matter is now before the lists. I'd suggest to add an implementation note to rfc2393bis that identifies that problem and recommends (c). (5) DEFLATE (RFC 2394) The discussion on using DEFLATE header and Adler32 checksum, which started in the town-hall meeting in the VPN workshop in January 2000, continued. In a straw-poll, _all_ implementors indicated support for NOT including the extra information. Roy, could you please issue rfc2394bis that reflects that consensus? === eom === From owner-ipsec@lists.tislabs.com Mon Oct 2 08:26:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17146; Mon, 2 Oct 2000 08:26:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07322 Mon, 2 Oct 2000 10:09:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <14805.3467.20133.51811@thomasm-u1.cisco.com> References: <20000927085920.B11807@blackbird.extern.uni-ulm.de> <14805.3467.20133.51811@thomasm-u1.cisco.com> Date: Sat, 30 Sep 2000 16:10:26 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: ICMP "Destination unreachable" - should it be sent? Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, >Henry Spencer writes: > > On Wed, 27 Sep 2000, Stefan Schlott wrote: > > > ..."Destination Unreachable Message > > > Code 1 - communication with destination administratively prohibited" > > > Should this message be sent when a packet does not conform to the local > > > security policy database (spd), or should such packets be silently dis- > > > carded? > > > > The central question is whether the ICMP message is believable. > > > > If it will flow via an authenticated path (e.g. an IPsec tunnel) or via a > > physically-secure path (e.g. on the "interior" side of a security gateway, > > where plaintext communication is normal), then sending it is probably > > wise... although administrators might want to be able to control that. > > > > If it will flow via an insecure path, then what good is it? The receiver > > can't trust it to tell the truth. At most, it might give the receiver a > > hint that communications difficulties are occurring, but the receiver > > cannot trust that report without confirming it by other means. > > This strikes me as completely backward: the sender should *always* > send it. It is the *receiver's* job to determine whether it is > believable. Having the sender second guess what the receiver > should and should not discard sounds like a great way to cause > an interoperability deadlock. A receiving end system that has an IPsec Sg somewhere in front of it is not necessarily able to know whether the sender is a secure source. I interpret Henry's advice in the context of that SG, and there is seems appropriate. Steve From owner-ipsec@lists.tislabs.com Mon Oct 2 09:52:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18856; Mon, 2 Oct 2000 09:52:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07595 Mon, 2 Oct 2000 11:23:00 -0400 (EDT) Message-ID: <00b001c02c8f$536976e0$a432a8c0@qiang-ntdesk.ecutel.com> From: "Qiang Zhang" To: Subject: looking for "draft-ietf-ipsec-isakmp-mode-cfg" Date: Mon, 2 Oct 2000 11:39:25 -0500 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.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry have to send into the list, I am looking for a document which I couldn't find on the IETF ftp site, draft-ietf-ipsec-isakmp-mode-cfg-05.txt or alternative version, please send me a copy if possible. Thank you Qiang From owner-ipsec@lists.tislabs.com Mon Oct 2 11:06:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20403; Mon, 2 Oct 2000 11:06:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07876 Mon, 2 Oct 2000 12:53:06 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789207@md-exchange1.nai.com> From: "Mason, David" To: "'Qiang Zhang'" , ipsec@lists.tislabs.com Subject: RE: looking for "draft-ietf-ipsec-isakmp-mode-cfg" Date: Mon, 2 Oct 2000 10:01:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This brings up an important question that many people would probably like to know. Is there already or is there going to be a mailing list for the outlawed mode-cfg/xauth/hybrid protocols? Since these things were banished by someone(s) in the IETF management chain I assume the mailing list/working group for these items won't fall under the auspices of the IETF. One thing that was apparent at the VPN workshop is that these protocols aren't going to happen - they already have happened! Many vendors were testing these protocols and many of the vendors that weren't testing were seriously contemplating the possibility of supporting them in the future. Products from multiple vendors supporting these forbidden arts are already being shipped. Market forces being what they are, vendors just can't wait for the results of the IPSRA working group and are actively pursuing the alternative (now non-IETF) standards that currently exist. The IETF pretending that these protocols don't exist isn't going to make them go away but I suppose some people feel that sticking your head in the sand (and/or yelling really loudly) is the best way to deal with something you don't like. The IETF police will now be coming to take me away for mentioning the unmentionable :( -dave P.S.: Any volunteers for hosting the outlawed list? -----Original Message----- From: Qiang Zhang [mailto:qzhang@ecutel.com] Sent: Monday, October 02, 2000 12:39 PM To: ipsec@lists.tislabs.com Subject: looking for "draft-ietf-ipsec-isakmp-mode-cfg" Sorry have to send into the list, I am looking for a document which I couldn't find on the IETF ftp site, draft-ietf-ipsec-isakmp-mode-cfg-05.txt or alternative version, please send me a copy if possible. Thank you Qiang From owner-ipsec@lists.tislabs.com Mon Oct 2 12:25:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22439; Mon, 2 Oct 2000 12:25:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08276 Mon, 2 Oct 2000 14:24:33 -0400 (EDT) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Mon, 2 Oct 2000 20:11:18 +0300 (EET DST) From: Helger Lipmaa To: ipsec@lists.tislabs.com, coderpunks@toad.com Subject: Rijndael selected as AES Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See http://www.nist.gov/aes Helger From owner-ipsec@lists.tislabs.com Mon Oct 2 16:30:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28168; Mon, 2 Oct 2000 16:30:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08967 Mon, 2 Oct 2000 18:17:49 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14809.3097.165880.5474@thomasm-u1.cisco.com> Date: Mon, 2 Oct 2000 15:28:41 -0700 (PDT) To: Stephen Kent Cc: Michael Thomas , IP Security List Subject: Re: ICMP "Destination unreachable" - should it be sent? In-Reply-To: References: <20000927085920.B11807@blackbird.extern.uni-ulm.de> <14805.3467.20133.51811@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > > This strikes me as completely backward: the sender should *always* > > send it. It is the *receiver's* job to determine whether it is > > believable. Having the sender second guess what the receiver > > should and should not discard sounds like a great way to cause > > an interoperability deadlock. > > A receiving end system that has an IPsec Sg somewhere in front of it > is not necessarily able to know whether the sender is a secure > source. I interpret Henry's advice in the context of that SG, and > there is seems appropriate. I guess I'm being really dense -- or maybe I've missed something pertinent -- because I don't see the receiver's job any easier or harder because there is an upstream SG. The upstream SG may or may not filter ICMP, but that's just a normal firewallesque filtering decision, right? Maybe what I'm missing is what this has to do with IPsec per se. Mike From owner-ipsec@lists.tislabs.com Mon Oct 2 16:30:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28181; Mon, 2 Oct 2000 16:30:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09000 Mon, 2 Oct 2000 18:22:21 -0400 (EDT) Date: Mon, 2 Oct 2000 18:33:09 -0400 (EDT) From: Henry Spencer To: Michael Thomas cc: IP Security List Subject: Re: ICMP "Destination unreachable" - should it be sent? In-Reply-To: <14805.3467.20133.51811@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 29 Sep 2000, Michael Thomas wrote: > > The central question is whether the ICMP message is believable... > > If it will flow via an insecure path, then what good is it? The receiver > > can't trust it to tell the truth... > > This strikes me as completely backward: the sender should *always* > send it. It is the *receiver's* job to determine whether it is > believable. As already noted, the receiver might not have complete information. Arguably the sender should not send it if he *knows* it will go via an insecure path. However, on further analysis I see an inherent problem -- of a slightly different flavor -- in trying to be too smart here. The problem is that, as I briefly noted, such a message may well be useful as a hint, requiring confirmation from another source, but prompting the receiver to check with that source when it otherwise wouldn't think to. Given this, the sender should probably send regardless... although he should probably rate-limit the sending, in case the receiver is ignoring the messages. In particular, this strikes me as possibly part of a scalable solution for the problem of one end of an IPsec connection rebooting but not realizing it should inform the other end. The still-up end will be sending packets on IPsec SAs that the rebooted end no longer recognizes, and it is highly desirable for the rebooted end to have some way of notifying the still-up end that something is wrong. (The alternative is heartbeats, which scale poorly, require arbitrary patience settings, and can't tell the difference between link failure and loss of memory on the other end.) Authenticating this notification is difficult -- the rebooted end may not know enough to initiate an IKE negotiation -- but treating it as a (rate-limited!) hint minimizes the problems therefrom. (Of course, the receiver still needs to have some way of checking the hint, e.g. an IKE-level ping. That's the other part of the scalable solution.) > Having the sender second guess what the receiver > should and should not discard sounds like a great way to cause > an interoperability deadlock. We already have this problem, since it's easy to read RFC 2401's current wording (section 5.2.1, step 1) as forbidding notification altogether. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Oct 3 11:49:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26276; Tue, 3 Oct 2000 11:49:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11652 Tue, 3 Oct 2000 13:09:18 -0400 (EDT) Message-ID: From: "Joergensen, Michael" To: ipsec@lists.tislabs.com, coderpunks@toad.com Subject: RE: Rijndael selected as AES Date: Tue, 3 Oct 2000 10:18:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Has IANA assigned AES a number within the IPSec DOI? Like, DES is 3 and 3DES is 5. -Michael. -----Original Message----- From: Helger Lipmaa [mailto:helger@tml.hut.fi] Sent: 2. oktober 2000 19:11 To: ipsec@lists.tislabs.com; coderpunks@toad.com Subject: Rijndael selected as AES See http://www.nist.gov/aes Helger From owner-ipsec@lists.tislabs.com Tue Oct 3 11:49:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26301; Tue, 3 Oct 2000 11:49:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11660 Tue, 3 Oct 2000 13:09:56 -0400 (EDT) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Tue, 3 Oct 2000 16:10:26 +0300 (EET DST) From: Helger Lipmaa To: ipsec@lists.tislabs.com Subject: counter mode Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A submission of me, Phil Rogaway and David Wagner to the AES Symmetric Key Encryption Modes workshop is available from http://www.tml.hut.fi/~helger/papers/lrw00. There has been quite a lot of discussions and misunderstandings concerning this mode. We tried to outline why most of the perceived disadvantages are not valid. We also proposed the next somewhat foolproof usage scenario: sender keeps a N-bit nonce that he increases at every packet transmission. The actual counter is computed as N-bit nonce || 128-N bit block counter N=64 makes the most sense security-wise; in standard IPSEC context one could use N=32, where nonce = sequence number. So let's hope counter mode will be accepted as standard. I know that many people (also here) would love to incorporate it in their products. Helger From owner-ipsec@lists.tislabs.com Tue Oct 3 11:49:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26275; Tue, 3 Oct 2000 11:49:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11958 Tue, 3 Oct 2000 13:36:44 -0400 (EDT) Message-ID: <39DA1B01.F4C894B8@NORTELNETWORKS.COM> Date: Tue, 03 Oct 2000 13:44:33 -0400 From: "Marcus Leech" X-Mailer: Mozilla 4.73C-CCK-MCD [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: Rijndael selected as AES References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've asked IANA to make AES assignments for IKE/ISAKMP, and they have done so. See: http://www.isi.edu/in-notes/iana/assignments/ipsec-registry and http://www.isi.edu/in-notes/iana/assignments/isakmp-registry In order to prevent the kind of last-minute-scramble that AES has caused with respect to IANA assignments, I also got IANA to assign codepoints for the SHA2 algorithm, which will get announced in the coming months. NIST confirmed that it will have 3 different residue sizes: 256 bits 384 bits 512 bits Which, not surprisingly, correspond to the AES required key lengths. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Tue Oct 3 11:49:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26277; Tue, 3 Oct 2000 11:49:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11945 Tue, 3 Oct 2000 13:34:39 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Joergensen, Michael" Cc: ipsec@lists.tislabs.com, coderpunks@toad.com Subject: Re: Rijndael selected as AES Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Oct 2000 13:45:52 -0400 Message-Id: <20001003174556.0A5E335DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , " Joergensen, Michael" writes: >Has IANA assigned AES a number within the IPSec DOI? > >Like, DES is 3 and 3DES is 5. Yes! Marcus Leech made the request this morning; IANA responded in under two hours. See http://www.isi.edu/in-notes/iana/assignments/isakmp-registry for the values. (Note that there are also new values for SHA2-256, SHA2-384, and SHA2-512, the forthcoming new hash functions from NIST.) Btw -- where did you get 3 and 5? That URL lists 2 and 3. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Oct 3 12:00:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26634; Tue, 3 Oct 2000 12:00:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12017 Tue, 3 Oct 2000 13:51:27 -0400 (EDT) Message-Id: <200010031802.e93I1xl122853@thunk.east.sun.com> From: Bill Sommerfeld To: "Joergensen, Michael" cc: ipsec@lists.tislabs.com, coderpunks@toad.com Subject: Re: Rijndael selected as AES In-reply-to: Your message of "Tue, 03 Oct 2000 10:18:58 PDT." Reply-to: sommerfeld@East.Sun.COM Date: Tue, 03 Oct 2000 14:01:59 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you read the press release closely, it might be premature to assign a DOI number for "AES" (but not premature to assign one for "RIJNDAEL").. http://www.nist.gov/public_affairs/releases/aesq&a.htm 6. Is the AES now an official U.S. Government standard? No. NIST has simply announced the algorithm that will be formally proposed for incorporation in a new Draft Federal Information Processing Standard (FIPS) for public review and comment. Thereafter, the standard--revised, if appropriate - will be proposed to the Secretary of Commerce for adoption as an official Government standard. - Bill From owner-ipsec@lists.tislabs.com Tue Oct 3 12:10:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26939; Tue, 3 Oct 2000 12:10:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12056 Tue, 3 Oct 2000 14:05:00 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: sommerfeld@East.Sun.COM Cc: "Joergensen, Michael" , ipsec@lists.tislabs.com, coderpunks@toad.com Subject: Re: Rijndael selected as AES Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Oct 2000 14:16:22 -0400 Message-Id: <20001003181622.3688235DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200010031802.e93I1xl122853@thunk.east.sun.com>, Bill Sommerfeld wri tes: >If you read the press release closely, it might be premature to assign >a DOI number for "AES" (but not premature to assign one for >"RIJNDAEL").. > >http://www.nist.gov/public_affairs/releases/aesq&a.htm > > 6. Is the AES now an official U.S. Government standard? > > No. NIST has simply announced the algorithm that will be formally > proposed for incorporation in a new Draft Federal Information > Processing Standard (FIPS) for public review and comment. Thereafter, > the standard--revised, if appropriate - will be proposed to the > Secretary of Commerce for adoption as an official Government > standard. I think that that's activity at the paperwork layer. I don't think it affects us. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Oct 3 12:37:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27429; Tue, 3 Oct 2000 12:37:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12218 Tue, 3 Oct 2000 14:30:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 3 Oct 2000 14:32:45 -0400 To: Helger Lipmaa From: Stephen Kent Subject: Re: counter mode Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Helger, >A submission of me, Phil Rogaway and David Wagner to the AES Symmetric Key >Encryption Modes workshop is available from >http://www.tml.hut.fi/~helger/papers/lrw00. > >There has been quite a lot of discussions and misunderstandings concerning >this mode. We tried to outline why most of the perceived disadvantages are >not valid. We also proposed the next somewhat foolproof usage scenario: >sender keeps a N-bit nonce that he increases at every packet transmission. >The actual counter is computed as > > N-bit nonce || 128-N bit block counter > >N=64 makes the most sense security-wise; in standard IPSEC context one >could use N=32, where nonce = sequence number. > >So let's hope counter mode will be accepted as standard. I know that many >people (also here) would love to incorporate it in their products. I have some trouble reconciling your suggestion above with the proposal in the workshop paper. That paper seems to suggest a 64 bit counter value, followed by 64 zero bits, to form a 128-bit counter. Above, you seem to suggest a 32-bit counter transmitted with each packet, taken from the sequence number field, and a 96-bit block counter. You don't indicate whether this latter counter is purely intra-packet, or whether it is stateful for all packets received on an SA. The pipelining that is an attraction of counter mode can be effected so long as there is a part of the counter that generates enough key stream to cover the largest single packet, measured in the block size of the cipher. That part of the counter is purely internal to the endpoints and need not be transmitted, and thus need not waste any space in an encrypted packet. For example, 16 bits of counter are more than sufficient to cover a max size IP datagram, using an 8 or 16 byte codebook. If this value is purely intra-packet, then there is no need to maintain state for it at sender or receiver, right? That's why I raise the question about the size of the block counter above, and ask whether it is stateful. I get the feeling (in part from your paper) that you might view this latter value as stateful, but that seems to add unnecessary complexity to each end. The 32-bit per-packet counter one gets from the ESP sequence number is nominally big enough for IPsec use of this mode, since we don't allow the counter to cycle, and the creation of a new SA with a new key avoids compromise in depth concerns. But, if we want to, one could carry additional counter bits or even an explicit IV, just as we do for CBC mode today (so long as there is confidence that the IV will be unique on a per SA basis). Using the lengths of these field values, and if one needs a 128-bit counter value for AES the format might look like this: IV or high order cntr bits || ESP seq # || intra-packet cntr || zeros The IV or high order counter bits could be as few as 2 or as many as 8 bytes (we already accommodate 8-byte IVs for CBC), leaving the zero field to be 2-8 bytes. The use of a purely intra-packet counter allows all the performance benefits one wants from counter mode, but without devoting any per-packet space to carry the bits. Steve From owner-ipsec@lists.tislabs.com Tue Oct 3 12:45:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27579; Tue, 3 Oct 2000 12:45:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12289 Tue, 3 Oct 2000 14:43:13 -0400 (EDT) Message-Id: <3.0.5.32.20001003145959.007b9100@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 03 Oct 2000 14:59:59 -0400 To: ipsec@lists.tislabs.com From: Sheila Frankel Subject: Assigned Numbers for AES Cc: itojun@iijlab.net In-Reply-To: <10147.970549811@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Marcus Leech worked wonders, leaped tall buildings, and got IKE/DOI numbers assigned for AES and also for the upcoming SHA-2 algorithms. You can find them at: http://www.isi.edu/in-notes/iana/assignments/ipsec-registry (Phase 1): Encryption Algorithm Value Reference -------------------- ----- --------- AES-CBC 7 [Leech] Hash Algorithm Value References -------------- ----- ---------- SHA2-256 4 [Leech] SHA2-384 5 [Leech] SHA2-512 6 [Leech] http://www.isi.edu/in-notes/iana/assignments/isakmp-registry (Phase 2): Transform ID Value Reference ------------ ----- --------- AH_SHA2-256 5 [Leech] AH_SHA2-384 6 [Leech] AH_SHA2-512 7 [Leech] Transform ID Value Reference ------------ ----- --------- ESP_AES 12 [Leech] Sheila Frankel sheila.frankel@nist.gov From owner-ipsec@lists.tislabs.com Tue Oct 3 12:45:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27594; Tue, 3 Oct 2000 12:45:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12282 Tue, 3 Oct 2000 14:42:27 -0400 (EDT) Message-ID: <39DA2B30.4786A558@cyphers.net> Date: Tue, 03 Oct 2000 11:53:35 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Rijndael selected as AES References: <20001003174556.0A5E335DC2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Has it occurred to anyone the silliness of adding AES to IPsec/IKE without adding larger primes to IKE? There was a discussion in March on this list with regards to larger primes, but it died out around the time someone would need to have written a draft. I believe Tero did post the larger DH primes to the list. Any volunteers to write that up? "Steven M. Bellovin" wrote: > > In message , " > Joergensen, Michael" writes: > >Has IANA assigned AES a number within the IPSec DOI? > > > >Like, DES is 3 and 3DES is 5. > > Yes! Marcus Leech made the request this morning; IANA responded in > under two hours. See http://www.isi.edu/in-notes/iana/assignments/isakmp-registry > for the values. (Note that there are also new values for SHA2-256, > SHA2-384, and SHA2-512, the forthcoming new hash functions from NIST.) > [..] -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Tue Oct 3 14:16:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00310; Tue, 3 Oct 2000 14:16:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12780 Tue, 3 Oct 2000 16:05:05 -0400 (EDT) From: Dan McDonald Message-Id: <200010032016.e93KGIv16481@kebe.Eng.Sun.COM> Subject: AES and block size? To: ipsec@lists.tislabs.com Date: Tue, 3 Oct 2000 13:16:18 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IKE supports negotiation or proposal of key size. It doesn't support an abstraction like RESPONDER-LIFETIME. IKE doesn't at all support negotiation of block size. AES (e.g. Rijndael) has variable block size. We can: 1.) Add a block size attribute. 2.) Pick a block size. I'm sure the AES draft will address this, right? (I hope we pick something quickly and stick to it - I have PF_KEY mods that depend on the answer.) And since I'm on the subject, what do I do with IKE in the face of "I'm willing to support multiple keysizes"? Do I send multiple transforms with the only difference being different keysize attribute values? Or do I just pick one and try again later? Thanks, Dan From owner-ipsec@lists.tislabs.com Tue Oct 3 15:06:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01604; Tue, 3 Oct 2000 15:06:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12898 Tue, 3 Oct 2000 16:55:23 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789208@md-exchange1.nai.com> From: "Mason, David" To: "'wprice@cyphers.net'" , ipsec@lists.tislabs.com Subject: RE: Rijndael selected as AES Date: Tue, 3 Oct 2000 14:04:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the larger MODP DH groups that Tero had posted, the most/least significant 64 bits are set in the prime. It's been suggested to me that having the most/least significant 128 bits set may allow certain optimizations on CPUs with a larger word size. -dave -----Original Message----- From: Will Price [mailto:wprice@cyphers.net] Sent: Tuesday, October 03, 2000 2:54 PM To: ipsec@lists.tislabs.com Subject: Re: Rijndael selected as AES Has it occurred to anyone the silliness of adding AES to IPsec/IKE without adding larger primes to IKE? There was a discussion in March on this list with regards to larger primes, but it died out around the time someone would need to have written a draft. I believe Tero did post the larger DH primes to the list. Any volunteers to write that up? "Steven M. Bellovin" wrote: > > In message , " > Joergensen, Michael" writes: > >Has IANA assigned AES a number within the IPSec DOI? > > > >Like, DES is 3 and 3DES is 5. > > Yes! Marcus Leech made the request this morning; IANA responded in > under two hours. See http://www.isi.edu/in-notes/iana/assignments/isakmp-registry > for the values. (Note that there are also new values for SHA2-256, > SHA2-384, and SHA2-512, the forthcoming new hash functions from NIST.) > [..] -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Tue Oct 3 15:59:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02658; Tue, 3 Oct 2000 15:59:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13001 Tue, 3 Oct 2000 17:30:14 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: , Subject: RE: Rijndael selected as AES Date: Tue, 3 Oct 2000 17:33:44 -0400 Message-Id: <001301c02d81$9bfa30f0$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <39DA2B30.4786A558@cyphers.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Has it occurred to anyone the silliness of adding AES to > IPsec/IKE without > adding larger primes to IKE? There was a discussion in March > on this list > with regards to larger primes, but it died out around the time someone > would need to have written a draft. I believe Tero did post > the larger DH > primes to the list. Any volunteers to write that up? Will, I'm not sure that is so silly. We did an analysis (based on the data in Hillarie's paper), which suggested that DH group 5 & 3DES have sufficient strength to provide protection against brute force in the long term. The greatest benefit we will derive from AES is performance: 3DES security at DES speed. Just because AES will have even greater strength than 3DES doesn't mean we need to match that strength in the DH computation at a huge performance cost. The other concern is entropy. Yes, the large key size means that some bits in the key will be correlated, but that shouldn't be a problem if you trust your prf function. You would probably derive a greater benefit from upgrading your prf than from increasing the group size. Of course it doesn't do any harm to write up the additional groups in a draft, but I don't think we want to encourage people to actually use them for most real-world situations. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Oct 3 16:02:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02720; Tue, 3 Oct 2000 16:02:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13073 Tue, 3 Oct 2000 17:49:53 -0400 (EDT) Message-Id: <200010032200.e93M0Ql123288@thunk.east.sun.com> From: Bill Sommerfeld To: Stephen Kent cc: Helger Lipmaa , ipsec@lists.tislabs.com Subject: Re: counter mode In-reply-to: Your message of "Tue, 03 Oct 2000 14:32:45 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Tue, 03 Oct 2000 18:00:26 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For example, 16 bits of counter are more than > sufficient to cover a max size IP datagram, using an 8 or 16 byte > codebook. IPv6 jumbograms can (theoretically) be up to 2**32 bytes long. With a 128-bit block size, this requires ~25 bits of intra-block counter, but we might as well reserve 32 bits.. > IV or high order cntr bits || ESP seq # || intra-packet cntr || zeros I'd put the intra-packet counter in the low end since this make things easier in (big endian) 64-bit land and not appreciably harder for little-endian systems. IV/high order bits || ESP seq # || zeros || intrapacket cntr To be space/bandwidth efficient, I'd be inclined to leave out the IV entirely and perhaps just use the SPI in the high order bits, but I'm not sure if that's cryptographically weak... - Bill From owner-ipsec@lists.tislabs.com Tue Oct 3 17:13:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04203; Tue, 3 Oct 2000 17:13:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13297 Tue, 3 Oct 2000 19:11:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200010032200.e93M0Ql123288@thunk.east.sun.com> References: <200010032200.e93M0Ql123288@thunk.east.sun.com> Date: Tue, 3 Oct 2000 19:24:33 -0400 To: sommerfeld@East.Sun.COM From: Stephen Kent Subject: Re: counter mode Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill, I like using the low order 32 bits for an intra-packet counter, to accommodate ultra-jumbograms fro IP v6. Using the SPI as part of the counter is not equivalent to an IV or high order counter, because it is constant for all packets on an SA. Steve From owner-ipsec@lists.tislabs.com Tue Oct 3 22:55:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10408; Tue, 3 Oct 2000 22:55:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA13876 Wed, 4 Oct 2000 00:32:49 -0400 (EDT) Message-ID: <002801c02dbd$cc4de620$8a1b6e0a@jariws1.arenanet.fi> From: "Jari Arkko" To: "Dan McDonald" , Subject: Re: AES and block size? Date: Wed, 4 Oct 2000 07:44:36 +0300 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.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan writes: >And since I'm on the subject, what do I do with IKE in the face of "I'm >willing to support multiple keysizes"? Do I send multiple transforms with >the only difference being different keysize attribute values? Or do I just >pick one and try again later? My system has the possibility to configure the min/max limits for key size. I intersect these with the native algorithm limits, and get the final range. If more than one possible size remains, then I send two transforms, one for the smallest possible key size, one for the largest. It's not a perfect scheme but it seems to work most of the time. (A horrible idea: send a transform for each key size 40, 48, ..., 448 - or redo the IKE negotiations that many times...) Jari Arkko Ericsson P.S. Variable keysize support seems still somewhat rare, even with people who have algorithms like Blowfish. Many of them can only handle those at one key length. From owner-ipsec@lists.tislabs.com Wed Oct 4 09:48:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24991; Wed, 4 Oct 2000 09:48:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15638 Wed, 4 Oct 2000 11:15:05 -0400 (EDT) Message-ID: <079201c02e20$931a7630$a432a8c0@qiang-ntdesk.ecutel.com> From: "Qiang Zhang" To: Subject: [ipsec] IPSec implementations possible on handheld OS? Date: Wed, 4 Oct 2000 11:31:40 -0500 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.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I am wondering if there is any implemenation of the IPSec/IKE on the OSes for handheld, e.g. Palm OS, WinCE. what could possibly be the constraints? Futher I guess I have a suggestion to the email list manager, it would be good to automatically put a tag in the subject, such as [ipsec], so that I could easily sort the messages :) Thank you Qiang From owner-ipsec@lists.tislabs.com Wed Oct 4 09:48:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25000; Wed, 4 Oct 2000 09:48:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15679 Wed, 4 Oct 2000 11:23:10 -0400 (EDT) Message-Id: <200010031928.MAA20369@gallium.network-alchemy.com> To: Sheila Frankel cc: ipsec@lists.tislabs.com, itojun@iijlab.net Subject: Re: Assigned Numbers for AES In-Reply-To: Message from Sheila Frankel of "Tue, 03 Oct 2000 14:59:59 EDT." <3.0.5.32.20001003145959.007b9100@email.nist.gov> Date: Tue, 03 Oct 2000 12:28:42 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FYI, Quite a few vendors are already using the value (5) for AH with RIPEMD-160. I'd recommend we start with (6) for the AES values. Derrell From owner-ipsec@lists.tislabs.com Wed Oct 4 09:48:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25004; Wed, 4 Oct 2000 09:48:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15721 Wed, 4 Oct 2000 11:24:09 -0400 (EDT) From: ark@eltex.ru Date: Wed, 4 Oct 2000 13:52:14 +0400 Message-Id: <200010040952.NAA31814@paranoid.alpha.int> Organization: "Klingon Imperial Intelligence Service" Subject: Re: Assigned Numbers for AES To: sheila.frankel@nist.gov Cc: ipsec@lists.tislabs.com, itojun@iijlab.net Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- nuqneH, BTW i wonder why russian GOST algorithms (encryption and hash function, the only ones here that can get goverment certification required by many institutions) do not have any ANs.. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQCVAwUBOdr9zqH/mIJW9LeBAQGFgAQAoQCWrTRUNtAqjxJyB/SeOer20eIxerJA vgrGzj+ZRdWG+ZvoztmEDK88SJlnk6SNxUXddsYOT54STzfCzr1IbADvtAgPBh1n hJ5numBIaIxEeKkkWicRA1atfm4c9l2aqSTb3O0X41H3G+HZxhCO5WLgEDL+X7Dy VtLmYYu8CiY= =RaVl -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Oct 4 09:48:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25031; Wed, 4 Oct 2000 09:48:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15682 Wed, 4 Oct 2000 11:23:12 -0400 (EDT) Date: Tue, 3 Oct 2000 16:10:35 -0400 (EDT) From: spiff To: "Steven M. Bellovin" cc: "Joergensen, Michael" , ipsec@lists.tislabs.com, coderpunks@toad.com Subject: Re: Rijndael selected as AES In-Reply-To: <20001003174556.0A5E335DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Btw -- where did you get 3 and 5? That URL lists 2 and 3. > obviously encrypted... From owner-ipsec@lists.tislabs.com Wed Oct 4 09:50:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25079; Wed, 4 Oct 2000 09:50:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15670 Wed, 4 Oct 2000 11:22:10 -0400 (EDT) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Tue, 3 Oct 2000 22:26:04 +0300 (EET DST) From: Helger Lipmaa To: Stephen Kent cc: ipsec@lists.tislabs.com, Phillip Rogaway , David Wagner Subject: Re: counter mode In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 3 Oct 2000, Stephen Kent wrote: > Helger, > > >A submission of me, Phil Rogaway and David Wagner to the AES Symmetric Key > >Encryption Modes workshop is available from > >http://www.tml.hut.fi/~helger/papers/lrw00. > > > >There has been quite a lot of discussions and misunderstandings concerning > >this mode. We tried to outline why most of the perceived disadvantages are > >not valid. We also proposed the next somewhat foolproof usage scenario: > >sender keeps a N-bit nonce that he increases at every packet transmission. > >The actual counter is computed as > > > > N-bit nonce || 128-N bit block counter > > > >N=64 makes the most sense security-wise; in standard IPSEC context one > >could use N=32, where nonce = sequence number. > > > >So let's hope counter mode will be accepted as standard. I know that many > >people (also here) would love to incorporate it in their products. Stephen, > I have some trouble reconciling your suggestion above with the > proposal in the workshop paper. That paper seems to suggest a 64 bit > counter value, followed by 64 zero bits, to form a 128-bit counter. Paper is correct, but may be my explanation here seemt to be unclear (sorry for confusion - just look at the paper). We suggest 64-bit incremented 'nonce' concatenated with 64-bit intra-sequence block counter. The only reason why I generalized the first 64 to N was the RFC 2406 which specifies: 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. So, in the case of IPSec it is _perfectly_ ok to use the sequence number as a nonce and then concatenate it with the packet counter. However, the 32-bit sequence number does really not make any sence, as does not the 64-bit packet counter. Both should be 64-bit long. The 32+96 would just not break the standard _and_ not require any additional state elements to be maintained. > The 32-bit per-packet counter one gets from the ESP sequence number > is nominally big enough for IPsec use of this mode, since we don't > allow the counter to cycle, and the creation of a new SA with a new > key avoids compromise in depth concerns. But, if we want to, one > could carry additional counter bits or even an explicit IV, just as > we do for CBC mode today (so long as there is confidence that the IV > will be unique on a per SA basis). > > Using the lengths of these field values, and if one needs a 128-bit > counter value for AES the format might look like this: > > IV or high order cntr bits || ESP seq # || intra-packet cntr || zeros > > The IV or high order counter bits could be as few as 2 or as many as > 8 bytes (we already accommodate 8-byte IVs for CBC), leaving the zero > field to be 2-8 bytes. The use of a purely intra-packet counter > allows all the performance benefits one wants from counter mode, but > without devoting any per-packet space to carry the bits. What you proposed here is also a valid use, but requires (a somewhat more careful) maintaining of separate status information. On the other hand, it has the asset that one could send more than 2^32 sequences by using this mechanism. [Note that intra-packet counter also makes the mode also more foolproof, since a unique sequence number || unique block counter (both numbers are implicitly/explicitly maintained somehow in most of the IPSec implementations!) results in a unique counter number without any additional effort from the user] > Steve Thanks for comments, Helger http://www.tml.hut.fi/~helger From owner-ipsec@lists.tislabs.com Wed Oct 4 10:10:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25409; Wed, 4 Oct 2000 10:10:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16009 Wed, 4 Oct 2000 12:01:58 -0400 (EDT) Message-ID: <39DB5708.F9BD88C6@certicom.com> Date: Wed, 04 Oct 2000 12:12:57 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Qiang Zhang CC: ipsec@lists.tislabs.com Subject: Re: [ipsec] IPSec implementations possible on handheld OS? References: <5C4CDFF322E6B8228525696E00585AD7.00586E3D8525696E@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please check this link - http://www.certicom.com/vpn Yuri Poeluev Certicom Corp. Qiang Zhang wrote: > Hello, > > I am wondering if there is any implemenation of the IPSec/IKE on the OSes > for handheld, e.g. Palm OS, WinCE. what could possibly be the constraints? > > Futher I guess I have a suggestion to the email list manager, it would be > good to automatically put a tag in the subject, such as [ipsec], so that I > could easily sort the messages :) > > Thank you > > Qiang From owner-ipsec@lists.tislabs.com Wed Oct 4 10:17:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25541; Wed, 4 Oct 2000 10:17:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16074 Wed, 4 Oct 2000 12:14:02 -0400 (EDT) Date: Wed, 4 Oct 2000 12:24:56 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Assigned Numbers for AES In-Reply-To: <200010031928.MAA20369@gallium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 3 Oct 2000, Derrell D. Piper wrote: > Quite a few vendors are already using the value (5) for AH with RIPEMD-160. That's their mistake, a clear violation of the standard, since 5 is not in the private-use part of the number space. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Oct 4 10:52:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26258; Wed, 4 Oct 2000 10:52:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16092 Wed, 4 Oct 2000 12:14:37 -0400 (EDT) Date: Wed, 4 Oct 2000 12:25:32 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Assigned Numbers for AES In-Reply-To: <200010040952.NAA31814@paranoid.alpha.int> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 4 Oct 2000 ark@eltex.ru wrote: > BTW i wonder why russian GOST algorithms (encryption and hash function, > the only ones here that can get goverment certification required by many > institutions) do not have any ANs.. It probably just means that nobody has asked for them. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Oct 4 11:25:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27126; Wed, 4 Oct 2000 11:25:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16065 Wed, 4 Oct 2000 12:11:12 -0400 (EDT) To: "Qiang Zhang" cc: ipsec@lists.tislabs.com In-reply-to: qzhang's message of Wed, 04 Oct 2000 11:31:40 EST. <079201c02e20$931a7630$a432a8c0@qiang-ntdesk.ecutel.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [ipsec] IPSec implementations possible on handheld OS? From: itojun@iijlab.net Date: Thu, 05 Oct 2000 01:22:00 +0900 Message-ID: <4574.970676520@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I am wondering if there is any implemenation of the IPSec/IKE on the OSes >for handheld, e.g. Palm OS, WinCE. what could possibly be the constraints? nowadays you can run NetBSD (UNIX operating system) on WinCE devices, so there's no problem. you just need a right software :-) http://www.netbsd.org/Ports/hpcmips/ itojun From owner-ipsec@lists.tislabs.com Wed Oct 4 15:57:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03869; Wed, 4 Oct 2000 15:57:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17089 Wed, 4 Oct 2000 17:34:32 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Derrell D. Piper'" Cc: Subject: RE: Assigned Numbers for AES Date: Wed, 4 Oct 2000 17:38:03 -0400 Message-Id: <000e01c02e4b$613b1220$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <200010031928.MAA20369@gallium.network-alchemy.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hey, you guys set the precedent (Config Mode, Hybrid, etc.). You can't have it both ways... Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell D. Piper > Sent: Tuesday, October 03, 2000 3:29 PM > To: Sheila Frankel > Cc: ipsec@lists.tislabs.com; itojun@iijlab.net > Subject: Re: Assigned Numbers for AES > > > FYI, > > Quite a few vendors are already using the value (5) for AH > with RIPEMD-160. > I'd recommend we start with (6) for the AES values. > > Derrell > From owner-ipsec@lists.tislabs.com Wed Oct 4 18:18:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06914; Wed, 4 Oct 2000 18:18:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17574 Wed, 4 Oct 2000 20:23:44 -0400 (EDT) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Derrell D. Piper'" , "Andrew Krywaniuk" Cc: Subject: RE: Assigned Numbers for AES Date: Wed, 4 Oct 2000 20:27:16 -0400 Message-Id: <000f01c02e63$04188650$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <200010042225.PAA82791@gallium.network-alchemy.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hey, I would prefer that the IANA did make exceptions in cases where there were multiple deployed implementations. It seems silly (or rather excessively bureaucractic) to punish implementers of a widely used protocol because of a technicality. However, you'll understand if those of us who implemented config mode but not ripemd don't feel any sympathy... Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Derrell D. Piper [mailto:ddp@cips.nokia.COM] > Sent: Wednesday, October 04, 2000 6:26 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Derrell D. Piper'; ipsec@lists.tislabs.com > Subject: Re: Assigned Numbers for AES > > > Andrew, > > Fair enough, I don't really care which way we decide. I was > just pointing > out, as you have in the past, that I was aware of fielded > implementations > already using one of the new numbers assigned to AES. (I > know there are more > than one out there because I've successfully tested our > RIPEMD support with > other vendors.) I've already updated our code to use a > private value (249) > and am working under the assumption that the IANA allocations > are a done deal. > > Derrell > > From owner-ipsec@lists.tislabs.com Thu Oct 5 00:58:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18426; Thu, 5 Oct 2000 00:58:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18742 Thu, 5 Oct 2000 02:20:10 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: "Qiang Zhang" cc: ipsec@lists.tislabs.com Message-ID: <8525696F.0023BD22.00@smtpmail.certicom.com> Date: Wed, 4 Oct 2000 23:22:21 -0700 Subject: Re: [ipsec] IPSec implementations possible on handheld OS? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk www.certicom.com/vpn fully standards compliant IPSec client in beta. cheers - john "Qiang Zhang" on 10/04/2000 09:31:40 To: ipsec@lists.tislabs.com cc: (bcc: John Harleman/Certicom) Subject: [ipsec] IPSec implementations possible on handheld OS? Hello, I am wondering if there is any implemenation of the IPSec/IKE on the OSes for handheld, e.g. Palm OS, WinCE. what could possibly be the constraints? Futher I guess I have a suggestion to the email list manager, it would be good to automatically put a tag in the subject, such as [ipsec], so that I could easily sort the messages :) Thank you Qiang From owner-ipsec@lists.tislabs.com Thu Oct 5 03:51:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24939; Thu, 5 Oct 2000 03:51:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA19239 Thu, 5 Oct 2000 05:45:09 -0400 (EDT) Reply-To: From: "Rohit Khosla" To: Subject: IPSec test suite Date: Thu, 5 Oct 2000 15:37:23 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am looking for some freely available test tool or test suite to test the IPSec implementation. Thanks, Rohit. From owner-ipsec@lists.tislabs.com Thu Oct 5 06:15:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27812; Thu, 5 Oct 2000 06:15:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19482 Thu, 5 Oct 2000 08:00:24 -0400 (EDT) Message-Id: From: Caerwyn Pearce Date: Thu, 5 Oct 2000 14:05:54 +0200 To: ipsec@lists.tislabs.com Subject: RE: IPSec test suite MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Secure Messaging /320000000/320101050/320101051/320200319/ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA19479 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure whether this is what you're looking for but there are certainly some test sites available. Try these www.nist.org www.ire.com www.vpnforum.org http://www.rsasecurity.com/ http://isakmp-test.ssh.fi/ http://ipsec-wit.antd.nist.gov/ I've only used the last one. Caerwyn Pearce -----Original Message----- From: rkhosla@ishoni.com [mailto:rkhosla@ishoni.com] Sent: Thu 05 Oct 2000 13:50 To: ipsec@lists.tislabs.com Subject: IPSec test suite Hi, I am looking for some freely available test tool or test suite to test the IPSec implementation. Thanks, Rohit. From owner-ipsec@lists.tislabs.com Thu Oct 5 06:24:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27948; Thu, 5 Oct 2000 06:24:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19533 Thu, 5 Oct 2000 08:25:02 -0400 (EDT) Message-Id: <200010051236.IAA32342@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Assigned Numbers for AES In-Reply-To: Your message of "Wed, 04 Oct 2000 20:27:16 EDT." <000f01c02e63$04188650$d23e788a@andrewk3.ca.newbridge.com> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Oct 2000 08:36:29 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "andrew" == andrew krywaniuk writes: andrew> Hey, I would prefer that the IANA did make exceptions in cases where there andrew> were multiple deployed implementations. It seems silly (or rather andrew> excessively bureaucractic) to punish implementers of a widely used protocol andrew> because of a technicality. No, it isn't a technicality. It is called interoperability. If you don't want that, then don't implement IETF protocols at all. The mechanism for testing and deploying extensions is well documented, but apparently many developers just won't read that section. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Thu Oct 5 07:28:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29074; Thu, 5 Oct 2000 07:28:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19793 Thu, 5 Oct 2000 09:29:10 -0400 (EDT) Message-Id: <200010042225.PAA82791@gallium.network-alchemy.com> To: andrew.krywaniuk@alcatel.com cc: "'Derrell D. Piper'" , ipsec@lists.tislabs.com Subject: Re: Assigned Numbers for AES In-Reply-To: Message from "Andrew Krywaniuk" of "Wed, 04 Oct 2000 17:38:03 EDT." <000e01c02e4b$613b1220$d23e788a@andrewk3.ca.newbridge.com> Date: Wed, 04 Oct 2000 15:25:38 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, Fair enough, I don't really care which way we decide. I was just pointing out, as you have in the past, that I was aware of fielded implementations already using one of the new numbers assigned to AES. (I know there are more than one out there because I've successfully tested our RIPEMD support with other vendors.) I've already updated our code to use a private value (249) and am working under the assumption that the IANA allocations are a done deal. Derrell From owner-ipsec@lists.tislabs.com Thu Oct 5 07:32:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29155; Thu, 5 Oct 2000 07:32:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19815 Thu, 5 Oct 2000 09:30:09 -0400 (EDT) Message-Id: <200010050244.TAA30330@road.xisp.net> To: ipsec@lists.tislabs.com Cc: linux-ipsec@clinet.fi Subject: A few words of wisdom for us IETF folks Reply-To: hugh@xisp.net Date: Wed, 04 Oct 2000 19:44:18 -0700 From: Hugh Daniel Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- "The complexity of the recent IETF standards results in a lot of complexity in the code which increases the potential for bugs (security related or otherwise). Standards bloat, in combination with feeping creaturism demanded of us by our funders or users, results in software bloat which is probably our most significant challenge." -- David Conrad http://www.linuxsecurity.com/feature_stories/conrad_vixie-5.html -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOdvq5lZpdJR7FBQRAQGN9gP9GXyzIaFig77lXpr2BrTlf/DLGLa+c5lJ +T2g3sBpGO6m4Kai9JtuFOeupbiN/9SiDcL9crqNcOsTxgQLNuFCJseR5c2fmnB4 hjZNDTMTxzr071LzrML7173dASeWy8/IJo/F3XIsEw7vZ7UucGuUj59WUNvZv5BR +jyJ7GGc2rA= =bHV5 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Oct 5 07:33:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29169; Thu, 5 Oct 2000 07:33:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19871 Thu, 5 Oct 2000 09:37:45 -0400 (EDT) Message-Id: <200010051350.PAA99278@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Qiang Zhang" cc: ipsec@lists.tislabs.com Subject: Re: [ipsec] IPSec implementations possible on handheld OS? In-reply-to: Your message of Wed, 04 Oct 2000 11:31:40 CDT. <079201c02e20$931a7630$a432a8c0@qiang-ntdesk.ecutel.com> Date: Thu, 05 Oct 2000 15:50:13 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I am wondering if there is any implemenation of the IPSec/IKE on the OSes for handheld, e.g. Palm OS, WinCE. what could possibly be the constraints? => there is a Psion at 5 meters from me with a full IPsec/IKE on it then obviously this exists! Francis.Dupont@enst-bretagne.fr (at IPv6 ETSI bake-off, ie. there is an IPv6 on it too) From owner-ipsec@lists.tislabs.com Thu Oct 5 08:11:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29937; Thu, 5 Oct 2000 08:11:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20074 Thu, 5 Oct 2000 10:14:41 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A97F2@eseis06nok> To: ipsec@lists.tislabs.com Subject: Notification payloads IV (Repost) Date: Thu, 5 Oct 2000 17:26:01 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could someone help me with that or pint me a place to find how it's done? I can't find a way to make it work. Only works in Quaick mode but not in Main mode. Heeelp! Toni -----Original Message----- From: EXT antonio.barrera@nokia.com [mailto:antonio.barrera@nokia.com] Sent: 02. October 2000 14:02 To: ipsec@lists.tislabs.com Subject: Notification payloads IV How is the IV computed for notification messages in IKE Phase I? I know in phase II it's computed: "using the hash of a concatenation of the last Phase I CBC block concatenated and the message id in the ISAKMP header" (RFC 2409 Apendic B) However, I'm not really sure how to do it for Phase I when encryption is applied (messages 5 and 6) and an error is found. Is it explained somewhere? Toni From owner-ipsec@lists.tislabs.com Thu Oct 5 08:53:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04776; Thu, 5 Oct 2000 08:53:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20222 Thu, 5 Oct 2000 10:50:05 -0400 (EDT) Message-ID: <39DC9811.53A5AFA2@F-Secure.com> Date: Thu, 05 Oct 2000 18:02:42 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Larger DH groups? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there plans/interest in specifying larger standard DH groups, now that the AES has been chosen? If so, what sizes would be appropriate? Tero earlier posted groups of 2000-4000 bits, the draft for AES talks about 14000. Anybody know just how slow would 14000 bit modulus be? (I can guess it's something between extremely slow and ridiculously slow..) What about the speed of a 500 bit EC2N? Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Oct 5 11:52:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08531; Thu, 5 Oct 2000 11:52:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20655 Thu, 5 Oct 2000 13:25:13 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: Ari Huttunen cc: ipsec Message-ID: <8525696F.005896D3.00@smtpmail.certicom.com> Date: Thu, 5 Oct 2000 12:08:23 -0400 Subject: Re: Larger DH groups? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take about 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take about 25 times as long as 160-bit ECC. We don't have implementations of 15000-bit DH but we do have 512-bit ECDH and our performance roughly follows the estimates. (In fact we're in the process of adding 512-bit curves to our "Additional ECC groups for IKE" draft so that it has complete AES support.) Best regards. Simon S. Blake-Wilson Certicom Corp. Ari Huttunen on 10/05/2000 11:02:42 AM To: ipsec cc: (bcc: Simon Blake-Wilson/Certicom) Subject: Larger DH groups? Are there plans/interest in specifying larger standard DH groups, now that the AES has been chosen? If so, what sizes would be appropriate? Tero earlier posted groups of 2000-4000 bits, the draft for AES talks about 14000. Anybody know just how slow would 14000 bit modulus be? (I can guess it's something between extremely slow and ridiculously slow..) What about the speed of a 500 bit EC2N? Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Oct 5 12:41:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09476; Thu, 5 Oct 2000 12:41:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20919 Thu, 5 Oct 2000 14:25:36 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 05 Oct 2000 12:36:18 -0600 From: "Hilarie Orman" To: , Cc: Subject: Re: Larger DH groups? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA20916 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Support for 256-bit keys implies a strong belief in quantum computing (mentioned positively at the NIST press conference). Hilarie >>> "Simon Blake-Wilson" 10/05/00 10:08AM >>> Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take about 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take about 25 times as long as 160-bit ECC. We don't have implementations of 15000-bit DH but we do have 512-bit ECDH and our performance roughly follows the estimates. (In fact we're in the process of adding 512-bit curves to our "Additional ECC groups for IKE" draft so that it has complete AES support.) Best regards. Simon S. Blake-Wilson Certicom Corp. Ari Huttunen on 10/05/2000 11:02:42 AM To: ipsec cc: (bcc: Simon Blake-Wilson/Certicom) Subject: Larger DH groups? Are there plans/interest in specifying larger standard DH groups, now that the AES has been chosen? If so, what sizes would be appropriate? Tero earlier posted groups of 2000-4000 bits, the draft for AES talks about 14000. Anybody know just how slow would 14000 bit modulus be? (I can guess it's something between extremely slow and ridiculously slow..) What about the speed of a 500 bit EC2N? Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Oct 5 13:12:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10539; Thu, 5 Oct 2000 13:12:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20971 Thu, 5 Oct 2000 14:52:24 -0400 (EDT) Message-Id: <200010051858.LAA10296@potassium.network-alchemy.com> To: "Simon Blake-Wilson" cc: Ari Huttunen , ipsec Subject: Re: Larger DH groups? In-reply-to: Your message of "Thu, 05 Oct 2000 12:08:23 EDT." <8525696F.005896D3.00@smtpmail.certicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10293.970772296.1@network-alchemy.com> Date: Thu, 05 Oct 2000 11:58:16 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While updating the "Additional ECC groups for IKE" draft can you unqualify your IP statement? Do you or do you not have patents that cover this? It would be nice if there was a one syllable response to the question "is a license from Certicom essential to implement these curves?" Also, in the AES assigned numbers thread it became obvious that certain vendors have been assigning numbers which are reserved to IANA to their own use of algorithms. I'd like to note that you are repeating this error in your draft and respectfully ask you to use numbers from the private use range for all the groups in this draft. Section 11.4 of RFC2409 describes the procedure necessary for you to follow to get IANA to assign number to you. Dan. On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take about > 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take > about 25 times as long as 160-bit ECC. We don't have implementations of > 15000-bit DH but we do have 512-bit ECDH and our performance roughly follows the > estimates. (In fact we're in the process of adding 512-bit curves to our > "Additional ECC groups for IKE" draft so that it has complete AES support.) > > Best regards. Simon > > S. Blake-Wilson > Certicom Corp. > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > To: ipsec > cc: (bcc: Simon Blake-Wilson/Certicom) > Subject: Larger DH groups? > > > > > Are there plans/interest in specifying larger standard DH groups, now that > the AES has been chosen? > > If so, what sizes would be appropriate? Tero earlier posted groups of > 2000-4000 bits, the draft for AES talks about 14000. Anybody know just > how slow would 14000 bit modulus be? (I can guess it's something between > extremely slow and ridiculously slow..) What about the speed of a 500 bit EC2N? > > Ari > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Oct 5 14:40:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12216; Thu, 5 Oct 2000 14:40:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21164 Thu, 5 Oct 2000 16:26:13 -0400 (EDT) Message-ID: <39DCE745.1D9D2205@cisco.com> Date: Thu, 05 Oct 2000 13:40:37 -0700 From: "David A. McGrew" X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Helger Lipmaa CC: ipsec@lists.tislabs.com Subject: Re: counter mode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Helder, Helger Lipmaa wrote: > > A submission of me, Phil Rogaway and David Wagner to the AES Symmetric Key > Encryption Modes workshop is available from > http://www.tml.hut.fi/~helger/papers/lrw00. good, I'm glad to see this proposal. I'll support it at the workshop. I've been experimenting with counter mode for IPSEC, and planning to produce an Internet Draft for counter mode AES, within the context of the Stream Cipher ESP (which I presented at the Pittsburgh IETF, but which didn't generate a lot of discussion - it's at http://search.ietf.org/internet-drafts/draft-mcgrew-ipsec-scesp-01.txt). I would be glad to hear your comments on this draft. > There has been quite a lot of discussions and misunderstandings concerning > this mode. We tried to outline why most of the perceived disadvantages are > not valid. > > We also proposed the next somewhat foolproof usage scenario: > sender keeps a N-bit nonce that he increases at every packet transmission. > The actual counter is computed as > > N-bit nonce || 128-N bit block counter > This makes sense. > N=64 makes the most sense security-wise; in standard IPSEC context one > could use N=32, where nonce = sequence number. > > So let's hope counter mode will be accepted as standard. I know that many > people (also here) would love to incorporate it in their products. > > Helger There are some attacks that are possible against counter mode (at least for some values of N and some key sizes) that are not possible against CBC mode: key collision attacks and time-memory tradeoff attacks. It is certainly possible to choose parameters to defend against these attacks, and we would need to do that in a standard. I spent some time thinking about such attacks, and the paper describing this work is online at http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf. David From owner-ipsec@lists.tislabs.com Thu Oct 5 17:13:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14962; Thu, 5 Oct 2000 17:13:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21504 Thu, 5 Oct 2000 18:29:24 -0400 (EDT) Message-Id: <200010052235.PAA12216@potassium.network-alchemy.com> To: "Simon Blake-Wilson" cc: Ari Huttunen , ipsec Subject: Re: Larger DH groups? In-reply-to: Your message of "Thu, 05 Oct 2000 18:12:03 EDT." <8525696F.0079E505.00@smtpmail.certicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12213.970785315.1@network-alchemy.com> Date: Thu, 05 Oct 2000 15:35:15 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well other companies have been able to give black and white answers. For instance Cisco's statement on VRRP: "Cisco believes that implementation of draft-ietf-vrrp-spec-05.txt will require a license to Cisco's patent #5,473,599. If this protocol is approved as an IETF standard, licenses will be available to any party on reasonable, nondiscriminatory terms for implentation of the protocol." Your statement is vague and heavily qualified, e.g. "if Certicom has patents or patents pending that are essential to implementation...." Why not just come out and say it? Do you? And are they? You "believe [you have] rights under patents and patents pending for techniques...." but you don't say whether it is necessary to use those techniques to implement your draft. That is extremely disingenuous. Regarding the numbers assigned. Yes, I know they were given out by IANA but IANA did not follow the "IANA Considerations" section for assignment of new numbers for new D-H groups. I brought it up with IANA but they apparently didn't recind them (yet). I'm asking you to just follow the rules like everyone else is supposed to. Those rules are described in section 11.4 of RFC2409. They are there for a reason. Dan. On Thu, 05 Oct 2000 18:12:03 EDT you wrote > Hi Dan, > > Ahh ... the eternal patent question. Unfortunately the patent system doesn't > allow the kind of black and white answer you're looking for. However I think >our > IPR statement is fairly clear that we believe we have patents and patent > applcations covering ECC. Our advice to anyone implementing ECC is to take a > license from Certicom :-). > > On the IANA issue. I believe all our numbers for ECC groups were assigned by > IANA as specified in RFC 2409. I believe the link to the numbers on the IANA > site is: > http://www.isi.edu/in-notes/iana/assignments/ipsec-registry. > > Best regards. Simon > > S. Blake-Wilson > Certicom Corp. > > > > > > Dan Harkins on 10/05/2000 02:58:16 PM > > To: Simon Blake-Wilson/Certicom@Certicom > cc: Ari Huttunen , ipsec m> > Subject: Re: Larger DH groups? > > > > > While updating the "Additional ECC groups for IKE" draft can you unqualify > your IP statement? Do you or do you not have patents that cover this? It > would be nice if there was a one syllable response to the question "is a > license from Certicom essential to implement these curves?" > > Also, in the AES assigned numbers thread it became obvious that certain > vendors have been assigning numbers which are reserved to IANA to their > own use of algorithms. I'd like to note that you are repeating this error > in your draft and respectfully ask you to use numbers from the private use > range for all the groups in this draft. Section 11.4 of RFC2409 describes > the procedure necessary for you to follow to get IANA to assign number to > you. > > Dan. > > On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > > > Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take > about > > 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take > > about 25 times as long as 160-bit ECC. We don't have implementations of > > 15000-bit DH but we do have 512-bit ECDH and our performance roughly follow >s > the > > estimates. (In fact we're in the process of adding 512-bit curves to our > > "Additional ECC groups for IKE" draft so that it has complete AES support.) > > > > Best regards. Simon > > > > S. Blake-Wilson > > Certicom Corp. > > > > > > > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > > > To: ipsec > > cc: (bcc: Simon Blake-Wilson/Certicom) > > Subject: Larger DH groups? > > > > > > > > > > Are there plans/interest in specifying larger standard DH groups, now that > > the AES has been chosen? > > > > If so, what sizes would be appropriate? Tero earlier posted groups of > > 2000-4000 bits, the draft for AES talks about 14000. Anybody know just > > how slow would 14000 bit modulus be? (I can guess it's something between > > extremely slow and ridiculously slow..) What about the speed of a 500 bit > EC2N? > > > > Ari > > > > -- > > Ari Huttunen phone: +358 9 859 900 > > Senior Software Engineer fax : +358 9 8599 0452 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security > > > > From owner-ipsec@lists.tislabs.com Thu Oct 5 18:05:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15864; Thu, 5 Oct 2000 18:05:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21715 Thu, 5 Oct 2000 19:43:42 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 05 Oct 2000 17:54:11 -0600 From: "Hilarie Orman" To: , , Subject: Re: Larger DH groups? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA21712 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If Certicom wants to hint at secret sauce, that's their right. In this case, all they can be saying is that they think the dish tastes better with their sauce, not that you can't make the dish without it. I'm vegetarian anyway. Hilarie >>> Dan Harkins 10/05/00 04:35PM >>> Well other companies have been able to give black and white answers. For instance Cisco's statement on VRRP: "Cisco believes that implementation of draft-ietf-vrrp-spec-05.txt will require a license to Cisco's patent #5,473,599. If this protocol is approved as an IETF standard, licenses will be available to any party on reasonable, nondiscriminatory terms for implentation of the protocol." Your statement is vague and heavily qualified, e.g. "if Certicom has patents or patents pending that are essential to implementation...." Why not just come out and say it? Do you? And are they? You "believe [you have] rights under patents and patents pending for techniques...." but you don't say whether it is necessary to use those techniques to implement your draft. That is extremely disingenuous. Regarding the numbers assigned. Yes, I know they were given out by IANA but IANA did not follow the "IANA Considerations" section for assignment of new numbers for new D-H groups. I brought it up with IANA but they apparently didn't recind them (yet). I'm asking you to just follow the rules like everyone else is supposed to. Those rules are described in section 11.4 of RFC2409. They are there for a reason. Dan. On Thu, 05 Oct 2000 18:12:03 EDT you wrote > Hi Dan, > > Ahh ... the eternal patent question. Unfortunately the patent system doesn't > allow the kind of black and white answer you're looking for. However I think >our > IPR statement is fairly clear that we believe we have patents and patent > applcations covering ECC. Our advice to anyone implementing ECC is to take a > license from Certicom :-). > > On the IANA issue. I believe all our numbers for ECC groups were assigned by > IANA as specified in RFC 2409. I believe the link to the numbers on the IANA > site is: > http://www.isi.edu/in-notes/iana/assignments/ipsec-registry. > > Best regards. Simon > > S. Blake-Wilson > Certicom Corp. > > > > > > Dan Harkins on 10/05/2000 02:58:16 PM > > To: Simon Blake-Wilson/Certicom@Certicom > cc: Ari Huttunen , ipsec m> > Subject: Re: Larger DH groups? > > > > > While updating the "Additional ECC groups for IKE" draft can you unqualify > your IP statement? Do you or do you not have patents that cover this? It > would be nice if there was a one syllable response to the question "is a > license from Certicom essential to implement these curves?" > > Also, in the AES assigned numbers thread it became obvious that certain > vendors have been assigning numbers which are reserved to IANA to their > own use of algorithms. I'd like to note that you are repeating this error > in your draft and respectfully ask you to use numbers from the private use > range for all the groups in this draft. Section 11.4 of RFC2409 describes > the procedure necessary for you to follow to get IANA to assign number to > you. > > Dan. > > On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > > > Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take > about > > 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take > > about 25 times as long as 160-bit ECC. We don't have implementations of > > 15000-bit DH but we do have 512-bit ECDH and our performance roughly follow >s > the > > estimates. (In fact we're in the process of adding 512-bit curves to our > > "Additional ECC groups for IKE" draft so that it has complete AES support.) > > > > Best regards. Simon > > > > S. Blake-Wilson > > Certicom Corp. > > > > > > > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > > > To: ipsec > > cc: (bcc: Simon Blake-Wilson/Certicom) > > Subject: Larger DH groups? > > > > > > > > > > Are there plans/interest in specifying larger standard DH groups, now that > > the AES has been chosen? > > > > If so, what sizes would be appropriate? Tero earlier posted groups of > > 2000-4000 bits, the draft for AES talks about 14000. Anybody know just > > how slow would 14000 bit modulus be? (I can guess it's something between > > extremely slow and ridiculously slow..) What about the speed of a 500 bit > EC2N? > > > > Ari > > > > -- > > Ari Huttunen phone: +358 9 859 900 > > Senior Software Engineer fax : +358 9 8599 0452 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security > > > > From owner-ipsec@lists.tislabs.com Thu Oct 5 23:41:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA21888; Thu, 5 Oct 2000 23:41:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA22529 Fri, 6 Oct 2000 00:26:32 -0400 (EDT) Reply-To: From: "Rohit Khosla" To: "'Caerwyn Pearce'" , Subject: RE: IPSec test suite Date: Fri, 6 Oct 2000 10:18:40 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Caerwyn, i am mainly looking for some kind of test cases which i should execute offline on the IPSec implementaion, to test weather its IPSec compliant (As per the IPSec RFC's) Rohit -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Caerwyn Pearce Sent: Thursday, October 05, 2000 5:36 PM To: ipsec@lists.tislabs.com Subject: RE: IPSec test suite I'm not sure whether this is what you're looking for but there are certainly some test sites available. Try these www.nist.org www.ire.com www.vpnforum.org http://www.rsasecurity.com/ http://isakmp-test.ssh.fi/ http://ipsec-wit.antd.nist.gov/ I've only used the last one. Caerwyn Pearce -----Original Message----- From: rkhosla@ishoni.com [mailto:rkhosla@ishoni.com] Sent: Thu 05 Oct 2000 13:50 To: ipsec@lists.tislabs.com Subject: IPSec test suite Hi, I am looking for some freely available test tool or test suite to test the IPSec implementation. Thanks, Rohit. From owner-ipsec@lists.tislabs.com Fri Oct 6 01:19:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24657; Fri, 6 Oct 2000 01:19:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23033 Fri, 6 Oct 2000 03:16:05 -0400 (EDT) Message-ID: <018201c02f66$9a00b080$0b6d130a@cisco.com> From: "Ajith Thrivikramannair" To: , "'Caerwyn Pearce'" , References: Subject: Re: IPSec test suite Date: Fri, 6 Oct 2000 00:25:28 -0700 Organization: Cisco Systems 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some info here: http://www.ietf.org/internet-drafts/draft-hoffman-ipsec-testing-01.txt ----- Original Message ----- From: "Rohit Khosla" To: "'Caerwyn Pearce'" ; Sent: Thursday, October 05, 2000 9:48 PM Subject: RE: IPSec test suite > > Thanks Caerwyn, i am mainly looking for some kind of test cases which i > should execute offline on the IPSec implementaion, to test weather its IPSec > compliant (As per the IPSec RFC's) > > Rohit > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Caerwyn Pearce > Sent: Thursday, October 05, 2000 5:36 PM > To: ipsec@lists.tislabs.com > Subject: RE: IPSec test suite > > > I'm not sure whether this is what you're looking for but there are certainly > some test sites available. Try these > > www.nist.org > www.ire.com > www.vpnforum.org > http://www.rsasecurity.com/ > http://isakmp-test.ssh.fi/ > http://ipsec-wit.antd.nist.gov/ > > > I've only used the last one. > > Caerwyn Pearce > > > -----Original Message----- > From: rkhosla@ishoni.com [mailto:rkhosla@ishoni.com] > Sent: Thu 05 Oct 2000 13:50 > To: ipsec@lists.tislabs.com > Subject: IPSec test suite > > > Hi, > > I am looking for some freely available test tool or test suite to test the > IPSec implementation. > > Thanks, > Rohit. > > > From owner-ipsec@lists.tislabs.com Fri Oct 6 02:52:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26101; Fri, 6 Oct 2000 02:52:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA23333 Fri, 6 Oct 2000 04:48:56 -0400 (EDT) Message-ID: <39DD94A6.79EB9978@lmf.ericsson.se> Date: Fri, 06 Oct 2000 12:00:22 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPSec test suite References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have used some of the test sites, and they are indeed very useful. Thanks for everybody who is providing them. However, I believe many IPsec implementations would benefit if there was a comprehensive suite of test cases available in an easily executable form that would look not only at the "normal" cases of IPsec and IKE connections but also various error situations, test ranges and limits. Instead of the normal authalg x encalg x authmethod x identitytype combinations, I'm thinking along the lines of checking what happens when nonces are the smallest or largest possible, packets get fragmented, ESP padding size varies to something else than the strictly necessary, number of transforms or proposals grows very high, all illegal and error combinations, the known (?) denial of service attacks against IKE, and so on. Anybody have something like this? Jari ---- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com Private WWW: http://www.iki.fi/jar. Standard disclaimers apply. From owner-ipsec@lists.tislabs.com Fri Oct 6 06:32:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03502; Fri, 6 Oct 2000 06:32:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23658 Fri, 6 Oct 2000 08:14:58 -0400 (EDT) Message-ID: <39DDC508.FD53C278@storm.ca> Date: Fri, 06 Oct 2000 08:26:49 -0400 From: Sandy Harris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPSec test suite References: <39DD94A6.79EB9978@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari Arkko wrote: > > I believe many IPsec implementations would benefit if there was > a comprehensive suite of test cases available in an easily > executable form that would look not only at the "normal" cases > of IPsec and IKE connections but also ... Methinks the route to it would be to modify one of the open source IPSEC implementations. Even unmodified, one or more of them is likely a good testing tool. Linux FreeS/WAN: http://www.freeswan.org KAME for BSD Unices: http://www.kame.net/project-overview.html OpenBSD: http://www.openbsd.org Linux Pipsecd: http://perso.enst.fr/~beyssac/pipsec/ Pipsecd might be easiest to modify since it is a userspace program. From owner-ipsec@lists.tislabs.com Fri Oct 6 10:42:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12866; Fri, 6 Oct 2000 10:42:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24321 Fri, 6 Oct 2000 12:28:12 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9815@eseis06nok> Cc: ipsec@lists.tislabs.com Subject: RE: Notification payloads IV Date: Fri, 6 Oct 2000 19:39:37 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I thought about that and the IV that should be used is the one that would be used for a normal packet. I think this IV + the Mesage Id (Data to apply the PRF function) and then Compute an IV like would be in a normal Informational packet Some implementations reject clear packets at this point thats why I thought about this solution. Toni -----Original Message----- From: EXT Tero Kivinen [mailto:kivinen@ssh.fi] Sent: 06. October 2000 19:36 To: antonio.barrera@nokia.com Cc: ipsec@lists.tislabs.com Subject: Notification payloads IV antonio.barrera@nokia.com writes: > How is the IV computed for notification messages in IKE Phase I? It is not computed. You send the error message in clear until you receive the final Phase I packet and get the last Phase I CBC block to start your IV calculations. > However, I'm not really sure how to do it for Phase I when > encryption is applied (messages 5 and 6) and an error is found. > Is it explained somewhere? No. It is not explained anywhere, and different implementations are doing it differently. I know there are implementations which send those notifications encrypted and I don't know which IV they are using. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Oct 6 10:42:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12867; Fri, 6 Oct 2000 10:42:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24290 Fri, 6 Oct 2000 12:24:57 -0400 (EDT) Date: Fri, 6 Oct 2000 19:36:21 +0300 (EET DST) Message-Id: <200010061636.TAA27411@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: antonio.barrera@nokia.com Cc: ipsec@lists.tislabs.com Subject: Notification payloads IV In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A051A97A8@eseis06nok> References: <0B3F42CA1FB6D2118FE50008C7894B0A051A97A8@eseis06nok> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk antonio.barrera@nokia.com writes: > How is the IV computed for notification messages in IKE Phase I? It is not computed. You send the error message in clear until you receive the final Phase I packet and get the last Phase I CBC block to start your IV calculations. > However, I'm not really sure how to do it for Phase I when > encryption is applied (messages 5 and 6) and an error is found. > Is it explained somewhere? No. It is not explained anywhere, and different implementations are doing it differently. I know there are implementations which send those notifications encrypted and I don't know which IV they are using. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Oct 6 10:47:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12933; Fri, 6 Oct 2000 10:47:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24388 Fri, 6 Oct 2000 12:49:15 -0400 (EDT) Message-ID: <39DE0556.8F1473A1@storm.ca> Date: Fri, 06 Oct 2000 13:01:10 -0400 From: Sandy Harris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Losing one private key Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For IKE with public key authentication, I'm wondering about the situation where one private key is compromised, e.g. some evildoer has acquired root privilege on one gateway and grabbed the key. I know that: with one key, he can impersonate its owner and wreak diverse havocs if he gets both keys, we are vulnerable to man-in-the-middle attacks if he plants a trojan on the compromised gateway, or otherwise maintains control of that machine, all is lost I suspect that with only one key, he cannot conduct a man-in-the-middle attack and intercept genuine gateway-to-gateway traffic. The worst he can do is impersonate the compromised gateway and grab whatever the other side sends him. That is bad enough, but better than the results when IKE with shared secrets or manual keying are used. In those cases compromising one gateway gets him everything. Am I right about that, or is there some even nastier attack available with one private key? How would one add impersonation detection? Obviously not in the IPSEC protocol suite; they're too complex already and this is outside their scope, but is there some fairly simple client-to-client check you could do that would detect an impersonating gateway? I'm thinking of the situation where your public key is compromised, I don't know that and my gateway is talking to an impostor. What do I ask of some system behind your gateway to double-check things? From owner-ipsec@lists.tislabs.com Fri Oct 6 10:53:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13050; Fri, 6 Oct 2000 10:53:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24408 Fri, 6 Oct 2000 12:58:44 -0400 (EDT) Date: Fri, 6 Oct 2000 20:10:13 +0300 (EET DST) Message-Id: <200010061710.UAA18482@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: wprice@cyphers.net Cc: ipsec@lists.tislabs.com Subject: Re: Rijndael selected as AES In-Reply-To: <39DA2B30.4786A558@cyphers.net> References: <20001003174556.0A5E335DC2@smb.research.att.com> <39DA2B30.4786A558@cyphers.net> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will Price writes: > Has it occurred to anyone the silliness of adding AES to IPsec/IKE without > adding larger primes to IKE? There was a discussion in March on this list > with regards to larger primes, but it died out around the time someone > would need to have written a draft. I believe Tero did post the larger DH > primes to the list. Any volunteers to write that up? I can put those groups we generated to the draft and send it next week. I don't think it is going to be practical to include groups bigger than 4096 bits now, as using them is going to be too slow, and generating them is going to take a long time... I was planning to add 2048, 3072 and 4096 bit groups, and also document the 1536 bit group (it is not currently documented anywhere). Is there any need for any other group sizes less than 4096 bits? -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Oct 6 12:05:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14301; Fri, 6 Oct 2000 12:04:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24563 Fri, 6 Oct 2000 13:58:03 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: Dan Harkins cc: Ari Huttunen , ipsec Message-ID: <8525696F.0079E505.00@smtpmail.certicom.com> Date: Thu, 5 Oct 2000 18:12:03 -0400 Subject: Re: Larger DH groups? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Ahh ... the eternal patent question. Unfortunately the patent system doesn't allow the kind of black and white answer you're looking for. However I think our IPR statement is fairly clear that we believe we have patents and patent applcations covering ECC. Our advice to anyone implementing ECC is to take a license from Certicom :-). On the IANA issue. I believe all our numbers for ECC groups were assigned by IANA as specified in RFC 2409. I believe the link to the numbers on the IANA site is: http://www.isi.edu/in-notes/iana/assignments/ipsec-registry. Best regards. Simon S. Blake-Wilson Certicom Corp. Dan Harkins on 10/05/2000 02:58:16 PM To: Simon Blake-Wilson/Certicom@Certicom cc: Ari Huttunen , ipsec Subject: Re: Larger DH groups? While updating the "Additional ECC groups for IKE" draft can you unqualify your IP statement? Do you or do you not have patents that cover this? It would be nice if there was a one syllable response to the question "is a license from Certicom essential to implement these curves?" Also, in the AES assigned numbers thread it became obvious that certain vendors have been assigning numbers which are reserved to IANA to their own use of algorithms. I'd like to note that you are repeating this error in your draft and respectfully ask you to use numbers from the private use range for all the groups in this draft. Section 11.4 of RFC2409 describes the procedure necessary for you to follow to get IANA to assign number to you. Dan. On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take about > 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take > about 25 times as long as 160-bit ECC. We don't have implementations of > 15000-bit DH but we do have 512-bit ECDH and our performance roughly follows the > estimates. (In fact we're in the process of adding 512-bit curves to our > "Additional ECC groups for IKE" draft so that it has complete AES support.) > > Best regards. Simon > > S. Blake-Wilson > Certicom Corp. > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > To: ipsec > cc: (bcc: Simon Blake-Wilson/Certicom) > Subject: Larger DH groups? > > > > > Are there plans/interest in specifying larger standard DH groups, now that > the AES has been chosen? > > If so, what sizes would be appropriate? Tero earlier posted groups of > 2000-4000 bits, the draft for AES talks about 14000. Anybody know just > how slow would 14000 bit modulus be? (I can guess it's something between > extremely slow and ridiculously slow..) What about the speed of a 500 bit EC2N? > > Ari > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Oct 6 13:51:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15710; Fri, 6 Oct 2000 13:51:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24999 Fri, 6 Oct 2000 15:53:26 -0400 (EDT) Message-Id: <200010062004.e96K49l135177@thunk.east.sun.com> From: Bill Sommerfeld To: "Simon Blake-Wilson" cc: Dan Harkins , Ari Huttunen , ipsec Subject: Re: Larger DH groups? In-reply-to: Your message of "Thu, 05 Oct 2000 18:12:03 EDT." <8525696F.0079E505.00@smtpmail.certicom.com> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 06 Oct 2000 16:04:09 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about listing the patent numbers so we can look at the claims ourselves? - Bill From owner-ipsec@lists.tislabs.com Fri Oct 6 14:01:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15824; Fri, 6 Oct 2000 14:01:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25008 Fri, 6 Oct 2000 15:54:01 -0400 (EDT) Message-ID: <39DE30D5.2F62F387@redcreek.com> Date: Fri, 06 Oct 2000 13:06:45 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Blake-Wilson CC: Dan Harkins , Ari Huttunen , ipsec Subject: Re: Larger DH groups? References: <8525696F.0079E505.00@smtpmail.certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My understanding from earlier statements from certicom (minneapolis ietf?) was that certicom is attempting to patent certain ec acceleration techniques, but that ec's themselves are not patentable. Your statement seems to be that ec's in any form are either patented or patent-pending by certicom. Is this correct? Simon Blake-Wilson wrote: > > Hi Dan, > > Ahh ... the eternal patent question. Unfortunately the patent system doesn't > allow the kind of black and white answer you're looking for. However I think our > IPR statement is fairly clear that we believe we have patents and patent > applcations covering ECC. Our advice to anyone implementing ECC is to take a > license from Certicom :-). > > On the IANA issue. I believe all our numbers for ECC groups were assigned by > IANA as specified in RFC 2409. I believe the link to the numbers on the IANA > site is: > http://www.isi.edu/in-notes/iana/assignments/ipsec-registry. > > Best regards. Simon > > S. Blake-Wilson > Certicom Corp. > > Dan Harkins on 10/05/2000 02:58:16 PM > > To: Simon Blake-Wilson/Certicom@Certicom > cc: Ari Huttunen , ipsec > Subject: Re: Larger DH groups? > > While updating the "Additional ECC groups for IKE" draft can you unqualify > your IP statement? Do you or do you not have patents that cover this? It > would be nice if there was a one syllable response to the question "is a > license from Certicom essential to implement these curves?" > > Also, in the AES assigned numbers thread it became obvious that certain > vendors have been assigning numbers which are reserved to IANA to their > own use of algorithms. I'd like to note that you are repeating this error > in your draft and respectfully ask you to use numbers from the private use > range for all the groups in this draft. Section 11.4 of RFC2409 describes > the procedure necessary for you to follow to get IANA to assign number to > you. > > Dan. > > On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > > > Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take > about > > 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take > > about 25 times as long as 160-bit ECC. We don't have implementations of > > 15000-bit DH but we do have 512-bit ECDH and our performance roughly follows > the > > estimates. (In fact we're in the process of adding 512-bit curves to our > > "Additional ECC groups for IKE" draft so that it has complete AES support.) > > > > Best regards. Simon > > > > S. Blake-Wilson > > Certicom Corp. > > > > > > > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > > > To: ipsec > > cc: (bcc: Simon Blake-Wilson/Certicom) > > Subject: Larger DH groups? > > > > > > > > > > Are there plans/interest in specifying larger standard DH groups, now that > > the AES has been chosen? > > > > If so, what sizes would be appropriate? Tero earlier posted groups of > > 2000-4000 bits, the draft for AES talks about 14000. Anybody know just > > how slow would 14000 bit modulus be? (I can guess it's something between > > extremely slow and ridiculously slow..) What about the speed of a 500 bit > EC2N? > > > > Ari > > > > -- > > Ari Huttunen phone: +358 9 859 900 > > Senior Software Engineer fax : +358 9 8599 0452 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Oct 6 15:57:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17487; Fri, 6 Oct 2000 15:57:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25320 Fri, 6 Oct 2000 17:37:52 -0400 (EDT) Message-ID: <99120312047FD41183AA009027AA616008960D@ca-exchange2.nai.com> From: "Glawitsch, Gregor" To: ipsec Subject: RE: Larger DH groups? Date: Fri, 6 Oct 2000 14:45:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think it is actually GOOD if Simon/Certicom tries to claim that their patents cover the whole EC area. As the old saying goes: Here lies a toppled god, his fall was not a small one, we did but build a pedestal, a narrow and a tall one. What I'm trying to say: If they try to claim too much coverage, someone will show the judge a late seventies/early eighties Cryptography textbook and the patent will be thrown out faster than any Certicom lawyer can say the S-word. Greg -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Friday, October 06, 2000 1:07 PM To: Simon Blake-Wilson Cc: Dan Harkins; Ari Huttunen; ipsec Subject: Re: Larger DH groups? My understanding from earlier statements from certicom (minneapolis ietf?) was that certicom is attempting to patent certain ec acceleration techniques, but that ec's themselves are not patentable. Your statement seems to be that ec's in any form are either patented or patent-pending by certicom. Is this correct? Simon Blake-Wilson wrote: > > Hi Dan, > > Ahh ... the eternal patent question. Unfortunately the patent system doesn't > allow the kind of black and white answer you're looking for. However I think our > IPR statement is fairly clear that we believe we have patents and patent > applcations covering ECC. Our advice to anyone implementing ECC is to take a > license from Certicom :-). > > On the IANA issue. I believe all our numbers for ECC groups were assigned by > IANA as specified in RFC 2409. I believe the link to the numbers on the IANA > site is: > http://www.isi.edu/in-notes/iana/assignments/ipsec-registry. > > Best regards. Simon > > S. Blake-Wilson > Certicom Corp. > > Dan Harkins on 10/05/2000 02:58:16 PM > > To: Simon Blake-Wilson/Certicom@Certicom > cc: Ari Huttunen , ipsec > Subject: Re: Larger DH groups? > > While updating the "Additional ECC groups for IKE" draft can you unqualify > your IP statement? Do you or do you not have patents that cover this? It > would be nice if there was a one syllable response to the question "is a > license from Certicom essential to implement these curves?" > > Also, in the AES assigned numbers thread it became obvious that certain > vendors have been assigning numbers which are reserved to IANA to their > own use of algorithms. I'd like to note that you are repeating this error > in your draft and respectfully ask you to use numbers from the private use > range for all the groups in this draft. Section 11.4 of RFC2409 describes > the procedure necessary for you to follow to get IANA to assign number to > you. > > Dan. > > On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > > > Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take > about > > 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take > > about 25 times as long as 160-bit ECC. We don't have implementations of > > 15000-bit DH but we do have 512-bit ECDH and our performance roughly follows > the > > estimates. (In fact we're in the process of adding 512-bit curves to our > > "Additional ECC groups for IKE" draft so that it has complete AES support.) > > > > Best regards. Simon > > > > S. Blake-Wilson > > Certicom Corp. > > > > > > > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > > > To: ipsec > > cc: (bcc: Simon Blake-Wilson/Certicom) > > Subject: Larger DH groups? > > > > > > > > > > Are there plans/interest in specifying larger standard DH groups, now that > > the AES has been chosen? > > > > If so, what sizes would be appropriate? Tero earlier posted groups of > > 2000-4000 bits, the draft for AES talks about 14000. Anybody know just > > how slow would 14000 bit modulus be? (I can guess it's something between > > extremely slow and ridiculously slow..) What about the speed of a 500 bit > EC2N? > > > > Ari > > > > -- > > Ari Huttunen phone: +358 9 859 900 > > Senior Software Engineer fax : +358 9 8599 0452 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Oct 6 16:14:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17649; Fri, 6 Oct 2000 16:14:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25330 Fri, 6 Oct 2000 17:39:04 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02FDF.0B38B239" Subject: Reliable delete notifies Date: Fri, 6 Oct 2000 14:47:37 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C076265740C5F19@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: Larger DH groups? Thread-Index: AcAv0sfPNyamtMo6SQ2SSYCoI2ybGQACqVSg From: "Brian Swander" To: "ipsec" X-OriginalArrivalTime: 06 Oct 2000 21:48:17.0435 (UTC) FILETIME=[22CB86B0:01C02FDF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C02FDF.0B38B239 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reliable deletes are basically essential for decent interop of IKE, and most people I talked to at the last bakeoff agree with me. However, I am concerned that the draft that mentioned them (son-of-ike) has not only not progressed, but has vanished. That is problem 1. Equally important is how reliable notifies will work. One of the brilliant aspects of the draft (i erroneously thought) was that it also addressed the backwards compatibility problem. I had initially interpreted the draft to say that reliable notifies were exactly like normal notifies, except that the payload contained an extra Nonce field for liveness checking of the Ack. I felt this brilliant, since down level clients who didn't support the reliable notify wouldn't send a response, ignore the nonce, but otherwise process the message. The cost is a few extra retransmissions, which also serve to insure that the peer gets the message anyway. =20 It was pointed out to me, however, that there is a new exchange number for reliable notifies. Doing this breaks all the beautiful backwards compatibility. Of course, we can do the standard silly IKE thing of negotiating reliable delete functionality with the vendor ID payload, or sending double the notifies, once with the standard number, and once with the new one. Both of these methods seem much less clean then just having a single info exchange ID. =20 Can someone justify the choice of changing the exchange type, and also comment on if there are any plans to actually advance this necessary functionality beyond the word-of-mouth stage. bs ------_=_NextPart_001_01C02FDF.0B38B239 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reliable delete notifies

Reliable deletes are basically essential for decent = interop of IKE, and most people I talked to at the last bakeoff agree = with me.  However, I am concerned that the draft that mentioned = them (son-of-ike) has not only not progressed, but has = vanished.

That is problem 1.  Equally important is how = reliable notifies will work.  One of the brilliant aspects of the = draft (i erroneously thought) was that it also addressed the backwards = compatibility problem.  I had initially interpreted the draft to = say that reliable notifies were exactly like normal notifies, except = that the payload contained an extra Nonce field for liveness checking of = the Ack.  I felt this brilliant, since down level clients who = didn't support the reliable notify wouldn't send a response, ignore the = nonce, but otherwise process the message.  The cost is a few extra = retransmissions, which also serve to insure that the peer gets the = message anyway. 

It was pointed out to me, however, that there is a new = exchange number for reliable notifies.  Doing this breaks all the = beautiful backwards compatibility.  Of course, we can do the = standard silly IKE thing of negotiating reliable delete functionality = with the vendor ID payload, or sending double the notifies, once with = the standard number, and once with the new one.  Both of these = methods seem much less clean then just having a single info exchange = ID. 

Can someone justify the choice of changing the = exchange type, and also comment on if there are any plans to actually = advance this necessary functionality beyond the word-of-mouth = stage.

bs

------_=_NextPart_001_01C02FDF.0B38B239-- From owner-ipsec@lists.tislabs.com Fri Oct 6 17:33:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18279; Fri, 6 Oct 2000 17:33:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25560 Fri, 6 Oct 2000 19:24:22 -0400 (EDT) Date: Fri, 6 Oct 2000 16:35:11 -0700 (PDT) From: Jan Vilhuber To: Brian Swander , Dan Harkins cc: ipsec Subject: Re: Reliable delete notifies In-Reply-To: <5B90AD65A9E8934987DB0C8C076265740C5F19@DF-BOWWOW.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Furthermore, can someone resurrect son-of-ike? Dan? Any word on this? If not you, should someone else take this? There's good stuff there that we should get into the next rev of ike. This stuff is important to increase IKE robustness and interoperability. jan On Fri, 6 Oct 2000, Brian Swander wrote: > Reliable deletes are basically essential for decent interop of IKE, and > most people I talked to at the last bakeoff agree with me. However, I > am concerned that the draft that mentioned them (son-of-ike) has not > only not progressed, but has vanished. > > That is problem 1. Equally important is how reliable notifies will > work. One of the brilliant aspects of the draft (i erroneously thought) > was that it also addressed the backwards compatibility problem. I had > initially interpreted the draft to say that reliable notifies were > exactly like normal notifies, except that the payload contained an extra > Nonce field for liveness checking of the Ack. I felt this brilliant, > since down level clients who didn't support the reliable notify wouldn't > send a response, ignore the nonce, but otherwise process the message. > The cost is a few extra retransmissions, which also serve to insure that > the peer gets the message anyway. > > It was pointed out to me, however, that there is a new exchange number > for reliable notifies. Doing this breaks all the beautiful backwards > compatibility. Of course, we can do the standard silly IKE thing of > negotiating reliable delete functionality with the vendor ID payload, or > sending double the notifies, once with the standard number, and once > with the new one. Both of these methods seem much less clean then just > having a single info exchange ID. > > Can someone justify the choice of changing the exchange type, and also > comment on if there are any plans to actually advance this necessary > functionality beyond the word-of-mouth stage. > > bs > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Oct 6 17:39:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18325; Fri, 6 Oct 2000 17:39:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25624 Fri, 6 Oct 2000 19:43:44 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: Reliable delete notifies Date: Fri, 6 Oct 2000 16:50:01 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2041E7742@fifi.platinum.corp.microsoft.com> Thread-Topic: Larger DH groups? Thread-Index: AcAv0sfPNyamtMo6SQ2SSYCoI2ybGQACqVSgAAR9EkA= From: "William Dixon" To: "Brian Swander" , "ipsec" X-OriginalArrivalTime: 06 Oct 2000 23:51:25.0813 (UTC) FILETIME=[569C8A50:01C02FF0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk resending in plain text, I hope... -----Original Message----- From: Brian Swander Sent: Friday, October 06, 2000 2:48 PM To: ipsec Subject: Reliable delete notifies Reliable deletes are basically essential for decent interop of IKE, and most people I talked to at the last bakeoff agree with me. However, I am concerned that the draft that mentioned them (son-of-ike) has not only not progressed, but has vanished. That is problem 1. Equally important is how reliable notifies will work. One of the brilliant aspects of the draft (i erroneously thought) was that it also addressed the backwards compatibility problem. I had initially interpreted the draft to say that reliable notifies were exactly like normal notifies, except that the payload contained an extra Nonce field for liveness checking of the Ack. I felt this brilliant, since down level clients who didn't support the reliable notify wouldn't send a response, ignore the nonce, but otherwise process the message. The cost is a few extra retransmissions, which also serve to insure that the peer gets the message anyway. It was pointed out to me, however, that there is a new exchange number for reliable notifies. Doing this breaks all the beautiful backwards compatibility. Of course, we can do the standard silly IKE thing of negotiating reliable delete functionality with the vendor ID payload, or sending double the notifies, once with the standard number, and once with the new one. Both of these methods seem much less clean then just having a single info exchange ID. Can someone justify the choice of changing the exchange type, and also comment on if there are any plans to actually advance this necessary functionality beyond the word-of-mouth stage. bs From owner-ipsec@lists.tislabs.com Fri Oct 6 18:11:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18770; Fri, 6 Oct 2000 18:11:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25715 Fri, 6 Oct 2000 20:13:59 -0400 (EDT) Message-Id: <200010070020.RAA17423@potassium.network-alchemy.com> To: Jan Vilhuber cc: Brian Swander , ipsec Subject: Re: Reliable delete notifies In-reply-to: Your message of "Fri, 06 Oct 2000 16:35:11 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17420.970878025.1@network-alchemy.com> Date: Fri, 06 Oct 2000 17:20:25 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm presently doing just that. The new draft will combine all three of the key management RFCs into one. This will give an opportunity to remove lots of the duplication, confusion, and conflicts that arose because of the 3 separate documents. I'm also planning on cutting out quite a bit of the optional things that are now referred to as "standards bloat". For instance, one of the public key authentication methods will be removed as will Aggressive Mode and most of the ISAKMP exchanges defined in RFC2408. Dan. On Fri, 06 Oct 2000 16:35:11 PDT you wrote > Furthermore, can someone resurrect son-of-ike? Dan? Any word on this? If not > you, should someone else take this? > > There's good stuff there that we should get into the next rev of ike. This > stuff is important to increase IKE robustness and interoperability. > > jan > > > > > On Fri, 6 Oct 2000, Brian Swander wrote: > > > Reliable deletes are basically essential for decent interop of IKE, and > > most people I talked to at the last bakeoff agree with me. However, I > > am concerned that the draft that mentioned them (son-of-ike) has not > > only not progressed, but has vanished. > > > > That is problem 1. Equally important is how reliable notifies will > > work. One of the brilliant aspects of the draft (i erroneously thought) > > was that it also addressed the backwards compatibility problem. I had > > initially interpreted the draft to say that reliable notifies were > > exactly like normal notifies, except that the payload contained an extra > > Nonce field for liveness checking of the Ack. I felt this brilliant, > > since down level clients who didn't support the reliable notify wouldn't > > send a response, ignore the nonce, but otherwise process the message. > > The cost is a few extra retransmissions, which also serve to insure that > > the peer gets the message anyway. > > > > It was pointed out to me, however, that there is a new exchange number > > for reliable notifies. Doing this breaks all the beautiful backwards > > compatibility. Of course, we can do the standard silly IKE thing of > > negotiating reliable delete functionality with the vendor ID payload, or > > sending double the notifies, once with the standard number, and once > > with the new one. Both of these methods seem much less clean then just > > having a single info exchange ID. > > > > Can someone justify the choice of changing the exchange type, and also > > comment on if there are any plans to actually advance this necessary > > functionality beyond the word-of-mouth stage. > > > > bs > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Fri Oct 6 18:52:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19126; Fri, 6 Oct 2000 18:52:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25801 Fri, 6 Oct 2000 20:43:25 -0400 (EDT) From: "Scott Fanning" To: "Dan Harkins" , "Jan Vilhuber" Cc: "Brian Swander" , "ipsec" Subject: RE: Reliable delete notifies Date: Fri, 6 Oct 2000 18:01:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200010070020.RAA17423@potassium.network-alchemy.com> x-mimeole: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan I am also assuming that the new hash (or some equivalent) will be include to ensure that all the payloads are covered ;-) Also, and clarifications on the following would be nice.. 1) Commit Bit: The usual confusion, but I am not sure how much more plain it could be. 2) Notifies: Some of Scott Kellys notifies would be nice inclusions. 3) Acks on Notifies. I would like to see that a MUST, but the presence of them would be a step forward. 4) Re-keying explained, and no wiggle room in it. Lots of interop problems here. Linkage of Phase 1 / Phase 2 sas as an option would be nice. 5) Get rid of new group mode. 6) Allow for Authentication before DH. 7) Some accommodation for remote access would be nice, but might be out of scope. 8) Recommendations of retries, timers, etc on IKE packets. This might avoid the "15 times send a packet" method of reliability. 9) A well defined state-machine in the doc would be an added touch of class as well. I am sure there are more, but this is some of the things on my wish list. Just my 2 cents. Maybe others would like to add to the wish list now, or forever hold your piece. Scott > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Friday, October 06, 2000 5:20 PM > To: Jan Vilhuber > Cc: Brian Swander; ipsec > Subject: Re: Reliable delete notifies > > > I'm presently doing just that. The new draft will combine all three of > the key management RFCs into one. This will give an opportunity to remove > lots of the duplication, confusion, and conflicts that arose because of > the 3 separate documents. I'm also planning on cutting out quite a bit of > the optional things that are now referred to as "standards bloat". For > instance, one of the public key authentication methods will be removed > as will Aggressive Mode and most of the ISAKMP exchanges defined in > RFC2408. > > Dan. > > On Fri, 06 Oct 2000 16:35:11 PDT you wrote > > Furthermore, can someone resurrect son-of-ike? Dan? Any word on > this? If not > > you, should someone else take this? > > > > There's good stuff there that we should get into the next rev > of ike. This > > stuff is important to increase IKE robustness and interoperability. > > > > jan > > > > > > > > > > On Fri, 6 Oct 2000, Brian Swander wrote: > > > > > Reliable deletes are basically essential for decent interop > of IKE, and > > > most people I talked to at the last bakeoff agree with me. However, I > > > am concerned that the draft that mentioned them (son-of-ike) has not > > > only not progressed, but has vanished. > > > > > > That is problem 1. Equally important is how reliable notifies will > > > work. One of the brilliant aspects of the draft (i > erroneously thought) > > > was that it also addressed the backwards compatibility problem. I had > > > initially interpreted the draft to say that reliable notifies were > > > exactly like normal notifies, except that the payload > contained an extra > > > Nonce field for liveness checking of the Ack. I felt this brilliant, > > > since down level clients who didn't support the reliable > notify wouldn't > > > send a response, ignore the nonce, but otherwise process the message. > > > The cost is a few extra retransmissions, which also serve to > insure that > > > the peer gets the message anyway. > > > > > > It was pointed out to me, however, that there is a new exchange number > > > for reliable notifies. Doing this breaks all the beautiful backwards > > > compatibility. Of course, we can do the standard silly IKE thing of > > > negotiating reliable delete functionality with the vendor ID > payload, or > > > sending double the notifies, once with the standard number, and once > > > with the new one. Both of these methods seem much less clean > then just > > > having a single info exchange ID. > > > > > > Can someone justify the choice of changing the exchange type, and also > > > comment on if there are any plans to actually advance this necessary > > > functionality beyond the word-of-mouth stage. > > > > > > bs > > > > > > > -- > > Jan Vilhuber > vilhuber@cisco.com > > Cisco Systems, San Jose > (408) 527-0847 > > > From owner-ipsec@lists.tislabs.com Sat Oct 7 07:58:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02707; Sat, 7 Oct 2000 07:58:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27270 Sat, 7 Oct 2000 09:32:44 -0400 (EDT) Message-ID: <39DF28CF.29F19E3E@indusriver.com> Date: Sat, 07 Oct 2000 09:44:47 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec Subject: Re: Reliable delete notifies References: <200010070020.RAA17423@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, > For instance, one of the public key authentication methods will be removed > as will Aggressive Mode and most of the ISAKMP exchanges defined in > RFC2408. Why do you plan to remove Aggressive Mode? It is the only way to use ID's other than IP addresses with pre-shared keys. Before I get flamed, I agree that pre-shared keys are inferior to certs and that identity protection is highly desirable, but, are they so desirable that an entire mode of operation has to be deleted? -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Sat Oct 7 10:48:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08670; Sat, 7 Oct 2000 10:48:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27496 Sat, 7 Oct 2000 12:51:54 -0400 (EDT) Message-Id: <200010071658.JAA22917@potassium.network-alchemy.com> To: Ben McCann cc: ipsec Subject: Re: Reliable delete notifies In-reply-to: Your message of "Sat, 07 Oct 2000 09:44:47 EDT." <39DF28CF.29F19E3E@indusriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22914.970937900.1@network-alchemy.com> Date: Sat, 07 Oct 2000 09:58:20 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ben, The reason we have the mess we have today is because I tried to make IKE be all things for all people. Every suggesstion or whim was seriously entertained and no one complained until we reached Last Call and at that point the Working Group decided to avoid changes because the entire set of I-Ds-- including the architecture draft, the AH draft, the ESP draft, etc-- would've been held up. We have Aggressive Mode because people complained about having to do a 6 message exchange just to get an authticated secret between the two peers. Given certain assumptions, SKIP could just start sending IPsec-protected packets immediately! But Aggressive Mode doesn't protect the identities from passive snooping and it was suggested to me to do away with it because 6 messages (well, 9 actually) has turned out to be not that big of a deal-- Aggressive Mode is not necessary. But you bring up a good point. As it turns out Aggressive Mode does have a use. I'd like to clarify, though, that you can still use pre-shared keys without Aggressive Mode, you just can't do it from random, unknown IP addresses. I'm doing this work for the Working Group and I can't just unilaterally declare that Aggressive Mode is out. I was noting that it's out of my drafty-draft. If the Working Group wants Aggressive Mode in the protocol then it is in. So let's start a discussion. Does the Working Group want to keep Aggressive Mode? Is Aggressive Mode "standards bloat" or is it a necessary addition to do what Ben wants to do? Dan. On Sat, 07 Oct 2000 09:44:47 EDT you wrote > Dan, > > > For instance, one of the public key authentication methods will be removed > > as will Aggressive Mode and most of the ISAKMP exchanges defined in > > RFC2408. > > Why do you plan to remove Aggressive Mode? It is the only way to > use ID's other than IP addresses with pre-shared keys. Before I > get flamed, I agree that pre-shared keys are inferior to certs > and that identity protection is highly desirable, but, are they > so desirable that an entire mode of operation has to be deleted? > > -Ben McCann > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Sat Oct 7 12:48:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09727; Sat, 7 Oct 2000 12:48:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27714 Sat, 7 Oct 2000 14:31:06 -0400 (EDT) Message-ID: <39DF6EB4.1C802295@storm.ca> Date: Sat, 07 Oct 2000 14:43:00 -0400 From: Sandy Harris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dan Harkins CC: ipsec Subject: Re: Reliable delete notifies References: <200010071658.JAA22917@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > ... So let's > start a discussion. Does the Working Group want to keep > Aggressive Mode? Is Aggressive Mode "standards bloat" or > is it a necessary addition to do what Ben wants to do? Here's something I posted on the linux-ipsec list a few weeks back. The whole thread might be of interest. See archives at: http://www.sandelman.ottawa.on.ca/linux-ipsec/ http://www.nexial.com/mailinglists/ The outcome of the thread was Linux FreeS/WAN dropping support for DH Group one. We dropped DES support some time back. ---- forwarded message ------------ Subject: Re: linux-ipsec: Diffie-Hellman groups Date: Thu, 14 Sep 2000 20:05:18 -0400 From: Sandy Harris Svenning Soerensen wrote: > In the spirit of strong security in FreeS/WAN, I wondered > if it is reasonable for pluto to propose DH group 1. > > To quote from draft-ietf-ipsec-ike-01.txt: > > "The strength supplied by group one may not be sufficient for the > mandatory-to-implement encryption algorithm and is here for historic > reasons." > > In the lights of the team's decision not to support single-DES, I > think DH group 1 should be abandoned too. There's been some discussion of a "best current practices" draft that could aim at becoming an RFC. Things I think such a draft should deprecate: DES Group 1 Aggressive mode (reveals identities to eavesdropper) Phase two connections without PFS MD5 (Dobbertin's published attack casts doubt here) A BCP draft should recommend for these: these must not be used in the default configuration for any implementation implementers are permitted to drop support for them. if they are supported, they are not used unless explicitly enabled by the administrator using any of them is an auditable event; it should generate warnings I'd like to see all the above removed from the standard, perhaps along with some of the things the Schneier/Ferguson critique suggested dropping. However, I don't think that will happen. I think a BCP RFC that only recommends the above might fly, though. Currently single DES is the only cipher marked MUST in the RFCs. 3DES is a SHOULD. Efforts to upgrade 3DES to MUST and deprecate DES have been blocked. I think the right thing to do in a BCP draft is to add the AES winner, due to be announced this month: http://csrc.nist.gov/encryption/aes/ as a MUST. Alternately, make 3DES a MUST and AES a SHOULD. Not a BCP issue, but I'm inclined to think it would be useful to add the Tiger hash from: http://www.uni-mannheim.de/studorg/gahg/rweis/rgp/tiger/tiger.html This is a SHOULD in the RFCs and becomes more important if MD5 is deprecated. Designers are very credible folk, and it is faster on 64-bit CPUs than MD5 or SHA. It is not a priority for the team. Volunteers? From owner-ipsec@lists.tislabs.com Sat Oct 7 15:05:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11018; Sat, 7 Oct 2000 15:05:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27915 Sat, 7 Oct 2000 17:06:45 -0400 (EDT) Message-ID: <000d01c030a3$ce4f9b60$2589fcd8@COL4999> From: =?iso-8859-1?Q?Gerardo_Ar=E9valo_Tamayo?= To: "IPsec List" Subject: Tutor Date: Sat, 7 Oct 2000 16:15:17 -0500 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wonder if: 1) There is a software application like a tutor that helps anyone who wants to implement IPsec.? 2) It is a good idea to include something about network managing, cryptographics laws, vendors, or the rfcs are enough in this application.? I really appreciate your help. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use Comment: PubKey http://orbita.starmedia.com/~gerarg1/gat.asc iQA/AwUBOd+SFqB2HuDO7EnLEQK8GQCeIcfJv9+F6w2Yo1mSPE9lgYkMCcoAnjgP 4xBcg7CpvJxf49NYMbepQvBL =Ri3G -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Oct 7 20:47:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14623; Sat, 7 Oct 2000 20:47:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA28589 Sat, 7 Oct 2000 22:19:22 -0400 (EDT) Message-ID: <085e01c030cf$beb32970$3002a8c0@tf.ispsoft.com> From: "raghu arni" To: =?iso-8859-1?Q?Gerardo_Ar=E9valo_Tamayo?= , "IPsec List" References: <000d01c030a3$ce4f9b60$2589fcd8@COL4999> Subject: Re: Tutor Date: Sat, 7 Oct 2000 22:30:37 -0400 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk see the book on ipsec by dorswamay...has some good notes for implementers.. also get the freeswan ipsec implementation..no substitute for seeing some good implementation code..;) A > > I wonder if: > > 1) There is a software application like a tutor that helps anyone who > wants to implement IPsec.? > 2) It is a good idea to include something about network managing, > cryptographics laws, vendors, or the rfcs are enough in this > application.? > > I really appreciate your help. > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.1 Int. for non-commercial use > > Comment: PubKey http://orbita.starmedia.com/~gerarg1/gat.asc > > iQA/AwUBOd+SFqB2HuDO7EnLEQK8GQCeIcfJv9+F6w2Yo1mSPE9lgYkMCcoAnjgP > 4xBcg7CpvJxf49NYMbepQvBL > =Ri3G > -----END PGP SIGNATURE----- > > > From owner-ipsec@lists.tislabs.com Sun Oct 8 17:29:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12237; Sun, 8 Oct 2000 17:29:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00565 Sun, 8 Oct 2000 18:32:37 -0400 (EDT) Date: Sun, 8 Oct 2000 15:43:33 -0700 (PDT) From: Jan Vilhuber To: Sandy Harris cc: Dan Harkins , ipsec Subject: Re: Reliable delete notifies In-Reply-To: <39DF6EB4.1C802295@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm somewhat divided on the aggressive mode issue. While I'm all for a full-fledged roll-out of PKI, it hasn't happened yet. As I've argued internally here at cisco, it's primarily the fact that we keep coming up with (sometimes ingenious, sometimes insecure) hacks so that we don't have to use PKI (Like group pre-shared keys. YIKES), because most customers are still very much afraid of PKI (for a myriad of reasons). So until PKI rolls out, aggressive mode is still very much needed, especially in the VPN space, which HAS to work through firewalls and (tadaa!!) NAT. Counterview: Maybe getting rid of aggressive mode will speed up the need for a concerted effort on PKI. On the other hand, if we simply deprecate aggressive mode, then I'm afraid we're pusihing a lot of people towards SSL solutions to the above VPN through NAT problem. And that's NOT something I like, personally. Using aggressive mode and picking your shared secret based on the ID is the only thing that's keeping a lot of VPN still on the verge of usability. Let's face it: IKE and IPSec through firewalls and NAT is still very fragile (in part because firewalls and NAT vendors can't seem to get it right). If we deprecate Aggressive mode, then we're going to have to take a LONG hard look at what it'll take to make ike and ipsec work robustly in scenarios involving firewalls and NAT. Think especially about older firewalls, and the fact that you may not be able to get rid of them (they may not be in your control). I assume we all want ipsec to survive, and there's still a lot of NAT devices and firewalls through which ipsec simply doesn't work. Assume that these will not go away or be replaced in the near future. Getting rid of aggressive mode means we need to make it work. I'm not sure how. One might argue that we could get rid of aggressive mode, and let IPSRA figure out the above problem. But that's really shirking our responsibility. My 2c, anyway. jan On Sat, 7 Oct 2000, Sandy Harris wrote: > Dan Harkins wrote: > > > ... So let's > > start a discussion. Does the Working Group want to keep > > Aggressive Mode? Is Aggressive Mode "standards bloat" or > > is it a necessary addition to do what Ben wants to do? > > Here's something I posted on the linux-ipsec list a few weeks back. The whole > thread might be of interest. See archives at: > > http://www.sandelman.ottawa.on.ca/linux-ipsec/ > http://www.nexial.com/mailinglists/ > > The outcome of the thread was Linux FreeS/WAN dropping support for DH Group one. > We dropped DES support some time back. > > ---- forwarded message ------------ > > Subject: Re: linux-ipsec: Diffie-Hellman groups > Date: Thu, 14 Sep 2000 20:05:18 -0400 > From: Sandy Harris > > Svenning Soerensen wrote: > > > In the spirit of strong security in FreeS/WAN, I wondered > > if it is reasonable for pluto to propose DH group 1. > > > > To quote from draft-ietf-ipsec-ike-01.txt: > > > > "The strength supplied by group one may not be sufficient for the > > mandatory-to-implement encryption algorithm and is here for historic > > reasons." > > > > In the lights of the team's decision not to support single-DES, I > > think DH group 1 should be abandoned too. > > There's been some discussion of a "best current practices" draft > that could aim at becoming an RFC. > > Things I think such a draft should deprecate: > DES > Group 1 > Aggressive mode (reveals identities to eavesdropper) > Phase two connections without PFS > MD5 (Dobbertin's published attack casts doubt here) > > A BCP draft should recommend for these: > these must not be used in the default configuration for > any implementation > implementers are permitted to drop support for them. > if they are supported, they are not used unless explicitly > enabled by the administrator > using any of them is an auditable event; it should > generate warnings > > I'd like to see all the above removed from the standard, perhaps > along with some of the things the Schneier/Ferguson critique > suggested dropping. However, I don't think that will happen. > I think a BCP RFC that only recommends the above might fly, though. > > Currently single DES is the only cipher marked MUST in the RFCs. > 3DES is a SHOULD. Efforts to upgrade 3DES to MUST and deprecate DES > have been blocked. > > I think the right thing to do in a BCP draft is to add the AES winner, > due to be announced this month: > http://csrc.nist.gov/encryption/aes/ > as a MUST. Alternately, make 3DES a MUST and AES a SHOULD. > > Not a BCP issue, but I'm inclined to think it would be useful > to add the Tiger hash from: > > http://www.uni-mannheim.de/studorg/gahg/rweis/rgp/tiger/tiger.html > > This is a SHOULD in the RFCs and becomes more important if MD5 > is deprecated. Designers are very credible folk, and it is faster > on 64-bit CPUs than MD5 or SHA. It is not a priority for the team. > Volunteers? > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sun Oct 8 21:35:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20008; Sun, 8 Oct 2000 21:35:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA01129 Sun, 8 Oct 2000 23:00:17 -0400 (EDT) Message-Id: <200010090310.e993AUM18668@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec Subject: Re: Reliable delete notifies In-reply-to: Your message of "Sat, 07 Oct 2000 09:58:20 PDT." <200010071658.JAA22917@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Oct 2000 23:10:30 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [snip] > I'm doing this work for the Working Group and I can't just >unilaterally declare that Aggressive Mode is out. I was >noting that it's out of my drafty-draft. If the Working Group >wants Aggressive Mode in the protocol then it is in. So let's >start a discussion. Does the Working Group want to keep >Aggressive Mode? Is Aggressive Mode "standards bloat" or >is it a necessary addition to do what Ben wants to do? I would in fact argue for removal of preshared-key authentication; it was useful for debugging or for very simple setups, but the protocol complexity introduced both directly (because of the need to support 2 or 3 auth methods) and indirectly (encourages addition of other authentication mechanisms) are simply not worth it. Ways to retrieve certificates (or have temporary certificates issued, after using XYZ authentication) are known, simple, and well-understood. -Angelos From owner-ipsec@lists.tislabs.com Sun Oct 8 23:11:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24431; Sun, 8 Oct 2000 23:11:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA01386 Mon, 9 Oct 2000 01:03:55 -0400 (EDT) Date: Mon, 9 Oct 2000 07:15:08 +0200 (Israel Standard Time) From: Arne Ansper To: Jan Vilhuber cc: ipsec Subject: Re: Reliable delete notifies In-Reply-To: Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On the other hand, if we simply deprecate aggressive mode, then I'm afraid > we're pusihing a lot of people towards SSL solutions to the above VPN through > NAT problem. And that's NOT something I like, personally. SSL solutions need PKI exactly as much as IKE does. They are both usable without one. Being your own CA is very simple and cheap nowdays. And if you are worried about user-friendlines, you can hide it into your management software. Arne Ansper From owner-ipsec@lists.tislabs.com Mon Oct 9 07:08:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09421; Mon, 9 Oct 2000 07:08:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00212 Mon, 9 Oct 2000 08:54:40 -0400 (EDT) Date: Mon, 9 Oct 2000 16:06:12 +0300 (EET DST) Message-Id: <200010091306.QAA14751@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Angelos D. Keromytis" Cc: ipsec Subject: Re: Reliable delete notifies In-Reply-To: <200010090310.e993AUM18668@nyarlathotep.cis.upenn.edu> References: <200010071658.JAA22917@potassium.network-alchemy.com> <200010090310.e993AUM18668@nyarlathotep.cis.upenn.edu> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos D. Keromytis writes: > I would in fact argue for removal of preshared-key authentication; it was > useful for debugging or for very simple setups, but the protocol complexity > introduced both directly (because of the need to support 2 or 3 auth methods) > and indirectly (encourages addition of other authentication mechanisms) are > simply not worth it. I would also remove both RSA encryption modes at the same time. I don't really see points for them. They will offer "a plausably deniable exchange", but I don't think that is important enough to justify the added complexity. I think we could get rid of the pre-shared keys authentication. If we do that then we can get rid of both aggressive mode and base mode... -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Oct 9 07:08:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09443; Mon, 9 Oct 2000 07:08:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02566 Mon, 9 Oct 2000 08:35:15 -0400 (EDT) Date: Mon, 9 Oct 2000 15:46:47 +0300 (EET DST) Message-Id: <200010091246.PAA10749@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Brian Swander" Cc: "ipsec" Subject: Reliable delete notifies In-Reply-To: <5B90AD65A9E8934987DB0C8C076265740C5F19@DF-BOWWOW.platinum.corp.microsoft.com> References: <5B90AD65A9E8934987DB0C8C076265740C5F19@DF-BOWWOW.platinum.corp.microsoft.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brian Swander writes: > That is problem 1. Equally important is how reliable notifies will > work. One of the brilliant aspects of the draft (i erroneously thought) > was that it also addressed the backwards compatibility problem. I had > initially interpreted the draft to say that reliable notifies were > exactly like normal notifies, except that the payload contained an extra > Nonce field for liveness checking of the Ack. I felt this brilliant, > since down level clients who didn't support the reliable notify wouldn't > send a response, ignore the nonce, but otherwise process the message. > The cost is a few extra retransmissions, which also serve to insure that > the peer gets the message anyway. Most of the current implementations will ignore the notification if it contains anything special, and having nonce there usually qualifies as a something special. I.e that kind of backward compatibility only works for very few implementations. > It was pointed out to me, however, that there is a new exchange number > for reliable notifies. Doing this breaks all the beautiful backwards > compatibility. Of course, we can do the standard silly IKE thing of > negotiating reliable delete functionality with the vendor ID payload, or > sending double the notifies, once with the standard number, and once > with the new one. You send new notification that has new exchange type. The old implementation does not understand that and replies with INVALID-EXCHANGE-TYPE notification (because it does not know that this was notification, it will send notification even when we should not send error notifications to notifications). When you see this INVALID-EXCHANGE-TYPE you will know that the other end does not support reliable notifications and can fall back to old method. > Both of these methods seem much less clean then just > having a single info exchange ID. >From the discussion in the interop and last few IETF WGs, it seems to be that WG wants to have new version of IKE that will have some backward incompatible changes anyways. This will be done by updating the IKE version number and in new IKE version 2 we can deprecate the old exchange ID. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Oct 9 07:08:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09420; Mon, 9 Oct 2000 07:08:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00184 Mon, 9 Oct 2000 08:44:12 -0400 (EDT) Message-Id: <200010091255.IAA16481@granger.mail.mindspring.net> X-Sender: krumpli6@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 09 Oct 2000 20:59:50 -0400 To: ipsec@lists.tislabs.com From: "Thomas Porter, Ph.D." Subject: Re: Reliable delete notifies In-Reply-To: <200010090310.e993AUM18668@nyarlathotep.cis.upenn.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:10 PM 10/8/2000 -0400, you wrote: >I would in fact argue for removal of preshared-key authentication; it was >useful for debugging or for very simple setups, but the protocol complexity >introduced both directly (because of the need to support 2 or 3 auth methods) >and indirectly (encourages addition of other authentication mechanisms) are >simply not worth it. I'm not sure that it matters much here, but we need IPSec solutions, and are using them now. Without the ability to use preshared keys, we would not have been able to hack out the solutions we currently have in a production environment.. Tom > >Ways to retrieve certificates (or have temporary certificates issued, after >using XYZ authentication) are known, simple, and well-understood. >-Angelos > From owner-ipsec@lists.tislabs.com Mon Oct 9 07:12:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09513; Mon, 9 Oct 2000 07:12:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00194 Mon, 9 Oct 2000 08:46:36 -0400 (EDT) Date: Mon, 9 Oct 2000 15:58:06 +0300 (EET DST) Message-Id: <200010091258.PAA26824@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Dan Harkins Cc: Ben McCann , ipsec Subject: Re: Reliable delete notifies In-Reply-To: <200010071658.JAA22917@potassium.network-alchemy.com> References: <39DF28CF.29F19E3E@indusriver.com> <200010071658.JAA22917@potassium.network-alchemy.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > I'm doing this work for the Working Group and I can't just > unilaterally declare that Aggressive Mode is out. I was > noting that it's out of my drafty-draft. If the Working Group > wants Aggressive Mode in the protocol then it is in. So let's > start a discussion. Does the Working Group want to keep > Aggressive Mode? Is Aggressive Mode "standards bloat" or > is it a necessary addition to do what Ben wants to do? When I talked to implementors in the ipsec interop meeting most of them said, that aggressive mode should be REPLACED with base mode. Aggressive mode has lots of problems. Base mode fixes most of them, and at the same time allows dynamic ip-addresses for all kind of authentication methods. I would say we get rid of aggressive mode and add base mode instead. If we are going to keep aggressive mode, then I will say we must not add base mode, as I think even 2 different modes is little too much, 3 modes is definately too much. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Oct 9 07:52:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10125; Mon, 9 Oct 2000 07:52:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00486 Mon, 9 Oct 2000 09:54:15 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B78920F@md-exchange1.nai.com> From: "Mason, David" To: "'Tero Kivinen'" , Dan Harkins Cc: Ben McCann , ipsec Subject: RE: Reliable delete notifies Date: Mon, 9 Oct 2000 07:02:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I like the idea of replacing Aggressive Mode with Base Mode. Preshared keys will remain useful until IPSRA completes its work. I would like to see Manual key IPsec changed from MUST to MAY. I would like to see Quick Mode as always 4 messages. Solves the commit bit problem (I would like to see the commit bit go away but realize some people can't seem to live without it for some reason). In the four message QM, the initiator's key exchange payload could go in the third message allowing for DH group negotiation in phase 2. -dave -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Monday, October 09, 2000 8:58 AM To: Dan Harkins Cc: Ben McCann; ipsec Subject: Re: Reliable delete notifies Dan Harkins writes: > I'm doing this work for the Working Group and I can't just > unilaterally declare that Aggressive Mode is out. I was > noting that it's out of my drafty-draft. If the Working Group > wants Aggressive Mode in the protocol then it is in. So let's > start a discussion. Does the Working Group want to keep > Aggressive Mode? Is Aggressive Mode "standards bloat" or > is it a necessary addition to do what Ben wants to do? When I talked to implementors in the ipsec interop meeting most of them said, that aggressive mode should be REPLACED with base mode. Aggressive mode has lots of problems. Base mode fixes most of them, and at the same time allows dynamic ip-addresses for all kind of authentication methods. I would say we get rid of aggressive mode and add base mode instead. If we are going to keep aggressive mode, then I will say we must not add base mode, as I think even 2 different modes is little too much, 3 modes is definately too much. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Oct 9 08:15:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11014; Mon, 9 Oct 2000 08:15:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00701 Mon, 9 Oct 2000 10:19:51 -0400 (EDT) Message-Id: <200009291411.KAA00287@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Replacing private lines with tunnels In-reply-to: Your message of "Thu, 28 Sep 2000 11:06:38 EDT." <39D35E7E.DFCE73EB@research.telcordia.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 29 Sep 2000 10:09:14 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sanjai" == Sanjai Narain writes: Sanjai> connectivity between the gateway routers. Now suppose the private Sanjai> lines are replaced by IPSec tunnels. Then any-to-any connectivity Sanjai> will be lost. This is because router interfaces at tunnel Sanjai> endpoints will, in general, not belong to the same subnet, so Sanjai> OSPF won't work. If you are saying that OSPF does not work when one uses unnumebered PPP links, then I guess you are right. I don't see why that should be the case. There are IPsec implementations that actually have interfaces for the tunnels. NRL's was one. Recent implementations have abandoned this, claiming scalability reasons. Sanjai> So, what can be done to restore any-to-any connectivity between Sanjai> the gateway routers? In particular, do people implement a form of Sanjai> static routing over tunnels, i.e., direct the traffic coming out Sanjai> of one tunnel into another? Some do. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Oct 9 08:22:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12016; Mon, 9 Oct 2000 08:22:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00700 Mon, 9 Oct 2000 10:19:50 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "Scott G. Kelly" cc: Dan Harkins , Ari Huttunen , ipsec Message-ID: <85256970.00769E0D.00@smtpmail.certicom.com> Date: Fri, 6 Oct 2000 17:35:26 -0400 Subject: Re: Larger DH groups? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, Sorry ... I'm not a patent lawyer so I don't make patent statements ... beyond repeating what Certicom has said before. But I will fold all comments into the internal discussion process we have before updating the curves draft. BTW as far as I'm aware, the only 'formal' patent statement we have made specifically about IPSec is the one up on the IETF web page. If anyone wants to look at Certicom's patents (or anyone else's), I recommend www.patents.ibm.com. The only caveat is that as I understand it, patent applications are usually not published until 18 months after they are filed outside the US, and not before they are granted in the US. Best regards. Simon PS. As I understand it, you can't patent an algorithm, only an implementation or use of an algorithm. I don't know if this is related to the issue you mentioned below. "Scott G. Kelly" on 10/06/2000 04:06:45 PM To: Simon Blake-Wilson/Certicom@Certicom cc: Dan Harkins , Ari Huttunen , ipsec Subject: Re: Larger DH groups? My understanding from earlier statements from certicom (minneapolis ietf?) was that certicom is attempting to patent certain ec acceleration techniques, but that ec's themselves are not patentable. Your statement seems to be that ec's in any form are either patented or patent-pending by certicom. Is this correct? Simon Blake-Wilson wrote: > > Hi Dan, > > Ahh ... the eternal patent question. Unfortunately the patent system doesn't > allow the kind of black and white answer you're looking for. However I think our > IPR statement is fairly clear that we believe we have patents and patent > applcations covering ECC. Our advice to anyone implementing ECC is to take a > license from Certicom :-). > > On the IANA issue. I believe all our numbers for ECC groups were assigned by > IANA as specified in RFC 2409. I believe the link to the numbers on the IANA > site is: > http://www.isi.edu/in-notes/iana/assignments/ipsec-registry. > > Best regards. Simon > > S. Blake-Wilson > Certicom Corp. > > Dan Harkins on 10/05/2000 02:58:16 PM > > To: Simon Blake-Wilson/Certicom@Certicom > cc: Ari Huttunen , ipsec > Subject: Re: Larger DH groups? > > While updating the "Additional ECC groups for IKE" draft can you unqualify > your IP statement? Do you or do you not have patents that cover this? It > would be nice if there was a one syllable response to the question "is a > license from Certicom essential to implement these curves?" > > Also, in the AES assigned numbers thread it became obvious that certain > vendors have been assigning numbers which are reserved to IANA to their > own use of algorithms. I'd like to note that you are repeating this error > in your draft and respectfully ask you to use numbers from the private use > range for all the groups in this draft. Section 11.4 of RFC2409 describes > the procedure necessary for you to follow to get IANA to assign number to > you. > > Dan. > > On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > > > Diffie-Hellman is a cubic operation, so I believe 15000-bit DH should take > about > > 15^3 approx=3000 times as long as 1000-bit DH, and 512-bit ECDH should take > > about 25 times as long as 160-bit ECC. We don't have implementations of > > 15000-bit DH but we do have 512-bit ECDH and our performance roughly follows > the > > estimates. (In fact we're in the process of adding 512-bit curves to our > > "Additional ECC groups for IKE" draft so that it has complete AES support.) > > > > Best regards. Simon > > > > S. Blake-Wilson > > Certicom Corp. > > > > > > > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > > > To: ipsec > > cc: (bcc: Simon Blake-Wilson/Certicom) > > Subject: Larger DH groups? > > > > > > > > > > Are there plans/interest in specifying larger standard DH groups, now that > > the AES has been chosen? > > > > If so, what sizes would be appropriate? Tero earlier posted groups of > > 2000-4000 bits, the draft for AES talks about 14000. Anybody know just > > how slow would 14000 bit modulus be? (I can guess it's something between > > extremely slow and ridiculously slow..) What about the speed of a 500 bit > EC2N? > > > > Ari > > > > -- > > Ari Huttunen phone: +358 9 859 900 > > Senior Software Engineer fax : +358 9 8599 0452 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Oct 9 08:39:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14840; Mon, 9 Oct 2000 08:39:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01021 Mon, 9 Oct 2000 10:43:22 -0400 (EDT) Message-Id: <200010091454.e99EsAl135935@thunk.east.sun.com> From: Bill Sommerfeld To: Dan Harkins cc: Ben McCann , ipsec Subject: Re: Reliable delete notifies In-reply-to: Your message of "Sat, 07 Oct 2000 09:58:20 PDT." <200010071658.JAA22917@potassium.network-alchemy.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 09 Oct 2000 10:54:09 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is Aggressive Mode "standards bloat" Yes. or is it a necessary addition to do what Ben wants to do? It appears that what Ben wants to do is to use shared secret authentication by "identity" rather than ip address. it should be possible to do this with main mode; we should figure out how to tweak Main Mode to make this possible. - Bill From owner-ipsec@lists.tislabs.com Mon Oct 9 08:59:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15072; Mon, 9 Oct 2000 08:59:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01238 Mon, 9 Oct 2000 11:00:43 -0400 (EDT) Message-ID: <39E1E079.F130108D@indusriver.com> Date: Mon, 09 Oct 2000 11:12:57 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@East.Sun.COM CC: ipsec Subject: Re: Reliable delete notifies References: <200010091454.e99EsAl135935@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > Is Aggressive Mode "standards bloat" > > Yes. > > or is it a necessary addition to do what Ben wants to do? > > It appears that what Ben wants to do is to use shared secret > authentication by "identity" rather than ip address. it should be > possible to do this with main mode; we should figure out how to tweak > Main Mode to make this possible. Correct. As Jan Vilhuber so eloquently pointed out, our customers want remote access IPSEC VPN's without the hassle of deploying a PKI. Aggressive mode provides a viable (IMHO) solution for remote access with identities other than IP addresses using pre-shared keys for authentication. Other options for remote access without _requiring_ certs are: - XAUTH with a group pre-shared key. - XAUTH with Hybrid Auth. - IPSRA temporary certificates. The XAUTH solutions, while available today from a number of vendors, are not on the standards track and the third IPSRA option is far from any interoperability testing, much less deployment. So, until IPSRA defines its remote access protocols and they are implemented, Aggressive Mode is the only standards track interoperable method to do remote access without mandating adoption of a PKI as a pre-requisite for deploying a VPN. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Mon Oct 9 09:21:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15374; Mon, 9 Oct 2000 09:21:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01318 Mon, 9 Oct 2000 11:21:36 -0400 (EDT) To: Ben McCann Cc: sommerfeld@East.Sun.COM, ipsec Subject: Re: Reliable delete notifies References: <200010091454.e99EsAl135935@thunk.east.sun.com> <39E1E079.F130108D@indusriver.com> From: Derek Atkins Date: 09 Oct 2000 11:33:07 -0400 In-Reply-To: Ben McCann's message of "Mon, 09 Oct 2000 11:12:57 -0400" Message-ID: Lines: 70 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Personally, I don't see what's so hard about using e.g. RSA for authentication. It is no harder to setup an RSA-based infrastructure than it is to create a shared-secret infrastructure. Indeed, I think it is easier. You don't need a full-blown PKI for an IPSec VPN. All you need to do is have your VPN 'client' machines generate a keypair, and then 'authentically' install that certificate in some 'database' based on their userID. Linux's FreeS/WAN does this fairly easily, for example. You don't need signed certificates. Treat them just like shared secrets (which you seem to be able to handle already). Instead of assigning a password (shared secret) to an account, you assign an RSA public key. Just treat them the same for account provisioning. So, what's the problem? -derek Ben McCann writes: > Bill Sommerfeld wrote: > > > > Is Aggressive Mode "standards bloat" > > > > Yes. > > > > or is it a necessary addition to do what Ben wants to do? > > > > It appears that what Ben wants to do is to use shared secret > > authentication by "identity" rather than ip address. it should be > > possible to do this with main mode; we should figure out how to tweak > > Main Mode to make this possible. > > Correct. As Jan Vilhuber so eloquently pointed out, our customers > want remote access IPSEC VPN's without the hassle of deploying > a PKI. Aggressive mode provides a viable (IMHO) solution for > remote access with identities other than IP addresses using > pre-shared keys for authentication. > > Other options for remote access without _requiring_ certs are: > > - XAUTH with a group pre-shared key. > > - XAUTH with Hybrid Auth. > > - IPSRA temporary certificates. > > The XAUTH solutions, while available today from a number of vendors, > are not on the standards track and the third IPSRA option is far from > any interoperability testing, much less deployment. > > So, until IPSRA defines its remote access protocols and they are > implemented, Aggressive Mode is the only standards track interoperable > method to do remote access without mandating adoption of a PKI as a > pre-requisite for deploying a VPN. > > -Ben McCann > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Oct 9 10:04:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16079; Mon, 9 Oct 2000 10:04:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01488 Mon, 9 Oct 2000 12:15:40 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14817.61891.690529.301481@thomasm-u1.cisco.com> Date: Mon, 9 Oct 2000 09:26:43 -0700 (PDT) To: Ben McCann Cc: sommerfeld@East.Sun.COM, ipsec Subject: Re: Reliable delete notifies In-Reply-To: <39E1E079.F130108D@indusriver.com> References: <200010091454.e99EsAl135935@thunk.east.sun.com> <39E1E079.F130108D@indusriver.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ben McCann writes: > Correct. As Jan Vilhuber so eloquently pointed out, our customers > want remote access IPSEC VPN's without the hassle of deploying > a PKI. Aggressive mode provides a viable (IMHO) solution for > remote access with identities other than IP addresses using > pre-shared keys for authentication. > > Other options for remote access without _requiring_ certs are: > > - XAUTH with a group pre-shared key. > > - XAUTH with Hybrid Auth. > > - IPSRA temporary certificates. I'm far from up to speed on all of these protocols, but it seems that there is a potential wildcard here which is to use KINK as a scalable vehicle to key IPsec sessions using secret keys. People may want to read: draft-ietf-kink-kink-00.txt Mike From owner-ipsec@lists.tislabs.com Mon Oct 9 10:09:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16153; Mon, 9 Oct 2000 10:09:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01475 Mon, 9 Oct 2000 12:14:02 -0400 (EDT) Message-Id: <200010091620.JAA27605@potassium.network-alchemy.com> To: "Thomas Porter, Ph.D." cc: ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies In-reply-to: Your message of "Mon, 09 Oct 2000 20:59:50 EDT." <200010091255.IAA16481@granger.mail.mindspring.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27602.971108402.1@network-alchemy.com> Date: Mon, 09 Oct 2000 09:20:03 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Whatever method you used to hack out a solution using pre-shared keys could be used to hack out a solution using, say, RSA encrypt mode of authentication. You just distribute public keys instead of pre-shared keys. They both scale poorly but you can apparently deal with that in your production environment. Dan. On Mon, 09 Oct 2000 20:59:50 EDT you wrote > At 11:10 PM 10/8/2000 -0400, you wrote: > > >I would in fact argue for removal of preshared-key authentication; it was > >useful for debugging or for very simple setups, but the protocol complexity > >introduced both directly (because of the need to support 2 or 3 auth methods >) > >and indirectly (encourages addition of other authentication mechanisms) are > >simply not worth it. > > I'm not sure that it matters much here, but we need IPSec solutions, and > are using > them now. Without the ability to use preshared keys, we would not have > been able > to hack out the solutions we currently have in a production environment.. > Tom > > > >Ways to retrieve certificates (or have temporary certificates issued, after > >using XYZ authentication) are known, simple, and well-understood. > >-Angelos > > From owner-ipsec@lists.tislabs.com Mon Oct 9 14:31:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21242; Mon, 9 Oct 2000 14:31:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02466 Mon, 9 Oct 2000 16:27:16 -0400 (EDT) Message-Id: <200010092036.e99KaK712026@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: "Thomas Porter, Ph.D." , ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies In-reply-to: Your message of "Mon, 09 Oct 2000 13:35:12 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Oct 2000 16:36:20 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >I don't know if it's a problem of inadequate marketing, or with customers, >but customers don't seem to WANT any sort of Public keys. Whether it's >equivalent to pre-shared keys (in scaling) or not is apparently not the >issue (or maybe they aren't being educated by those who know, i.e. sales and >marketing). I agree that using public keys and distributing them in the same >way as pre-shared keys (except for the fact that pre-shared keys can be >typed, whereas public-keys are not easily typed by hand) scales in the same >way (i.e. doesn't ;), but there's still the fact that customers seem to WANT >pre-shared keys. > >Maybe simply getting rid of pre-shared key authentication will help customer >perception here... I wonder if it would be possible to use a supposedly pre-shared key to generate a (very weak) public/private key pair that could then be used for authentication. -Angelos From owner-ipsec@lists.tislabs.com Mon Oct 9 14:31:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21240; Mon, 9 Oct 2000 14:31:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02336 Mon, 9 Oct 2000 16:00:50 -0400 (EDT) Message-Id: <200010092010.e99K9v701326@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: "Thomas Porter, Ph.D." Cc: ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies In-reply-to: Your message of "Mon, 09 Oct 2000 20:59:50 EDT." <200010091255.IAA16481@granger.mail.mindspring.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Oct 2000 16:09:57 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200010091255.IAA16481@granger.mail.mindspring.net>, "Thomas Porter, Ph.D." writes: > >I'm not sure that it matters much here, but we need IPSec solutions, and >are using >them now. Without the ability to use preshared keys, we would not have >been able >to hack out the solutions we currently have in a production environment.. "hack" and "production environment" are very incompatible terms. There's no reason why you can't use public keys and certificates; they have a higher initial setup overhead, but that more than pays off over time in management ease. -Angelos From owner-ipsec@lists.tislabs.com Mon Oct 9 14:31:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21267; Mon, 9 Oct 2000 14:31:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02445 Mon, 9 Oct 2000 16:25:02 -0400 (EDT) Date: Mon, 9 Oct 2000 13:35:12 -0700 (PDT) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: "Thomas Porter, Ph.D." , ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies In-Reply-To: <200010092010.e99K9v701326@adk.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can't, of course, say for sure, since I'm not in marketing, but: I don't know if it's a problem of inadequate marketing, or with customers, but customers don't seem to WANT any sort of Public keys. Whether it's equivalent to pre-shared keys (in scaling) or not is apparently not the issue (or maybe they aren't being educated by those who know, i.e. sales and marketing). I agree that using public keys and distributing them in the same way as pre-shared keys (except for the fact that pre-shared keys can be typed, whereas public-keys are not easily typed by hand) scales in the same way (i.e. doesn't ;), but there's still the fact that customers seem to WANT pre-shared keys. Maybe simply getting rid of pre-shared key authentication will help customer perception here... jan On Mon, 9 Oct 2000, Angelos D. Keromytis wrote: > > In message <200010091255.IAA16481@granger.mail.mindspring.net>, "Thomas Porter, > Ph.D." writes: > > > >I'm not sure that it matters much here, but we need IPSec solutions, and > >are using > >them now. Without the ability to use preshared keys, we would not have > >been able > >to hack out the solutions we currently have in a production environment.. > > "hack" and "production environment" are very incompatible terms. > > There's no reason why you can't use public keys and certificates; they > have a higher initial setup overhead, but that more than pays off over > time in management ease. > -Angelos > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Oct 9 16:39:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA22984; Mon, 9 Oct 2000 16:39:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03580 Mon, 9 Oct 2000 18:37:08 -0400 (EDT) Date: Mon, 9 Oct 2000 18:48:01 -0400 (EDT) From: Henry Spencer To: Dan Harkins cc: Ben McCann , ipsec Subject: Re: Reliable delete notifies In-Reply-To: <200010071658.JAA22917@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 7 Oct 2000, Dan Harkins wrote: > ...Does the Working Group want to keep > Aggressive Mode? Is Aggressive Mode "standards bloat" or > is it a necessary addition to do what Ben wants to do? The FreeS/WAN project thinks it's bloat and says get rid of it. We will not implement it, ever. As others have noted, anything you can do with shared secrets, you can do better with manually-installed public keys. Now that a certain patent has died, we're moving to RSA signatures as our normal authentication method, with shared secrets not actually de-supported... at least, not yet... but moved to the "esoteric specialized topics" category already occupied by things like manual keying. This removes our last vestige of interest in Aggressive Mode. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Oct 9 18:49:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA25244; Mon, 9 Oct 2000 18:49:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03954 Mon, 9 Oct 2000 20:24:14 -0400 (EDT) Date: Mon, 9 Oct 2000 17:34:38 -0700 (PDT) From: Jan Vilhuber To: Henry Spencer cc: Dan Harkins , Ben McCann , ipsec Subject: Re: Reliable delete notifies In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 9 Oct 2000, Henry Spencer wrote: > On Sat, 7 Oct 2000, Dan Harkins wrote: > > ...Does the Working Group want to keep > > Aggressive Mode? Is Aggressive Mode "standards bloat" or > > is it a necessary addition to do what Ben wants to do? > > The FreeS/WAN project thinks it's bloat and says get rid of it. We will > not implement it, ever. > > As others have noted, anything you can do with shared secrets, you can do > better with manually-installed public keys. Actually, I've come to think (during the course of the day) that this is not actually true. With pre-shared keys, you have ONE SINGLE key. This means that I can create a special install-package for my employees, that they can install on their computer, that contains this shared-key. (Yes I know it's insecure.. bear with me). With pure public keys, you need TWO of them. Granted, I can provision every box with the same private key, which would make it equivalent to the above group-pre-shared key scenarion. But in reality you need two public keys, where before you had a single pre-shared key. Ok.. I'm not comparing apples-to-apples... So shoot me. For some reason a group-rsa-private-key bothers me even MORE than a group-pre-shared key, although that's rather irrational. Is free-swan planning or at least thinking about implementing hybrid mode? Then you could provision every peer with a central gateway's public key at installation time, and use one-time passwords for authentication... The alternative is a group-rsa-key, and xauth. Shudder. Or CRACK? jan > Now that a certain patent has > died, we're moving to RSA signatures as our normal authentication method, > with shared secrets not actually de-supported... at least, not yet... but > moved to the "esoteric specialized topics" category already occupied by > things like manual keying. This removes our last vestige of interest in > Aggressive Mode. > > Henry Spencer > henry@spsystems.net > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Oct 9 20:53:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26936; Mon, 9 Oct 2000 20:53:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA04303 Mon, 9 Oct 2000 22:42:52 -0400 (EDT) X-Authentication-Warning: samara.cisco.com: mfranz owned process doing -bs Date: Mon, 9 Oct 2000 21:08:01 +0000 (/etc/localtime) From: Matthew Franz To: Sandy Harris cc: ipsec@lists.tislabs.com Subject: Re: IPSec test suite In-Reply-To: <39DDC508.FD53C278@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Jari Arkko wrote: > > > > I believe many IPsec implementations would benefit if there was > > a comprehensive suite of test cases available in an easily > > executable form that would look not only at the "normal" cases > > of IPsec and IKE connections but also ... > > Methinks the route to it would be to modify one of the open source > IPSEC implementations. Even unmodified, one or more of them is > likely a good testing tool. > IMHO a better path (because it is more portable) would be to add AH, ESP, IKE, et. al. support to Libnet (http://www.packetfactory.net), which is a platform-independant API for generating various types of legal and illegal TCP/IP packets. This avoids a Linux-*BSD holy war and allows non-open source Unices (and perhaps even Win32) to utilize such a toolset. -mdf From owner-ipsec@lists.tislabs.com Mon Oct 9 20:56:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26979; Mon, 9 Oct 2000 20:56:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA04380 Mon, 9 Oct 2000 23:05:16 -0400 (EDT) Date: Mon, 9 Oct 2000 23:16:14 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: ipsec Subject: Re: Reliable delete notifies In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 9 Oct 2000, Jan Vilhuber wrote: > With pure public keys, you need TWO of them. Granted, I can provision every > box with the same private key, which would make it equivalent to the above > group-pre-shared key scenarion. But in reality you need two public keys, > where before you had a single pre-shared key. Consider them two halves of the same shared secret. There's no fundamental difference... > Is free-swan planning or at least thinking about implementing hybrid mode? Not at present. Faced with a choice of methods, we have a strong preference for picking one good general-purpose method and using it throughout, and we've chosen RSA signatures as the best general-purpose authentication method. (We'd like to make it easier for our contributors to contribute other authentication methods, but we have no plans to do any others ourselves.) > Then you could provision every peer with a central gateway's public key at > installation time, and use one-time passwords for authentication... Actually you don't even need to provision the peers with the gateway's public key, if you trust DNS lookups -- you can get it from DNS. But we have no plans to support any password scheme... although it wouldn't be hard to do one-time RSA keys by adding a few tweaks to scripts. :-) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Oct 9 21:12:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27236; Mon, 9 Oct 2000 21:12:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA04364 Mon, 9 Oct 2000 23:01:04 -0400 (EDT) To: Matthew Franz cc: Sandy Harris , ipsec@lists.tislabs.com In-reply-to: mfranz's message of Mon, 09 Oct 2000 21:08:01 GMT. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSec test suite From: itojun@iijlab.net Date: Tue, 10 Oct 2000 12:12:08 +0900 Message-ID: <3869.971147528@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> > I believe many IPsec implementations would benefit if there was >> > a comprehensive suite of test cases available in an easily >> > executable form that would look not only at the "normal" cases >> > of IPsec and IKE connections but also ... >> Methinks the route to it would be to modify one of the open source >> IPSEC implementations. Even unmodified, one or more of them is >> likely a good testing tool. >IMHO a better path (because it is more portable) would be to add AH, ESP, >IKE, et. al. support to Libnet (http://www.packetfactory.net), which is a >platform-independant API for generating various types of legal and illegal >TCP/IP packets. This avoids a Linux-*BSD holy war and allows non-open >source Unices (and perhaps even Win32) to utilize such a toolset. you may want to check www.tahi.org (TAHI project). they ship IPv6/IPsec (supports IPv4 too, I believe) conformance test suite as a free software. itojun From owner-ipsec@lists.tislabs.com Tue Oct 10 02:11:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06605; Tue, 10 Oct 2000 02:11:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05250 Tue, 10 Oct 2000 03:26:33 -0400 (EDT) Reply-To: From: "Awan kumar" To: "IpsecMailingList (E-mail)" Subject: FW: Negotiation for Ipsec SA Date: Tue, 10 Oct 2000 13:11:17 +1000 Message-Id: <000001c03267$c26cbba0$6d0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am sorry if this has been discussed earlier. I have some doubt in the negotiation of Ipsec SA. When Ipsec decides to establish an Ipsec SA and sends an SADB_ACQUIRE (PF_KEY Mesage) to the key management daemon. 1) For how much time should we wait for the SA to get negotiated. I feel this is required. 2) If my first point is relevant, then should the time for the renegotiation of the Ipsec SA, after the soft lifetime expires, be less then the difference of the soft and hard seconds lifetime. Any comments on this are most welcome. Awan Kumar Sharma From owner-ipsec@lists.tislabs.com Tue Oct 10 02:26:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06934; Tue, 10 Oct 2000 02:26:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA05361 Tue, 10 Oct 2000 04:24:50 -0400 (EDT) Message-ID: <39E2D4BF.6BA1E7D7@cisco.com> Date: Tue, 10 Oct 2000 10:35:11 +0200 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: "Angelos D. Keromytis" , "Thomas Porter, Ph.D." , ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can answer that (I am not marketting but I work at a call center and I face questions every day. I also realized the deep misunderstanding during conferences I presented). First, people do not understand IPSec and even less IKE. When you find someone who knows the basics, he generally does not understand how the keys are used. Worse, in the mind of people, the IKE keys are used to encrypt the traffic (sic.). They also believe pre-shared keys are worse than certs or RSA because the pre-shared key is _shorter_ (and no other reason). They do not want RSA or PKI for simple reasons: . it is easier to type a pre-shared key that looks like a password. They feel more under control. Transfering large public keys is simply hassle and they feel insecure. . public key algorithms blow their mind. They do not see how the RSA keys are related to 3des and so on (sic. again). Or they do not understand why they need the CA cert and the device cert and things like that. . People believe they have to leave the CA on all the time in all the case (they see it working like DNS sec). They are also afraid the certs are made public (oh yes). . PKI are bloody expensive and softwares are awfully complex. There is no simple CA to put to work. It always has to be a fully bloated software with tons of components (namely LDAP) people barely understand. I have only seen a single CA easy to set up but the documentation was very poor (unfortunately). The enrollement protocols are very hard to understand (because they alreayd missed the previous step) and CRL's are even worse. In short: . it is a matter of education. IKE is still too new to be understood. . PKI vendors need to come with something veeeeery simple (click click click, no ldap, no tons of passwords, no tons of roles and everything). . Enrollment protocols are an extra complexity (for the challenged). it should always be possible to copy-paste the certs. frederic detienne -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 Jan Vilhuber wrote: > > I can't, of course, say for sure, since I'm not in marketing, but: > > I don't know if it's a problem of inadequate marketing, or with customers, > but customers don't seem to WANT any sort of Public keys. Whether it's > equivalent to pre-shared keys (in scaling) or not is apparently not the > issue (or maybe they aren't being educated by those who know, i.e. sales and > marketing). I agree that using public keys and distributing them in the same > way as pre-shared keys (except for the fact that pre-shared keys can be > typed, whereas public-keys are not easily typed by hand) scales in the same > way (i.e. doesn't ;), but there's still the fact that customers seem to WANT > pre-shared keys. > > Maybe simply getting rid of pre-shared key authentication will help customer > perception here... > > jan > > On Mon, 9 Oct 2000, Angelos D. Keromytis wrote: > > > > > In message <200010091255.IAA16481@granger.mail.mindspring.net>, "Thomas Porter, > > Ph.D." writes: > > > > > >I'm not sure that it matters much here, but we need IPSec solutions, and > > >are using > > >them now. Without the ability to use preshared keys, we would not have > > >been able > > >to hack out the solutions we currently have in a production environment.. > > > > "hack" and "production environment" are very incompatible terms. > > > > There's no reason why you can't use public keys and certificates; they > > have a higher initial setup overhead, but that more than pays off over > > time in management ease. > > -Angelos > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Oct 10 03:35:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10765; Tue, 10 Oct 2000 03:35:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05572 Tue, 10 Oct 2000 05:26:20 -0400 (EDT) Date: Tue, 10 Oct 2000 11:37:25 +0200 (Israel Standard Time) From: Arne Ansper To: Ben McCann cc: ipsec Subject: Re: Reliable delete notifies In-Reply-To: <39E1E079.F130108D@indusriver.com> Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Correct. As Jan Vilhuber so eloquently pointed out, our customers > want remote access IPSEC VPN's without the hassle of deploying > a PKI. Aggressive mode provides a viable (IMHO) solution for certificates and PKI are there to authenticate public keys. there are other ways to accomplish the same task. for example one can take hash of the self signed certificate (or any certificate), convert it into base64 form, name it "shared non-secret" and pass this string around much like you do with shared secrets. your peer will enter this string into his ipsec device which will use it to verify authenticity of certificates presented by his peers. you don't have to change ike or ipsec or anything. you must just tweak your certificate validation routine to accept certificates by theri hash, not by signature. arne From owner-ipsec@lists.tislabs.com Tue Oct 10 07:25:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18316; Tue, 10 Oct 2000 07:25:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06153 Tue, 10 Oct 2000 09:10:34 -0400 (EDT) Message-Id: <200010101320.e9ADKVh11372@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: fd@cisco.com Cc: Jan Vilhuber , "Thomas Porter, Ph.D." , ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies In-reply-to: Your message of "Tue, 10 Oct 2000 10:35:11 +0200." <39E2D4BF.6BA1E7D7@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Oct 2000 09:20:31 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >. it is a matter of education. IKE is still too new to be understood. >. PKI vendors need to come with something veeeeery simple (click click click, >no ldap, no tons of passwords, no tons of roles and everything). >. Enrollment protocols are an extra complexity (for the challenged). it should > always be possible to copy-paste the certs. Fred, I think you're exactly right. It's interesting that (two of) the free implementations (FreeS/WAN and OpenBSD) are actually arguing for public key authentication exclusively. FreeS/ WAN uses OpenSSL, OpenBSD uses both OpenSSL and KeyNote for certificates -- both do not in fact require any type of infrastructure to use the certificates, and both allow cut-and-paste. Unfortunately, it's still not simple to generate those certs... Having to interoperate with the commercial PKI vendors has always been a pain, because they each have non-intuitive ways of importing or exporting certs (some require LDAP or other brain-dead schemes). -Angelos From owner-ipsec@lists.tislabs.com Tue Oct 10 09:46:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02103; Tue, 10 Oct 2000 09:46:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06835 Tue, 10 Oct 2000 11:48:12 -0400 (EDT) Message-Id: <200010101559.LAA14678@solidum.com> To: ipsec Subject: Re: Reliable delete notifies In-Reply-To: Your message of "09 Oct 2000 11:33:07 EDT." Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Oct 2000 11:59:47 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> Personally, I don't see what's so hard about using e.g. RSA for Derek> authentication. It is no harder to setup an RSA-based Derek> infrastructure than it is to create a shared-secret Derek> infrastructure. Indeed, I think it is easier. Derek> You don't need a full-blown PKI for an IPSec VPN. All you need to You do if your vendor bought a semi-closed PKI solution from a PKI vendor! That is where this entire argument comes from --- the business models of the PKI vendors. From owner-ipsec@lists.tislabs.com Tue Oct 10 09:47:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02215; Tue, 10 Oct 2000 09:47:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06817 Tue, 10 Oct 2000 11:42:56 -0400 (EDT) Message-Id: <200010101554.LAA14452@solidum.com> To: ipsec Subject: Re: Reliable delete notifies In-Reply-To: Your message of "Sun, 08 Oct 2000 23:10:30 EDT." <200010090310.e993AUM18668@nyarlathotep.cis.upenn.edu> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Oct 2000 11:54:30 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Angelos" == Angelos D Keromytis writes: Angelos> I would in fact argue for removal of preshared-key Angelos> authentication; it was useful for debugging or for very simple Angelos> setups, but the protocol complexity introduced both directly Angelos> (because of the need to support 2 or 3 auth methods) and Angelos> indirectly (encourages addition of other authentication Angelos> mechanisms) are simply not worth it. I would agree to this on one condition only: That the spec lists a simple, well known format (i.e. PKCS10) by which self-signed certificates can be loaded into the trusted store, and by which they will be produced. That implementations *MUST* support this. Debugging a CA system as well as IKE is simply a non-starter. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Oct 10 11:43:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07312; Tue, 10 Oct 2000 11:43:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07274 Tue, 10 Oct 2000 13:32:25 -0400 (EDT) To: Michael Richardson Cc: ipsec Subject: Re: Reliable delete notifies References: <200010101559.LAA14678@solidum.com> From: Derek Atkins Date: 10 Oct 2000 13:43:42 -0400 In-Reply-To: Michael Richardson's message of "Tue, 10 Oct 2000 11:59:47 -0400" Message-Id: Lines: 35 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Then change your PKI vendor or, shudder, implement RSA yourself in your IPSec software. Now that RSA is free, you can do that. If MIT freshmen can implement RSA, I'm sure your IPSec engineers can do it. As I said, you DONT need a full PKI. You can treat RSA keys just like you treat secret keys. Instead of passing a single string of bytes, you pass, in essense, two strings of bytes (N and e :) You DO NOT NEED signed certificates for this functionality. If your PKI vendor doesn't support that, route around them :) Look at FreeS/WAN for a great way to do it (and no, I'm NOT on the freeswan team -- I'm just a user). -derek Michael Richardson writes: > >>>>> "Derek" == Derek Atkins writes: > Derek> Personally, I don't see what's so hard about using e.g. RSA for > Derek> authentication. It is no harder to setup an RSA-based > Derek> infrastructure than it is to create a shared-secret > Derek> infrastructure. Indeed, I think it is easier. > > Derek> You don't need a full-blown PKI for an IPSec VPN. All you need to > > You do if your vendor bought a semi-closed PKI solution from a PKI vendor! > > That is where this entire argument comes from --- the business models > of the PKI vendors. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Oct 10 12:00:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08006; Tue, 10 Oct 2000 12:00:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07377 Tue, 10 Oct 2000 14:03:53 -0400 (EDT) From: Dan McDonald Message-Id: <200010101814.e9AIEqS29979@kebe.Eng.Sun.COM> Subject: Re: FW: Negotiation for Ipsec SA In-Reply-To: <000001c03267$c26cbba0$6d0c000a@future.futsoft.com> from Awan kumar at "Oct 10, 2000 01:11:17 pm" To: awank@future.futsoft.com Date: Tue, 10 Oct 2000 11:14:52 -0700 (PDT) CC: pf_key@inner.net Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First off, if you have a questions specific to PF_KEY, try the PF_KEY mailing list: pf_key@inner.net. (This concludes the part of the note relevant to the IPsec mailing list. Sorry for the additional traffic, boys and girls!) > I am sorry if this has been discussed earlier. I have some doubt in the > negotiation of Ipsec SA. When Ipsec decides to establish an Ipsec SA and > sends an SADB_ACQUIRE (PF_KEY Mesage) to the key management daemon. > > 1) For how much time should we wait for the SA to get negotiated. I feel > this is required. Actually, it depends a lot on the KM protocol (or worse, what mode of the KM protocol) that handles the ACQUIRE message. If it's a low-latency thing like KINK promises, or if it's IKE with an already-established Phase 1, it can be really short. OTOH, if you need to establish a Phase 1 SA complete with LDAP lookups certificate (and maybe even policy), then it's going to be a while before the first results from the UPDATE hit the kernel's SADB. For example: in Solaris, we make this an ndd(1m) tunable. (See /dev/ipsecesp, ipsecesp_acquire_timeout. It'll move somewhere else when we have extended ACQUIREs built.) > 2) If my first point is relevant, then should the time for the renegotiation > of the Ipsec SA, after the soft lifetime expires, be less then the > difference of the soft and hard seconds lifetime. Absolutely! This depends, of course, on two things: 1.) You can handle soft-lifetime EXPIRE messages as a hint to start a new negotiation (and possibly knowing what was negotiatied before). 2.) The other side doesn't decide to beat you to it! Dan From owner-ipsec@lists.tislabs.com Tue Oct 10 16:45:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17028; Tue, 10 Oct 2000 16:45:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08225 Tue, 10 Oct 2000 18:35:40 -0400 (EDT) Date: Tue, 10 Oct 2000 18:46:35 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Reliable delete notifies In-Reply-To: <200010101554.LAA14452@solidum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 10 Oct 2000, Michael Richardson wrote: > Angelos> I would in fact argue for removal of preshared-key > Angelos> authentication... > > I would agree to this on one condition only: > That the spec lists a simple, well known format (i.e. PKCS10) by which > self-signed certificates can be loaded into the trusted store, and by which > they will be produced. That implementations *MUST* support this. I would agree wholeheartedly with this. This is a problem we've run into during interoperability testing: even when both parties are perfectly happy to exchange RSA keys manually, no two systems agree on the key-exchange data format. Personally, I'd favor something much closer to RFC 2537 format -- it's far simpler than any form of certificate -- but *any* standard, even a messy one, would be better than none. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Oct 10 16:45:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17048; Tue, 10 Oct 2000 16:45:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08254 Tue, 10 Oct 2000 18:41:05 -0400 (EDT) Message-Id: <200010102250.e9AMo5732509@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: Henry Spencer Cc: IP Security List Subject: Re: Reliable delete notifies In-reply-to: Your message of "Tue, 10 Oct 2000 18:46:35 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Oct 2000 18:50:05 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spe ncer writes: > >I would agree wholeheartedly with this. This is a problem we've run into >during interoperability testing: even when both parties are perfectly >happy to exchange RSA keys manually, no two systems agree on the >key-exchange data format. Personally, I'd favor something much closer to >RFC 2537 format -- it's far simpler than any form of certificate -- but >*any* standard, even a messy one, would be better than none. That has been our experience (OpenBSD) as well; it is the rare vendor that allows import/export of third-party certificates (I personally know of only one). -Angelos From owner-ipsec@lists.tislabs.com Wed Oct 11 02:07:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA00798; Wed, 11 Oct 2000 02:07:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA09958 Wed, 11 Oct 2000 03:46:01 -0400 (EDT) Date: Wed, 11 Oct 2000 09:57:11 +0200 (IST) From: Hugo Krawczyk To: Henry Spencer cc: ipsec Subject: ike and secure DNS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to gather information on existing projects (commerical or academic) working towards the integration of DNSSEC infrastructure and IKE/ipsec. I know FreeSWAN has such integration plans? Any progress in that front? Other experiences? Thanks, Hugo On Mon, 9 Oct 2000, Henry Spencer wrote: > > > Then you could provision every peer with a central gateway's public key at > > installation time, and use one-time passwords for authentication... > > Actually you don't even need to provision the peers with the gateway's > public key, if you trust DNS lookups -- you can get it from DNS. > > From owner-ipsec@lists.tislabs.com Wed Oct 11 04:13:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06390; Wed, 11 Oct 2000 04:13:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10431 Wed, 11 Oct 2000 06:14:24 -0400 (EDT) From: Bill Manning Message-Id: <200010111025.DAA06812@zed.isi.edu> Subject: Re: ike and secure DNS To: hugo@ee.technion.ac.il (Hugo Krawczyk) Date: Wed, 11 Oct 2000 03:25:54 -0700 (PDT) Cc: henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) In-Reply-To: from "Hugo Krawczyk" at Oct 11, 2000 09:57:11 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A couple academic projects, TBDS and FMESHD, are either dependent on working DNSSEC or leverage DNSSEC for key exchange, while the upcoming DNSSEC workshop on the 25th in WDC will be evaluating DNSSEC viability in the ip6.int tree. If that can be shown to be stable, it can act as a precursor to a signed in-addr.arpa. and other address-name trees. I think this is what is needed to exploit any IKE/ipsec & DNS interactions since that will give us a "chain-of-custody" up the delegation heirarchy. Does Free/SWAN have this as a shared goal? % % % I'd like to gather information on existing projects (commerical or % academic) working towards the integration of DNSSEC infrastructure and % IKE/ipsec. I know FreeSWAN has such integration plans? Any progress in % that front? Other experiences? % % Thanks, % % Hugo % % On Mon, 9 Oct 2000, Henry Spencer wrote: % > % > > Then you could provision every peer with a central gateway's public key at % > > installation time, and use one-time passwords for authentication... % > % > Actually you don't even need to provision the peers with the gateway's % > public key, if you trust DNS lookups -- you can get it from DNS. % % > % > % % % -- --bill From owner-ipsec@lists.tislabs.com Wed Oct 11 06:05:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10811; Wed, 11 Oct 2000 06:05:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10942 Wed, 11 Oct 2000 08:03:34 -0400 (EDT) Message-Id: <200010110911.CAA16157@gallium.network-alchemy.com> To: "Angelos D. Keromytis" cc: "Thomas Porter, Ph.D." , ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies In-Reply-To: Message from "Angelos D. Keromytis" of "Mon, 09 Oct 2000 16:09:57 EDT." <200010092010.e99K9v701326@adk.gr> Date: Wed, 11 Oct 2000 02:11:54 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There's no reason why you can't use public keys and certificates; they > have a higher initial setup overhead, but that more than pays off over > time in management ease. > -Angelos I feel compelled to echo what Jan has already said. For whatever reason, many of our customers are extremely reluctant to use PKI-based authentication. We even have a built-in CA in our product and probably 30% of our customers still prefer to use pre-shared keys for site-to-site authentication. Beat's me why, but they do. I wasn't able to attend the last bake-off, but from what I heard and read from folks who attended, I don't sense that we're at the level of interoperability between PKI-enabled IPSec implementations that we need to be at before we can remove pre-shared keys from the standard. Derrell From owner-ipsec@lists.tislabs.com Wed Oct 11 06:05:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10814; Wed, 11 Oct 2000 06:05:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10941 Wed, 11 Oct 2000 08:03:34 -0400 (EDT) Message-Id: <200010110919.CAA16174@gallium.network-alchemy.com> To: Henry Spencer cc: Dan Harkins , Ben McCann , ipsec Subject: Re: Reliable delete notifies In-Reply-To: Message from Henry Spencer of "Mon, 09 Oct 2000 18:48:01 EDT." Date: Wed, 11 Oct 2000 02:19:19 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For purposes of concensus, I think Aggressive Mode is bloat and I'd like to remove it. There are ways to use pre-shared keys without fixed IP addresses which solve the problem without giving up identity protection. Aggressive Mode is a remnant of the SKIP vs ISAKMP debate which optimized round-trips at the expense of protocol complexity. It was a bad design decision on our part to include it in the first place. Derrell From owner-ipsec@lists.tislabs.com Wed Oct 11 06:11:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11235; Wed, 11 Oct 2000 06:11:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA10905 Wed, 11 Oct 2000 07:55:34 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'ipsec'" Subject: Simplifying IKE (was RE: Reliable delete notifies) Date: Wed, 11 Oct 2000 07:58:28 -0400 Message-Id: <007201c0337a$955ed260$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200010091454.e99EsAl135935@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It has been my observation that just about everything we have do for the sake of some type of optimization (memory, latency, throughput), has made IKE into a more complex and ambiguous protocol. Examples: aggressive mode, dangling phase 2s, 3 message quick mode, 2 byte CPIs, arcane attribute encoding schemes (which only save a byte or two). Why isn't there a message counter in the isakmp header (i.e. MM3)? I know it's redundant, but it would sure make the state machine easier on lossy networks. Forget aggressive mode as an optimization and think only of the security properties it gives you: no identity protection (so you can use preshared keys) and DoS resistance (trading one attack for another, actually). Base mode would cause a lot fewer interoperability problems than aggressive mode because it works just like main mode except without the KE. Or we could go a step farther, as Bill has suggested, and tweak main mode. (However, I think that keeping Base Mode as a separate exchange mode is actually less complex.) I'm not sure that merging the big 3 documents will actually make IKE easier to understand. ISAKMP is fine as it is, as far as I'm concerned. Merging IKE and DOI seems more sensible, although I'm worried that they will end up being shorter; IKE is too terse already. It should be more restrictive... recommend a payload ordering, restrict vendor ids to MM1&2 only, put some kind of limitation on rekeying, use a counter for the message id. I doubt this is a popular belief, but I would like to see a fourth document, something that was hinted at in the Schneier/Ferguson analysis of IKE: an explanation of what properties the IKE protocol is meant to have -- a derivation of the formulas, e.g. SKEYID derivation, key refresh, cookie calculation, what PFS will accomplish, what "uniqueness" of the message id means. ;-) I don't understand the argument about extra algorithms causing interoperability problems. Public key encryption has never caused an interoperability problem for us because we simply don't support it. I can understand how some people might want a non-repudation property in their authentication algorithm, and I think the protocol shouldn't limit that, but those aren't the kinds of people who buy our products. And I don't understand this whole "derive a pre-shared key from a self-signed certificate" thing. The whole point of using certificates (IMHO only, I have discovered) is that they have extra properties that preshared keys do not have (e.g. the fact that they can be publicly distributed without revealing the key). If you use the hash of a self-signed certificate as a preshared key (in which case you cannot distribute the certificate publicly) then you inherit the worst of both worlds. TimeStep has supported certificates for 6 years or so, and for intra-domain communication they are great. But believe it or not, I have seen situations where preshared keys are much easier to deploy than certificates. One example is inter-domain communication where the two gateways have different trusted roots (and restrictive policy rules). Yes, I know you *can* solve this problem using certificates (by cross-certifying the gateways or by creating a new domain exclusively for the connection), but I hardly think that is easier than using a single preshared key. At the heart of this discussion, I think, is an effort to legislate the way in which IPsec is used. The IETF overlords can't directly impose their whims on customers, so instead they place that burden on us, the implementors. This smacks of the whole IPSRA problem. I happen to prefer protocols that don't come with a political agenda. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Oct 11 07:23:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15306; Wed, 11 Oct 2000 07:23:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11211 Wed, 11 Oct 2000 09:09:35 -0400 (EDT) Message-ID: <39E46510.85ECA14@oracle.com> Date: Wed, 11 Oct 2000 18:33:12 +0530 From: Arvind Devarajan Organization: Oracle Corporation X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, x-kernel-l@it.swin.edu.au Subject: Help - IPSEC beginner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi all, as a part of my Masters, i am developing the IPSec code - ground up. well, as it stands, i am very new to IPSec, and have just managed to go through the RFC 2401. My project is for 2.5 months from now. i know that this is too short a time to do anything much in IPSec, but, i've got this plan: at the end of the 2.5 months period, i'll have these: 1. SPD and SAD interface code: 1. Code that reads packet headers 2. Queries SPD entries 3. Queries/Adds SAD entries 2. AH and ESP 1. As of now, i propose using a simple form of encryption, or use any freely available encyption code. (I am not working for compatibility with other systems) 2. No support for nested SAs (or can i support them in the given period?) 3. Support only for transport mode. 4. IPV4 assumed. 5. Auditing: Not fullfledged 3. IKE 1. Manual. Very simple methods 4. Test program 1. Write a small program that tests. Help needed later. I am not sure whether i have the right decisions done here. probably, experts in this list could coment on my plans. i am going to implement this on the XKernel - a protocol framework from university of Arizona. As of now, i have gone through the XKernel architecture, and fully well understand the details involved in implementing a new protocol. My problem is mainly with the protocol itself - IPSec (or, may i say - a collection of smaller protocols?) I would greatly appreciate help from people in these lists. To begin with, i have not yet decided the data structures, etc. that i will be having in the code. i am reading the freeswan code too, but, since my platform is XKernel, i do not quiet think that freeswan way of creating an IPSec vitual interface, and then having SAD in proc filesystem would work. Here are some basic doubts: 1. SPD is a static database. I am proposing to have it in the form of a flat file. The file format would be something like this (for each entry): [ENTRY] dstaddr= srcaddr= name= sensitivity= tlp= dstport= srcport= action= sas= how= In my initalisation code, i'll read these entries in the in-core memory. i guess there should be two such files - one for INBOUND packets and one for OUBOUND packets. Please coment on this way of having the SPD 1. SAD: I am not very sure - is this a static database? I my opinion, the administrator has a startup SAD created. I am proposing to have a similar file structure (as above) for SAD too. The reason for having a doubt of whether the SAD is static or dynamic springs from the fact that the oubound processing _creates_ a new SA if an SA does not already exist to satisfy the selected SPD entry. (Please coment) Secondly, when an incoming packet arrives, accordinf to the RFC, if an SA does not already exist (seen from the IP Dest addr/Proto/SPI), the packet is _dropped_. If this should not happen, admin can (or, can he?) create a startup SAD as said above. (Please coment) Should SAD also be separate for inbound and outbound packets? 2. For XKernel experts: Do i need to write a socket interface for writing my test program? i've seen that XKernel has a socket interface called XKSocket, that is specifically written for Mac. I am using Linux. If this is a laborious task, i propose writing an ipsectest protocol, just as many other such tests written as a part of Xkernel. Which, in your opinions is the best? Once i start, i propose giving a regular update on what i have done, so that my progress is helped by you. Awaiting a reply. I will be writing about my data structures, and coding styles later. Thanking you, arvind. From owner-ipsec@lists.tislabs.com Wed Oct 11 08:03:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18129; Wed, 11 Oct 2000 08:03:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11345 Wed, 11 Oct 2000 09:54:26 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'IP Security List'" Subject: Definition of PFS... Date: Wed, 11 Oct 2000 09:50:54 -0400 Message-Id: <007a01c0338a$476ad120$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I recently decided to do some research on something that has bugged me for quite awhile now: What is the point of doing PFS in phase 2? The reason I wonder about this is that presumably you will use the same group in phase 2 that you used in phase 1, so if an adversary can crack your phase 1 DH then he can presumably expend the 1 bit of additional effort required to crack the phase 2 DH. It seems like you would be better off using a larger modulus for the initial DH rather than wasting your CPU resources on subsequent DH's with small moduli. In reading the archives, it appears that the meaning of PFS has changed over the years. Originally, PFS referred to any mode of operation in which the session key could not be derived directly from the long term credentials. PGP, for example, was criticized for not having a PFS mode. The addition of a single DH exchange to the KMP (SKIP/Photuris) was all that was necessary for PFS. So at what point did it become necessary to do a second DH exchange in order to accomplish PFS? Is SKEYID_D now considered to be a "long term credential?" Using the original definition, why can't PFS be accomplished simply by occasional phase 1 rekeying? Could someone who has been following this WG since the time of SKIP please explain how and why the meaning has changed? (To avoid confusion, I'm going to refer to the mode of PFS used in IKE as QM PFS.) IKE w/ QM PFS appears to offer one advantage over IKE w/o QM PFS, which is the consequence of SKEYID compromise. Without QM PFS, cracking SKEYID will reveal all past and future traffic. With QM PFS, cracking SKEYID will only allow the adversary to intercept future traffic (and impersonate both parties). But isn't this splitting hairs? Both of those situations are very serious security breaches. In terms of the volume of data that is compromised, it seems reasonable to believe that QM PFS will, on average, cut the consequences of compromise in half. Since when is 1 bit significant? I suppose it is possible that an implementation might think it is capable of detecting a security breach in real time. If that is the case, a host would be able to detect the attack and immediately tear down the phase 1 SA, thus limiting the damage to a single IPsec session key. Is that the scenerio that QM PFS is meant to guard against? Somehow I doubt it. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Oct 11 08:21:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20597; Wed, 11 Oct 2000 08:21:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11433 Wed, 11 Oct 2000 10:17:19 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Bill Manning Cc: hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) Subject: Re: ike and secure DNS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Oct 2000 10:28:46 -0400 Message-Id: <20001011142847.2866435DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200010111025.DAA06812@zed.isi.edu>, Bill Manning writes: > A couple academic projects, TBDS and FMESHD, are either dependent on > working DNSSEC or leverage DNSSEC for key exchange, while the upcoming > DNSSEC workshop on the 25th in WDC will be evaluating DNSSEC viability > in the ip6.int tree. If that can be shown to be stable, it can act as > a precursor to a signed in-addr.arpa. and other address-name trees. > I think this is what is needed to exploit any IKE/ipsec & DNS interactions > since that will give us a "chain-of-custody" up the delegation heirarchy. > Does Free/SWAN have this as a shared goal? I'd love to see any sort of secure address-to-entity map. But there seems to be considerable uncertainty about who actually owns various chunks of address space. Is the database clean enough that it's worth signing? I sure don't get that impression from, say, the NANOG list. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Oct 11 08:21:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20610; Wed, 11 Oct 2000 08:21:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11448 Wed, 11 Oct 2000 10:19:32 -0400 (EDT) Message-Id: <200010111431.SAA04298@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: "'ipsec'" , Date: Wed, 11 Oct 2000 18:30:20 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-reply-to: <007201c0337a$955ed260$d23e788a@andrewk3.ca.newbridge.com> References: <200010091454.e99EsAl135935@thunk.east.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 11 Oct 00, at 7:58, Andrew Krywaniuk wrote: > It has been my observation that just about everything we have do for the > sake of some type of optimization (memory, latency, throughput), has made > IKE into a more complex and ambiguous protocol. > > Examples: aggressive mode, dangling phase 2s, 3 message quick mode, 2 byte > CPIs, arcane attribute encoding schemes (which only save a byte or two). > > Why isn't there a message counter in the isakmp header (i.e. MM3)? I know > it's redundant, but it would sure make the state machine easier on lossy > networks. > > Forget aggressive mode as an optimization and think only of the security > properties it gives you: no identity protection (so you can use preshared > keys) and DoS resistance (trading one attack for another, actually). Base > mode would cause a lot fewer interoperability problems than aggressive mode > because it works just like main mode except without the KE. Or we could go a > step farther, as Bill has suggested, and tweak main mode. (However, I think > that keeping Base Mode as a separate exchange mode is actually less > complex.) > > I'm not sure that merging the big 3 documents will actually make IKE easier > to understand. ISAKMP is fine as it is, as far as I'm concerned. Merging IKE It probably will. But there is one thing that I'm worried about: merging all in one document may close the doors to independently enhance protocol parts - every such attempt will require updating of this big document. Currently ISAKMP defines the framework in which different key management protocols may be defined. Nowdays IKE is the only of such protocols, but the room for others is still here. Combining everything into one document will probably mean "IKE forever" - the approach that I'm not too happy about. > and DOI seems more sensible, although I'm worried that they will end up > being shorter; IKE is too terse already. It should be more restrictive... > recommend a payload ordering, restrict vendor ids to MM1&2 only, put some > kind of limitation on rekeying, use a counter for the message id. > > I doubt this is a popular belief, but I would like to see a fourth document, > something that was hinted at in the Schneier/Ferguson analysis of IKE: an > explanation of what properties the IKE protocol is meant to have -- a > derivation of the formulas, e.g. SKEYID derivation, key refresh, cookie > calculation, what PFS will accomplish, what "uniqueness" of the message id > means. ;-) I concur. > I don't understand the argument about extra algorithms causing > interoperability problems. Public key encryption has never caused an > interoperability problem for us because we simply don't support it. I can > understand how some people might want a non-repudation property in their > authentication algorithm, and I think the protocol shouldn't limit that, but > those aren't the kinds of people who buy our products. > > And I don't understand this whole "derive a pre-shared key from a > self-signed certificate" thing. The whole point of using certificates (IMHO > only, I have discovered) is that they have extra properties that preshared > keys do not have (e.g. the fact that they can be publicly distributed > without revealing the key). If you use the hash of a self-signed certificate > as a preshared key (in which case you cannot distribute the certificate > publicly) then you inherit the worst of both worlds. > > TimeStep has supported certificates for 6 years or so, and for intra-domain > communication they are great. But believe it or not, I have seen situations > where preshared keys are much easier to deploy than certificates. One > example is inter-domain communication where the two gateways have different > trusted roots (and restrictive policy rules). Yes, I know you *can* solve > this problem using certificates (by cross-certifying the gateways or by > creating a new domain exclusively for the connection), but I hardly think > that is easier than using a single preshared key. > > At the heart of this discussion, I think, is an effort to legislate the way > in which IPsec is used. The IETF overlords can't directly impose their whims > on customers, so instead they place that burden on us, the implementors. > This smacks of the whole IPSRA problem. I happen to prefer protocols that > don't come with a political agenda. Me too. > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Wed Oct 11 08:30:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22277; Wed, 11 Oct 2000 08:30:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11521 Wed, 11 Oct 2000 10:31:43 -0400 (EDT) From: kalluraya@netzero.net Message-ID: <002f01c03391$ea3b4040$adcdf5d1@prash> Reply-To: To: Subject: use of HAMC-MD5 with AH or ESP Date: Wed, 11 Oct 2000 09:45:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C03367.FFA93060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C03367.FFA93060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I was wondering if anyone could help me by answering my question = regarding the way HMAC-MD5-96 used with AH or ESP. The RFC2403 says, = HMAC-MD5-96 operates on 64 bytes of data and a produces a message digest = of 128bit value. What I didn't understand is, when a packet has more than 64 bytes of = data (say 512bytes), how do you feed rest of the blocks and how to = handle the intermediate mesage digests.(In this case one will have 8 = messgae digests generated for every 64 byte block of data). I would really appreciate if someone can help me unedrstand this. Thanx Prashanth ------=_NextPart_000_002C_01C03367.FFA93060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
I was wondering if anyone could help me = by=20 answering my question regarding the way HMAC-MD5-96 used with AH or = ESP.=20 The RFC2403 says, HMAC-MD5-96 operates on 64 bytes of data and a = produces a=20 message digest of 128bit value.
What I didn't understand is, when a = packet has more=20 than 64 bytes of data (say 512bytes), how do you feed rest of the blocks = and how=20 to handle the intermediate mesage digests.(In this case one will have 8 = messgae=20 digests generated for every
64 byte block of data).
 
I would really appreciate if someone = can help me=20 unedrstand this.
 
Thanx
Prashanth
------=_NextPart_000_002C_01C03367.FFA93060-- _____NetZero Free Internet Access and Email______ http://www.netzero.net/download/index.html From owner-ipsec@lists.tislabs.com Wed Oct 11 08:44:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24336; Wed, 11 Oct 2000 08:44:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11590 Wed, 11 Oct 2000 10:47:52 -0400 (EDT) Message-ID: From: "Linn, John" To: "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Subject: charter question re IKE changes Date: Wed, 11 Oct 2000 10:59:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to ask a charter question which relates to both IPsec and IPSRA WGs. IPSRA, based on IESG inputs, has been operating under the premise that its work should not impact IKE's syntax or semantics if feasibly avoidable, with a strong preference to work instead alongside IKE as currently defined. This premise has constrained the design space for candidate IPSRA proposals. Recent discussion on IPsec has suggested significant changes to IKE, potentially removing or replacing authentication modes. Question: If IKE's definition is to be reopened within IPsec, should IPSRA's admissible design space continue to be constrained by RFC-2409? --jl From owner-ipsec@lists.tislabs.com Wed Oct 11 08:49:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24478; Wed, 11 Oct 2000 08:49:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11620 Wed, 11 Oct 2000 10:55:34 -0400 (EDT) To: "Steven M. Bellovin" Cc: Bill Manning , hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) Subject: Re: ike and secure DNS References: <20001011142847.2866435DC2@smb.research.att.com> From: Derek Atkins Date: 11 Oct 2000 11:05:07 -0400 In-Reply-To: "Steven M. Bellovin"'s message of "Wed, 11 Oct 2000 10:28:46 -0400" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" writes: > I'd love to see any sort of secure address-to-entity map. But there > seems to be considerable uncertainty about who actually owns various > chunks of address space. Is the database clean enough that it's worth > signing? I sure don't get that impression from, say, the NANOG list. Perhaps a small change to what it means to "sign" a zone? If the "root" could sign my NS records (which "they" own), and my key record (which "I" own, but supply to them the same way I supply my NS records), then this works. But I doubt NSI is willing to accept a KEY record or sign it. Let alone sign my NS records. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Oct 11 08:49:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24476; Wed, 11 Oct 2000 08:49:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11636 Wed, 11 Oct 2000 10:56:38 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Linn, John" Cc: "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Subject: Re: charter question re IKE changes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Oct 2000 11:08:12 -0400 Message-Id: <20001011150812.9657C35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Linn, John" writes: >I'd like to ask a charter question which relates to both IPsec and IPSRA >WGs. IPSRA, based on IESG inputs, has been operating under the premise that >its work should not impact IKE's syntax or semantics if feasibly avoidable, >with a strong preference to work instead alongside IKE as currently defined. >This premise has constrained the design space for candidate IPSRA proposals. >Recent discussion on IPsec has suggested significant changes to IKE, >potentially removing or replacing authentication modes. Question: If IKE's >definition is to be reopened within IPsec, should IPSRA's admissible design >space continue to be constrained by RFC-2409? Yes. Most of the talk here has been about removing things, not adding more. IPSRA would need to add more. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Oct 11 08:50:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24544; Wed, 11 Oct 2000 08:50:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11578 Wed, 11 Oct 2000 10:47:22 -0400 (EDT) From: Bill Manning Message-Id: <200010111458.HAA11092@zed.isi.edu> Subject: Re: ike and secure DNS To: smb@research.att.com (Steven M. Bellovin) Date: Wed, 11 Oct 2000 07:58:56 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) In-Reply-To: <20001011142847.2866435DC2@smb.research.att.com> from "Steven M. Bellovin" at Oct 11, 2000 10:28:46 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % % In message <200010111025.DAA06812@zed.isi.edu>, Bill Manning writes: % > A couple academic projects, TBDS and FMESHD, are either dependent on % > working DNSSEC or leverage DNSSEC for key exchange, while the upcoming % > DNSSEC workshop on the 25th in WDC will be evaluating DNSSEC viability % > in the ip6.int tree. If that can be shown to be stable, it can act as % > a precursor to a signed in-addr.arpa. and other address-name trees. % > I think this is what is needed to exploit any IKE/ipsec & DNS interactions % > since that will give us a "chain-of-custody" up the delegation heirarchy. % > Does Free/SWAN have this as a shared goal? % % I'd love to see any sort of secure address-to-entity map. But there % seems to be considerable uncertainty about who actually owns various % chunks of address space. Is the database clean enough that it's worth % signing? I sure don't get that impression from, say, the NANOG list. % % --Steve Bellovin First off, the test case is the ip6.int tree, not a high profile NANOG item. One should remember that address space is not owned, the responsiblity for portions of it are delegated. DNSSEC provides the ability to run the "chain of custody" to authenticate the delegation, while goofy things like CERT RR's let you do key binding to individual, specific IP addresses, which is where the interaction w/ IPSEC might come into play. wrt "cleanliness", my own audits indicate that the data is roughly 50% accurate and has remained near those levels for four years. The recent Mice&Men survey of the forward tree indicates that roughly 80% of the forward tree is inaccurate and the trend seems to be growing worse on that side. So... one is allowed to draw ones own conclusions. And then there is the play for using DNS delegation heirarchies for validating live routing announcements. While this idea has its warts and has been buried in piles of rocks every time it has poked its head above ground, if the DNS can provide an authenticatable "chain of custody" then is is a much stronger tool for doing routing checks (although I'm still not convivnced about the validity of doing so in real time on the live routing system). And when there is operational need, and the responsiblity is delegated, folks will keep their data current... at least in my limited experience. -- --bill From owner-ipsec@lists.tislabs.com Wed Oct 11 08:58:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24911; Wed, 11 Oct 2000 08:58:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11656 Wed, 11 Oct 2000 10:58:52 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Derek Atkins Cc: Bill Manning , hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) Subject: Re: ike and secure DNS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Oct 2000 11:10:27 -0400 Message-Id: <20001011151027.2DFE135DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Derek Atkins writes: >"Steven M. Bellovin" writes: > >> I'd love to see any sort of secure address-to-entity map. But there >> seems to be considerable uncertainty about who actually owns various >> chunks of address space. Is the database clean enough that it's worth >> signing? I sure don't get that impression from, say, the NANOG list. > >Perhaps a small change to what it means to "sign" a zone? If the "root" >could sign my NS records (which "they" own), and my key record (which "I" >own, but supply to them the same way I supply my NS records), then this >works. > >But I doubt NSI is willing to accept a KEY record or sign it. Let alone >sign my NS records. My point is that the records of who owns (or has the delegation for, if you prefer) address blocks are not very good. Why sign something that isn't correct to start with? --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Oct 11 09:00:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25256; Wed, 11 Oct 2000 09:00:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11694 Wed, 11 Oct 2000 11:05:52 -0400 (EDT) From: Bill Manning Message-Id: <200010111517.IAA23091@zed.isi.edu> Subject: Re: ike and secure DNS To: warlord@mit.edu (Derek Atkins) Date: Wed, 11 Oct 2000 08:17:27 -0700 (PDT) Cc: smb@research.att.com (Steven M. Bellovin), bmanning@ISI.EDU (Bill Manning), hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) In-Reply-To: from "Derek Atkins" at Oct 11, 2000 11:05:07 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % Perhaps a small change to what it means to "sign" a zone? If the "root" % could sign my NS records (which "they" own), and my key record (which "I" % own, but supply to them the same way I supply my NS records), then this % works. % % But I doubt NSI is willing to accept a KEY record or sign it. Let alone % sign my NS records. % % -derek Ah, but NSI doesn't have that token so that issue is a peruvian herring. For a working system, ICANN/IANA would sign "root" and the in-addr.arpa zone(s).Then, say MIT, would sign 18.in-addr.arpa. If you were delegated a section of that tree, say 167.49.18.in-addr.arpa., you would need MIT to accept your key. And in the case where ICANN is tied up in legal/business issues, MIT can self-sign. Given the nature of DNSSEC, we are able to swap keys in some OOB mannor to enable the DNSSEC signed subzones we operate while our parents futz about with other issues. e.g. the tree does not have to be complete. --bill From owner-ipsec@lists.tislabs.com Wed Oct 11 09:03:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25632; Wed, 11 Oct 2000 09:03:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11682 Wed, 11 Oct 2000 11:04:51 -0400 (EDT) Date: Wed, 11 Oct 2000 11:15:57 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: ike and secure DNS In-Reply-To: <200010111025.DAA06812@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Oct 2000, Bill Manning wrote: > ...DNSSEC workshop on the 25th in WDC will be evaluating DNSSEC viability > in the ip6.int tree. If that can be shown to be stable, it can act as > a precursor to a signed in-addr.arpa. and other address-name trees. > I think this is what is needed to exploit any IKE/ipsec & DNS interactions > since that will give us a "chain-of-custody" up the delegation heirarchy. > Does Free/SWAN have this as a shared goal? Correct -- we want to use secure DNS for key distribution and lookup, which means having some way of tracing signatures back to a known-good one (e.g., one supplied as part of the named.root file that we need anyway). We're already set up to fetch keys from DNS, in fact, and anything done to make that more secure fits very nicely. (Mind you, we have not been addressing the implementation details much ourselves -- our management sees it as a separate problem, to be dealt with by the BIND guys rather than by us, except insofar as we need to be explicit about what we want.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Oct 11 09:07:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25958; Wed, 11 Oct 2000 09:07:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11720 Wed, 11 Oct 2000 11:09:36 -0400 (EDT) From: Bill Manning Message-Id: <200010111521.IAA25142@zed.isi.edu> Subject: Re: ike and secure DNS To: smb@research.att.com (Steven M. Bellovin) Date: Wed, 11 Oct 2000 08:21:13 -0700 (PDT) Cc: warlord@mit.edu (Derek Atkins), bmanning@ISI.EDU (Bill Manning), hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) In-Reply-To: <20001011151027.2DFE135DC2@smb.research.att.com> from "Steven M. Bellovin" at Oct 11, 2000 11:10:27 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % My point is that the records of who owns (or has the delegation for, if % you prefer) address blocks are not very good. Why sign something that % isn't correct to start with? % % --Steve Bellovin What is the source of your concern? That the various RIR whois data is inaccurate? Or that the delegations themselves are "busted", ie. no working servers? -- --bill From owner-ipsec@lists.tislabs.com Wed Oct 11 09:11:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26018; Wed, 11 Oct 2000 09:11:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11773 Wed, 11 Oct 2000 11:15:31 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Bill Manning Cc: warlord@mit.edu (Derek Atkins), hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) Subject: Re: ike and secure DNS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Oct 2000 11:27:05 -0400 Message-Id: <20001011152706.E479D35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200010111521.IAA25142@zed.isi.edu>, Bill Manning writes: >% My point is that the records of who owns (or has the delegation for, if >% you prefer) address blocks are not very good. Why sign something that >% isn't correct to start with? >% >% --Steve Bellovin > >What is the source of your concern? That the various RIR whois data is >inaccurate? Or that the delegations themselves are "busted", ie. no working >servers? The former is the main issue. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Oct 11 09:16:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26155; Wed, 11 Oct 2000 09:16:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11802 Wed, 11 Oct 2000 11:17:42 -0400 (EDT) To: Bill Manning Cc: smb@research.att.com (Steven M. Bellovin), hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) Subject: Re: ike and secure DNS References: <200010111517.IAA23091@zed.isi.edu> From: Derek Atkins Date: 11 Oct 2000 11:28:13 -0400 In-Reply-To: Bill Manning's message of "Wed, 11 Oct 2000 08:17:27 -0700 (PDT)" Message-ID: Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ahh, but I want forward delegation as much as reverse delegation. I want to be able to sign ihtfp.org. as much as I want to sign 200.107.204.in-addr.arpa. NSI is the registrar for the former, and ARIN is the the registrar for the latter. -derek Bill Manning writes: > % Perhaps a small change to what it means to "sign" a zone? If the "root" > % could sign my NS records (which "they" own), and my key record (which "I" > % own, but supply to them the same way I supply my NS records), then this > % works. > % > % But I doubt NSI is willing to accept a KEY record or sign it. Let alone > % sign my NS records. > % > % -derek > > Ah, but NSI doesn't have that token so that issue is a peruvian herring. > For a working system, ICANN/IANA would sign "root" and the in-addr.arpa zone(s).Then, say MIT, would sign 18.in-addr.arpa. If you were delegated a section > of that tree, say 167.49.18.in-addr.arpa., you would need MIT to accept your > key. > > And in the case where ICANN is tied up in legal/business issues, MIT can > self-sign. Given the nature of DNSSEC, we are able to swap > keys in some OOB mannor to enable the DNSSEC signed subzones we operate > while our parents futz about with other issues. e.g. the tree does not > have to be complete. > > --bill -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Oct 11 09:21:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26308; Wed, 11 Oct 2000 09:21:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11847 Wed, 11 Oct 2000 11:26:29 -0400 (EDT) From: Bill Manning Message-Id: <200010111538.IAA04463@zed.isi.edu> Subject: Re: ike and secure DNS To: warlord@mit.edu (Derek Atkins) Date: Wed, 11 Oct 2000 08:38:05 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), smb@research.att.com (Steven M. Bellovin), hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) In-Reply-To: from "Derek Atkins" at Oct 11, 2000 11:28:13 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Baby steps... :) We'll get there. I'm mostly concerned w/ the IP delegations right now. NSI is active in this area, perhaps more so since the Verisign buyout. ARIN is less so, but with the recent mgmt change there, I have more hope that ARIN too, will embrace DNSSEC. % % Ahh, but I want forward delegation as much as reverse delegation. I % want to be able to sign ihtfp.org. as much as I want to sign % 200.107.204.in-addr.arpa. NSI is the registrar for the former, and % ARIN is the the registrar for the latter. % % -derek % % Bill Manning writes: % % > % Perhaps a small change to what it means to "sign" a zone? If the "root" % > % could sign my NS records (which "they" own), and my key record (which "I" % > % own, but supply to them the same way I supply my NS records), then this % > % works. % > % % > % But I doubt NSI is willing to accept a KEY record or sign it. Let alone % > % sign my NS records. % > % % > % -derek % > % > Ah, but NSI doesn't have that token so that issue is a peruvian herring. % > For a working system, ICANN/IANA would sign "root" and the in-addr.arpa zone(s).Then, say MIT, would sign 18.in-addr.arpa. If you were delegated a section % > of that tree, say 167.49.18.in-addr.arpa., you would need MIT to accept your % > key. % > % > And in the case where ICANN is tied up in legal/business issues, MIT can % > self-sign. Given the nature of DNSSEC, we are able to swap % > keys in some OOB mannor to enable the DNSSEC signed subzones we operate % > while our parents futz about with other issues. e.g. the tree does not % > have to be complete. % > % > --bill % % -- % Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory % Member, MIT Student Information Processing Board (SIPB) % URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH % warlord@MIT.EDU PGP key available % -- --bill From owner-ipsec@lists.tislabs.com Wed Oct 11 09:23:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26433; Wed, 11 Oct 2000 09:23:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11778 Wed, 11 Oct 2000 11:15:47 -0400 (EDT) Date: Wed, 11 Oct 2000 11:26:49 -0400 (EDT) From: Henry Spencer To: "Steven M. Bellovin" cc: ipsec Subject: Re: ike and secure DNS In-Reply-To: <20001011151027.2DFE135DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Oct 2000, Steven M. Bellovin wrote: > My point is that the records of who owns (or has the delegation for, if > you prefer) address blocks are not very good. Why sign something that > isn't correct to start with? I think there's a hierarchy issue here. Remember that delegation is done one level at a time, *not* all at once, and signing can be done the same way. What we care about is not whether we can consult some central source and learn who owns 209.47.149.227, but whether the owner of 209.47.149/24 knows how it's divided up, because *he* (not the DNS root administrators) is the one who's going to have to sign the key for the next level down. Ownership needs to be positively known only locally, not globally. Where there may still be a problem is with all the chunks of address space that were allocated globally in the old days. I think the answer for them is simply that if you can't convincingly establish ownership, you can't get your key signed. There is no requirement that we be able to sign the whole tree, every last little branch, right at the start. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Oct 11 09:33:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27177; Wed, 11 Oct 2000 09:33:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11833 Wed, 11 Oct 2000 11:24:27 -0400 (EDT) From: Bill Manning Message-Id: <200010111536.IAA03210@zed.isi.edu> Subject: Re: ike and secure DNS To: smb@research.att.com (Steven M. Bellovin) Date: Wed, 11 Oct 2000 08:36:01 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), warlord@mit.edu (Derek Atkins), hugo@ee.technion.ac.il (Hugo Krawczyk), henry@spsystems.net (Henry Spencer), ipsec@lists.tislabs.com (ipsec) In-Reply-To: <20001011152706.E479D35DC2@smb.research.att.com> from "Steven M. Bellovin" at Oct 11, 2000 11:27:05 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % % In message <200010111521.IAA25142@zed.isi.edu>, Bill Manning writes: % >% My point is that the records of who owns (or has the delegation for, if % >% you prefer) address blocks are not very good. Why sign something that % >% isn't correct to start with? % >% % >% --Steve Bellovin % > % >What is the source of your concern? That the various RIR whois data is % >inaccurate? Or that the delegations themselves are "busted", ie. no working % >servers? % % The former is the main issue. % % --Steve Bellovin Ah, a known issue. At least one RIR has baroque methods for updating contact data and significant penelties (including fiscal) if the current rules are not enforced when an update is attempted. There is also limited encourgment to facilitate local administration of such data (eg. rWhois) These conspire to ensure people do not touch the RIR data unless absolutely needed. But the DNS delegations work and it is possible to get accurate data from the delegation heirarchy even if the whois data is wrong. And since we are talking about the DNS and not whois, I'm less concerned. --bill From owner-ipsec@lists.tislabs.com Wed Oct 11 09:43:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27782; Wed, 11 Oct 2000 09:43:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11970 Wed, 11 Oct 2000 11:43:21 -0400 (EDT) Message-ID: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> From: "Walker, Jesse" To: "'Steven M. Bellovin'" , "Linn, John" Cc: "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Subject: RE: charter question re IKE changes Date: Wed, 11 Oct 2000 08:54:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve: "Most" is the operative word, because there has also been very extensive discussion and repeated suggestions and pleas to replace Aggressive Mode with Base Mode. This certainly sounds like an "add" as well as a "remove" to me. Be that as it may, to ellaborate on what I take to be John's point, one of the spectres against which IPsec is fighting is, unlike the SSL community, the IPsec community decided that everyone needs mutual authentication all the time, 100% without exception, regardless of any and all other considerations. My belief, for what it is worth, is experience now shows that this was a genuinely bad decision, and the creation of IPSRA to solve the legacy authentication problem simply confirms this. Real deployments need strong one way authentication of an infrastructure or community to a newly enrolling participant in order to bootstrap; requiring strong two way authentication even during enrollment has created the deployment nightmare that IPSRA has been chartered to fix. Both of the IPSRA proposals on the table make use of this realization by essentially relying on one-way authentication to get around the chicken and egg problem that exists at deployment time. IPSRA words the problem much differently than I've charaterized it here, but it is the same problem. It seems to me that the PIC proposal in particular could easily be incorporated into the larger IKE framework, obviate the need for this IPSRA legacy authentication task, and result in a much more widely deployable and usable IPsec. Just my two cents. -- Jesse -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Wednesday, October 11, 2000 8:08 AM To: Linn, John Cc: 'ipsec@lists.tislabs.com'; 'ietf-ipsra@vpnc.org' Subject: Re: charter question re IKE changes In message , "Linn, John" writes: >I'd like to ask a charter question which relates to both IPsec and IPSRA >WGs. IPSRA, based on IESG inputs, has been operating under the premise that >its work should not impact IKE's syntax or semantics if feasibly avoidable, >with a strong preference to work instead alongside IKE as currently defined. >This premise has constrained the design space for candidate IPSRA proposals. >Recent discussion on IPsec has suggested significant changes to IKE, >potentially removing or replacing authentication modes. Question: If IKE's >definition is to be reopened within IPsec, should IPSRA's admissible design >space continue to be constrained by RFC-2409? Yes. Most of the talk here has been about removing things, not adding more. IPSRA would need to add more. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Oct 11 10:03:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29267; Wed, 11 Oct 2000 10:03:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12054 Wed, 11 Oct 2000 11:57:31 -0400 (EDT) Message-Id: <200010111606.e9BG6u722475@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: "Derrell D. Piper" Cc: "Thomas Porter, Ph.D." , ipsec@lists.tislabs.com Subject: Re: Reliable delete notifies In-reply-to: Your message of "Wed, 11 Oct 2000 02:11:54 PDT." <200010110911.CAA16157@gallium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Oct 2000 12:06:56 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200010110911.CAA16157@gallium.network-alchemy.com>, "Derrell D. Pip er" writes: > >I wasn't able to attend the last bake-off, but from what I heard and read from >folks who attended, I don't sense that we're at the level of interoperability >between PKI-enabled IPSec implementations that we need to be at before we can >remove pre-shared keys from the standard. That is a problem of the PKI vendors; as others have already said, you don't need a PKI to do public-key authentication. -Angelos From owner-ipsec@lists.tislabs.com Wed Oct 11 12:02:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03253; Wed, 11 Oct 2000 12:02:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12503 Wed, 11 Oct 2000 13:57:00 -0400 (EDT) Date: Wed, 11 Oct 2000 14:06:40 -0400 (EDT) From: Henry Spencer To: Hugo Krawczyk cc: ipsec Subject: Re: ike and secure DNS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Oct 2000, Hugo Krawczyk wrote: > I'd like to gather information on existing projects (commerical or > academic) working towards the integration of DNSSEC infrastructure and > IKE/ipsec. I know FreeSWAN has such integration plans? Any progress in > that front? We're fetching keys from DNS operationally, and starting to fetch our gateway-discovery information as well. We haven't yet done much about integration specifically with DNSSEC, partly because we are waiting for BIND9's new resolver to be *documented* so we can use it. We see the bulk of the DNSSEC side of things as being the resolver's job rather than ours. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Oct 11 12:23:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03695; Wed, 11 Oct 2000 12:23:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12624 Wed, 11 Oct 2000 14:26:18 -0400 (EDT) Message-Id: <200010111831.LAA20769@potassium.network-alchemy.com> To: Henry Spencer cc: Hugo Krawczyk , ipsec Subject: Re: ike and secure DNS In-reply-to: Your message of "Wed, 11 Oct 2000 14:06:40 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20766.971289060.1@network-alchemy.com> Date: Wed, 11 Oct 2000 11:31:00 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Oct 2000 14:06:40 EDT you wrote > > We're fetching keys from DNS operationally, and starting to fetch our > gateway-discovery information as well. We haven't yet done much about ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'd be very interested in hearing about your plans for this. Are you planning on writing a draft or something on this? Dan. From owner-ipsec@lists.tislabs.com Wed Oct 11 13:02:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05529; Wed, 11 Oct 2000 13:02:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12843 Wed, 11 Oct 2000 15:10:06 -0400 (EDT) Message-ID: <39E4BD5B.6B585098@storm.ca> Date: Wed, 11 Oct 2000 15:19:55 -0400 From: Sandy Harris X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Help - IPSEC beginner References: <39E46510.85ECA14@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Arvind Devarajan wrote: > > hi all, > as a part of my Masters, i am developing the IPSec code - ground up. > well, as it stands, i am very new to IPSec, and have just managed to go > through the RFC 2401. My project is for 2.5 months from now. I'd say your best bet would be to look at one of the several open source implementations of IPSEC: Linux FreeS/WAN http://www.freeswan.org Open BSD http://www.openbsd.org KAME: http://www.kame.net/ Porting one of those to your Xkernel might be much easier than building IPSEC from the ground up. At the very least, there should be considerable code you can use. > i know that this is too short a time to do anything much in IPSec, Consider negotiating with your supervisor and the implementers of one of the systems listed to find a project that's useful and is reasonable in your time frame. e.g. FreeS/WAN has only a rudimentary SPDB at this stage and does not support the Rijndael AES cipher yet and ... Other possibilities: Many systems support RSA signatures for authentication of gateways doing IKE, but there are many different formats for storing the public keys involved. See recent messages such as this one, Oct 10: Michael Richardson wrote: > > >>>>> "Angelos" == Angelos D Keromytis writes: > Angelos> I would in fact argue for removal of preshared-key > Angelos> authentication; it was useful for debugging or for very simple > Angelos> setups, but the protocol complexity introduced both directly > Angelos> (because of the need to support 2 or 3 auth methods) and > Angelos> indirectly (encourages addition of other authentication > Angelos> mechanisms) are simply not worth it. > > I would agree to this on one condition only: > > That the spec lists a simple, well known format (i.e. PKCS10) by which > self-signed certificates can be loaded into the trusted store, and by which > they will be produced. That implementations *MUST* support this. > > Debugging a CA system as well as IKE is simply a non-starter. Other formats were suggested elsewhere in the thread. At least until such a standard format is agreed on and widely implemented, it would be useful to have some sort of translation software that converts among a number of the more common formats to facilitate interoperation among IPSEC implementations that use different formats. Some such converters already exist, e.g. for FreeS/WAN and PGP keyring or X.509 certificate formats. See FreeS/WAN docs for details. Could you, in your time frame, implement a general-purpose translator? All the implementations listed above (and I think, some others) use PF-key v2 (RFC 2367) for communication between their kernel code and their daemons. Howver, as I understand it, v2 does not handle policy so each implementation has added extensions to do that. The extensions are similar, but different. I understand the implementers have talked about this, and they all think a common set of extensions would be a good idea, and likely not really difficult, but they're all busy with other things. Could you sort this out in your timeframe, develop a common set of extensions based on ideas from those implementers, and change one or more implementations to use them? This might have large payoffs. It would make daemons portable across implementations so, for example, you could use OpenBSD's Photuris daemon on Linux or FreeS/WAN's IKE daemon on *BSD. Also, it might get your name on a PF-key v3 RFC as well as on a thesis. From owner-ipsec@lists.tislabs.com Wed Oct 11 13:07:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05628; Wed, 11 Oct 2000 13:07:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12802 Wed, 11 Oct 2000 14:59:04 -0400 (EDT) Date: Wed, 11 Oct 2000 15:10:07 -0400 (EDT) From: Henry Spencer To: Dan Harkins cc: ipsec Subject: Re: ike and secure DNS In-Reply-To: <200010111831.LAA20769@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Oct 2000, Dan Harkins wrote: > > We're fetching keys from DNS operationally, and starting to fetch our > > gateway-discovery information as well. We haven't yet done much about > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I'd be very interested in hearing about your plans for this. Are you > planning on writing a draft or something on this? I've got a project-internal draft, which needs one more revision for content and then some reworking to make it presentable. Soon, I hope; there are a couple of other things in the queue ahead of it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Oct 11 17:10:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10494; Wed, 11 Oct 2000 17:10:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13357 Wed, 11 Oct 2000 18:39:59 -0400 (EDT) Message-Id: <200010112251.SAA18092@solidum.com> To: "'IP Security List'" Subject: Re: Definition of PFS... In-Reply-To: Your message of "Wed, 11 Oct 2000 09:50:54 EDT." <007a01c0338a$476ad120$d23e788a@andrewk3.ca.newbridge.com> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Oct 2000 18:51:34 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> I recently decided to do some research on something that has Andrew> bugged me for quite awhile now: What is the point of doing PFS in Andrew> phase 2? Andrew> The reason I wonder about this is that presumably you will use Andrew> the same group in phase 2 that you used in phase 1, so if an Andrew> adversary can crack your phase 1 DH then he can presumably expend Andrew> the 1 bit of additional effort required to crack the phase 2 Andrew> DH. It seems like you would be better off using a larger modulus PFS does not just defend against being attacked. It also defends against the situation where a third party compels one party to provide some set of keys. PFS guarantees that a simple search warant only catches traffic *currently* in transit, not all previous and future traffic. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Oct 11 18:01:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11146; Wed, 11 Oct 2000 18:01:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13384 Wed, 11 Oct 2000 19:00:51 -0400 (EDT) To: Sandy Harris cc: ipsec@lists.tislabs.com In-reply-to: sandy's message of Wed, 11 Oct 2000 15:19:55 -0400. <39E4BD5B.6B585098@storm.ca> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Help - IPSEC beginner From: itojun@iijlab.net Date: Thu, 12 Oct 2000 08:12:15 +0900 Message-ID: <3401.971305935@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Could you, in your time frame, implement a general-purpose translator? > >All the implementations listed above (and I think, some others) use PF-key v2 >(RFC 2367) for communication between their kernel code and their daemons. >Howver, as I understand it, v2 does not handle policy so each implementation >has added extensions to do that. The extensions are similar, but different. >I understand the implementers have talked about this, and they all think >a common set of extensions would be a good idea, and likely not really >difficult, but they're all busy with other things. > >Could you sort this out in your timeframe, develop a common set of >extensions based on ideas from those implementers, and change one or more >implementations to use them? for PF_KEY portability issue, you may want to look at isakmpd (ftp.gsnig.org should have the portable version of it - openbsd tree does not have the portability layer). itojun From owner-ipsec@lists.tislabs.com Wed Oct 11 21:55:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19576; Wed, 11 Oct 2000 21:55:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14156 Wed, 11 Oct 2000 23:17:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Wed, 11 Oct 2000 20:28:48 -0700 To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: RE: charter question re IKE changes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:31 PM -0400 10/11/00, Stephen Kent wrote: >certainly we know how to generate and distribte certs to users who >already have entries in a Radius database. Of course, if that was all we needed to do, our lives would be simpler and freer from suffering. However, it isn't. Implementations of PKI in the user environment have found that distributing the private keys associated with the public keys in the certs, and doing so in such a way that the user can use the certificate easily and flexibly, is the difficult problem. Note that "distributing" is even difficult when the private-public pair is generated on the user's own device because the private key has to be secured and yet be made available through applications that would need the user to sign things. We know the technology for doing this, but we have so far implemented it in very klunky fashions. Passwords that can be memorized by a user seem a lot more attractive to people who don't understand how utterly insecure they are (and even to some people who do). --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Oct 11 22:22:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21795; Wed, 11 Oct 2000 22:22:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14113 Wed, 11 Oct 2000 22:49:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Wed, 11 Oct 2000 21:31:14 -0400 To: "Walker, Jesse" From: Stephen Kent Subject: RE: charter question re IKE changes Cc: "'Steven M. Bellovin'" , "Linn, John" , "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jesse, SSL was designed to address a fundamentally different set of communication security requirements, for a client/server model so it is not unreasonable that they made a different decision. However, the result is that most users are burdened with the need to remember and provide passwords for each public web site they log into via SSL, and if these passwords are poorly chosen, the use of encryption does not make it harder for an attacker to guess them and masquerade. IPsec set higher standards for its peer-oriented authentication (not client server). the push back we see wrt PKI use in dialup environments is a result of many factors, some of which have been discussed recently on this list. certainly we know how to generate and distribte certs to users who already have entries in a Radius database. but, what products can we buy that allow us to do this? so, my view is that the IPsec insistence for high quality, 2-way authentication is appropriate, but that implementations have not yet provided good enough PKI support to make it easy for folks to "embrace" the technology. Steve From owner-ipsec@lists.tislabs.com Wed Oct 11 23:16:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23971; Wed, 11 Oct 2000 23:16:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14277 Wed, 11 Oct 2000 23:59:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20001011235845.00c41a40@pop.rcn.com> X-Sender: rjp@192.168.17.12 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Oct 2000 00:05:13 -0400 To: ipsec From: "Plummer, Ron" Subject: Re: Reliable delete notifies In-Reply-To: <200010090310.e993AUM18668@nyarlathotep.cis.upenn.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What are your arguments (scale, performance, reliability, security) against preshared-key authentication when using the IPSec protocol? Many who don't have access to an operational PKI and significant numbers of IPSec devices to worry about are hanging on to preshared keys. Should they be worried other than with scale issues? Ron Plummer At 11:10 PM 10/8/00, you wrote: >[snip] > > I'm doing this work for the Working Group and I can't just > >unilaterally declare that Aggressive Mode is out. I was > >noting that it's out of my drafty-draft. If the Working Group > >wants Aggressive Mode in the protocol then it is in. So let's > >start a discussion. Does the Working Group want to keep > >Aggressive Mode? Is Aggressive Mode "standards bloat" or > >is it a necessary addition to do what Ben wants to do? > >I would in fact argue for removal of preshared-key authentication; it was >useful for debugging or for very simple setups, but the protocol complexity >introduced both directly (because of the need to support 2 or 3 auth methods) >and indirectly (encourages addition of other authentication mechanisms) are >simply not worth it. > >Ways to retrieve certificates (or have temporary certificates issued, after >using XYZ authentication) are known, simple, and well-understood. >-Angelos -- Ron Plummer Senior Consultant/Engineer Project Manager Professional Services Telcordia Technologies, Inc. An SAIC Company 3 Corporate Place Piscataway, NJ 08854 (732) 699-6312 (Voice) (732) 699-4432 (FAX) (609) 203-4825 (Mobile) rplummer@telcordia.com rjp_pager@sahana.cc.telcordia.com (pager) PGP Fingerprint: 8508 2EFB C11D 013E 231B 5D10 D644 7DC6 53EE 60C3 From owner-ipsec@lists.tislabs.com Thu Oct 12 03:59:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06445; Thu, 12 Oct 2000 03:59:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14904 Thu, 12 Oct 2000 04:25:54 -0400 (EDT) Message-ID: <39E577C3.B1BA158@oracle.com> Date: Thu, 12 Oct 2000 14:05:16 +0530 From: Arvind Devarajan Organization: Oracle Corporation X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Help - IPSEC beginner References: <39E46510.85ECA14@oracle.com> <39E4BD5B.6B585098@storm.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, thank you very much for your response. to summarise, i've got replies that clearly indicate that my work for 2 and a half months is a bit more... As a matter of fact, i'll have a masters degree in that time, but, i propose continuing the work even after that. responses also mentioned about looking at the OPENBSD, FreeS/WAN and KAME's code. i've been doing quite a lot of code study there too. they give in such interesting details, that i can never afford to miss. i've got a doubt - as we know, SAD is a dynamic entity, and entries are created in SAD on the fly - whenever there is a policy in the SPD that suggests use of an non-existant SA. my doubt is, how does the SPD mention that a particular SA be used for Outbound processing when that SA does not exist? or, does it just mention that "use an SA that has this particular characteristic - algos, etc" - the IPSec code looks in the dynamically created SAD for an SA having that characteristic, and, if not present, creates it? if this is the case, SPI for the SA is dynamically generated? according to the OPENBSD, security associations are created initially using the utility ipsecadm. This, i guess should go into the kernel data structures, and, are consulted everytime an incoming packet arrives (initially). when a packet arrives, and an SA exists (that match the packet's IPSec header's Dst Addr, Proto and SPI fields), the packet is IPSec processed. if not, it is dropped (RFC 2401). however, as the host (or the gateway) generates more packets, these outbound packets may trigger creation of more SAs that add to the existing set of SAs. in brief: 1. How will SPD mention the set of SAs to be used for outbound processing? 2. Am i right in assuming that we need to create an initial set of SAs? thanks again for the previous responses (Sandy Harris, itojun, Jerome Freedman Jr.) regards, arvind. From owner-ipsec@lists.tislabs.com Thu Oct 12 04:05:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA07092; Thu, 12 Oct 2000 04:05:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA14978 Thu, 12 Oct 2000 06:03:14 -0400 (EDT) X-Originating-IP: [194.100.112.129] Reply-To: silvere@iki.fi From: "Sami Vaarala" To: svan@trustworks.com, ipsec@lists.tislabs.com, andrew.krywaniuk@alcatel.com Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) Date: Thu, 12 Oct 2000 12:09:11 EEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2000 09:09:11.0457 (UTC) FILETIME=[15C15110:01C0342C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I'm not sure that merging the big 3 documents will actually make > > IKE easier to understand. ISAKMP is fine as it is, as far as I'm > > concerned. Merging IKE > >It probably will. But there is one thing that I'm worried about: >merging all in one document may close the doors to independently >enhance protocol parts - every such attempt will require updating of >this big document. Currently ISAKMP defines the framework in which >different key management protocols may be defined. Nowdays IKE is the >only of such protocols, but the room for others is still here. >Combining everything into one document will probably mean "IKE >forever" - the approach that I'm not too happy about. That might be. But is someone actually planning to implement two key management protocols on top of the *same* isakmp code? From my experience there are enough dependencies between ISAKMP and IKE to make such isolation difficult and probably unwise, too. As a framework for specifying the new protocols, ISAKMP is fine (it could be less ambiguous though). But I don't think there will be too much code sharing between the different key management protocols one could build into the ISAKMP framework. And if not, I am not sure there is enough justification not to roll the ISAKMP stuff into a new IKE specification. That should clear a lot of ambiguities that are a result of artificial separation of the two specifications. Sami -- Sami Vaarala / Pygmy Projects - We make it small! www.iki.fi/~silvere / / No matter where you go, there you are. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-ipsec@lists.tislabs.com Thu Oct 12 06:18:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26424; Thu, 12 Oct 2000 06:18:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15397 Thu, 12 Oct 2000 08:20:28 -0400 (EDT) X-Originating-IP: [194.100.112.129] Reply-To: silvere@iki.fi From: "Sami Vaarala" To: svan@trustworks.com, ipsec@lists.tislabs.com Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) Date: Thu, 12 Oct 2000 15:31:33 EEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2000 12:31:33.0456 (UTC) FILETIME=[5AF35500:01C03448] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Valery, It is true that you can attempt to isolate ISAKMP code from IKE, but imho you will never reach anything as clean as HTTP over TCP. >Well, code sharing is not the only (and probably not the most >important) issue here. My point here is that IKE is far from ideal >now but it is stalled in this state due to sole political reasons. In >this situation one could try to define another KE protocol inside >ISAKMP framework, reusing its constructions (payloads, messages, >attributes etc.). How much of ISAKMP code will be reused depends, >again, on implementation design, but at least at the protocol >definition level a lot of stuff will be. Combining everithing into >one document will (ok, may) effectively eliminate this possibility. I agree in some ways. If ISAKMP is to remain a separate spec, we (or rather, "someone") should define a new non-ipsec key management protocol using it to ensure that it is reasonably separate from IKE. The current state does not make sense, it should be either-or. If ISAKMP is to be kept separate, I think a lot of stuff should be removed from it. The message format (header, payloads, etc) are worth keeping, and so is the UDP transport mechanism (which should be described more completely, esp. wrt completion of an exchange). But eg the exchanges defined in the ISAKMP spec (apart from Informational). I don't see any point in ISAKMP defining 'example' exchanges (and even defining numbers for them) for two reasons. First, the key exchange and authentication mechanism will (and has) severely affected the actual payloads in the messages, and how the messages should be processed (consider the RSA encryption authentication modes). Second, the code handling the exchanges will almost certainly have to be tailored for the particular exchange too, because of eg security and performance reasons. Any two key management protocols taking the ISAKMP identity protection exchange will probably have to re-define it to meet the actual protocol's needs. Again, consider IKE's revised RSA encryption authentication mode (in main mode), and compare the messages to ISAKMP identity protection exchange. Of course it is useful to have sketches of how to design new exchange types, but they should hardly be a part of the spec. Sami -- Sami Vaarala / Pygmy Projects - We make it small! www.iki.fi/~silvere / / No matter where you go, there you are. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-ipsec@lists.tislabs.com Thu Oct 12 06:18:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26437; Thu, 12 Oct 2000 06:18:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15381 Thu, 12 Oct 2000 08:18:14 -0400 (EDT) Date: Thu, 12 Oct 2000 14:30:07 +0200 (Israel Standard Time) From: Arne Ansper To: Andrew Krywaniuk cc: "'ipsec'" Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: <007201c0337a$955ed260$d23e788a@andrewk3.ca.newbridge.com> Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > And I don't understand this whole "derive a pre-shared key from a > self-signed certificate" thing. The whole point of using certificates (IMHO > only, I have discovered) is that they have extra properties that preshared > keys do not have (e.g. the fact that they can be publicly distributed > without revealing the key). If you use the hash of a self-signed certificate > as a preshared key (in which case you cannot distribute the certificate > publicly) then you inherit the worst of both worlds. i'm sorry. i was unclear in my previous posts. i did not mean to use hash of the certificate as a preshared key. i tried to point out that certificate hash can be used in human-machine interaction same way as pre-shared secret is used: you can enter it manually (it is short enough), you can write it down to post-it note and so on. what machine does with this string is different: pre-shared key is used by ike directly. certificate hash is used indirectly via certificate validation routine. conventional certificate validation routine checks the signature of the certificate using public key from CA certificate. i proposed to validate the certificate by comparing the hash of the certificate with previously entered hash. important point is that it provides almost same feeling to user as working with pre-shared keys and you do not need any CA to make it work: just two ipsec devices. at the same time we can simplify ike by removing authentication using pre-shared keys and simplify management software by removing the need to store and distribute confidential information (pre-shared secrets). arne From owner-ipsec@lists.tislabs.com Thu Oct 12 06:46:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26951; Thu, 12 Oct 2000 06:46:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15477 Thu, 12 Oct 2000 08:42:00 -0400 (EDT) Date: Thu, 12 Oct 2000 14:53:04 +0200 (IST) From: Hugo Krawczyk To: "Derrell D. Piper" cc: Dan Harkins , ipsec Subject: Re: Simplifying IKE In-Reply-To: <200010110919.CAA16174@gallium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Oct 2000, Derrell D. Piper wrote: > For purposes of concensus, I think Aggressive Mode is bloat and I'd like to > remove it. There are ways to use pre-shared keys without fixed IP addresses > which solve the problem without giving up identity protection. Aggressive > Mode is a remnant of the SKIP vs ISAKMP debate which optimized round-trips > at > the expense of protocol complexity. It was a bad design decision on our > part > to include it in the first place. > > Derrell If savings of rounds is considered important this can be achieved without aggressive mode, namely, whenever a phase 1 exchange is performed skip phase 2 and derive key material directly from SKEYID_d. This is possible and has no cryptographic disadvantage. However, it certainly changes IKE. Moreover, it violates current isakmp processing. Are there any clear reasons (beyond the above changes to IKE and isakmp) not to do that? Note that if one adopts the above approach, Quick Mode should still be maintained as a periodic re-key mechanism (this was the original intent of this mode in SKEME). Such refreshments are important to limit key usage and to resist cryptanalysis (present and future). Hugo From owner-ipsec@lists.tislabs.com Thu Oct 12 06:51:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27062; Thu, 12 Oct 2000 06:51:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15531 Thu, 12 Oct 2000 09:00:50 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854AAD0@hhdata3.cdsemea.baltimore.com> From: Chris Trobridge To: "Glawitsch, Gregor" , ipsec Subject: RE: Larger DH groups? Date: Thu, 12 Oct 2000 14:12:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I had a look at the patent database and Certicom not the only ones to claim a digital signature patent using Elliptic curves. US6088798 is a digital signature algorithm (a collection thereof?), filed by "Kabushiki Kaisha Toshiba, Kawasaki, Japan". I'm not particularly familiar with the patent system but it seems fairly obscure and I wouldn't want to be responsible for making decisions about patents... Chris > -----Original Message----- > From: Glawitsch, Gregor [mailto:Gregor_Glawitsch@nai.com] > Sent: 06 October 2000 22:46 > To: ipsec > Subject: RE: Larger DH groups? > > > I think it is actually GOOD if Simon/Certicom tries > to claim that their patents cover the whole EC area. > > As the old saying goes: > Here lies a toppled god, > his fall was not a small one, > we did but build a pedestal, > a narrow and a tall one. > > What I'm trying to say: If they try to claim too > much coverage, someone will show the judge a > late seventies/early eighties Cryptography > textbook and the patent will be thrown out > faster than any Certicom lawyer can say the > S-word. > > Greg > > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Friday, October 06, 2000 1:07 PM > To: Simon Blake-Wilson > Cc: Dan Harkins; Ari Huttunen; ipsec > Subject: Re: Larger DH groups? > > > My understanding from earlier statements from certicom (minneapolis > ietf?) was that certicom is attempting to patent certain ec > acceleration > techniques, but that ec's themselves are not patentable. Your > statement > seems to be that ec's in any form are either patented or > patent-pending > by certicom. Is this correct? > > Simon Blake-Wilson wrote: > > > > Hi Dan, > > > > Ahh ... the eternal patent question. Unfortunately the patent system > doesn't > > allow the kind of black and white answer you're looking > for. However I > think our > > IPR statement is fairly clear that we believe we have > patents and patent > > applcations covering ECC. Our advice to anyone implementing > ECC is to take > a > > license from Certicom :-). > > > > On the IANA issue. I believe all our numbers for ECC groups > were assigned > by > > IANA as specified in RFC 2409. I believe the link to the > numbers on the > IANA > > site is: > > http://www.isi.edu/in-notes/iana/assignments/ipsec-registry. > > > > Best regards. Simon > > > > S. Blake-Wilson > > Certicom Corp. > > > > Dan Harkins on 10/05/2000 02:58:16 PM > > > > To: Simon Blake-Wilson/Certicom@Certicom > > cc: Ari Huttunen , ipsec > > > Subject: Re: Larger DH groups? > > > > While updating the "Additional ECC groups for IKE" draft can you > unqualify > > your IP statement? Do you or do you not have patents that > cover this? It > > would be nice if there was a one syllable response to the > question "is a > > license from Certicom essential to implement these curves?" > > > > Also, in the AES assigned numbers thread it became > obvious that certain > > vendors have been assigning numbers which are reserved to > IANA to their > > own use of algorithms. I'd like to note that you are > repeating this error > > in your draft and respectfully ask you to use numbers from > the private use > > range for all the groups in this draft. Section 11.4 of > RFC2409 describes > > the procedure necessary for you to follow to get IANA to > assign number to > > you. > > > > Dan. > > > > On Thu, 05 Oct 2000 12:08:23 EDT you wrote > > > > > > Diffie-Hellman is a cubic operation, so I believe > 15000-bit DH should > take > > about > > > 15^3 approx=3000 times as long as 1000-bit DH, and > 512-bit ECDH should > take > > > about 25 times as long as 160-bit ECC. We don't have > implementations of > > > 15000-bit DH but we do have 512-bit ECDH and our > performance roughly > follows > > the > > > estimates. (In fact we're in the process of adding > 512-bit curves to our > > > "Additional ECC groups for IKE" draft so that it has complete AES > support.) > > > > > > Best regards. Simon > > > > > > S. Blake-Wilson > > > Certicom Corp. > > > > > > > > > > > > > > > > > > Ari Huttunen on 10/05/2000 11:02:42 AM > > > > > > To: ipsec > > > cc: (bcc: Simon Blake-Wilson/Certicom) > > > Subject: Larger DH groups? > > > > > > > > > > > > > > > Are there plans/interest in specifying larger standard DH > groups, now > that > > > the AES has been chosen? > > > > > > If so, what sizes would be appropriate? Tero earlier > posted groups of > > > 2000-4000 bits, the draft for AES talks about 14000. > Anybody know just > > > how slow would 14000 bit modulus be? (I can guess it's > something between > > > extremely slow and ridiculously slow..) What about the > speed of a 500 > bit > > EC2N? > > > > > > Ari > > > > > > -- > > > Ari Huttunen phone: +358 9 859 900 > > > Senior Software Engineer fax : +358 9 8599 0452 > > > > > > F-Secure Corporation http://www.F-Secure.com > > > > > > F-Secure products: Integrated Solutions for Enterprise Security > From owner-ipsec@lists.tislabs.com Thu Oct 12 08:14:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29645; Thu, 12 Oct 2000 08:14:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15756 Thu, 12 Oct 2000 10:03:41 -0400 (EDT) Message-Id: <200010121412.e9CEC0V18350@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Hugo Krawczyk Cc: "Derrell D. Piper" , Dan Harkins , ipsec Subject: Re: Simplifying IKE In-reply-to: Your message of "Thu, 12 Oct 2000 14:53:04 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Oct 2000 10:12:00 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Hugo Kr awczyk writes: > >If savings of rounds is considered important this can be achieved >without aggressive mode, namely, whenever a phase 1 exchange is performed >skip phase 2 and derive key material directly from SKEYID_d. >This is possible and has no cryptographic disadvantage. However, it >certainly changes IKE. Moreover, it violates current isakmp processing. >Are there any clear reasons (beyond the above changes to IKE and isakmp) >not to do that? You'd have to move the negotiation currently happening in Phase 2 to Phase 1; this includes all the Phase 2 IDs and the IPsec SA parameters. -Angelos From owner-ipsec@lists.tislabs.com Thu Oct 12 08:16:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00400; Thu, 12 Oct 2000 08:16:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15776 Thu, 12 Oct 2000 10:05:05 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B00369521E@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'silvere@iki.fi'" , svan@trustworks.com, ipsec@lists.tislabs.com Subject: RE: Simplifying IKE (was RE: Reliable delete notifies) Date: Thu, 12 Oct 2000 07:16:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are other key exchanges (and domains of interpretation) defined over ISAKMP. However, they are apparently classified. At least it lets us know that the spooks trust ISAKMP. (After all, they designed it.) From owner-ipsec@lists.tislabs.com Thu Oct 12 08:36:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05273; Thu, 12 Oct 2000 08:36:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15936 Thu, 12 Oct 2000 10:36:12 -0400 (EDT) Message-Id: <200010121447.e9CEl8l141619@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: "'IP Security List'" Subject: Re: Definition of PFS... In-reply-to: Your message of "Wed, 11 Oct 2000 18:51:34 EDT." <200010112251.SAA18092@solidum.com> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 12 Oct 2000 10:47:08 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It also defends against the situation where a third party compels one > party to provide some set of keys. PFS guarantees that a simple search warant > only catches traffic *currently* in transit, not all previous and future > traffic. Not quite that simple; it's a matter of what the lifetimes of the IKE and AH/ESP SA's really are.. If your AH/ESP SA lifetimes are 12 hours, this gives someone 12 hours of traffic even if quick mode with PFS was used to create them. Similarly, if you don't use PFS in quick mode, but limit your IKE SA's (and the AH/ESP SA's derived from them via quick mode) to a lifetime of 1 hour, you get 1 hour of traffic. - Bill From owner-ipsec@lists.tislabs.com Thu Oct 12 13:08:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14355; Thu, 12 Oct 2000 13:08:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16842 Thu, 12 Oct 2000 14:49:26 -0400 (EDT) Date: Thu, 12 Oct 2000 15:00:24 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Oct 2000, Sami Vaarala wrote: > ...That might be. But is someone actually planning to implement two > key management protocols on top of the *same* isakmp code? From my > experience there are enough dependencies between ISAKMP and IKE to > make such isolation difficult and probably unwise, too. Realistically, anyone designing a new key-management protocol would have to be out of his mind to base it on ISAKMP. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Oct 12 13:13:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14692; Thu, 12 Oct 2000 13:13:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16952 Thu, 12 Oct 2000 15:11:17 -0400 (EDT) Message-Id: <4.3.1.0.20001012091307.00d464d0@brisco.passedge.com> X-Sender: mbaugher@brisco.passedge.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 12 Oct 2000 12:23:22 -0700 To: ipsec@lists.tislabs.com From: Mark Baugher Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to call your attention to http://search.ietf.org/internet-drafts/draft-irtf-smug-gdoi-00.txt Mark >That might be. But is someone actually planning to implement two >key management protocols on top of the *same* isakmp code? From my >experience there are enough dependencies between ISAKMP and IKE to >make such isolation difficult and probably unwise, too. > >As a framework for specifying the new protocols, ISAKMP is fine >(it could be less ambiguous though). But I don't think there will >be too much code sharing between the different key management >protocols one could build into the ISAKMP framework. And if not, >I am not sure there is enough justification not to roll the ISAKMP >stuff into a new IKE specification. That should clear a lot of >ambiguities that are a result of artificial separation of the two >specifications. Mark Baugher PGP Fingerprint 01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C From owner-ipsec@lists.tislabs.com Thu Oct 12 13:51:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16200; Thu, 12 Oct 2000 13:51:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17179 Thu, 12 Oct 2000 15:55:57 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: Steve Bellovin To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Oct 2000 16:07:33 -0400 Message-Id: <20001012200733.8B5AE35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The new hash algorithms have been released. See http://www.nist.gov/sha/ for details. --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Oct 12 16:24:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19802; Thu, 12 Oct 2000 16:24:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17608 Thu, 12 Oct 2000 18:23:45 -0400 (EDT) Message-Id: <4.3.1.0.20001012153443.00d62e90@brisco.passedge.com> X-Sender: mbaugher@brisco.passedge.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 12 Oct 2000 15:35:56 -0700 To: IP Security List From: Mark Baugher Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Realistically, anyone designing a new key-management protocol would have >to be out of his mind to base it on ISAKMP. Why? Mark From owner-ipsec@lists.tislabs.com Thu Oct 12 16:49:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20235; Thu, 12 Oct 2000 16:49:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17673 Thu, 12 Oct 2000 18:55:15 -0400 (EDT) Date: Thu, 12 Oct 2000 19:06:12 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: <4.3.1.0.20001012153443.00d62e90@brisco.passedge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Oct 2000, Mark Baugher wrote: > >Realistically, anyone designing a new key-management protocol would have > >to be out of his mind to base it on ISAKMP. > > Why? Because it's grossly complex, badly designed, and poorly documented. It doesn't do enough for you to be worth the trouble. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Oct 12 16:52:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20591; Thu, 12 Oct 2000 16:52:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17661 Thu, 12 Oct 2000 18:53:16 -0400 (EDT) Message-ID: <1BE57AA01A5ED411866500B0D049657B550EB1@exchange.cylink.com> From: "Burke, John" To: "'raghu arni'" , =?iso-8859-1?Q?Gerardo_Ar=E9v?= =?iso-8859-1?Q?alo_Tamayo?= , IPsec List Subject: RE: Tutor Date: Thu, 12 Oct 2000 16:01:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA17658 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think it's right to mention, the book is by Doraswamy and Harkins, that's Dan Harkins and Naganand Doraswamy, both heavy contributors to the work of the IPSEC group. -----Original Message----- From: raghu arni [mailto:arni@caip.rutgers.edu] Sent: Saturday, October 07, 2000 7:31 PM To: Gerardo Arévalo Tamayo; IPsec List Subject: Re: Tutor see the book on ipsec by dorswamay...has some good notes for implementers.. also get the freeswan ipsec implementation..no substitute for seeing some good implementation code..;) A > > I wonder if: > > 1) There is a software application like a tutor that helps anyone who > wants to implement IPsec.? > 2) It is a good idea to include something about network managing, > cryptographics laws, vendors, or the rfcs are enough in this > application.? > > I really appreciate your help. > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.1 Int. for non-commercial use > > Comment: PubKey http://orbita.starmedia.com/~gerarg1/gat.asc > > iQA/AwUBOd+SFqB2HuDO7EnLEQK8GQCeIcfJv9+F6w2Yo1mSPE9lgYkMCcoAnjgP > 4xBcg7CpvJxf49NYMbepQvBL > =Ri3G > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Oct 12 23:59:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA28058; Thu, 12 Oct 2000 23:59:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA18741 Fri, 13 Oct 2000 01:36:00 -0400 (EDT) Message-Id: <200010130547.JAA18476@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: IP Security List , Henry Spencer Date: Fri, 13 Oct 2000 09:46:27 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) References: <4.3.1.0.20001012153443.00d62e90@brisco.passedge.com> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 12 Oct 00, at 19:06, Henry Spencer wrote: > On Thu, 12 Oct 2000, Mark Baugher wrote: > > >Realistically, anyone designing a new key-management protocol would have > > >to be out of his mind to base it on ISAKMP. > > > > Why? > > Because it's grossly complex, badly designed, and poorly documented. > It doesn't do enough for you to be worth the trouble. Please, suggest an alternative. > Henry Spencer > henry@spsystems.net Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Fri Oct 13 00:38:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA28772; Fri, 13 Oct 2000 00:38:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18935 Fri, 13 Oct 2000 02:41:29 -0400 (EDT) Date: Fri, 13 Oct 2000 02:47:50 -0400 From: Richard Guy Briggs To: Valery Smyslov Cc: IP Security List , Henry Spencer Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) Message-ID: <20001013024750.E26900@grendel.conscoop.ottawa.on.ca> References: <4.3.1.0.20001012153443.00d62e90@brisco.passedge.com> <200010130547.JAA18476@relay1.trustworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200010130547.JAA18476@relay1.trustworks.com>; from svan@trustworks.com on Fri, Oct 13, 2000 at 09:46:27AM +0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, Oct 13, 2000 at 09:46:27AM +0400, Valery Smyslov wrote: > On 12 Oct 00, at 19:06, Henry Spencer wrote: > > On Thu, 12 Oct 2000, Mark Baugher wrote: > > > >Realistically, anyone designing a new key-management protocol would have > > > >to be out of his mind to base it on ISAKMP. > > > > > > Why? > > > > Because it's grossly complex, badly designed, and poorly documented. > > It doesn't do enough for you to be worth the trouble. > > Please, suggest an alternative. Photuris. See OpenBSD.org > > Henry Spencer > > Regards, > Valery Smyslov. slainte mhath, RGB - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOeawFN+sBuIhFagtAQHTSAQAj112Ii63nKpKkXC6lRNCOMYSG3nHQvcY heUS5I4NmSgKTBRdIjkT4NMbq6DW4XnkhJFYOo4UpRbRmKkTXoazFYbnNB1bKLan dZxmANlxEPw4Dny2qMraOfZnjA3V4uFhu3CNqlnraQTTe7J7UCQnG0JmAsJ97tzg LAKk5mAyuQg= =Gwdu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Oct 13 02:49:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08880; Fri, 13 Oct 2000 02:49:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA19370 Fri, 13 Oct 2000 04:45:21 -0400 (EDT) Message-Id: <200010130856.MAA28375@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Richard Guy Briggs Date: Fri, 13 Oct 2000 12:55:35 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) CC: IP Security List , Henry Spencer In-reply-to: <20001013024750.E26900@grendel.conscoop.ottawa.on.ca> References: <200010130547.JAA18476@relay1.trustworks.com>; from svan@trustworks.com on Fri, Oct 13, 2000 at 09:46:27AM +0400 X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 13 Oct 00, at 2:47, Richard Guy Briggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > On Fri, Oct 13, 2000 at 09:46:27AM +0400, Valery Smyslov wrote: > > On 12 Oct 00, at 19:06, Henry Spencer wrote: > > > On Thu, 12 Oct 2000, Mark Baugher wrote: > > > > >Realistically, anyone designing a new key-management protocol would have > > > > >to be out of his mind to base it on ISAKMP. > > > > > > > > Why? > > > > > > Because it's grossly complex, badly designed, and poorly documented. > > > It doesn't do enough for you to be worth the trouble. > > > > Please, suggest an alternative. > > Photuris. See OpenBSD.org I know it well and I like it (especially its true stateless cookies). However, it is not a real alternative to ISAKMP. It may be considered as an alternative to IKE (as an "instantiation" of ISAKMP), but not to ISAKMP itself. Even comparing to IKE, Photuris (despite some really good things that it has), IMHO, suffers from the lack of extensibility and flexibility. Photuris demonstrates a good solid design, but any attempt to add something substantially different to the protocol may lead to its collapse. Any more suggestions (please, do not mention SKIP or HIP)? Regards, Valery Smyslov. > > > Henry Spencer > > > > Regards, > > Valery Smyslov. > > slainte mhath, RGB > - -- > Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada > > Prevent Internet Wiretapping! -- FreeS/WAN: > Thanks for voting Green! -- Marillion: > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3i > Charset: noconv > > iQCVAwUBOeawFN+sBuIhFagtAQHTSAQAj112Ii63nKpKkXC6lRNCOMYSG3nHQvcY > heUS5I4NmSgKTBRdIjkT4NMbq6DW4XnkhJFYOo4UpRbRmKkTXoazFYbnNB1bKLan > dZxmANlxEPw4Dny2qMraOfZnjA3V4uFhu3CNqlnraQTTe7J7UCQnG0JmAsJ97tzg > LAKk5mAyuQg= > =Gwdu > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Fri Oct 13 04:53:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA16143; Fri, 13 Oct 2000 04:53:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA19721 Fri, 13 Oct 2000 06:39:05 -0400 (EDT) Message-Id: <200010131034.GAA02111@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippcp@external.cisco.com, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-06.txt Date: Fri, 13 Oct 2000 06:34:05 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-06.txt Pages : 11 Date : 12-Oct-00 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-06.txt Internet-Drafts are also 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-shacham-ippcp-rfc2393bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-06.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: <20001012120930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001012120930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Oct 13 06:52:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19357; Fri, 13 Oct 2000 06:52:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20435 Fri, 13 Oct 2000 08:47:12 -0400 (EDT) Message-ID: <21B2FBDAE847D411A8BA009027A128B938DED5@cms3.etri.re.kr> From: =?euc-kr?B?scfH9cL5?= To: "'ipsec'" Subject: Help : Mobile IPsec Date: Fri, 13 Oct 2000 09:27:51 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. please help me !!! I need an information about IPSec in Mobile IP. I would like to know about related projects which were completed or are being carried out, and an information about any products from them, and related research papers, etc. Thanks in advance. Hyeok Chan Kwon. From owner-ipsec@lists.tislabs.com Fri Oct 13 08:34:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25902; Fri, 13 Oct 2000 08:34:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20785 Fri, 13 Oct 2000 10:09:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Thu, 12 Oct 2000 12:51:45 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: RE: charter question re IKE changes Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, >At 9:31 PM -0400 10/11/00, Stephen Kent wrote: >>certainly we know how to generate and distribte certs to users who >>already have entries in a Radius database. > >Of course, if that was all we needed to do, our lives would be >simpler and freer from suffering. However, it isn't. Implementations >of PKI in the user environment have found that distributing the >private keys associated with the public keys in the certs, and doing >so in such a way that the user can use the certificate easily and >flexibly, is the difficult problem. Note that "distributing" is even >difficult when the private-public pair is generated on the user's >own device because the private key has to be secured and yet be made >available through applications that would need the user to sign >things. We know the technology for doing this, but we have so far >implemented it in very klunky fashions. Passwords that can be >memorized by a user seem a lot more attractive to people who don't >understand how utterly insecure they are (and even to some people >who do). Your characterization of the problem does not match mine. We're working from different models: - yes, I would expect the user to generate a key pair on the machine in question, to avoid the problem of "distributing" a private key. smart cards would be better, and then we incur more costs, but folks who argue for use of SecurID cards must address the same sorts of costs of hardware acquisition and distribution. so, if we just compare passwords to key pairs, it seems quite reasonable to assume local generation of key pairs. - no, I would not make this key available to other applications, and thus would not have to address the second problem you cite. a key used to authenticate the user for IPsec need not be used for anything else. trying to impose a one-user one-key philosophy is asking fro trouble, from a security standpoint, and from an implementation perspective as well Given this perspective, remind me again why knowledgeable folks prefer passwords, IF we provide them with good software for the initial certificate issuance process, working from an existing password database :-) Steve From owner-ipsec@lists.tislabs.com Fri Oct 13 08:38:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26592; Fri, 13 Oct 2000 08:38:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20898 Fri, 13 Oct 2000 10:26:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Fri, 13 Oct 2000 07:35:20 -0700 To: Stephen Kent From: Paul Hoffman / VPNC Subject: RE: charter question re IKE changes Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:51 PM -0400 10/12/00, Stephen Kent wrote: >Given this perspective, remind me again why knowledgeable folks >prefer passwords, IF we provide them with good software for the >initial certificate issuance process, working from an existing >password database :-) Because we don't. I agree with your perspectives about how it *could* work, but that's not what is being delivered. Today's users make choices based on what is available to them today. I also think the market disagrees with you about smart cards. Smart cards are only useful where there are smart card readers. They become an obstacle where there are no readers. Again, I fully support the use of certs and wish that more users agreed with me. But they don't, and designing a protocol around a wish that has had plenty of time to come true but hasn't is a good way to design yet another protocol that won't get implemented. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Oct 13 09:20:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27812; Fri, 13 Oct 2000 09:20:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21046 Fri, 13 Oct 2000 11:07:34 -0400 (EDT) To: Paul Hoffman / VPNC Cc: Stephen Kent , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: charter question re IKE changes References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> From: Derek Atkins Date: 13 Oct 2000 11:19:06 -0400 In-Reply-To: Paul Hoffman / VPNC's message of "Fri, 13 Oct 2000 07:35:20 -0700" Message-ID: Lines: 46 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FWIW, I have been working on a Web-based CA that allows a user to obtain a certificate based upon an existing username/password. It's currently setup for web-client certificates (netscape/msie/lynx) but it could be extended to others as well. As Steve said, it's not difficult to create such a beast. However Paul is right in that nobody has, as of yet, delivered one. FWIW, at MIT I've setup an IPSec-based tunnel server that uses HTTPS+Certificates for secure administration. A user generates their RSA key and then submits it via SSL for entry into the IPSec database. They have to use their certs obtained as above. There ya go! Automated "password" sharing of RSA keys based upon existing username/password entries :) -derek Paul Hoffman / VPNC writes: > At 12:51 PM -0400 10/12/00, Stephen Kent wrote: > >Given this perspective, remind me again why knowledgeable folks > >prefer passwords, IF we provide them with good software for the > >initial certificate issuance process, working from an existing > >password database :-) > > Because we don't. I agree with your perspectives about how it *could* > work, but that's not what is being delivered. Today's users make > choices based on what is available to them today. > > I also think the market disagrees with you about smart cards. Smart > cards are only useful where there are smart card readers. They become > an obstacle where there are no readers. > > Again, I fully support the use of certs and wish that more users > agreed with me. But they don't, and designing a protocol around a > wish that has had plenty of time to come true but hasn't is a good > way to design yet another protocol that won't get implemented. > > --Paul Hoffman, Director > --VPN Consortium -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Oct 13 10:05:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01314; Fri, 13 Oct 2000 10:05:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21242 Fri, 13 Oct 2000 11:51:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Fri, 13 Oct 2000 12:03:48 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: RE: charter question re IKE changes Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I think there is confusion about the context in which I made the initial statement. I agree that what is provided today falls short of what could/should be done. I call your attention to the two sentences at the end of the message that I sent and which precipitated this discussion: >but, what products can we buy that allow us to do this? so, my view >is that the IPsec insistence for high quality, 2-way authentication >is appropriate, but that implementations have not yet provided good >enough PKI support to make it easy for folks to "embrace" the >technology. Steve From owner-ipsec@lists.tislabs.com Fri Oct 13 10:31:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02155; Fri, 13 Oct 2000 10:31:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21458 Fri, 13 Oct 2000 12:29:53 -0400 (EDT) Message-Id: <200010131635.JAA26753@potassium.network-alchemy.com> To: Paul Hoffman / VPNC cc: Stephen Kent , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: charter question re IKE changes In-reply-to: Your message of "Fri, 13 Oct 2000 07:35:20 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26750.971454929.1@network-alchemy.com> Date: Fri, 13 Oct 2000 09:35:29 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The lack of people implementing good products should not be a motivating factor in developing standards. If we all agree on how it *could* work then let's promote that. I think the market will follow a good solution. I used to love teco until someone showed me vi and that love affair lasted until someone showed me emacs. Dan. On Fri, 13 Oct 2000 07:35:20 PDT you wrote > At 12:51 PM -0400 10/12/00, Stephen Kent wrote: > >Given this perspective, remind me again why knowledgeable folks > >prefer passwords, IF we provide them with good software for the > >initial certificate issuance process, working from an existing > >password database :-) > > Because we don't. I agree with your perspectives about how it *could* > work, but that's not what is being delivered. Today's users make > choices based on what is available to them today. > > I also think the market disagrees with you about smart cards. Smart > cards are only useful where there are smart card readers. They become > an obstacle where there are no readers. > > Again, I fully support the use of certs and wish that more users > agreed with me. But they don't, and designing a protocol around a > wish that has had plenty of time to come true but hasn't is a good > way to design yet another protocol that won't get implemented. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Oct 13 11:47:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03508; Fri, 13 Oct 2000 11:47:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21834 Fri, 13 Oct 2000 13:43:06 -0400 (EDT) Date: Fri, 13 Oct 2000 13:54:13 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: <200010130856.MAA28375@relay1.trustworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 13 Oct 2000, Valery Smyslov wrote: > > Photuris. See OpenBSD.org > > I know it well and I like it (especially its true stateless cookies). > However, it is not a real alternative to ISAKMP. It may be considered > as an alternative to IKE (as an "instantiation" of ISAKMP), but not > to ISAKMP itself. That's true. The question is whether there is any real need for an alternative to ISAKMP. The real alternative, as in Photuris, is simply to design the data structures to suit the application, rather than insisting that the application must be an "instantiation" of some more general structure -- which typically is as much a hindrance as a help. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Oct 13 11:54:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03661; Fri, 13 Oct 2000 11:54:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21877 Fri, 13 Oct 2000 13:53:33 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 13 Oct 2000 12:04:23 -0600 From: "Hilarie Orman" To: , Subject: Re: Definition of PFS... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA21873 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The point of ephemeral Diffie-Hellman in QM is to get independent keying material (PFS) without repetition of authentication. The assumption is that this will be done periodically and should be as inexpensive as possible. Hilarie From owner-ipsec@lists.tislabs.com Fri Oct 13 13:01:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05102; Fri, 13 Oct 2000 13:01:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22115 Fri, 13 Oct 2000 14:47:26 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: , "'Michael Richardson'" Cc: "'IP Security List'" Subject: RE: Definition of PFS... Date: Fri, 13 Oct 2000 14:50:55 -0400 Message-Id: <00bb01c03546$851d0bb0$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200010121447.e9CEl8l141619@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's what I thought. To me, it makes more sense to limit key exposure via. phase 1 rekeying rather than by PFS. It's slightly slower (if your CertSign/CertVerify operations are comparable in CPU time to your DH calculation), but the security tradeoffs make more sense. I suppose that QM PFS does have a value (as an optimization of phase 1 rekeying) solely for the purpose of combatting search warrants. Assuming that: 1. key escrow is not required 2. law enforcement officers can bypass your box's tamper-proof mechanisms 3. but they are ethically prevented from cryptographically impersonating you then you would indeed be able to limit your key exposure using PFS. But for the purpose of preventing against active or passive attacks by persons other than law enforcement, DH refresh without re-authentication doesn't do that much for you. What concerns me is that, as with many things in IKE, the intent of this feature is not documented, particularly the security model in which DH refresh without re-authentication is "warranted" :-) Consequently, most implementers I have talked to don't understand what the supposed purpose of PFS is (most of them will cite the log(n) added security argument, which really isn't significant). Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bill Sommerfeld > Sent: Thursday, October 12, 2000 10:47 AM > To: Michael Richardson > Cc: 'IP Security List' > Subject: Re: Definition of PFS... > > > > It also defends against the situation where a third party > compels one > > party to provide some set of keys. PFS guarantees that a > simple search warant > > only catches traffic *currently* in transit, not all > previous and future > > traffic. > > Not quite that simple; it's a matter of what the lifetimes of the IKE > and AH/ESP SA's really are.. > > If your AH/ESP SA lifetimes are 12 hours, this gives someone 12 hours > of traffic even if quick mode with PFS was used to create them. > > Similarly, if you don't use PFS in quick mode, but limit your IKE SA's > (and the AH/ESP SA's derived from them via quick mode) to a lifetime > of 1 hour, you get 1 hour of traffic. > > - Bill > From owner-ipsec@lists.tislabs.com Fri Oct 13 13:03:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05135; Fri, 13 Oct 2000 13:03:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22207 Fri, 13 Oct 2000 15:01:47 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789223@md-exchange1.nai.com> From: "Mason, David" To: "'Hilarie Orman'" , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: RE: Definition of PFS... Date: Fri, 13 Oct 2000 12:10:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are you saying that a 768-bit MODP DH would be useful (and make sense security wise cryptographically) in QM even though the IPsec cipher negotiated has a large key? Would using a 1536-bit (or larger) DH generally be a waste of computational resources for the QM DH (in what cases would/would not a 768-bit DH suffice)? The way IPsec keys are currently generated in IKE I would think that you would want to either always do a QM DH or never do a QM DH (periodically doing them only helps that specific exchange - should son-of-ike consider folding the QM g^xy back into SKEYID_d somehow so that periodic QM DH has value beyond the specific exchange - although simultaneous QMs would make this problematic?). -dave -----Original Message----- From: Hilarie Orman [mailto:HORMAN@novell.com] Sent: Friday, October 13, 2000 2:04 PM To: andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com Subject: Re: Definition of PFS... The point of ephemeral Diffie-Hellman in QM is to get independent keying material (PFS) without repetition of authentication. The assumption is that this will be done periodically and should be as inexpensive as possible. Hilarie From owner-ipsec@lists.tislabs.com Fri Oct 13 14:51:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07327; Fri, 13 Oct 2000 14:51:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22573 Fri, 13 Oct 2000 16:30:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200010131635.JAA26753@potassium.network-alchemy.com> References: <200010131635.JAA26753@potassium.network-alchemy.com> Date: Fri, 13 Oct 2000 16:35:30 -0400 To: Dan Harkins From: Stephen Kent Subject: Re: charter question re IKE changes Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:35 AM -0700 10/13/00, Dan Harkins wrote: > The lack of people implementing good products should not be a >motivating factor in developing standards. If we all agree on >how it *could* work then let's promote that. > > I think the market will follow a good solution. I used to love >teco until someone showed me vi and that love affair lasted >until someone showed me emacs. > > Dan. I am in complete agreement with Dan. Steve From owner-ipsec@lists.tislabs.com Fri Oct 13 15:30:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07926; Fri, 13 Oct 2000 15:30:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22739 Fri, 13 Oct 2000 17:32:50 -0400 (EDT) Message-ID: From: Rajesh Mohan To: sommerfeld@East.Sun.COM, "'Michael Richardson'" , "'Andrew Krywaniuk'" Cc: "'IP Security List'" Subject: RE: Definition of PFS... Date: Fri, 13 Oct 2000 14:46:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The amount of data encrypted using a key is limited by doing phase 2 rekeying with PFS. This prevents attack based on encrypted data. So, DH refresh without re-authentication prevents ciphertext only attack. Ofcourse, doing phase 1 rekeying with every phase 2 rekeying, is more safe but does have a overhead. Rajesh M ---------- From: Andrew Krywaniuk [SMTP:andrew.krywaniuk@alcatel.com] Sent: Friday, October 13, 2000 11:51 AM To: sommerfeld@East.Sun.COM; 'Michael Richardson' Cc: 'IP Security List' Subject: RE: Definition of PFS... That's what I thought. To me, it makes more sense to limit key exposure via. phase 1 rekeying rather than by PFS. It's slightly slower (if your CertSign/CertVerify operations are comparable in CPU time to your DH calculation), but the security tradeoffs make more sense. I suppose that QM PFS does have a value (as an optimization of phase 1 rekeying) solely for the purpose of combatting search warrants. Assuming that: 1. key escrow is not required 2. law enforcement officers can bypass your box's tamper-proof mechanisms 3. but they are ethically prevented from cryptographically impersonating you then you would indeed be able to limit your key exposure using PFS. But for the purpose of preventing against active or passive attacks by persons other than law enforcement, DH refresh without re-authentication doesn't do that much for you. What concerns me is that, as with many things in IKE, the intent of this feature is not documented, particularly the security model in which DH refresh without re-authentication is "warranted" :-) Consequently, most implementers I have talked to don't understand what the supposed purpose of PFS is (most of them will cite the log(n) added security argument, which really isn't significant). Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bill Sommerfeld > Sent: Thursday, October 12, 2000 10:47 AM > To: Michael Richardson > Cc: 'IP Security List' > Subject: Re: Definition of PFS... > > > > It also defends against the situation where a third party > compels one > > party to provide some set of keys. PFS guarantees that a > simple search warant > > only catches traffic *currently* in transit, not all > previous and future > > traffic. > > Not quite that simple; it's a matter of what the lifetimes of the IKE > and AH/ESP SA's really are.. > > If your AH/ESP SA lifetimes are 12 hours, this gives someone 12 hours > of traffic even if quick mode with PFS was used to create them. > > Similarly, if you don't use PFS in quick mode, but limit your IKE SA's > (and the AH/ESP SA's derived from them via quick mode) to a lifetime > of 1 hour, you get 1 hour of traffic. > > - Bill > From owner-ipsec@lists.tislabs.com Fri Oct 13 15:36:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07971; Fri, 13 Oct 2000 15:36:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22768 Fri, 13 Oct 2000 17:41:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200010131635.JAA26753@potassium.network-alchemy.com> References: <200010131635.JAA26753@potassium.network-alchemy.com> Date: Fri, 13 Oct 2000 14:52:44 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: charter question re IKE changes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:35 AM -0700 10/13/00, Dan Harkins wrote: > The lack of people implementing good products should not be a >motivating factor in developing standards. If we all agree on >how it *could* work then let's promote that. Of course. We should continue to promote certs and explain the security problems of preshared secrets. No one has said otherwise. The question is should we continue to allow the *use* of preshared secrets. > I think the market will follow a good solution. So far, that has not been shown true in the IPsec market. The proposal to remove preshared secrets from son-of-IKE was made as a way to *force* people towards the better solution. Given that IKE will exist forever, it is unclear to me that removing preshared secrets from son-of-IKE will do anything to convince the users of preshared secrets to switch. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Oct 13 16:59:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09418; Fri, 13 Oct 2000 16:59:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22911 Fri, 13 Oct 2000 19:07:32 -0400 (EDT) From: "Scott Fanning" To: "Paul Hoffman / VPNC" , Subject: RE: charter question re IKE changes Date: Fri, 13 Oct 2000 16:25:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is always the customers choice to develop their security model based on their threat model. To impose a solution, sometimes makes a customer more nervous. My two cents. Scott > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Friday, October 13, 2000 2:53 PM > To: ipsec@lists.tislabs.com > Subject: Re: charter question re IKE changes > > > At 9:35 AM -0700 10/13/00, Dan Harkins wrote: > > The lack of people implementing good products should not be a > >motivating factor in developing standards. If we all agree on > >how it *could* work then let's promote that. > > Of course. We should continue to promote certs and explain the > security problems of preshared secrets. No one has said otherwise. > The question is should we continue to allow the *use* of preshared > secrets. > > > I think the market will follow a good solution. > > So far, that has not been shown true in the IPsec market. The > proposal to remove preshared secrets from son-of-IKE was made as a > way to *force* people towards the better solution. Given that IKE > will exist forever, it is unclear to me that removing preshared > secrets from son-of-IKE will do anything to convince the users of > preshared secrets to switch. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Fri Oct 13 17:02:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09494; Fri, 13 Oct 2000 17:02:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22887 Fri, 13 Oct 2000 18:50:35 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" Cc: "'IP Security List'" Subject: RE: Definition of PFS... Date: Fri, 13 Oct 2000 18:54:06 -0400 Message-Id: <00c901c03568$7e442540$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, phase 2 rekeying without PFS already fully protects against attacks based on encrypted data (unless you think you can break an HMAC more easily than a DH). If PFS is being used as an optimization to phase 1 rekeying (skipping the authentication phase), then I was going to suggest what Dave said (replacing SKEYID_D from the phase 1 with the new DH value and doing PFS only occasionally). But even so, I still can't think of any threat models (except for the ethical law-enforcement one) that would be mitigated by using PFS as an optimization. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Rajesh Mohan [mailto:RMohan@vpnet.com] > Sent: Friday, October 13, 2000 5:47 PM > To: sommerfeld@East.Sun.COM; 'Michael Richardson'; 'Andrew Krywaniuk' > Cc: 'IP Security List' > Subject: RE: Definition of PFS... > > > The amount of data encrypted using a key is limited by doing phase 2 > rekeying with PFS. This prevents attack based on encrypted > data. So, DH > refresh without re-authentication prevents ciphertext only attack. > > Ofcourse, doing phase 1 rekeying with every phase 2 rekeying, > is more safe > but does have a overhead. > > Rajesh M > > ---------- > From: Andrew Krywaniuk [SMTP:andrew.krywaniuk@alcatel.com] > Sent: Friday, October 13, 2000 11:51 AM > To: sommerfeld@East.Sun.COM; 'Michael Richardson' > Cc: 'IP Security List' > Subject: RE: Definition of PFS... > > That's what I thought. To me, it makes more sense to limit key > exposure via. > phase 1 rekeying rather than by PFS. It's slightly > slower (if your > CertSign/CertVerify operations are comparable in CPU > time to your DH > calculation), but the security tradeoffs make more sense. > > I suppose that QM PFS does have a value (as an > optimization of phase > 1 > rekeying) solely for the purpose of combatting search warrants. > Assuming > that: > > 1. key escrow is not required > 2. law enforcement officers can bypass your box's tamper-proof > mechanisms > 3. but they are ethically prevented from cryptographically > impersonating you > > then you would indeed be able to limit your key > exposure using PFS. > > But for the purpose of preventing against active or > passive attacks > by > persons other than law enforcement, DH refresh without > re-authentication > doesn't do that much for you. > > What concerns me is that, as with many things in IKE, > the intent of > this > feature is not documented, particularly the security > model in which > DH > refresh without re-authentication is "warranted" :-) > > Consequently, most implementers I have talked to don't > understand > what the > supposed purpose of PFS is (most of them will cite the > log(n) added > security > argument, which really isn't significant). > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > Bill Sommerfeld > > Sent: Thursday, October 12, 2000 10:47 AM > > To: Michael Richardson > > Cc: 'IP Security List' > > Subject: Re: Definition of PFS... > > > > > > > It also defends against the situation where a third party > > compels one > > > party to provide some set of keys. PFS guarantees that a > > simple search warant > > > only catches traffic *currently* in transit, not all > > previous and future > > > traffic. > > > > Not quite that simple; it's a matter of what the > lifetimes of the > IKE > > and AH/ESP SA's really are.. > > > > If your AH/ESP SA lifetimes are 12 hours, this gives > someone 12 > hours > > of traffic even if quick mode with PFS was used to > create them. > > > > Similarly, if you don't use PFS in quick mode, but > limit your IKE > SA's > > (and the AH/ESP SA's derived from them via quick mode) to a > lifetime > > of 1 hour, you get 1 hour of traffic. > > > > - Bill > > > From owner-ipsec@lists.tislabs.com Fri Oct 13 17:24:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10113; Fri, 13 Oct 2000 17:24:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22984 Fri, 13 Oct 2000 19:29:35 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 13 Oct 2000 17:40:29 -0600 From: "Hilarie Orman" To: , Cc: , , Subject: Re: charter question re IKE changes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA22980 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How amazing. I use emacs, too. Hilarie >>> Stephen Kent 10/13/00 02:35PM >>> At 9:35 AM -0700 10/13/00, Dan Harkins wrote: > The lack of people implementing good products should not be a >motivating factor in developing standards. If we all agree on >how it *could* work then let's promote that. > > I think the market will follow a good solution. I used to love >teco until someone showed me vi and that love affair lasted >until someone showed me emacs. > > Dan. I am in complete agreement with Dan. Steve From owner-ipsec@lists.tislabs.com Fri Oct 13 17:35:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10281; Fri, 13 Oct 2000 17:35:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23004 Fri, 13 Oct 2000 19:38:29 -0400 (EDT) Date: Fri, 13 Oct 2000 16:49:36 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: "Shriver, John" cc: "'silvere@iki.fi'" , svan@trustworks.com, ipsec@lists.tislabs.com Subject: RE: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: <392A357CE6FFD111AC3E00A0C99848B00369521E@hdsmsx31.hd.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Oct 2000, Shriver, John wrote: > There are other key exchanges (and domains of interpretation) defined over > ISAKMP. However, they are apparently classified. At least it lets us know > that the spooks trust ISAKMP. (After all, they designed it.) > I've been thinking (not too hard, though) about an snmpv3 DOI, and I know the secure-multicast folks were talking about a separate DOI for multicast keying as well... It's not ALL classified ;) jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Oct 13 17:36:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10299; Fri, 13 Oct 2000 17:36:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23019 Fri, 13 Oct 2000 19:42:26 -0400 (EDT) Date: Fri, 13 Oct 2000 16:54:08 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Henry Spencer cc: IP Security List Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Oct 2000, Henry Spencer wrote: > On Thu, 12 Oct 2000, Sami Vaarala wrote: > > ...That might be. But is someone actually planning to implement two > > key management protocols on top of the *same* isakmp code? From my > > experience there are enough dependencies between ISAKMP and IKE to > > make such isolation difficult and probably unwise, too. > > Realistically, anyone designing a new key-management protocol would have > to be out of his mind to base it on ISAKMP. > I don't consider myself out of my mind, but opinions vary on that. I certainly didn't consider ISAKMP in toto for some stuff I had been working on, but having well-defined payload-formats saves me from having to reinvent the wheel. Afterall, that's not where we've seen problems in IKE. The problems in IKE stem more from differing interpretations of the semantics and use of payloads and exchanges, rather than the message formats in ISAKMP. My original goal for KKMP (now KINK) was to use a stripped down version of quick-mode, using kerberos merely as the 'secure transport' if you so will. Possibly out of his mind, but generally too lazy to reinvent the wheel, jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Oct 13 19:12:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11249; Fri, 13 Oct 2000 19:12:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23254 Fri, 13 Oct 2000 21:06:16 -0400 (EDT) Message-Id: <200010140112.SAA28664@potassium.network-alchemy.com> To: Jan Vilhuber cc: "Shriver, John" , "'silvere@iki.fi'" , svan@trustworks.com, ipsec@lists.tislabs.com Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-reply-to: Your message of "Fri, 13 Oct 2000 16:49:36 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28661.971485930.1@network-alchemy.com> Date: Fri, 13 Oct 2000 18:12:10 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was a RIP DOI and an OSPF DOI but they died very quiet deaths. Secure multicast will require a different key exchange not just a different DOI. The goals were grand-- generic transport on which a generic key exchange is written which has DOIs for specific security services, you can plug in different key exchanges and/or make the key exchange work for multiple services-- but the reality is otherwise. In fact, the complication of having three documents (which are not all in sync) has lead many to scream and run away in horror when the subject of IKE comes up. Remember DOCSIS, Jan? Heck, look at the KKMP/KINK archives for a discussion on the evils of IKE. Wouldn't a key exchange just for IPsec be better? It seems to me that the features that were supposed to attract other people to using IKE have had the exactly opposite effect. Dan. On Fri, 13 Oct 2000 16:49:36 PDT you wrote > On Thu, 12 Oct 2000, Shriver, John wrote: > > > There are other key exchanges (and domains of interpretation) defined over > > ISAKMP. However, they are apparently classified. At least it lets us know > > that the spooks trust ISAKMP. (After all, they designed it.) > > > I've been thinking (not too hard, though) about an snmpv3 DOI, and I know the > secure-multicast folks were talking about a separate DOI for multicast keying > as well... > > It's not ALL classified ;) > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Fri Oct 13 19:13:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11263; Fri, 13 Oct 2000 19:13:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23225 Fri, 13 Oct 2000 20:57:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 13 Oct 2000 18:09:15 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Getting focus for son-of-IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Many of us are quite excited that Dan Harkins is doing the son-of-IKE draft. In our excitement, we have started telling him what we want, and some of it is conflicting information. Now would be a good time to actually decide what we as a group want son-of-IKE to look like, so that Dan doesn't do one thing and we all later ask for something different. On the list, Dan said: > The new draft will combine all three of the key management RFCs into > one. This will give an opportunity to remove lots of the duplication, > confusion, and conflicts that arose because of the 3 separate documents. For this, there is probably little disagreement. > I'm also planning on cutting out quite a bit of the optional things that > are now referred to as "standards bloat". For instance, one of the > public key authentication methods will be removed as will Aggressive > Mode and most of the ISAKMP exchanges defined in RFC2408. And this is what led to people asking for other things to be removed and to be added. It would be useful here for us to say *why* we want things removed. If we have a clearly-stated goal, we can probably figure out which parts to remove to meet the goal and let Dan know soon. So far, some of the things that have been asked for are: - Adding small features that would probably be really useful - Removing features that are not commonly used - Removing features that add only minor security advantages but are confusing - Removing features whose security isn't as good as other features - Changing features that have flaws (not just specification issues) - Replacing some features with better but different ones - Adding large new features to fix some problems discovered in the market None of these are, by themselves, goals. They are methods to achieve the general goals of "better interoperability" and "easier to implement" and "fix known bugs" and "better functionality". Unfortunately, some of the proposals go against some of the goals, and some of the goals conflict. Given the lack of agreement in the discussions on this list over the past year about new functionality and clarifications, it seems unlikely that we are going to be able to universal agreement on exactly what son-of-IKE should do. But, let's try anyway. I propose that there will be wide agreement on the following: - No change should make any part of IKE less secure. - Some features of IKE have been implemented in only a few products, and have not been well tested. - If son-of-IKE changes any of the wire protocol, the major or minor version number would have to be changed. - Although a few advanced customers know exactly which IKE features they want, the vast majority of customers only know the functionality that they want (but not the features that they need for that functionality). - Most of the functionality that is required by the market today is available in current IKE. The two areas of functionality that we most often hear is missing are (a) remote access using legacy authentication and (b) IPsec through NATs. - If son-of-IKE was made a standard tomorrow, there would be systems running plain-old-IKE for at least another decade, and there would be strong market pressure for companies to keep making their new products interoperate with plain-old-IKE. Given those as a base, I propose that the primary goals for son-of-IKE should be "better interoperability" and "easier to implement" and "fix known bugs", but *not* "better functionality". Choosing these three goals (but not the fourth) makes it much easier to choose what parts of IKE should not go into son-of-IKE. Some of the bugs to be fixed would cause a version number change (Tero's hash bug comes to mind), which may be a blessing in disguise for better interoperability. If the first message of an IKE exchange has the son-of-IKE version number, the responder will know immediately to use only the smaller set of son-of-IKE features and that all further messages should use this new version number. Do people agree that this is a good set of primary goals? If we want son-of-IKE to come out soon and meet these goals, we must put off "better functionality" for after son-of-IKE. Yes, yes, we have all have functionality that we want to add, but making additions in son-of-IKE will *not* lead to better interoperability or ease of implementation. Let's strongly consider getting son-of-IKE done easily and quickly, and then consider adding the new functionality after that. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Oct 13 19:20:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11434; Fri, 13 Oct 2000 19:20:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23278 Fri, 13 Oct 2000 21:09:36 -0400 (EDT) Date: Fri, 13 Oct 2000 18:20:45 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Dan Harkins cc: "Shriver, John" , "'silvere@iki.fi'" , svan@trustworks.com, ipsec@lists.tislabs.com Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: <200010140112.SAA28664@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 13 Oct 2000, Dan Harkins wrote: > There was a RIP DOI and an OSPF DOI but they died very quiet deaths. > Secure multicast will require a different key exchange not just a > different DOI. > I believe they managed to reuse phase 1 and define a different phase 2. There's a draft out, I think, but I'm not very involved in this work. > The goals were grand-- generic transport on which a generic key exchange > is written which has DOIs for specific security services, you can plug in > different key exchanges and/or make the key exchange work for multiple > services-- but the reality is otherwise. In fact, the complication of having > three documents (which are not all in sync) has lead many to scream and > run away in horror when the subject of IKE comes up. Yes, including me when I first had to read them ;) But I still think it's worthwhile. > Remember DOCSIS, Jan? Not really. I wasnt involved in DOCSIS (unless you mean packetcable). > Heck, look at the KKMP/KINK archives for a discussion on the evils of IKE. > > Wouldn't a key exchange just for IPsec be better? It seems to me that > the features that were supposed to attract other people to using IKE have > had the exactly opposite effect. > There's middle-ground, I think... jan > Dan. > > On Fri, 13 Oct 2000 16:49:36 PDT you wrote > > On Thu, 12 Oct 2000, Shriver, John wrote: > > > > > There are other key exchanges (and domains of interpretation) defined over > > > ISAKMP. However, they are apparently classified. At least it lets us know > > > that the spooks trust ISAKMP. (After all, they designed it.) > > > > > I've been thinking (not too hard, though) about an snmpv3 DOI, and I know the > > secure-multicast folks were talking about a separate DOI for multicast keying > > as well... > > > > It's not ALL classified ;) > > > > jan > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Oct 13 20:13:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA12325; Fri, 13 Oct 2000 20:13:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23555 Fri, 13 Oct 2000 22:11:28 -0400 (EDT) Message-ID: From: Rajesh Mohan To: "'IP Security List'" Subject: RE: Definition of PFS... Date: Fri, 13 Oct 2000 19:25:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My point was that a DH exchange in phase 2 contributes more random bits to the IPSec key. Hence analysis of encrypted data using the previous key does not help in analyzing the current encrypted data. I realize that NONCE provides random bits to the IPSec key during rekey but DH does provide random bits that does not go over the wire. I do not know much about cryptanalysis but if I have option of exchanging shared secret over encrypted tunnel or DH exchange over encrypted tunnel, I will choose DH exchange. Usually, phase 1 key is not used to encrypt much data but it can be made to by making it sent, say, INVALID SPI. I do not know the advancements in cryptanalysis. So I would prefer adding few safe random bits to IPSec key during phase 2 rekey. Thanks, - Rajesh M ---------- From: Andrew Krywaniuk [SMTP:andrew.krywaniuk@alcatel.com] Sent: Friday, October 13, 2000 3:54 PM Cc: 'IP Security List' Subject: RE: Definition of PFS... Actually, phase 2 rekeying without PFS already fully protects against attacks based on encrypted data (unless you think you can break an HMAC more easily than a DH). If PFS is being used as an optimization to phase 1 rekeying (skipping the authentication phase), then I was going to suggest what Dave said (replacing SKEYID_D from the phase 1 with the new DH value and doing PFS only occasionally). But even so, I still can't think of any threat models (except for the ethical law-enforcement one) that would be mitigated by using PFS as an optimization. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Rajesh Mohan [mailto:RMohan@vpnet.com] > Sent: Friday, October 13, 2000 5:47 PM > To: sommerfeld@East.Sun.COM; 'Michael Richardson'; 'Andrew Krywaniuk' > Cc: 'IP Security List' > Subject: RE: Definition of PFS... > > > The amount of data encrypted using a key is limited by doing phase 2 > rekeying with PFS. This prevents attack based on encrypted > data. So, DH > refresh without re-authentication prevents ciphertext only attack. > > Ofcourse, doing phase 1 rekeying with every phase 2 rekeying, > is more safe > but does have a overhead. > > Rajesh M > > ---------- > From: Andrew Krywaniuk [SMTP:andrew.krywaniuk@alcatel.com] > Sent: Friday, October 13, 2000 11:51 AM > To: sommerfeld@East.Sun.COM; 'Michael Richardson' > Cc: 'IP Security List' > Subject: RE: Definition of PFS... > > That's what I thought. To me, it makes more sense to limit key > exposure via. > phase 1 rekeying rather than by PFS. It's slightly > slower (if your > CertSign/CertVerify operations are comparable in CPU > time to your DH > calculation), but the security tradeoffs make more sense. > > I suppose that QM PFS does have a value (as an > optimization of phase > 1 > rekeying) solely for the purpose of combatting search warrants. > Assuming > that: > > 1. key escrow is not required > 2. law enforcement officers can bypass your box's tamper-proof > mechanisms > 3. but they are ethically prevented from cryptographically > impersonating you > > then you would indeed be able to limit your key > exposure using PFS. > > But for the purpose of preventing against active or > passive attacks > by > persons other than law enforcement, DH refresh without > re-authentication > doesn't do that much for you. > > What concerns me is that, as with many things in IKE, > the intent of > this > feature is not documented, particularly the security > model in which > DH > refresh without re-authentication is "warranted" :-) > > Consequently, most implementers I have talked to don't > understand > what the > supposed purpose of PFS is (most of them will cite the > log(n) added > security > argument, which really isn't significant). > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > Bill Sommerfeld > > Sent: Thursday, October 12, 2000 10:47 AM > > To: Michael Richardson > > Cc: 'IP Security List' > > Subject: Re: Definition of PFS... > > > > > > > It also defends against the situation where a third party > > compels one > > > party to provide some set of keys. PFS guarantees that a > > simple search warant > > > only catches traffic *currently* in transit, not all > > previous and future > > > traffic. > > > > Not quite that simple; it's a matter of what the > lifetimes of the > IKE > > and AH/ESP SA's really are.. > > > > If your AH/ESP SA lifetimes are 12 hours, this gives > someone 12 > hours > > of traffic even if quick mode with PFS was used to > create them. > > > > Similarly, if you don't use PFS in quick mode, but > limit your IKE > SA's > > (and the AH/ESP SA's derived from them via quick mode) to a > lifetime > > of 1 hour, you get 1 hour of traffic. > > > > - Bill > > > From owner-ipsec@lists.tislabs.com Sat Oct 14 09:13:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04233; Sat, 14 Oct 2000 09:13:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25156 Sat, 14 Oct 2000 10:36:23 -0400 (EDT) From: Mike_Borella@3com.com X-Lotus-FromDomain: 3COM To: "Paul Hoffman / VPNC" cc: ipsec@lists.tislabs.com Message-ID: <88256978.00516A4A.00@hqoutbound.ops.3com.com> Date: Sat, 14 Oct 2000 09:47:06 -0500 Subject: Re: Getting focus for son-of-IKE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I generally agree with the direction you've outlined. I would like to suggest however, that the new "how" document be accompanied by an informational track "why" document that explains what son-of-IKE gives you in terms of protection, why certain design decisions / tradeoffs were made, and other background. It would be nice to have an IKE-for-dummies introduction that doesn't have a steep learning curve. -Mike "Paul Hoffman / VPNC" on 10/13/2000 08:09:15 PM Sent by: "Paul Hoffman / VPNC" To: ipsec@lists.tislabs.com cc: (Mike Borella/MW/US/3Com) Subject: Getting focus for son-of-IKE Many of us are quite excited that Dan Harkins is doing the son-of-IKE draft. In our excitement, we have started telling him what we want, and some of it is conflicting information. Now would be a good time to actually decide what we as a group want son-of-IKE to look like, so that Dan doesn't do one thing and we all later ask for something different. On the list, Dan said: > The new draft will combine all three of the key management RFCs into > one. This will give an opportunity to remove lots of the duplication, > confusion, and conflicts that arose because of the 3 separate documents. For this, there is probably little disagreement. > I'm also planning on cutting out quite a bit of the optional things that > are now referred to as "standards bloat". For instance, one of the > public key authentication methods will be removed as will Aggressive > Mode and most of the ISAKMP exchanges defined in RFC2408. And this is what led to people asking for other things to be removed and to be added. It would be useful here for us to say *why* we want things removed. If we have a clearly-stated goal, we can probably figure out which parts to remove to meet the goal and let Dan know soon. So far, some of the things that have been asked for are: - Adding small features that would probably be really useful - Removing features that are not commonly used - Removing features that add only minor security advantages but are confusing - Removing features whose security isn't as good as other features - Changing features that have flaws (not just specification issues) - Replacing some features with better but different ones - Adding large new features to fix some problems discovered in the market None of these are, by themselves, goals. They are methods to achieve the general goals of "better interoperability" and "easier to implement" and "fix known bugs" and "better functionality". Unfortunately, some of the proposals go against some of the goals, and some of the goals conflict. Given the lack of agreement in the discussions on this list over the past year about new functionality and clarifications, it seems unlikely that we are going to be able to universal agreement on exactly what son-of-IKE should do. But, let's try anyway. I propose that there will be wide agreement on the following: - No change should make any part of IKE less secure. - Some features of IKE have been implemented in only a few products, and have not been well tested. - If son-of-IKE changes any of the wire protocol, the major or minor version number would have to be changed. - Although a few advanced customers know exactly which IKE features they want, the vast majority of customers only know the functionality that they want (but not the features that they need for that functionality). - Most of the functionality that is required by the market today is available in current IKE. The two areas of functionality that we most often hear is missing are (a) remote access using legacy authentication and (b) IPsec through NATs. - If son-of-IKE was made a standard tomorrow, there would be systems running plain-old-IKE for at least another decade, and there would be strong market pressure for companies to keep making their new products interoperate with plain-old-IKE. Given those as a base, I propose that the primary goals for son-of-IKE should be "better interoperability" and "easier to implement" and "fix known bugs", but *not* "better functionality". Choosing these three goals (but not the fourth) makes it much easier to choose what parts of IKE should not go into son-of-IKE. Some of the bugs to be fixed would cause a version number change (Tero's hash bug comes to mind), which may be a blessing in disguise for better interoperability. If the first message of an IKE exchange has the son-of-IKE version number, the responder will know immediately to use only the smaller set of son-of-IKE features and that all further messages should use this new version number. Do people agree that this is a good set of primary goals? If we want son-of-IKE to come out soon and meet these goals, we must put off "better functionality" for after son-of-IKE. Yes, yes, we have all have functionality that we want to add, but making additions in son-of-IKE will *not* lead to better interoperability or ease of implementation. Let's strongly consider getting son-of-IKE done easily and quickly, and then consider adding the new functionality after that. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 16 04:07:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA29608; Mon, 16 Oct 2000 04:07:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA01102 Mon, 16 Oct 2000 05:32:50 -0400 (EDT) Message-ID: <39EACDC2.8AF9DBDD@cisco.com> Date: Mon, 16 Oct 2000 11:43:30 +0200 From: Frederic Detienne Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes References: <200010131635.JAA26753@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: > > At 9:35 AM -0700 10/13/00, Dan Harkins wrote: > > The lack of people implementing good products should not be a > >motivating factor in developing standards. If we all agree on > >how it *could* work then let's promote that. > > Of course. We should continue to promote certs and explain the > security problems of preshared secrets. No one has said otherwise. > The question is should we continue to allow the *use* of preshared > secrets. only through backward compatibility of old-IKE (i.e. when an old-IKE initiates). > > I think the market will follow a good solution. > > So far, that has not been shown true in the IPsec market. The > proposal to remove preshared secrets from son-of-IKE was made as a > way to *force* people towards the better solution. Given that IKE > will exist forever, it is unclear to me that removing preshared > secrets from son-of-IKE will do anything to convince the users of > preshared secrets to switch. If they use pre-shared keys, it is because they do not understand how IKE/IPSec works. I agree with you: people will see no reason to move to son-of-IKE ; they will actually see it as a bad move because they do not have pre-shared anymore. But this is because son-of-IKE would bring nothing else than the hassle of switching. I believe that son-of-IKE should get rid of pre-shared keys and aggressive mode (both for security reasons) but should also provide new market required features (at least, the most important ones) => users will switch on to son-of-IKE. Just cleaning the protocol is not enough to make people consider it. Who cares about a car consuming less if gas is cheap ? Make it more comfortable and safer will push people to upgrade. Promoting son-of-IKE as more secure is a good start, adding necessary features will make the protocol more comfortable to deploy and users will move (e.g: remote-SPI-inexistant determination). frederic > --Paul Hoffman, Director > --VPN Consortium -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Mon Oct 16 04:08:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA29624; Mon, 16 Oct 2000 04:08:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA01153 Mon, 16 Oct 2000 06:09:06 -0400 (EDT) Message-ID: <39EAD6E2.6AB286E3@F-Secure.com> Date: Mon, 16 Oct 2000 13:22:26 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Definition of PFS... References: <447A3F40A07FD211BA2700A0C99D759B789223@md-exchange1.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Would it make any sense to do a low-security DH in phase I, followed by a higher-security DH in phase II, after the peer has been authenticated, to provide protection against some DoS attacks while also giving good long-term traffic protection? Similarly, would it make sense to use elliptic curves in phase I, followed by MODP in phase II? Also, what's the point in doing the one-QM-per-one-IKE-SA thing to provide identity PFS? Knowing the identity used for the current IKE SA does not give you the identity used for setting up any previous or next IKE SAs? Anybody actually expect this identity to change? Ari "Mason, David" wrote: > > Are you saying that a 768-bit MODP DH would be useful (and make sense > security wise cryptographically) in QM even though the IPsec cipher > negotiated has a large key? Would using a 1536-bit (or larger) DH generally > be a waste of computational resources for the QM DH (in what cases > would/would not a 768-bit DH suffice)? The way IPsec keys are currently > generated in IKE I would think that you would want to either always do a QM > DH or never do a QM DH (periodically doing them only helps that specific > exchange - should son-of-ike consider folding the QM g^xy back into SKEYID_d > somehow so that periodic QM DH has value beyond the specific exchange - > although simultaneous QMs would make this problematic?). > > -dave > > -----Original Message----- > From: Hilarie Orman [mailto:HORMAN@novell.com] > Sent: Friday, October 13, 2000 2:04 PM > To: andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com > Subject: Re: Definition of PFS... > > The point of ephemeral Diffie-Hellman in QM is to get independent keying > material (PFS) without repetition of authentication. The assumption is that > this will be done periodically and should be as inexpensive as possible. > > Hilarie -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Oct 16 07:19:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07601; Mon, 16 Oct 2000 07:19:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01697 Mon, 16 Oct 2000 09:16:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 16 Oct 2000 09:26:32 -0400 To: "Scott Fanning" From: Stephen Kent Subject: RE: charter question re IKE changes Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, >It is always the customers choice to develop their security model based on >their threat model. To impose a solution, sometimes makes a customer more >nervous. If only this were true I'd be more comfortable. I almost never find a customer who has a written description of a threat model, and most can't even correctly define "threat." Steve From owner-ipsec@lists.tislabs.com Mon Oct 16 10:37:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19184; Mon, 16 Oct 2000 10:37:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05931 Mon, 16 Oct 2000 12:11:39 -0400 (EDT) Message-Id: <4.3.1.0.20001013215505.00b3a180@brisco.passedge.com> X-Sender: mbaugher@brisco.passedge.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 16 Oct 2000 09:09:42 -0700 To: ipsec@lists.tislabs.com From: Mark Baugher Subject: Re: Simplifying IKE (was RE: Reliable delete notifies) In-Reply-To: <200010140112.SAA28664@potassium.network-alchemy.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Secure multicast will require a different key exchange not just a >different DOI. Page 15 of RFC 2408 reads: " services. A DOI defines: o A "situation": the set of information that will be used to determine the required security services. o The set of security policies that must, and may, be supported. o A syntax for the specification of proposed security services. o A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, security policy attributes, and certificate authorities. o The specific formats of the various payload contents. o Additional exchange types, if required. " Thus, a DOI defines new exchanges. So what does it mean that multicast will require a new key exchange (not just a new DOI) when one of the Internet Standards-track specs says it can be extended with new exchanges? It is a problem that both RFC 2408 and RFC 2409 claim to support DOIs. Does one use RFC 2408 to define a new DOI or RFC 2409? Mark From owner-ipsec@lists.tislabs.com Mon Oct 16 10:45:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19432; Mon, 16 Oct 2000 10:45:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06015 Mon, 16 Oct 2000 12:19:29 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 16 Oct 2000 10:30:22 -0600 From: "Hilarie Orman" To: , Subject: Re: Definition of PFS... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA06012 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why would you do MODP if you've got EC? Are you equating "slow" with "secure"? Hilarie >>> Ari Huttunen 10/16/00 04:22AM >>> Would it make any sense to do a low-security DH in phase I, followed by a higher-security DH in phase II, after the peer has been authenticated, to provide protection against some DoS attacks while also giving good long-term traffic protection? Similarly, would it make sense to use elliptic curves in phase I, followed by MODP in phase II? From owner-ipsec@lists.tislabs.com Mon Oct 16 12:26:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22996; Mon, 16 Oct 2000 12:26:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06457 Mon, 16 Oct 2000 14:05:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 16 Oct 2000 14:10:35 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: Getting focus for son-of-IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I generally like your analysis for IKE, but I would also like to suggest that there may be a few "added functions" that should be on the list. For example, we stripped out several negotiation features for phase II which had been supported in the SPD, e.g., port ranges or lists vs. individual port numbers. I'd like to see these added back. Steve From owner-ipsec@lists.tislabs.com Mon Oct 16 13:07:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24319; Mon, 16 Oct 2000 13:07:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06760 Mon, 16 Oct 2000 15:02:52 -0400 (EDT) Date: Mon, 16 Oct 2000 12:14:03 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: Scott Fanning , ipsec@lists.tislabs.com Subject: RE: charter question re IKE changes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Scott. I think that there should be multiple security models to address the different requirements. A common scenario these days in the silicon valley: a corporation got acquired by another, and the network administrators are tasked with connecting the two intranets ASAP. Pre-shared keys can be used to setup a tunnel quickly (or the public keys can be manually exchanged). If this tunnel over the Internet was only a temporary setup, until a leased line was available, or if there were only a couple of sites to be connected, I guess seting up a PKI would not be worth while. I don't think mandating PKI always, is good. People will come up with proprietary solutions that don't need PKI, to address customer needs. I use both emacs and vi based on what I am doing and the system capabilities, and sometimes notepad is the only option available, to get the job done. chinna On Mon, 16 Oct 2000, Stephen Kent wrote: > Scott, > > >It is always the customers choice to develop their security model based on > >their threat model. To impose a solution, sometimes makes a customer more > >nervous. > > If only this were true I'd be more comfortable. I almost never find > a customer who has a written description of a threat model, and most > can't even correctly define "threat." > > Steve > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Mon Oct 16 17:44:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01197; Mon, 16 Oct 2000 17:44:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07613 Mon, 16 Oct 2000 19:08:42 -0400 (EDT) From: Scott Kelly To: Stephen Kent Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Message-ID: <39EB8DA6.620CD9C5@redcreek.com> Date: Mon, 16 Oct 2000 16:22:14 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Getting focus for son-of-IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Paul, > > I generally like your analysis for IKE, but I would also like to > suggest that there may be a few "added functions" that should be on > the list. For example, we stripped out several negotiation features > for phase II which had been supported in the SPD, e.g., port ranges > or lists vs. individual port numbers. I'd like to see these added > back. > > Steve I agree with Steve. In general, I would like to see a more comprehensive selector specification mechanism in IKE. Scott From owner-ipsec@lists.tislabs.com Mon Oct 16 18:54:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03086; Mon, 16 Oct 2000 18:54:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07880 Mon, 16 Oct 2000 20:56:49 -0400 (EDT) Message-Id: <200010170108.VAA14643@solidum.com> To: ipsec@lists.tislabs.com, "Chinna N.R. Pellacuru" Subject: Re: charter question re IKE changes In-Reply-To: Your message of "Mon, 16 Oct 2000 12:14:03 PDT." Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Mon, 16 Oct 2000 21:08:33 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> A common scenario these days in the silicon valley: a corporation got Chinna> acquired by another, and the network administrators are tasked with Chinna> connecting the two intranets ASAP. Pre-shared keys can be used to setup a Chinna> tunnel quickly (or the public keys can be manually exchanged). If This is only true if you are comparing against some poorly designed CA product. Go try someone else's product before you base your decisions on poor design decisions in your own product. Exchanging self-signed certificates can be done with *less* hassle than pre-shared keys. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Mon Oct 16 19:25:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04295; Mon, 16 Oct 2000 19:25:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07934 Mon, 16 Oct 2000 21:20:44 -0400 (EDT) Date: Mon, 16 Oct 2000 21:31:55 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: charter question re IKE changes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 16 Oct 2000, Chinna N.R. Pellacuru wrote: > I don't think mandating PKI always, is good. People will come up with > proprietary solutions that don't need PKI, to address customer needs. As has been mentioned several times already: the alternative to shared secrets is not necessarily a PKI. You don't need a PKI to use public-key authentication. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Oct 16 23:02:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09273; Mon, 16 Oct 2000 23:02:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08518 Tue, 17 Oct 2000 00:38:40 -0400 (EDT) Date: Mon, 16 Oct 2000 21:49:22 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes In-Reply-To: <200010170108.VAA14643@solidum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Traffic can be sent in the clear "with *less* hassle" then trying to secure it. chinna On Mon, 16 Oct 2000, Michael Richardson wrote: > > >>>>> "Chinna" == Chinna N R Pellacuru writes: > Chinna> A common scenario these days in the silicon valley: a corporation got > Chinna> acquired by another, and the network administrators are tasked with > Chinna> connecting the two intranets ASAP. Pre-shared keys can be used to setup a > Chinna> tunnel quickly (or the public keys can be manually exchanged). If > > This is only true if you are comparing against some poorly designed CA > product. Go try someone else's product before you base your decisions on poor > design decisions in your own product. > > Exchanging self-signed certificates can be done with *less* hassle than > pre-shared keys. > > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com > Michael Richardson |For a better connected world,where data flows faster > Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Oct 17 05:18:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20637; Tue, 17 Oct 2000 05:18:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09454 Tue, 17 Oct 2000 06:34:29 -0400 (EDT) Message-Id: <200010171046.GAA06987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt Date: Tue, 17 Oct 2000 06:46:13 -0400 Sender: owner-ipsec@lists.tislabs.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 : More MODP Diffie-Hellman groups for IKE Author(s) : T. Kivinen, M. Kojo Filename : draft-ietf-ipsec-ike-modp-groups-00.txt Pages : 5 Date : 16-Oct-00 This document defines new MODP groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, and 4096 bit Diffie-Hellman groups. The groups are gen- erated using the guidelines defined in the [RFC-2412]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-00.txt Internet-Drafts are also 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-ike-modp-groups-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-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: <20001016145508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-modp-groups-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001016145508.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Oct 17 18:38:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16661; Tue, 17 Oct 2000 18:38:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12720 Tue, 17 Oct 2000 20:27:35 -0400 (EDT) Date: Tue, 17 Oct 2000 17:38:13 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: "Angelos D. Keromytis" cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes In-Reply-To: <200010180027.e9I0Rrv25750@nyarlathotep.cis.upenn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My point is that, a security model based on self-signed certificates is completely different than a model based on CA. You can't compare them as if they provide the same benefits, and as if they meet the same requirements. chinna On Tue, 17 Oct 2000, Angelos D. Keromytis wrote: > > In message , "Chinn > a N.R. Pellacuru" writes: > >Traffic can be sent in the clear "with *less* hassle" then trying to > >secure it. > > It's even easier not to send any traffic. The point is, we want (for > whatever reason) to send traffic securely. A certificate-based > configuration is in fact easier (at least on the free IPsec > implementations -- OpenBSD, Linux, KAME) than pre-shared keys. > > The commercial vendors should get their act together. > -Angelos > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Oct 17 18:38:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16660; Tue, 17 Oct 2000 18:38:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12704 Tue, 17 Oct 2000 20:20:18 -0400 (EDT) Message-Id: <200010180027.e9I0Rrv25750@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: "Chinna N.R. Pellacuru" Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes In-reply-to: Your message of "Mon, 16 Oct 2000 21:49:22 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Oct 2000 20:27:53 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Chinn a N.R. Pellacuru" writes: >Traffic can be sent in the clear "with *less* hassle" then trying to >secure it. It's even easier not to send any traffic. The point is, we want (for whatever reason) to send traffic securely. A certificate-based configuration is in fact easier (at least on the free IPsec implementations -- OpenBSD, Linux, KAME) than pre-shared keys. The commercial vendors should get their act together. -Angelos From owner-ipsec@lists.tislabs.com Wed Oct 18 08:25:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14885; Wed, 18 Oct 2000 08:25:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15231 Wed, 18 Oct 2000 09:41:13 -0400 (EDT) Date: Wed, 18 Oct 2000 09:52:23 -0400 (EDT) From: Henry Spencer To: "Chinna N.R. Pellacuru" cc: "Angelos D. Keromytis" , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 17 Oct 2000, Chinna N.R. Pellacuru wrote: > My point is that, a security model based on self-signed certificates is > completely different than a model based on CA. You can't compare them as > if they provide the same benefits, and as if they meet the same > requirements. True, but irrelevant. The comparison here is between a model using shared secrets and a model using self-signed certificates, since the topic on the table is the elimination of the former in favor of the latter. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Oct 18 10:59:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21998; Wed, 18 Oct 2000 10:59:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15989 Wed, 18 Oct 2000 12:53:47 -0400 (EDT) Date: Wed, 18 Oct 2000 10:04:03 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Henry Spencer cc: "Angelos D. Keromytis" , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was responding to the "poorly designed CA product" comment that was made earlier. How does a "poorly designed CA product" fit into the comparision of self-signed certificates and pre-shared keys! chinna On Wed, 18 Oct 2000, Henry Spencer wrote: > On Tue, 17 Oct 2000, Chinna N.R. Pellacuru wrote: > > My point is that, a security model based on self-signed certificates is > > completely different than a model based on CA. You can't compare them as > > if they provide the same benefits, and as if they meet the same > > requirements. > > True, but irrelevant. The comparison here is between a model using shared > secrets and a model using self-signed certificates, since the topic on the > table is the elimination of the former in favor of the latter. > > Henry Spencer > henry@spsystems.net > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Oct 18 11:11:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22736; Wed, 18 Oct 2000 11:11:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16048 Wed, 18 Oct 2000 13:07:09 -0400 (EDT) Message-Id: <200010181718.NAA22222@solidum.com> To: "Chinna N.R. Pellacuru" CC: ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes In-Reply-To: Your message of "Wed, 18 Oct 2000 10:04:03 PDT." Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Oct 2000 13:18:51 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> I was responding to the "poorly designed CA product" comment that Chinna> was made earlier. How does a "poorly designed CA product" fit Chinna> into the comparision of self-signed certificates and pre-shared Chinna> keys! If son-of-IKE mandates support for self-signed certificates, then one does not need to depend on the quality of the CA products to use public key authentication. The origin of the desire to keep pre-shared keys is due to "poorly designed CA products" --- really more to do with business models of certain public key libraries. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Oct 18 12:04:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24561; Wed, 18 Oct 2000 12:04:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16148 Wed, 18 Oct 2000 13:55:07 -0400 (EDT) Message-Id: <200010181805.e9II5Tl155094@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: "Chinna N.R. Pellacuru" , "Angelos D. Keromytis" , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes In-reply-to: Your message of "Wed, 18 Oct 2000 09:52:23 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Wed, 18 Oct 2000 14:05:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > True, but irrelevant. The comparison here is between a model using shared > secrets and a model using self-signed certificates, since the topic on the > table is the elimination of the former in favor of the latter. The one missing piece would be a well-defined format for exchange/distribution of self-signed certificates (rather than 10 different incompatible ones)... This should not be hard, but it needs to be written down in the spec.. - Bill From owner-ipsec@lists.tislabs.com Thu Oct 19 04:52:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA21870; Thu, 19 Oct 2000 04:52:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18754 Thu, 19 Oct 2000 06:21:24 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A98AC@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: charter question re IKE changes Date: Thu, 19 Oct 2000 13:33:04 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I know it's asking a lot, but if a new RFC has to be written, could it be a bit more self-contained than the last one? Sometimes ones turns crazy looking for things. Toni -----Original Message----- From: EXT Bill Sommerfeld [mailto:sommerfeld@East.Sun.COM] Sent: 18. October 2000 21:05 To: Henry Spencer Cc: Chinna N.R. Pellacuru; Angelos D. Keromytis; Michael Richardson; ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes > True, but irrelevant. The comparison here is between a model using shared > secrets and a model using self-signed certificates, since the topic on the > table is the elimination of the former in favor of the latter. The one missing piece would be a well-defined format for exchange/distribution of self-signed certificates (rather than 10 different incompatible ones)... This should not be hard, but it needs to be written down in the spec.. - Bill From owner-ipsec@lists.tislabs.com Thu Oct 19 05:20:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22517; Thu, 19 Oct 2000 05:20:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18898 Thu, 19 Oct 2000 07:19:51 -0400 (EDT) Message-ID: <39EEDB92.77497E67@lmf.ericsson.se> Date: Thu, 19 Oct 2000 14:31:30 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: bernarda@microsoft.com, mstenber@ssh.com, ari.huttunen@F-Secure.com CC: jarkko@piuha.net, ipsec@lists.tislabs.com Subject: NAT and IPsec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. I've been studying the IPsec through a NAT issue, and in particular the drafts http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt http://search.ietf.org/internet-drafts/draft-huttunen-ipsec-esp-in-udp-00.txt http://search.ietf.org/internet-drafts/draft-stenberg-ipsec-nat-traversal-00.txt I have some questions and some issues I'd like to discuss. Here they are: * In terms of requirements, I think we'd be on the wrong path if we put much effort in getting all IPsec and IKE modes to work. I'd rather have a simple scheme that allows only ESP and only TUNNEL mode and only ... than a complex scheme. Also - and this may be just my own experience - I consider most NAT devices as _hostile_ and therefore approaches like RSIP aren't very fruitful (hostile as in made too early before RSIP was available or as in owned by an operator who wants $ for true IP access). Also, I'm not sure about the scalability of RSIP to an operator or large corporation NAT. * Bernard's draft says in section 7.1 the following: "By adding a NAT compatibility mode to IKE/IPSEC, the total time to negotiate an IPSEC SA may be increased significantly. For example, when an IKE initiator fails to receive a response, it will typically need to try again using UDP encapsulation, since the lack of response may have been due to the presence of intervening NATs." But is this really the case? I could see an implementation that tries BOTH standard IKE and NAT-IKE at the same time, and uses the one that succeeds. And if both happen to succeed as they would in a no-NAT case, a DELETE could be performed on the more expensive one afterwards. (A scheme that might also be useful for other purposes, such as IKE vs. KINK selection.) * Related to the above, would IKE be run directly in the UDP encapsulation method, or would it too be encapsulated in UDP? If latter, that would offer a very simple way for the responder to detect the capability (= existence of encapsulation) and need (= outer ip not equal to inner ip). * I worry about the denial of service issues for plain UDP encapsulation. For instance, if I'd implement an UDP tunnel scheme independently from IPsec, and used the last incoming packet's src and src-port to determine where the next outgoing packet to the inner src address should go, then anybody could send a fake packet that is later dropped by IPsec, but already modified the return address mapping. Therefore, it seems that a procedure similar to IPsec sequence number updates must be applied here, or alternatively the return addresses must be fixed at the time of IKE negotiations. * I saw in the minutes of the last NAT WG meeting that somebody proposed the use of L2TP to tunnel IPsec. While confidentiality and other properties would be satisfied in this approach, I think a DoS would be possible here as well: snoop the tunnel IDs and sequence numbers, then close the tunnel using a fake IP address. * To what extent do we believe that the use of IPsec through NAT must be negotiated, and to what extent it could just be _configured_? Normally, users would know that they are behind a NAT. Can we simplify based on such an assumption? Or perhaps we want to apply e.g. centrally made corporate policies and not even let users configure things like this? * Would it be simpler to just use a client-initiated ping as needed rather than a special-case heartbeat packets as in two of the drafts? * I'm not sure I understand the need for the ESPUDP attribute value in Ari's draft. If the connection has been determined to be through a NAT, and the VIDs have been exchanged - what's left? Or, why not use just the ESPUDP value and not VIDs? * The Stenberg draft has an overhead of 25 bytes (section 4.2). This is close to the 28 bytes of an UDP encapsulation. Can you comment on whether a a new header format is desireable, given the small difference in the outcome? Or perhaps the use of this specific header format gives some added benefits that can not be realized with just using UDP + IP headers? * Why does the Stenberg draft include an unused field in the packet encapsulation? And isn't the version fields in IKE negotiation sufficient, do we need a version field in the traversal tunnel header as well? Isn't TOS field thrown away in any case after IPsec has been processed? * As a part of the IKE negotiations, the peer exchange perceived and local identities (section 3.1.2 of the Stenberg draft). Actual IPsec packets then contain an envelope that contains, among other things, the local address. But why? If I receive a packet from the perceived address, can't I just replace the local addresses without having to restate them in every packet? Jari ---- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com Private WWW: http://www.iki.fi/jar. Standard disclaimers apply. From owner-ipsec@lists.tislabs.com Thu Oct 19 06:42:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24150; Thu, 19 Oct 2000 06:42:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19188 Thu, 19 Oct 2000 08:41:15 -0400 (EDT) Message-Id: <200010190055.GAA03839@venus.roc.com> X-Sender: vamsi@brahma.roc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Oct 2000 18:20:18 +0530 To: ipsec@lists.tislabs.com From: vamsi Subject: XAuth Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can any one give the information regarding about 'Extended Authentication Within ISAKMP/Oakley'? The draft for that Extended Authentication is expired and can any one guide where I can get the proper information regarding this XAUTH. bye From owner-ipsec@lists.tislabs.com Thu Oct 19 07:11:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25081; Thu, 19 Oct 2000 07:11:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19350 Thu, 19 Oct 2000 08:58:47 -0400 (EDT) Message-ID: <006e01c039cd$404c1220$4cf62ca1@cisco.com> From: "Stephane Beaulieu" To: , Subject: IPsec and Remote Access related drafts Date: Thu, 19 Oct 2000 09:05:26 -0400 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry for the cross postings. This may be of interest to people on both mailing lists. The Mode-Cfg draft and XAUTH draft have been resubmitted as personal submissions. New mailing lists have been set up, so that those interested can post constructive comments. You can subscribe to the lists by sending an email to: ietf-mode-cfg-request@vpnc.org (for mode-cfg) and ietf-xauth-request@vpnc.org (for XAUTH) and having the work "subscribe" in the body. The lists will not be accepting posts for the next couple of days to give a chance to people to sign up. The drafts can be found at: http://www.ietf.org/internet-drafts/draft-dukes-ike-mode-cfg-00.txt http://www.ietf.org/internet-drafts/draft-beaulieu-ike-xauth-00.txt Thanks, Stephane. ------ Stephane Beaulieu S/W Engineer VSEC Business Unit, Enterprise Line of Business Cisco Systems. email: stephane@cisco.com phone: (613) 271-3678 From owner-ipsec@lists.tislabs.com Thu Oct 19 07:20:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25321; Thu, 19 Oct 2000 07:20:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19367 Thu, 19 Oct 2000 08:59:49 -0400 (EDT) Message-Id: <3.0.5.32.20001019141730.0349bd30@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 19 Oct 2000 14:17:30 +0200 To: Jari Arkko From: Joern Sierwald Subject: Re: NAT and IPsec Cc: bernarda@microsoft.com, mstenber@ssh.com, ari.huttunen@F-Secure.com, jarkko@piuha.net, ipsec@lists.tislabs.com In-Reply-To: <39EEDB92.77497E67@lmf.ericsson.se> 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 lists.tislabs.com id IAA19010 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:31 19.10.2000 +0300, Jari Arkko wrote: > >Hi. I've been studying the IPsec through a NAT issue, and >in particular the drafts > > http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt > http://search.ietf.org/internet-drafts/draft-huttunen-ipsec-esp-in-udp-00.txt >http://search.ietf.org/internet-drafts/draft-stenberg-ipsec-nat-traversal -00.txt > >I have some questions and some issues I'd like to discuss. >Here they are: > >* In terms of requirements, I think we'd be on the wrong path > if we put much effort in getting all IPsec and IKE modes > to work. I'd rather have a simple scheme that allows only > ESP and only TUNNEL mode and only ... than a complex scheme. It should be noted that our (huttunen) scheme is a simple as it possibly can be. There are a lot of thoughts in the draft, but you have to make it work for yourself. It mentions transport mode, yes. But we don't even have that ourselves. You want to configure it, not negotiate it? Well, you have to configure it in order to negotiate it, right. The only change in negotiation is the 61440 number. You don't _have_ to use the VID... It says "SHOULD" in the draft. You can use a configuation switch instead. >* Would it be simpler to just use a client-initiated > ping as needed rather than a special-case heartbeat > packets as in two of the drafts? There are two UDP ports here... IKE and ESPoverUDP. With the ping you only keep ESPoverUDP alive. >* I worry about the denial of service issues for plain > UDP encapsulation. For instance, if I'd implement > an UDP tunnel scheme independently from IPsec, and > used the last incoming packet's src and src-port to > determine where the next outgoing packet to the > inner src address should go, then anybody could > send a fake packet that is later dropped by IPsec, > but already modified the return address mapping. > Therefore, it seems that a procedure similar to > IPsec sequence number updates must be applied here, or > alternatively the return addresses must be fixed > at the time of IKE negotiations. > I understand the problem, but you found the solution. Change your mapping only after the packet has passed ESP... J–rn From owner-ipsec@lists.tislabs.com Thu Oct 19 08:21:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29134; Thu, 19 Oct 2000 08:21:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19889 Thu, 19 Oct 2000 10:04:00 -0400 (EDT) Message-ID: <39EF01F0.1029F7A9@indusriver.com> Date: Thu, 19 Oct 2000 10:15:13 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: IPsec and Remote Access related drafts References: <006e01c039cd$404c1220$4cf62ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can we also include Hybrid-Auth as part of the agenda for the XAUTH mailing list? IMHO, Hybrid plus XAUTH is much better for legacy authentication than XAUTH by itself. Perhaps the hybrid auth authors (M. Litvin, R. Shamir, T. Zegman of Check Point) can also resubmit the Hybrid Auth draft as a personal submission. I assume it expires soon if it hasn't already. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu Oct 19 12:16:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08899; Thu, 19 Oct 2000 12:16:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20589 Thu, 19 Oct 2000 13:56:39 -0400 (EDT) Message-ID: <39EF38F7.214F49DB@F-Secure.com> Date: Thu, 19 Oct 2000 21:09:59 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hilarie Orman CC: ipsec@lists.tislabs.com Subject: Re: Definition of PFS... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, I'm equating anything "new" with "potentially unsecure". Ari Hilarie Orman wrote: > > Why would you do MODP if you've got EC? Are you equating "slow" with > "secure"? > > Hilarie > > >>> Ari Huttunen 10/16/00 04:22AM >>> > Would it make any sense to do a low-security DH in phase I, followed > by a higher-security DH in phase II, after the peer has been authenticated, > to provide protection against some DoS attacks while also giving good > long-term traffic protection? > > Similarly, would it make sense to use elliptic curves in phase I, > followed by MODP in phase II? -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Oct 19 12:23:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09114; Thu, 19 Oct 2000 12:23:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20652 Thu, 19 Oct 2000 14:15:36 -0400 (EDT) Message-ID: <979695BB8922D411A54000D0B74C60B5A9B7A8@sottmxsdev.entrust.com> From: Joe MacLellan To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt Date: Thu, 19 Oct 2000 14:26:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C039FA.2704FF20" Sender: owner-ipsec@lists.tislabs.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_01C039FA.2704FF20 Content-Type: text/plain; charset="iso-8859-1" I know this was commented on before, but does anyone have any idea what group "XX" will likely be for these new modp groups? (ie 2048 is Group XX, 3072 is Group XX+1, 4096 is XX+2). Is this something that Dan will be rolling into the son-of-ike draft as well? :Later Joe MacLellan Entrust Technologies Ltd "We Bring Trust to e-Business"(tm) Entrust Toolkit/Core Components Development Email: joe.maclellan@entrust.com http://www.entrust.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 17, 2000 6:46 AM Cc: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt 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 : More MODP Diffie-Hellman groups for IKE Author(s) : T. Kivinen, M. Kojo Filename : draft-ietf-ipsec-ike-modp-groups-00.txt Pages : 5 Date : 16-Oct-00 This document defines new MODP groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, and 4096 bit Diffie-Hellman groups. The groups are gen- erated using the guidelines defined in the [RFC-2412]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-00.txt Internet-Drafts are also 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-ike-modp-groups-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-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_001_01C039FA.2704FF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt

I know this was commented on before, but does anyone = have any idea what group "XX" will likely be for these new = modp groups? (ie 2048 is Group XX, 3072 is Group XX+1, 4096 is = XX+2).

Is this something that Dan will be rolling into the = son-of-ike draft as well?

:Later
Joe MacLellan
Entrust Technologies Ltd
"We Bring Trust to e-Business"(tm)
Entrust Toolkit/Core Components Development
Email: joe.maclellan@entrust.com
http://www.entrust.com


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Tuesday, October 17, 2000 6:46 AM
Cc: ipsec@lists.tislabs.com
Subject: I-D = ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt


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           : = More MODP Diffie-Hellman groups for IKE
        Author(s)       : T. Kivinen, M. = Kojo
        Filename        : = draft-ietf-ipsec-ike-modp-groups-00.txt
        Pages           : = 5
        Date    =         : 16-Oct-00
       =20
This document defines new MODP groups for the IKE = [RFC-2409] protocol.
It documents the well know and used 1536 bit group = 5, and also defines
new 2048, 3072, and 4096 bit Diffie-Hellman groups. = The groups are gen-
erated using the guidelines defined in the = [RFC-2412].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-i= ke-modp-groups-00.txt

Internet-Drafts are also 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-ike-modp-groups-00.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-ipsec-ike-modp-groups-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

------_=_NextPart_001_01C039FA.2704FF20-- From owner-ipsec@lists.tislabs.com Thu Oct 19 13:32:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10698; Thu, 19 Oct 2000 13:32:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20782 Thu, 19 Oct 2000 15:09:45 -0400 (EDT) Message-ID: <009301c03a01$c8cb0320$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Joern Sierwald" Cc: , , , References: <3.0.5.32.20001019141730.0349bd30@smtp.datafellows.com> Subject: Re: NAT and IPsec Date: Thu, 19 Oct 2000 22:21:29 +0300 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joern writes: > It should be noted that our (huttunen) scheme is a simple as > it possibly can be. > > There are a lot of thoughts in the draft, but you have to > make it work for yourself. It mentions transport mode, yes. > But we don't even have that ourselves. > > You want to configure it, not negotiate it? > Well, you have to configure it in order to negotiate it, right. > The only change in negotiation is the 61440 number. > You don't _have_ to use the VID... It says "SHOULD" in the draft. > You can use a configuation switch instead. Yes, but even if I don't skip any functionality and want to retain the negotiation possibility, do I really need the VIDs? Wouldn't just the 61440 do? Or just the detection that the IKE packets seem to have gone through a NAT, and that the initiator is sending stuff encapsulated to the port 2797? > >* Would it be simpler to just use a client-initiated > > ping as needed rather than a special-case heartbeat > > packets as in two of the drafts? > > There are two UDP ports here... IKE and ESPoverUDP. > With the ping you only keep ESPoverUDP alive. Ah. Yes. Does somebody have an idea how long a large NAT's UDP session storage lasts, typically? Note that if you were to encapsulate both IKE and ESP to the same UDP port number (2797) then there'd be a need to keep just that alive, either with the ping or with the empty IKE message you suggested. Jari From owner-ipsec@lists.tislabs.com Thu Oct 19 13:35:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10765; Thu, 19 Oct 2000 13:35:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20796 Thu, 19 Oct 2000 15:14:33 -0400 (EDT) Date: Thu, 19 Oct 2000 15:25:43 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt In-Reply-To: <979695BB8922D411A54000D0B74C60B5A9B7A8@sottmxsdev.entrust.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 19 Oct 2000, Joe MacLellan wrote: > I know this was commented on before, but does anyone have any idea what > group "XX" will likely be for these new modp groups? (ie 2048 is Group XX, > 3072 is Group XX+1, 4096 is XX+2). One can make guesses, based on existing assignments... but as I understand it, the rule is that drafts -- which may or may not eventually become real RFCs -- are not supposed to encroach on the number space. There is no official XX until the draft becomes an RFC. Any interim numbering done by a particular implementation should use the private-use part of the number space, *not* a guess at what the official numbers might someday be. > Is this something that Dan will be rolling into the son-of-ike draft as > well? I would say that there's no particular reason to do that (although he might want to reference it). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Oct 19 23:23:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29892; Thu, 19 Oct 2000 23:23:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA22144 Fri, 20 Oct 2000 01:00:31 -0400 (EDT) Date: Thu, 19 Oct 2000 21:54:20 -0700 (MST) From: Joel M Snyder Subject: IKE "clustering" - IP address sensitive or not? To: ipsec@lists.tislabs.com Message-id: <01JVJCIQ510OBJS3VA@Opus1.COM> Organization: Opus One - +1 520 324 0494 MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Fruit-of-the-day: Bearss Lime Comments: Telecommunications and Information Technology Services Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Good day. I am evaluating some IPSEC clustering products, and have come across an impasse in interoperability between two vendors. All clusters appear to have n+1 IP addresses, one for each node and a virtual IP address (often called a VIP) for the cluster as a whole. In at least one vendor's implementation of IKE, the IP address of the IKE peer changes during the middle of the IKE dialog. Thus, a dialog might look like this: 1) Initiator 9.9.9.9 sends to Responder IKE cluster 1.1.1.1 with cookie 2) Responder IKE cluster member 1.1.1.2 responds to Initiator 9.9.9.9 or 1) Initiator IKE cluster 1.1.1.1 sends to Responder 9.9.9.9 with cookie 2) Responder 9.9.9.9 answers Initiator 1.1.1.1 with cookie pair 3) Initiator IKE cluster member 1.1.1.2 starts D-H negotiation part of MM Essentially, the cluster code only uses the cluster address when it absolutely has to and shifts over to an assigned member address asap, with the proviso that it may CONTINUE to shift IP addresses over time as the cluster does its thing. I cannot find any place in the ISAKMP or IKE RFCs where this is specifically prohibited; in fact, when the cookie contents are discussed in IKE, there is a long list of things which does NOT include the destination IP address (which implies that it might change). Similarly, ESP/AH are careful to not tie addresses up in a way which would prohibit one end from shifting around like this. However, this strikes me as A Bad Idea on the general principles of "if I wanted to talk to that IP address, I would have sent to that IP address." Am I totally off base? Is this a problem or a non-problem? [Yes, I know that it breaks transport mode, but let's talk about tunnel mode here.] Is this an example of "total compliance with RFCs, yet completely incompatible?" jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One From owner-ipsec@lists.tislabs.com Fri Oct 20 05:42:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA11735; Fri, 20 Oct 2000 05:42:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23074 Fri, 20 Oct 2000 07:28:44 -0400 (EDT) Message-ID: <39F02F2A.DCC120B4@lmf.ericsson.se> Date: Fri, 20 Oct 2000 14:40:26 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Markus Stenberg CC: bernarda@microsoft.com, ari.huttunen@F-Secure.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <39EEDB92.77497E67@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markus Stenberg wrote: > Depends on definition of complexity, I guess. Nobody has proven to me that > supporting all modes is much more difficult than just esp-tunnel, and I > believe that esp+ipcomp (for example) is definitely a valid combination > worth supporting on slow links. Yeah. Didn't mean to imply that I don't want everything if it comes at the same price :-) And esp+ipcomp is very valid combination, also in transport mode. Think wireless. > > * The Stenberg draft has an overhead of 25 bytes (section > > 4.2). This is close to the 28 bytes of an UDP encapsulation. > > Can you comment on whether a a new header format is > > desireable, given the small difference in the outcome? > > Or perhaps the use of this specific header format gives > > some added benefits that can not be realized with just > > using UDP + IP headers? > > Basically, that was simply "smallest encapsulation possible when using IKE > version field to detect packets". Most of the fields included (due to extra > space mainly) are not really necessary to support even the most nasty (IMO) > AH-transport case. Now I finally understand the format. Smart! However, I'm still wondering *why* it is necessary to use the IKE port. Does somebody have specific knowledge of situations where NATs have let IKE through but not other UDP traffic? Come to think of it, have there been incidents to specifically block IKE and IPsec but let other UDP traffic through [implemented by a very hostile NAT :-) ]? Or perhaps the IKE port is necessary for firewalling NATs to understand what they're letting through? What I'm getting at is UDP-only header insertion and non-IKE port would make the added header sizes smaller as in Ari's draft. Or do you have specific knowledge why the *encapsulation* part of that draft doesn't work? How are you planning to optimize the fake IKE header further? Can we set I-Cookie to 0 or some predefined value as to mark, IPsec packets or what? That would cut the overhead to 8... can't say I like that approach much. Will be interesting to see this traffic in Ethereal or to specify firewall rules... Jari From owner-ipsec@lists.tislabs.com Fri Oct 20 08:52:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19459; Fri, 20 Oct 2000 08:52:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23499 Fri, 20 Oct 2000 09:39:39 -0400 (EDT) X-Authentication-Warning: nurkka.hel.fi.ssh.com: mstenber set sender to markus.stenberg@ssh.com using -f To: Jari Arkko Cc: bernarda@microsoft.com, ari.huttunen@F-Secure.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <39EEDB92.77497E67@lmf.ericsson.se> From: Markus Stenberg Date: 19 Oct 2000 23:02:21 +0300 In-Reply-To: Jari Arkko's message of "Thu, 19 Oct 2000 14:31:30 +0300" Message-ID: Lines: 161 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari Arkko writes: > * In terms of requirements, I think we'd be on the wrong path > if we put much effort in getting all IPsec and IKE modes > to work. I'd rather have a simple scheme that allows only > ESP and only TUNNEL mode and only ... than a complex scheme. > Also - and this may be just my own experience - I consider > most NAT devices as _hostile_ and therefore approaches like > RSIP aren't very fruitful (hostile as in made too early > before RSIP was available or as in owned by an operator who > wants $ for true IP access). Also, I'm not sure about > the scalability of RSIP to an operator or large corporation > NAT. Depends on definition of complexity, I guess. Nobody has proven to me that supporting all modes is much more difficult than just esp-tunnel, and I believe that esp+ipcomp (for example) is definitely a valid combination worth supporting on slow links. > * Bernard's draft says in section 7.1 the following: "By adding a > NAT compatibility mode to IKE/IPSEC, the total time to negotiate > an IPSEC SA may be increased significantly. For example, when > an IKE initiator fails to receive a response, it will typically > need to try again using UDP encapsulation, since the lack of > response may have been due to the presence of intervening NATs." > But is this really the case? I could see an implementation > that tries BOTH standard IKE and NAT-IKE at the same time, > and uses the one that succeeds. And if both happen to > succeed as they would in a no-NAT case, a DELETE could > be performed on the more expensive one afterwards. (A > scheme that might also be useful for other purposes, such > as IKE vs. KINK selection.) Also you could just detect the need during IKE (note that IKE, being normal UDP traffic, should work between hosts even if there is a NAT in the middle - at least until P2) and adjust accordingly. > * Related to the above, would IKE be run directly in the > UDP encapsulation method, or would it too be encapsulated > in UDP? If latter, that would offer a very simple way > for the responder to detect the capability (= existence > of encapsulation) and need (= outer ip not equal to inner > ip). See above. > * I worry about the denial of service issues for plain > UDP encapsulation. For instance, if I'd implement > an UDP tunnel scheme independently from IPsec, and > used the last incoming packet's src and src-port to > determine where the next outgoing packet to the > inner src address should go, then anybody could > send a fake packet that is later dropped by IPsec, > but already modified the return address mapping. > Therefore, it seems that a procedure similar to > IPsec sequence number updates must be applied here, or > alternatively the return addresses must be fixed > at the time of IKE negotiations. Fixed addresses are the way to go, for various reasons. > * I saw in the minutes of the last NAT WG meeting that > somebody proposed the use of L2TP to tunnel IPsec. > While confidentiality and other properties would be > satisfied in this approach, I think a DoS would be > possible here as well: snoop the tunnel IDs and sequence > numbers, then close the tunnel using a fake IP address. Yes. As far as I (also) understand it, that's not secure approach at all (in DoS sense), as L2TP itself has no security features whatsoever. > * To what extent do we believe that the use of IPsec > through NAT must be negotiated, and to what extent > it could just be _configured_? Normally, users would > know that they are behind a NAT. Can we simplify based > on such an assumption? Or perhaps we want to apply > e.g. centrally made corporate policies and not even > let users configure things like this? Typical end users are ignorant/. Expecting them to be able to do more than just select 'yes, there is an machine I want to talk with securely' is not realistic, I think. Thus, this leads to question of whether or not we want to spend twice as much time detecting both options, or just detect it on the fly. I prefer later. YMMV. > * Would it be simpler to just use a client-initiated > ping as needed rather than a special-case heartbeat > packets as in two of the drafts? That's one of the options. However, IPsec SA-level-heartbeat has some adverse issues that I recall from the recent generic IKE/IPsec-heartbeat debates and thus won't get to it here. _Some_ form of mandatory heartbeat is necessary if you really intend to support 'general NAT case' (as opposed to the rare static {basic NAT,NAPT} cases). > * I'm not sure I understand the need for the ESPUDP > attribute value in Ari's draft. If the connection > has been determined to be through a NAT, and the > VIDs have been exchanged - what's left? Or, why > not use just the ESPUDP value and not VIDs? There's more than one thing I don't understand in the draft - of course, I can see that it's a work in progress and I'm keenly waiting for the next version to see if actual implementation (vrt. guessing how to implement it) is possible based on it. Out of curiosity - has anyone actually tried to implement either of the UDP-encapsulation drafts? (Besides the draft writers themselves, of course) > * The Stenberg draft has an overhead of 25 bytes (section > 4.2). This is close to the 28 bytes of an UDP encapsulation. > Can you comment on whether a a new header format is > desireable, given the small difference in the outcome? > Or perhaps the use of this specific header format gives > some added benefits that can not be realized with just > using UDP + IP headers? Basically, that was simply "smallest encapsulation possible when using IKE version field to detect packets". Most of the fields included (due to extra space mainly) are not really necessary to support even the most nasty (IMO) AH-transport case. Next version will have somewhat less overhead (25->20), and actual content is just 4 bytes. > * Why does the Stenberg draft include an unused field > in the packet encapsulation? And isn't the version > fields in IKE negotiation sufficient, do we need a version > field in the traversal tunnel header as well? Isn't > TOS field thrown away in any case after IPsec has been > processed? Because it uses IKE port, there has to be a way for IKE to detect that it is not a valid packet (reason for version being included). And because IKE version's 17th byte, there was simply extra space there. However, header format will change by -01 which should be out in two weeks or perhaps bit less. > * As a part of the IKE negotiations, the peer > exchange perceived and local identities (section > 3.1.2 of the Stenberg draft). Actual IPsec > packets then contain an envelope that contains, > among other things, the local address. But why? > If I receive a packet from the perceived address, > can't I just replace the local addresses without > having to restate them in every packet? Yes, exactly; that's one of the things that changes in -01 draft (see above for comments). > Jari > ---- > Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 > Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com > Private WWW: http://www.iki.fi/jar. Standard disclaimers apply. -Markus Stenberg From owner-ipsec@lists.tislabs.com Fri Oct 20 08:52:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19475; Fri, 20 Oct 2000 08:52:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00489 Fri, 20 Oct 2000 10:31:12 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: Steve Bellovin To: ipsec@lists.tislabs.com Subject: speed of HMAC vs. Rijndael-CBCMAC? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Oct 2000 10:44:18 -0400 Message-Id: <20001020144424.B898935DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Has anyone done any measurements on the relative speeds of a CBC-MAC using Rijndael (AES) vs. HMAC-MD5 or HMAC-SHA1? Rijndael is very fast, and we may be able to eliminate some code in our implementations. --Steve Bellovin From owner-ipsec@lists.tislabs.com Fri Oct 20 08:52:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19474; Fri, 20 Oct 2000 08:52:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23512 Fri, 20 Oct 2000 09:40:38 -0400 (EDT) X-Authentication-Warning: nurkka.hel.fi.ssh.com: mstenber set sender to markus.stenberg@ssh.com using -f To: "Jari Arkko" Cc: "Joern Sierwald" , , , Subject: Re: NAT and IPsec References: <3.0.5.32.20001019141730.0349bd30@smtp.datafellows.com> <009301c03a01$c8cb0320$8a1b6e0a@arenanet.fi> From: Markus Stenberg Date: 20 Oct 2000 02:46:23 +0300 In-Reply-To: "Jari Arkko"'s message of "Thu, 19 Oct 2000 22:21:29 +0300" Message-ID: Lines: 38 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Jari Arkko" writes: > Joern writes: > > >* Would it be simpler to just use a client-initiated > > > ping as needed rather than a special-case heartbeat > > > packets as in two of the drafts? > > > > There are two UDP ports here... IKE and ESPoverUDP. > > With the ping you only keep ESPoverUDP alive. > Ah. Yes. Does somebody have an idea how long a large NAT's UDP > session storage lasts, typically? 300 seconds might be reasonable typical value (they range from 30 sec to 3600 sec). However, to make it general-purpose you have to work by worst-case assumption. > Note that if you were to encapsulate both IKE and ESP to the > same UDP port number (2797) then there'd be a need to keep > just that alive, either with the ping or with the empty IKE message > you suggested. And you'd wind up with my proposal, except it doesn't encapsulate IKE (i.e. you would need to have overhead in normal IP packets beyond normal UDP header, _and_ you would have overhead in IKE packets). I can't see why you would want to do that, though, as IKE works as-is. Another thing is getting firewalls et al to recognize UDP port 2797 as 'nice traffic' port. (Does the fact that non-root-user can bind the port have bad future implications? I could see someone 'stealing' the port on UNIX box..) > Jari -Markus -- vi is [[13~^[[15~^[[15~^[[19~^[[18~^ a muk[^[[29~^[[34~^[[26~^[[32~^ch better editor than this emacs. I know I^[[14~'ll get flamed for this but the truth has to be said. ^[[D^[[D^[[D^[[D^~ [[D^[^[[D^[[D^[[B^ -- Jesper Lauridsen From owner-ipsec@lists.tislabs.com Fri Oct 20 11:23:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22185; Fri, 20 Oct 2000 11:23:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01218 Fri, 20 Oct 2000 13:02:45 -0400 (EDT) X-Authentication-Warning: nurkka.hel.fi.ssh.com: mstenber set sender to mstenber@ssh.com using -f To: Jari Arkko Cc: bernarda@microsoft.com, ari.huttunen@F-Secure.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <39EEDB92.77497E67@lmf.ericsson.se> <39F02F2A.DCC120B4@lmf.ericsson.se> From: Markus Stenberg Date: 20 Oct 2000 18:29:29 +0300 In-Reply-To: Jari Arkko's message of "Fri, 20 Oct 2000 14:40:26 +0300" Message-ID: Lines: 93 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari Arkko writes: > Markus Stenberg wrote: > > Depends on definition of complexity, I guess. Nobody has proven to me that > > supporting all modes is much more difficult than just esp-tunnel, and I > > believe that esp+ipcomp (for example) is definitely a valid combination > > worth supporting on slow links. > Yeah. Didn't mean to imply that I don't want everything if it comes > at the same price :-) And esp+ipcomp is very valid combination, > also in transport mode. Think wireless. Yes.. I see that there are currently three different (important) factors for solutions to this: - cases where it applies - complexity/overhead - ease of deployment (we do _NOT_ want to make anything that requires ipv6-level-changes in deployed hardware - thus RSIP is out) > However, I'm still wondering *why* it is necessary to use > the IKE port. Does somebody have specific knowledge of > situations where NATs have let IKE through but not other > UDP traffic? Come to think of it, have there been > incidents to specifically block IKE and IPsec but let > other UDP traffic through [implemented by a very hostile > NAT :-) ]? Or perhaps the IKE port is necessary for > firewalling NATs to understand what they're letting through? It is simply easier to deploy - as IKE will be used on the port in any case, the approach of 'if IKE works, IPsec works also' makes it a lot easier to cope with. (Hypothetical example): - corporation X allows only IPsec traffic, i.e. port 500 access to one host and ESP traffic to the host (which happens to be a SGW) - roaming road warrior of corporation X wants to access the internal network of corporation X, and happens to be in DoubleTree hotel somewhere in middle of nowhere, behind a NAT Which of the drafts will work as-is in this case? (-: Admittedly, most firewall configrations are (remote=500,local=500) but I think that anything that can simplify the end user experience without excessive cost should be done in this type of technology. IPsec as-is should be as transparent to end user as possible, and I believe the way of traversaing NAT should be the same. As rhetorical question - have you ever tried to debug why enduser cannot do something? > What I'm getting at is UDP-only header insertion and non-IKE > port would make the added header sizes smaller as in Ari's > draft. Or do you have specific knowledge why the *encapsulation* > part of that draft doesn't work? I think that you need something beyond UDP header to be able to support all modes (for example, original header length so that extra options which may or may not get snipped off can be stored elsewhere). > How are you planning to optimize the fake IKE header further? > Can we set I-Cookie to 0 or some predefined value as to mark, > IPsec packets or what? That would cut the overhead to 8... Yes, that. (+4 bytes of header information => 12 byte UDP payload => 20 byte total. > can't say I like that approach much. Will be interesting to > see this traffic in Ethereal or to specify firewall rules... Well, as a side note - it seems that Ethereal barfs equally nicely to IKE version approach (which it _should_ handle but apparently doesn't). That reminds me, I have to submit my Ethereal patches for this.. (-: Firewall rules are not _my_ concern - if why are you letting IKE through if you do not desire IPsec? (Excluding some obscure use of AH to make "verifiable but snoopable" Big Brother-friendly access somewhere.) > Jari -Markus P.S. It seems that the IPsec list is dropping my comments - at least I never saw it show up.. I guess it's in some form of paranoid subscribed-people-only-mode, but I wish it had at least sent me a bounce regarding the previous message(s).. :P -- Markus Stenberg of SSH Communications Security (www.ssh.com) -- John C. Kelley Computer Scientist NAILabs at Network Associates, Inc. Glenwood, MD From owner-ipsec@lists.tislabs.com Fri Oct 20 12:25:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23634; Fri, 20 Oct 2000 12:25:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01547 Fri, 20 Oct 2000 14:26:26 -0400 (EDT) Message-ID: <39F091FB.A40D9109@cisco.com> Date: Fri, 20 Oct 2000 11:42:03 -0700 From: "David A. McGrew" X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Bellovin CC: ipsec@lists.tislabs.com Subject: Re: speed of HMAC vs. Rijndael-CBCMAC? References: <20001020144424.B898935DC2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Steve Bellovin wrote: > > Has anyone done any measurements on the relative speeds of a CBC-MAC > using Rijndael (AES) vs. HMAC-MD5 or HMAC-SHA1? Rijndael is very fast, > and we may be able to eliminate some code in our implementations. > > --Steve Bellovin code elimination would be good. I'd favor the use of UMAC over CBC MAC though. UMAC is designed to work with AES, is provably secure, and is staggeringly fast. UMAC is well described at http://www.cs.ucdavis.edu/~rogaway/umac/. The creators of UMAC intended to submit a draft on their mechanism, though I don't think that they have done so yet. I guess that you're not at the NIST workshop either - or are you always online ;-) David From owner-ipsec@lists.tislabs.com Fri Oct 20 12:48:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28511; Fri, 20 Oct 2000 12:48:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01694 Fri, 20 Oct 2000 14:55:24 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "David A. McGrew" Cc: ipsec@lists.tislabs.com Subject: Re: speed of HMAC vs. Rijndael-CBCMAC? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Oct 2000 15:08:14 -0400 Message-Id: <20001020190823.8BAB635DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <39F091FB.A40D9109@cisco.com>, "David A. McGrew" writes: > >I guess that you're not at the NIST workshop either - or are you always >online ;-) Of course I'm at the workshop. Wireless is your friend... --Steve Bellovin From owner-ipsec@lists.tislabs.com Fri Oct 20 13:59:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01285; Fri, 20 Oct 2000 13:59:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01890 Fri, 20 Oct 2000 15:54:57 -0400 (EDT) Message-ID: <006001c03ad1$4c214ac0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Markus Stenberg" Cc: References: <39EEDB92.77497E67@lmf.ericsson.se> <39F02F2A.DCC120B4@lmf.ericsson.se> Subject: Re: NAT and IPsec Date: Fri, 20 Oct 2000 23:06:56 +0300 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 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markus Stenberg writes: > I think that you need something beyond UDP header to be able to support all > modes (for example, original header length so that extra options which may > or may not get snipped off can be stored elsewhere). Can we develop something more specific here. What and what ? For instance, I suppose header length and options are only relevant if one uses AH? Is there something that transport mode requires? What about the NAT operations performed by the hosts, do they require any extra information beyond the UDP header? Add to that an analysis of the presented approaches according to the criterias (supported cases, overhead, complexity, and ease of deployment). Then we'll be a lot closer to understanding which way to go. Also, I've got a new question regarding this whole IPsec over NAT business. I've been reading the notes of the previous NAT WG meeting: >Marcus Leech (AD): IPSec WG will be chartered to deal with the >interoperability issues. To the working group: what does the above mean? I have not noticed a change in the IPsec WG charter, will there be one? Is modifying IPsec and IKE a legitimate work item of this WG for this particular purpose? Jari From owner-ipsec@lists.tislabs.com Sat Oct 21 15:43:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04777; Sat, 21 Oct 2000 15:43:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04503 Sat, 21 Oct 2000 17:23:18 -0400 (EDT) Message-ID: <39F20C6A.32640896@F-Secure.com> Date: Sun, 22 Oct 2000 00:36:42 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Joern Sierwald , bernarda@microsoft.com, mstenber@ssh.com, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <3.0.5.32.20001019141730.0349bd30@smtp.datafellows.com> <009301c03a01$c8cb0320$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari Arkko wrote: > > Joern writes: > > > >* Would it be simpler to just use a client-initiated > > > ping as needed rather than a special-case heartbeat > > > packets as in two of the drafts? > > > > There are two UDP ports here... IKE and ESPoverUDP. > > With the ping you only keep ESPoverUDP alive. > > Ah. Yes. Does somebody have an idea how long a large NAT's UDP > session storage lasts, typically? > > Note that if you were to encapsulate both IKE and ESP to the > same UDP port number (2797) then there'd be a need to keep > just that alive, either with the ping or with the empty IKE message > you suggested. This is of course possible. However, I strongly believe that we should allow the firewall administrator an easy way to distinguish between two types of traffic. If this wasn't necessary, we could just make an RFC that every traffic must be passed along TCP port 80. It is also possible to define a method to negotiate the used port. I didn't try to define this, since it just makes the thing more complicated. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 15:46:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04810; Sat, 21 Oct 2000 15:46:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04483 Sat, 21 Oct 2000 17:17:37 -0400 (EDT) Message-ID: <39F20B13.F1753C26@F-Secure.com> Date: Sun, 22 Oct 2000 00:30:59 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Joern Sierwald CC: Jari Arkko , bernarda@microsoft.com, mstenber@ssh.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <3.0.5.32.20001019141730.0349bd30@smtp.datafellows.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joern Sierwald wrote: > > At 14:31 19.10.2000 +0300, Jari Arkko wrote: > >I have some questions and some issues I'd like to discuss. > >Here they are: > > > >* In terms of requirements, I think we'd be on the wrong path > > if we put much effort in getting all IPsec and IKE modes > > to work. I'd rather have a simple scheme that allows only > > ESP and only TUNNEL mode and only ... than a complex scheme. > > It should be noted that our (huttunen) scheme is a simple as > it possibly can be. Almost.. It could have been made somewhat simpler but I was constrained by a couple of factors. The first factor was the IPR statement that appears in the Stenberg draft. I made the assumption that SSH had filed for a patent recently, and I tried not to use methods in my draft that would not be self-evident for everyone. Another factor is the way private numbers and payloads are allowed to be used in IKE. Having now read through that patent application (assuming there is only one), I'm in a position to create an even simpler draft that according to my understanding does not infringe on the patent, if there is to be one of course. This is my best understanding at this time, but I may of course be wrong. You must not use this paragraph in any legal decision to use or not use the draft that we've written. I'll have more to say about this later as I suggest how my draft can be improved, but for now I'll just go through these messages and answer some points in them. > > There are a lot of thoughts in the draft, but you have to > make it work for yourself. It mentions transport mode, yes. > But we don't even have that ourselves. Right. The reason there is an attempt to incorporate transport mode is that some vendors do not implement IPsec tunnel mode in hosts, as it's not required by RFCs. As we have tunnel mode in our implementation, we're not actively pursuing in defining the transport mode. I welcome others to study using the transport mode. It is possible, but not so easy as tunnel mode. > > You want to configure it, not negotiate it? > Well, you have to configure it in order to negotiate it, right. > The only change in negotiation is the 61440 number. > You don't _have_ to use the VID... It says "SHOULD" in the draft. > You can use a configuation switch instead. To my understanding IKE RFCs require that we send a vendor ID if we use numbers from private ranges. That is the only real reason for it. If the number is from a standard range, we could just throw the VID away. > >* I worry about the denial of service issues for plain > > UDP encapsulation. For instance, if I'd implement > > an UDP tunnel scheme independently from IPsec, and > > used the last incoming packet's src and src-port to > > determine where the next outgoing packet to the > > inner src address should go, then anybody could > > send a fake packet that is later dropped by IPsec, > > but already modified the return address mapping. > > Therefore, it seems that a procedure similar to > > IPsec sequence number updates must be applied here, or > > alternatively the return addresses must be fixed > > at the time of IKE negotiations. > > > > I understand the problem, but you found the solution. > Change your mapping only after the packet has passed ESP... I wrote in the draft something to the effect that the source IP address and port MUST NOT change. As Joern said, it's possible to make it work. The question is, should the draft allow or disallow such changes? Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 16:09:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA04989; Sat, 21 Oct 2000 16:09:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04585 Sat, 21 Oct 2000 18:19:29 -0400 (EDT) Message-ID: <39F21995.687E06C@F-Secure.com> Date: Sun, 22 Oct 2000 01:32:53 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: bernarda@microsoft.com, mstenber@ssh.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <39EEDB92.77497E67@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari Arkko wrote: > > * Bernard's draft says in section 7.1 the following: "By adding a > NAT compatibility mode to IKE/IPSEC, the total time to negotiate > an IPSEC SA may be increased significantly. For example, when > an IKE initiator fails to receive a response, it will typically > need to try again using UDP encapsulation, since the lack of > response may have been due to the presence of intervening NATs." > But is this really the case? I could see an implementation > that tries BOTH standard IKE and NAT-IKE at the same time, > and uses the one that succeeds. And if both happen to > succeed as they would in a no-NAT case, a DELETE could > be performed on the more expensive one afterwards. (A > scheme that might also be useful for other purposes, such > as IKE vs. KINK selection.) This is basically just what our draft does. An initiator that supports both ESP and ESP-UDP sends proposals that cover both alternatives. The main disadvantage is that the proposal lists grow quit large, and some vendors do not even support large proposal lists (more than 10 proposals or something). BTW, if I could get something ADDED to IKE it would be this: allow the specification of - Lifetime MIN, MAX values allowed by X - In proposal lists, allow defining in one place a thing like "either X, Y or Z" is allowed here, rather than having to explode the whole thing - Allow specification of "I don't care about X" for many things X Of course, there's not much chance of this happening. ;) > * The Stenberg draft has an overhead of 25 bytes (section > 4.2). This is close to the 28 bytes of an UDP encapsulation. > Can you comment on whether a a new header format is > desireable, given the small difference in the outcome? > Or perhaps the use of this specific header format gives > some added benefits that can not be realized with just > using UDP + IP headers? clip > * As a part of the IKE negotiations, the peer > exchange perceived and local identities (section > 3.1.2 of the Stenberg draft). Actual IPsec > packets then contain an envelope that contains, > among other things, the local address. But why? > If I receive a packet from the perceived address, > can't I just replace the local addresses without > having to restate them in every packet? You might do wisely to read through a patent application made by SSH and Tatu Ylonen that concerns this issue. You can find it here: http://l2.espacenet.com/dips/bnsviewer?CY=fi&LG=fi&DB=EPD&PN=EP1036460&ID=WO+++9935799A2+I+ http://l2.espacenet.com/dips/viewer?PN=AU1879599&CY=fi&LG=fi&DB=EPD One point to note is that what is specified in the Stenberg draft MOST CLEARLY falls under this patent application. Here's a paragraph from that patent application (copied by hand): To compensate for transformations at the receiving node, the receiving node applies reverse transformations to the received data before computing the MAC. Thus, the sending node will send a packet that has a correct MAC, and the receiving node will convert the packet to the form sent by the sending node before verifying the MAC. Here's a sentence from the Stenberg draft: Decapsulation occurs before IPsec processing, and it copies values from the envelope to the real packet and discards the envelope. As our draft specifies a method that does not make correcting packet transformations BEFORE verifying the MAC, it is currently my belief that we do not 'infringe' on this patent application. Instead, we make a packet transformation after MAC checking as ordinary NAT boxes do. Yes, I know that claims are what counts, so I read through them and still believe in this. One thing that follows, is that AH cannot be made to pass NAT without 'infringing' on this patent application. Note that I have no lawyer training, so I'm not qualified in reading lawyer talk. You MUST NOT use anything that I said to guide your legal decisions about using or not using our draft. Or for anything else. In fact, I never wrote anything, so you never read anything ;). I think I'll probably specify something to the effect in a future draft version that the initiator sends the original IP address and port it used. Having these makes the most complex part of our draft simpler, i.e. the determination of whether NAT exists along the route. The current version only makes an educated guess, as specified in our draft. Question: What would be the best way to transport original IP address / port information in the first IKE packet (of any phase I)? I think private payloads are out, since one can't send them before a VID from the other end is received. Right? Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 16:45:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05458; Sat, 21 Oct 2000 16:45:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04624 Sat, 21 Oct 2000 18:53:31 -0400 (EDT) Message-ID: <39F2218E.5CB747AC@F-Secure.com> Date: Sun, 22 Oct 2000 02:06:54 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Stenberg CC: Jari Arkko , bernarda@microsoft.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <39EEDB92.77497E67@lmf.ericsson.se> <39F02F2A.DCC120B4@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markus Stenberg wrote: > > Jari Arkko writes: > > Markus Stenberg wrote: > > > Depends on definition of complexity, I guess. Nobody has proven to me that > > > supporting all modes is much more difficult than just esp-tunnel, and I > > > believe that esp+ipcomp (for example) is definitely a valid combination > > > worth supporting on slow links. > > Yeah. Didn't mean to imply that I don't want everything if it comes > > at the same price :-) And esp+ipcomp is very valid combination, > > also in transport mode. Think wireless. There's no reason why our draft couldn't support UDP+ESP+IPCOMP. It just wasn't specified in it, because we had no implementation experience with that combination. In fact, it should be better for wireless since the encapsulation overhead is smaller. > (Hypothetical example): > > - corporation X allows only IPsec traffic, i.e. port 500 access to one > host and ESP traffic to the host (which happens to be a SGW) > > - roaming road warrior of corporation X wants to access the internal > network of corporation X, and happens to be in DoubleTree hotel somewhere > in middle of nowhere, behind a NAT > > Which of the drafts will work as-is in this case? (-: Right, so? If some company fails to change their firewall when something new is deployed that needs such changes, well.. it's their problem. Someone at the interop. told me they actually made something similar that works along TCP port 80, a couple of years back. Sorry, I fail to remember who it was. And doesn't Microsoft have some protocol that tunnels everything along that? > > As rhetorical question - have you ever tried to debug why enduser cannot do > something? Yes. Sucks.. I somehow think IPsec WG should make an effort to do something to help in this (like specifying draft-ietf-ipsec-notifymsg-03.txt but more). The solution should NOT be to pass the bucket to IPSP WG, althought there is surely a need for it too. > Well, as a side note - it seems that Ethereal barfs equally nicely to IKE > version approach (which it _should_ handle but apparently doesn't). That > reminds me, I have to submit my Ethereal patches for this.. (-: > > Firewall rules are not _my_ concern - if why are you letting IKE through if > you do not desire IPsec? > > (Excluding some obscure use of AH to make "verifiable but snoopable" Big > Brother-friendly access somewhere.) I've been thinking that someone should make a patch to Ethereal that would enable it to look inside AH or ESP/NULL. That's somewhat hard, but doable with some innovative guesswork. (Right?) Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 16:56:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05549; Sat, 21 Oct 2000 16:56:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04646 Sat, 21 Oct 2000 19:07:21 -0400 (EDT) Message-ID: <39F224CE.471E5C9@F-Secure.com> Date: Sun, 22 Oct 2000 02:20:46 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Thu, 19 Oct 2000, Joe MacLellan wrote: > > I know this was commented on before, but does anyone have any idea what > > group "XX" will likely be for these new modp groups? (ie 2048 is Group XX, > > 3072 is Group XX+1, 4096 is XX+2). > > One can make guesses, based on existing assignments... but as I understand > it, the rule is that drafts -- which may or may not eventually become real > RFCs -- are not supposed to encroach on the number space. There is no > official XX until the draft becomes an RFC. Any interim numbering done by > a particular implementation should use the private-use part of the number > space, *not* a guess at what the official numbers might someday be. Right. However, I'd rather like someone to set the number so everyone would use the same private numbers, rather than every vendor using their own. It'd make testing easier. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 17:05:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05702; Sat, 21 Oct 2000 17:05:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04710 Sat, 21 Oct 2000 19:19:30 -0400 (EDT) Date: Sat, 21 Oct 2000 19:30:14 -0400 (EDT) From: Henry Spencer To: Ari Huttunen cc: IP Security List Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-00.txt In-Reply-To: <39F224CE.471E5C9@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 22 Oct 2000, Ari Huttunen wrote: > > > group "XX" will likely be for these new modp groups? (ie 2048 is Group XX, > > > 3072 is Group XX+1, 4096 is XX+2). > > ...Any interim numbering done by > > a particular implementation should use the private-use part of the number > > space... > > Right. However, I'd rather like someone to set the number so everyone > would use the same private numbers, rather than every vendor using their > own. It'd make testing easier. Good point. Hmm, let's see, private assignments start at 2^15 (32768). How about 32768+2048 for 2048, 32768+3072 for 3072, 32768+4096 for 4096? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Oct 21 17:08:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05749; Sat, 21 Oct 2000 17:08:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04716 Sat, 21 Oct 2000 19:20:10 -0400 (EDT) Message-ID: <39F227CF.86740A95@F-Secure.com> Date: Sun, 22 Oct 2000 02:33:35 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: ipsec@lists.tislabs.com Subject: Re: Getting focus for son-of-IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: > > > I'm also planning on cutting out quite a bit of the optional things that > > are now referred to as "standards bloat". For instance, one of the > > public key authentication methods will be removed as will Aggressive > > Mode and most of the ISAKMP exchanges defined in RFC2408. I definitely oppose removing aggressive mode, unless at the same time something like base mode is made a required part of IKE. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 17:11:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05816; Sat, 21 Oct 2000 17:11:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04687 Sat, 21 Oct 2000 19:14:59 -0400 (EDT) Message-ID: <39F22697.491100BD@F-Secure.com> Date: Sun, 22 Oct 2000 02:28:23 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Kelly CC: Stephen Kent , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Getting focus for son-of-IKE References: <39EB8DA6.620CD9C5@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Kelly wrote: > > Stephen Kent wrote: > > > > Paul, > > > > I generally like your analysis for IKE, but I would also like to > > suggest that there may be a few "added functions" that should be on > > the list. For example, we stripped out several negotiation features > > for phase II which had been supported in the SPD, e.g., port ranges > > or lists vs. individual port numbers. I'd like to see these added > > back. > > > > Steve > > I agree with Steve. In general, I would like to see a more comprehensive > selector specification mechanism in IKE. > > Scott Definitely, if possible! We, like many others, support firewall functionality, and can specify allowed traffic very finely in terms of local / remote port numbers. Since these cannot be specified in IKE, the end result is potentially very confusing for customers. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 17:15:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05890; Sat, 21 Oct 2000 17:15:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04750 Sat, 21 Oct 2000 19:29:06 -0400 (EDT) Message-ID: <39F229E8.107819BA@F-Secure.com> Date: Sun, 22 Oct 2000 02:42:32 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: "Chinna N.R. Pellacuru" , ipsec@lists.tislabs.com Subject: Re: charter question re IKE changes References: <200010181718.NAA22222@solidum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > If son-of-IKE mandates support for self-signed certificates, then one does > not need to depend on the quality of the CA products to use public key > authentication. > > The origin of the desire to keep pre-shared keys is due to "poorly designed > CA products" --- really more to do with business models of certain public > key libraries. What's the point of removing a feature that: - is the most interoperable authentication mode in existance - makes possible the smallest memory footprint implementation possible - is the most resistant to DoS attacks ??? Yes, it's not really usable in large scale, but that's beside the point. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 17:37:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06113; Sat, 21 Oct 2000 17:37:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04778 Sat, 21 Oct 2000 19:48:28 -0400 (EDT) Message-ID: <39F22E70.F5C88740@F-Secure.com> Date: Sun, 22 Oct 2000 03:01:52 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: Jan Vilhuber , ipsec Subject: Safety of pre-shared keys? (Re: Reliable delete notifies) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Mon, 9 Oct 2000, Jan Vilhuber wrote: > > With pure public keys, you need TWO of them. Granted, I can provision every > > box with the same private key, which would make it equivalent to the above > > group-pre-shared key scenarion. But in reality you need two public keys, > > where before you had a single pre-shared key. > > Consider them two halves of the same shared secret. There's no fundamental > difference... Incorrect. With a pre-shared key you have one key that is secret. With public keys, you have two keys, one of which is public, one is secret. I'm quite sure everyone on this list knows this much.. Now, if you have that public key, you CAN give it to some mechanical calculator for cracking. Eventually that machine will produce a result, and if it's based on quantum computing you might actually get a result before the Big Crash (if any). Out of curiosity, what would one need to fool authentication based on pre-shared keys, assuming only knowledge of things-on-the-wire? Would the method learn the value of the pre-shared key or something else? (Would it be safe against quantum computers?) Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Sat Oct 21 18:25:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06811; Sat, 21 Oct 2000 18:25:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04922 Sat, 21 Oct 2000 20:18:11 -0400 (EDT) From: "Joseph D. Harwood" To: "Ari Huttunen" Cc: "Ipsec" Subject: RE: NAT and IPsec Date: Sat, 21 Oct 2000 17:28:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C03B84.4F2F5DC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <39F20B13.F1753C26@F-Secure.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C03B84.4F2F5DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen > Sent: Saturday, October 21, 2000 2:31 PM > To: Joern Sierwald > Cc: Jari Arkko; bernarda@microsoft.com; mstenber@ssh.com; > jarkko@piuha.net; ipsec@lists.tislabs.com > Subject: Re: NAT and IPsec > > > Right. The reason there is an attempt to incorporate transport > mode is that some vendors do not implement IPsec tunnel mode > in hosts, as it's not required by RFCs. As we have tunnel mode > in our implementation, we're not actively pursuing in defining > the transport mode. I welcome others to study using the transport > mode. It is possible, but not so easy as tunnel mode. > > Regarding hosts not being required to implement IPsec tunnel mode, RFC 2401, Section 4.1: "In summary, a) A host MUST support both transport and tunnel mode. b) A security gateway is required to support only tunnel mode..." Has this changed? How would a host that doesn't support tunnel mode talk to another host behind a security gateway? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com ------=_NextPart_000_0000_01C03B84.4F2F5DC0 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0000_01C03B84.4F2F5DC0-- From owner-ipsec@lists.tislabs.com Sun Oct 22 01:57:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14060; Sun, 22 Oct 2000 01:57:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05561 Sun, 22 Oct 2000 03:38:16 -0400 (EDT) Message-ID: <004901c03bfc$b78de120$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Markus Stenberg" Cc: , References: <39EEDB92.77497E67@lmf.ericsson.se> <39F02F2A.DCC120B4@lmf.ericsson.se> Subject: Re: NAT and IPsec Date: Sun, 22 Oct 2000 10:50:15 +0300 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 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Marcus writes about why there is a need to use exactly the IKE port: >It is simply easier to deploy - as IKE will be used on the port in any >case, the approach of 'if IKE works, IPsec works also' makes it a lot >easier to cope with. > ... > Admittedly, most firewall configrations are (remote=500,local=500) but I > think that anything that can simplify the end user experience without > excessive cost should be done in this type of technology. IPsec as-is > should be as transparent to end user as possible, and I believe the way of > traversaing NAT should be the same. Well... just to be clear on this: in order to make [Stenberg] work we most likely need to modify the firewall policy to (remote=*,local=500). In order to make [Huttunen] work, we need to modify the policy to (remote=*,local=500, 2796). In both cases the firewall administrator and the user have a direct business relationship and making modifications in theory should be possible. I know this doesn't always hold in practise. But if a modification is needed most likely anyway...? And we're paying a substantial per-packet overhead to use the IKE port...? Jari From owner-ipsec@lists.tislabs.com Sun Oct 22 03:34:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18189; Sun, 22 Oct 2000 03:34:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05749 Sun, 22 Oct 2000 05:38:05 -0400 (EDT) Message-ID: <39F2B8A2.BA69844@F-Secure.com> Date: Sun, 22 Oct 2000 12:51:30 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Joseph D. Harwood" CC: Ipsec Subject: Re: NAT and IPsec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Joseph D. Harwood" wrote: > > Regarding hosts not being required to implement IPsec tunnel mode, RFC 2401, > Section 4.1: > > "In summary, > a) A host MUST support both transport and tunnel mode. > b) A security gateway is required to support only tunnel mode..." > > Has this changed? How would a host that doesn't support tunnel mode talk to > another host behind a security gateway? Hmm.. You're right, it's just been so long since I read RFC2401. I think such hosts do L2TP over IPsec to the gateway. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Oct 23 01:05:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24815; Mon, 23 Oct 2000 01:05:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07965 Mon, 23 Oct 2000 02:09:53 -0400 (EDT) Message-ID: <20001023062144.22109.qmail@web1406.mail.yahoo.com> Date: Sun, 22 Oct 2000 23:21:44 -0700 (PDT) From: Pyda Srisuresh Subject: Re: NAT and IPsec To: Ari Huttunen , Joern Sierwald Cc: Jari Arkko , bernarda@microsoft.com, mstenber@ssh.com, jarkko@piuha.net, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Ari Huttunen wrote: > > Joern Sierwald wrote: > > > > At 14:31 19.10.2000 +0300, Jari Arkko wrote: > > >I have some questions and some issues I'd like to discuss. > > >Here they are: > > > > > >* In terms of requirements, I think we'd be on the wrong path > > > if we put much effort in getting all IPsec and IKE modes > > > to work. I'd rather have a simple scheme that allows only > > > ESP and only TUNNEL mode and only ... than a complex scheme. > > > > It should be noted that our (huttunen) scheme is a simple as > > it possibly can be. > > Almost.. It could have been made somewhat simpler but I was constrained > by a couple of factors. The first factor was the IPR statement that > appears in the Stenberg draft. I made the assumption that SSH had filed > for a patent recently, and I tried not to use methods in my draft that > would not be self-evident for everyone. Another factor is the way > private numbers and payloads are allowed to be used in IKE. Having > now read through that patent application (assuming there is only one), > I'm in a position to create an even simpler draft that according to > my understanding does not infringe on the patent, if there is to be > one of course. This is my best understanding at this time, but I may > of course be wrong. You must not use this paragraph in any legal decision > to use or not use the draft that we've written. > > I'll have more to say about this later as I suggest how my draft can > be improved, but for now I'll just go through these messages and answer > some points in them. > Couple of questions: 1. Sanity check: I believe, ESPUDP is a specific instance of a UDP application, when the destination/Source is set to 2746 or 2797. Is this correct? The ESPUDP port apparently requires an ESP header to follow the UDP header, right? Does this ESPUDP also mandate that the UDP checksum field be turned off? 2. Assuming the above assertion is valid, the transport mode will not work with TCP/UDP packets for NAPT for the follwing 2 reasons A. Checksum failure, as pointed out in the draft[section 6] B. 2 independent hosts in the same private domain could be using the same (source port, destination port) pair and the external node will have no way to distinguish between the two. 3. As for tunnel mode using ESPUDP port, I dont see the point of transporting private address across to an external domain. This is essentially moving the NAT function from possibly multiple private domains to a single external Node. This is very problematic and shouldnt be used, in my opinion. Thanks. cheers, suresh __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Oct 23 02:16:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26306; Mon, 23 Oct 2000 02:16:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08297 Mon, 23 Oct 2000 04:02:41 -0400 (EDT) Message-ID: <39F3F3C4.69A96C39@F-Secure.com> Date: Mon, 23 Oct 2000 11:16:04 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pyda Srisuresh CC: Joern Sierwald , Jari Arkko , bernarda@microsoft.com, mstenber@ssh.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <20001023062144.22109.qmail@web1406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pyda Srisuresh wrote: > Couple of questions: > 1. Sanity check: I believe, ESPUDP is a specific instance of a UDP > application, when the destination/Source is set to 2746 or 2797. > Is this correct? The ESPUDP port apparently requires an ESP header > to follow the UDP header, right? Does this ESPUDP also mandate > that the UDP checksum field be turned off? ESP is required since we want to make a secure protocol, and AH will never work with this. IPCOMP may come after ESP. We mandate the UDP checksum to be turned off because it's just overhead in this case (same endpoints). > 2. Assuming the above assertion is valid, the transport mode will not > work with TCP/UDP packets for NAPT for the follwing 2 reasons > A. Checksum failure, as pointed out in the draft[section 6] > B. 2 independent hosts in the same private domain could be > using the same (source port, destination port) pair and the > external node will have no way to distinguish between the two. I still claim it can be made to work. For A the receiver of a packet (either end) must first process the ESP header, after which it needs to both do some sort of NAT and recalculate the TCP/UDP checksums. For B: Alice sends IP:A->GW UDP:2797->2797, GW receives IP:NATBOX->GW UDP:aaaa->2797 Bob sends IP:B->GW UDP:2797->2797, GW receives IP:NATBOX->GW UDP:bbbb->2797 > 3. As for tunnel mode using ESPUDP port, I dont see the > point of transporting private address across to an external > domain. This is essentially moving the NAT function from possibly > multiple private domains to a single external Node. This is very > problematic and shouldnt be used, in my opinion. There's no problem. You can do it with the politically correct DHCP over IPsec or the politically incorrect MODECFG. Works fine either way. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Oct 23 04:06:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01842; Mon, 23 Oct 2000 04:06:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08699 Mon, 23 Oct 2000 06:03:56 -0400 (EDT) Message-Id: <200010231015.GAA12542@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-07.txt Date: Mon, 23 Oct 2000 06:15:48 -0400 Sender: owner-ipsec@lists.tislabs.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 : DHCP Configuration of IPSEC Tunnel Mode in IPv4 Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-07.txt Pages : 14 Date : 20-Oct-00 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via Ipsec from the host's ISP-assigned address to the corporate security gateway. The Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSEC tunnel mode, and describes how the DHCP protocol may be leveraged for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-07.txt Internet-Drafts are also 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-dhcp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-07.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: <20001020112938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001020112938.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Oct 23 08:22:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11470; Mon, 23 Oct 2000 08:22:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09743 Mon, 23 Oct 2000 10:12:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03C27.52B51779" Subject: RE: NAT and IPsec Date: Sun, 22 Oct 2000 05:55:15 -0700 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50E108579@DF-SCRAPPY.platinum.corp.microsoft.com> Thread-Topic: NAT and IPsec Thread-Index: AcA5wD2hkCaK/tKPSUSNveluO94RBwCYTj/g From: "Bernard Aboba" To: "Jari Arkko" , , Cc: , , "William Dixon" X-OriginalArrivalTime: 22 Oct 2000 12:55:16.0197 (UTC) FILETIME=[5319E150:01C03C27] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C03C27.52B51779 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >In terms of requirements, I think we'd be on the wrong path >if we put much effort in getting all IPsec and IKE modes >to work.=20 Certainly, trying to get AH to work is a waste of time.=20 However, if it is possible to get transport mode ESP and IPCOMP to work, I'd argue that it is a win.=20 >approaches like RSIP aren't very fruitful=20 I'd agree. All approaches requiring changing code on the host; if you also require changing router code, then deployment will be of the same order of difficulty as IPv6. To my mind, RSIP is a "short term" solution that can only be deployed in the long term. That makes it a non-starter.=20 =20 >Bernard's draft says in section 7.1 the following... >Is this really the case? As you point out, it's better to send both ESP and=20 ESP-encapsulated proposals at the same time, and see=20 which ones are accepted. I'm going to=20 delete those paragraphs in the next version.=20 >I worry about the denial of service issues for plain >UDP encapsulation.=20 I think that this is worth worrying about. In fact, there are some who believe that it is a show stopper. We should have this discussion up front, so we know what the=20 potential attacks are, and can analyze the proposals to determine whether they are vulnerable. =20 > Does somebody have an idea how long a large NAT's UDP > session storage lasts, typically? Low-end NATs can age sessions out as quickly as 30 seconds to a minute.=20 >have there been incidents to specifically block IKE=20 >and IPsec but let other UDP traffic through [implemented=20 >by a very hostile NAT Some NAT vendors have required "upgrades" before enabling support of various protocols. The goal here seems to be to obtain a fee every time the user attempts to add new host capabilities. This kind of business model leads to products that are intentionally hostile.=20 However, in most cases basic support for TCP and UDP can be assumed.=20 > To what extent do we believe that the use of IPsec > through NAT must be negotiated, and to what extent > it could just be _configured_?=20 I'm not a big fan of manual configuration. People use their devices in many places -- when I'm at home I might use a NAT, but at work, perhaps not. A good solution should detect what situation I'm in and do the right thing. Having to switch settings whenever you move detracts from the mobile experience.=20 > I saw in the minutes of the last NAT WG meeting that > somebody proposed the use of L2TP to tunnel IPsec. To my mind this doesn't provide any advantages over=20 UDP encapsulation, just more overhead.=20 >And doesn't Microsoft have some protocol that tunnels=20 >everything along that? Other than various VPN solutions (PPTP, IPSEC tunnel mode, L2TP/IPSEC), and a sockets remoting capability, I'm not aware=20 of any other tunneling functionality implemented in Windows. =20 ------_=_NextPart_001_01C03C27.52B51779 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: NAT and IPsec >In terms of requirements, I think we'd be on the = wrong path >if we put much effort in getting all IPsec and = IKE modes >to work. Certainly, trying to get AH to work is a waste of = time. However, if it is possible to get transport mode = ESP and IPCOMP to work, I'd argue that it is a win. = >approaches like RSIP aren't very fruitful I'd agree. All approaches requiring changing code on = the host; if you also require changing router code, then = deployment will be of the same order of difficulty as IPv6. To = my mind, RSIP is a "short term" solution that = can only be deployed in the long term. That makes it a = non-starter. >Bernard's draft says in section 7.1 the = following... >Is this really the case? As you point out, it's better to send both ESP and = ESP-encapsulated proposals at the same time, and see = which ones are accepted. I'm going to delete those paragraphs in the next version. >I worry about the denial of service issues for = plain >UDP encapsulation. I think that this is worth worrying about. In fact, = there are some who believe that it is a show stopper. We = should have this discussion up front, so we know what the = potential attacks are, and can analyze the proposals = to determine whether they are vulnerable. > Does somebody have an idea how long a large NAT's = UDP > session storage lasts, typically? Low-end NATs can age sessions out as quickly as = 30 seconds to a minute. >have there been incidents to specifically block = IKE >and IPsec but let other UDP traffic through = [implemented >by a very hostile NAT Some NAT vendors have required "upgrades" = before enabling support of various protocols. The goal here seems to = be to obtain a fee every time the user attempts to add = new host capabilities. This kind of business model leads to products that are intentionally hostile. = However, in most cases basic support for TCP and = UDP can be assumed. > To what extent do we believe that the use of = IPsec > through NAT must be negotiated, and to = what extent > it could just be _configured_? I'm not a big fan of manual configuration. People = use their devices in many places -- when I'm at home = I might use a NAT, but at work, perhaps not. A = good solution should detect what situation I'm in = and do the right thing. Having to switch settings = whenever you move detracts from the mobile experience. > I saw in the minutes of the last NAT WG meeting = that > somebody proposed the use of L2TP to tunnel = IPsec. To my mind this doesn't provide any advantages over = UDP encapsulation, just more overhead. >And doesn't Microsoft have some protocol that = tunnels >everything along that? Other than various VPN solutions (PPTP, IPSEC tunnel = mode, L2TP/IPSEC), and a sockets remoting capability, I'm = not aware of any other tunneling functionality implemented in = Windows. ------_=_NextPart_001_01C03C27.52B51779-- From owner-ipsec@lists.tislabs.com Mon Oct 23 08:22:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11468; Mon, 23 Oct 2000 08:22:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09668 Mon, 23 Oct 2000 09:55:46 -0400 (EDT) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Sat, 21 Oct 2000 02:26:02 +0300 (EET DST) From: Helger Lipmaa To: Steve Bellovin cc: ipsec@lists.tislabs.com Subject: Re: speed of HMAC vs. Rijndael-CBCMAC? In-Reply-To: <20001020144424.B898935DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 20 Oct 2000, Steve Bellovin wrote: > Has anyone done any measurements on the relative speeds of a CBC-MAC > using Rijndael (AES) vs. HMAC-MD5 or HMAC-SHA1? Rijndael is very fast, > and we may be able to eliminate some code in our implementations. CBC-MAC-RIJNDAEL (128-bit block&key), using my own highly optimized Rijndael code + *not-at-all* optimized CBCMAC wrapper runs at 234 Mbit/s on a 500 MHz Pentium III, on long inputs. Since Rijndael code by itself runs at 275 Mbit/s, my guess is that *highly-optimized* CBCMAC-RIJNDAEL would run at something like >=265 Mbit/s. For comparison, other AES candidates with the same wrapper: CBC-MAC-MARS ~179 Mbit/s CBC-MAC-RC6 ~237 Mbit/s CBC-MAC-TWOFISH ~199 Mbit/s (CBC-MAC-SERPENT not implemented) Helger From owner-ipsec@lists.tislabs.com Mon Oct 23 10:01:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17970; Mon, 23 Oct 2000 10:01:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10163 Mon, 23 Oct 2000 11:55:05 -0400 (EDT) Message-ID: <20001023160659.17267.qmail@web1406.mail.yahoo.com> Date: Mon, 23 Oct 2000 09:06:59 -0700 (PDT) From: Pyda Srisuresh Subject: Re: NAT and IPsec To: Ari Huttunen Cc: Joern Sierwald , Jari Arkko , bernarda@microsoft.com, mstenber@ssh.com, jarkko@piuha.net, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Ari Huttunen wrote: > Pyda Srisuresh wrote: > > Couple of questions: > > 1. Sanity check: I believe, ESPUDP is a specific instance of a UDP > > application, when the destination/Source is set to 2746 or 2797. > > Is this correct? The ESPUDP port apparently requires an ESP header > > to follow the UDP header, right? Does this ESPUDP also mandate > > that the UDP checksum field be turned off? > > ESP is required since we want to make a secure protocol, and AH will > never work with this. IPCOMP may come after ESP. We mandate the UDP checksum > to be turned off because it's just overhead in this case (same endpoints). > I understand, if you choose to mandate turning off UDP checksum. However, UDP checksum is not an issue with the NAT devices. > > 2. Assuming the above assertion is valid, the transport mode will not > > work with TCP/UDP packets for NAPT for the follwing 2 reasons > > A. Checksum failure, as pointed out in the draft[section 6] > > B. 2 independent hosts in the same private domain could be > > using the same (source port, destination port) pair and the > > external node will have no way to distinguish between the two. > > I still claim it can be made to work. For A the receiver of a packet (either > end) > must first process the ESP header, after which it needs to both do some sort > of NAT and recalculate the TCP/UDP checksums. This is what I was refering to - Exporting NAT function to external devices. RSAP-IP, on the other hand, does this on the RSAP-node. External nodes will not see the private address or the port. > > For B: > Alice sends IP:A->GW UDP:2797->2797, GW receives IP:NATBOX->GW > UDP:aaaa->2797 > Bob sends IP:B->GW UDP:2797->2797, GW receives IP:NATBOX->GW > UDP:bbbb->2797 > > But, the end-to-end TCP/UDP header and payload are encrypted, right? I was refering to these encrypted ports that are decrypted by the peering external device. > > 3. As for tunnel mode using ESPUDP port, I dont see the > > point of transporting private address across to an external > > domain. This is essentially moving the NAT function from possibly > > multiple private domains to a single external Node. This is very > > problematic and shouldnt be used, in my opinion. > > There's no problem. You can do it with the politically correct DHCP over > IPsec or the politically incorrect MODECFG. Works fine either way. The tunnel peer will have to do unique address and port assignments, for each tuple of (Tunnel-encapsulating IP address, tunnel-encapsulating ESPUDP source port, encapsulated-IP address(pvt), encapsulated-port(pvt)). This is not just DHCP. It seems to me, the approach is complex and has scalability problem. Doing RSIP does not export the problem to external devices. > > Ari > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security cheers, suresh ===== __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Oct 23 11:19:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21191; Mon, 23 Oct 2000 11:19:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10418 Mon, 23 Oct 2000 13:13:58 -0400 (EDT) X-Authentication-Warning: nurkka.hel.fi.ssh.com: mstenber set sender to mstenber@ssh.com using -f To: Ari Huttunen Cc: Jari Arkko , bernarda@microsoft.com, jarkko@piuha.net, ipsec@lists.tislabs.com Subject: Re: NAT and IPsec References: <39EEDB92.77497E67@lmf.ericsson.se> <39F02F2A.DCC120B4@lmf.ericsson.se> <39F2218E.5CB747AC@F-Secure.com> From: Markus Stenberg Date: 23 Oct 2000 19:46:59 +0300 In-Reply-To: Ari Huttunen's message of "Sun, 22 Oct 2000 02:06:54 +0300" Message-ID: Lines: 34 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen writes: > > Well, as a side note - it seems that Ethereal barfs equally nicely to IKE > > version approach (which it _should_ handle but apparently doesn't). That > > reminds me, I have to submit my Ethereal patches for this.. (-: > > > > Firewall rules are not _my_ concern - if why are you letting IKE through if > > you do not desire IPsec? > > > > (Excluding some obscure use of AH to make "verifiable but snoopable" Big > > Brother-friendly access somewhere.) > I've been thinking that someone should make a patch to Ethereal that > would enable it to look inside AH or ESP/NULL. That's somewhat hard, but > doable with some innovative guesswork. (Right?) At least 0.8.12 does that already (and I think it has done it for few versions) with AH. I think I have equivalent patch for ESP/null in my version but I haven't submitted much recently (because submissions that do not get 'in' are silently ignored and I despise that type of behavior). > Ari -Markus > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ipsec@lists.tislabs.com Mon Oct 23 11:21:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21245; Mon, 23 Oct 2000 11:21:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10397 Mon, 23 Oct 2000 13:10:58 -0400 (EDT) Message-ID: <39F4666C.37F86697@polito.it> Date: Mon, 23 Oct 2000 18:25:16 +0200 From: Madalina Baltatu X-Mailer: Mozilla 4.72 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Identity Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello. Can anybody indicate to me an IKE document that specifies the identity types that may be used in phase 1 and phase 2 exchanges? Are there any restrictions, or all the ID types defined in RFC2407 can be used in both IKE phases? Thanks. Madalina. From owner-ipsec@lists.tislabs.com Mon Oct 23 11:24:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21304; Mon, 23 Oct 2000 11:24:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10465 Mon, 23 Oct 2000 13:18:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Date: Mon, 23 Oct 2000 10:29:20 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2038CB9B8@fifi.platinum.corp.microsoft.com> Thread-Topic: Safety of pre-shared keys? (Re: Reliable delete notifies) Thread-Index: AcA7vGGj2KZ/9cA5T96BlBKcww5R4QBWdv3w From: "William Dixon" To: "Ari Huttunen" , "Henry Spencer" Cc: "Jan Vilhuber" , "ipsec" X-OriginalArrivalTime: 23 Oct 2000 17:28:32.0446 (UTC) FILETIME=[AA70ADE0:01C03D16] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari, does John Pliam's paper answer your question on "what would it take to fool authentication based on pre-shared keys" ? http://www.ima.umn.edu/~pliam/xauth/ -----Original Message----- From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com] Sent: Saturday, October 21, 2000 5:02 PM To: Henry Spencer Cc: Jan Vilhuber; ipsec Subject: Safety of pre-shared keys? (Re: Reliable delete notifies) Henry Spencer wrote: > > On Mon, 9 Oct 2000, Jan Vilhuber wrote: > > With pure public keys, you need TWO of them. Granted, I can provision every > > box with the same private key, which would make it equivalent to the above > > group-pre-shared key scenarion. But in reality you need two public keys, > > where before you had a single pre-shared key. > > Consider them two halves of the same shared secret. There's no fundamental > difference... Incorrect. With a pre-shared key you have one key that is secret. With public keys, you have two keys, one of which is public, one is secret. I'm quite sure everyone on this list knows this much.. Now, if you have that public key, you CAN give it to some mechanical calculator for cracking. Eventually that machine will produce a result, and if it's based on quantum computing you might actually get a result before the Big Crash (if any). Out of curiosity, what would one need to fool authentication based on pre-shared keys, assuming only knowledge of things-on-the-wire? Would the method learn the value of the pre-shared key or something else? (Would it be safe against quantum computers?) Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Oct 23 12:58:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22802; Mon, 23 Oct 2000 12:58:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10635 Mon, 23 Oct 2000 14:17:06 -0400 (EDT) Message-Id: <3.0.5.32.20001023195728.03471eb0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Oct 2000 19:57:28 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Identity Type 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 lists.tislabs.com id NAA10508 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, here we go again. Others have seen this before, but the email is not that long, really. It should be noted that these are my personal opinions, not a standard. typedef enum { /* IPSEC_ID_RESERVED = 0, */ IPSEC_ID_IPV4_ADDR = 1, IPSEC_ID_FQDN = 2, IPSEC_ID_USER_FQDN = 3, IPSEC_ID_IPV4_ADDR_SUBNET = 4, IPSEC_ID_IPV6_ADDR = 5, IPSEC_ID_IPV6_ADDR_SUBNET = 6, IPSEC_ID_IPV4_ADDR_RANGE = 7, IPSEC_ID_IPV6_ADDR_RANGE = 8, IPSEC_ID_DER_ASN1_DN = 9, IPSEC_ID_DER_ASN1_GN = 10, IPSEC_ID_KEY_ID = 11 } IkeIpsecIdentificationType; PHASE 1 using preshared keys ============================ The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and KEY_ID are recommended in a phase 1 exchange using preshared keys. In agressive mode, the values can be used for an immediate policy lookup. In main mode, the responder must retrieve the secret from the spd before it receives the ID, thus only IPV4_ADDR is useful in main mode. Is the responder has a "group" policy to allow several hosts with volatile IP addresses to connect, the use of aggressive mode and ID types USER_FQDN and KEY_ID is recommended. DER_ASN1_DN and DER_ASN1_GN are meaningful IDs as well, if an implementation chooses to store policy data indexed by these IDs. Address ranges and subnets are not allowed in Phase 1. An IKE implementation MUST at least implement IPV4_ADDR. However, USER_FQDN is a very useful ID because end users are able to understand and remember them. PHASE 1 using pk signatures =========================== The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and DER_ASN1_DN are recommended in a phase 1 exchange using signatures. In agressive mode, the values can be used for an immediate policy lookup. In main mode, only the initiator's IP address is available for the initial policy lookup of the responder. Therefore, the policy must contain (IP address, ID) or (IP address range, ID range) pairs. After receiving the 5th packet of MM, the responder has to do a second policy check. The responder must reject a MM where the IDV4_ADDR ID and the IP address does not match. Is the responder has a "group" policy to allow several hosts with volatile IP addresses to connect, the use of aggressive mode and ID types USER_FQDN and DER_ASN1_DN is recommended. It should be noted that these IDs, especially DER_ASN1_DN may contain valuable information which is not suitable to be transmitted in cleartext. In this case, I recommend public key encrytion. The alternative is having one policy entry (0.0.0.0/0, (list of all IDs)). The ID must show up in the certificate! E.g., if the ID is USER_FQDN, the subjectAltName must contain an email address. DER_ASN1_GN is may be used as an alternative to IPV4_ADDR, IPV6_ADDR, FQDN and USER_FQDN. The subjectAltNames in certificates are encoded as general names, so DER_ASN1_GN is a generic pointer to a subjectAltName. One could even argue that USER_FQDN is not a valid ID and that email addresses must be encoded using DER_ASN1_GN. I don't think so. Address ranges and subnets are not allowed in Phase 1. IPSEC_ID_KEY_ID is not useful. An IKE implementation MUST at least implement IPV4_ADDR and DER_ASN1_DN. PHASE 1 using pk encryption =========================== Same as signatures, but the ID is safe in agressive mode. Quick Mode ========== QM IDs act as selectors for packets. src and dst addresses of IP packets transmitted through the SA must match the negotiated IDs. While it is possible to not send IDs in QM, it is not recommended. IPV4_ADDR, IPV4_ADDR_SUBNET, IPV4_ADDR_RANGE, IPV6_ADDR, IPV6_ADDR_SUBNET, IPV6_ADDR_RANGE may be used in QM. IPv4 and IPv6 may not be mixed. ADDR, RANGE and SUBNET may be mixed. Jörn Sierwald From owner-ipsec@lists.tislabs.com Mon Oct 23 13:54:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23884; Mon, 23 Oct 2000 13:54:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10891 Mon, 23 Oct 2000 15:51:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <766EFCAA12CB514CAC64D8C440F5A50E108579@DF-SCRAPPY.platinum.corp.microsoft .com> References: <766EFCAA12CB514CAC64D8C440F5A50E108579@DF-SCRAPPY.platinum.corp.microsoft .com> Date: Mon, 23 Oct 2000 16:01:53 -0400 To: "Bernard Aboba" From: Stephen Kent Subject: RE: NAT and IPsec Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bernard, You win the prize for the ugliest MIME-formatted message I have ever received! (No comment on the content.) Was there some good reason to send a multi-part message for this exchange? Steve From owner-ipsec@lists.tislabs.com Tue Oct 24 03:25:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24157; Tue, 24 Oct 2000 03:25:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12986 Tue, 24 Oct 2000 04:44:21 -0400 (EDT) Message-ID: <39F54F09.E2355507@F-Secure.com> Date: Tue, 24 Oct 2000 11:57:45 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: William Dixon CC: Henry Spencer , Jan Vilhuber , ipsec Subject: Re: Safety of pre-shared keys? (Re: Reliable delete notifies) References: <6A05D00595BE644E9F435BE5947423F2038CB9B8@fifi.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, I think it helps. I really didn't have sufficient time to read it, but here's how I understood it: Aggressive mode is vulnerable to off-line attacks against the pre-shared key because HASH_I contains enough information about it, and it's transmitted unencrypted. Main mode has no such vulnerability because HASH_I is transmitted encrypted. So, informed GUESSING would produce the additional results: - Aggressive mode with 3rd msg. encrypted is still vulnerable since the same information can probably be obtained from HASH_R. - Base mode has a similar vulnerability. Ari William Dixon wrote: > > Ari, does John Pliam's paper answer your question on "what would it take > to fool authentication based on pre-shared keys" ? > > http://www.ima.umn.edu/~pliam/xauth/ > > -----Original Message----- > From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com] > Sent: Saturday, October 21, 2000 5:02 PM > To: Henry Spencer > Cc: Jan Vilhuber; ipsec > Subject: Safety of pre-shared keys? (Re: Reliable delete notifies) > > Henry Spencer wrote: > > > > On Mon, 9 Oct 2000, Jan Vilhuber wrote: > > > With pure public keys, you need TWO of them. Granted, I can > provision every > > > box with the same private key, which would make it equivalent to the > above > > > group-pre-shared key scenarion. But in reality you need two public > keys, > > > where before you had a single pre-shared key. > > > > Consider them two halves of the same shared secret. There's no > fundamental > > difference... > > Incorrect. With a pre-shared key you have one key that is secret. With > public > keys, you have two keys, one of which is public, one is secret. I'm > quite > sure everyone on this list knows this much.. > > Now, if you have that public key, you CAN give it to some mechanical > calculator > for cracking. Eventually that machine will produce a result, and if it's > based > on quantum computing you might actually get a result before the Big > Crash (if any). > > Out of curiosity, what would one need to fool authentication based on > pre-shared keys, assuming only knowledge of things-on-the-wire? Would > the > method learn the value of the pre-shared key or something else? (Would > it > be safe against quantum computers?) > > Ari > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Tue Oct 24 08:54:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05756; Tue, 24 Oct 2000 08:54:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14526 Tue, 24 Oct 2000 10:32:30 -0400 (EDT) Date: Tue, 24 Oct 2000 16:42:00 +0200 (IST) From: Hugo Krawczyk To: Ari Huttunen cc: William Dixon , Henry Spencer , Jan Vilhuber , ipsec Subject: Re: Safety of pre-shared keys? (Re: Reliable delete notifies) In-Reply-To: <39F54F09.E2355507@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that the vulnerabilities of pre-shared key that you refer to only apply to the case of a WEAK KEY (such as a password-derived key). It says nothing about the security of the pre-shared mode (main or agressive) when using a strong key. In such a case there is no security problem! (There is always a security problem if you do not choose your keys correctly or you do not know how to manage them securely). In any case preshared mode (main or aggressive) was NOT designed to be used with passwords. A password-based protocol needs a specialized design (either a new mode for IKE or the proposals of ipsra). Hugo On Tue, 24 Oct 2000, Ari Huttunen wrote: > Thanks, I think it helps. I really didn't have sufficient time to read it, > but here's how I understood it: > > Aggressive mode is vulnerable to off-line attacks against the pre-shared > key because HASH_I contains enough information about it, and it's transmitted > unencrypted. Main mode has no such vulnerability because HASH_I is transmitted > encrypted. > > So, informed GUESSING would produce the additional results: > - Aggressive mode with 3rd msg. encrypted is still vulnerable since the same > information can probably be obtained from HASH_R. > - Base mode has a similar vulnerability. > > Ari > > William Dixon wrote: > > > > Ari, does John Pliam's paper answer your question on "what would it take > > to fool authentication based on pre-shared keys" ? > > > > http://www.ima.umn.edu/~pliam/xauth/ > > > > -----Original Message----- > > From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com] > > Sent: Saturday, October 21, 2000 5:02 PM > > To: Henry Spencer > > Cc: Jan Vilhuber; ipsec > > Subject: Safety of pre-shared keys? (Re: Reliable delete notifies) > > > > Henry Spencer wrote: > > > > > > On Mon, 9 Oct 2000, Jan Vilhuber wrote: > > > > With pure public keys, you need TWO of them. Granted, I can > > provision every > > > > box with the same private key, which would make it equivalent to the > > above > > > > group-pre-shared key scenarion. But in reality you need two public > > keys, > > > > where before you had a single pre-shared key. > > > > > > Consider them two halves of the same shared secret. There's no > > fundamental > > > difference... > > > > Incorrect. With a pre-shared key you have one key that is secret. With > > public > > keys, you have two keys, one of which is public, one is secret. I'm > > quite > > sure everyone on this list knows this much.. > > > > Now, if you have that public key, you CAN give it to some mechanical > > calculator > > for cracking. Eventually that machine will produce a result, and if it's > > based > > on quantum computing you might actually get a result before the Big > > Crash (if any). > > > > Out of curiosity, what would one need to fool authentication based on > > pre-shared keys, assuming only knowledge of things-on-the-wire? Would > > the > > method learn the value of the pre-shared key or something else? (Would > > it > > be safe against quantum computers?) > > > > Ari > > > > -- > > Ari Huttunen phone: +358 9 859 900 > > Senior Software Engineer fax : +358 9 8599 0452 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security > From owner-ipsec@lists.tislabs.com Tue Oct 24 08:54:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05767; Tue, 24 Oct 2000 08:54:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14474 Tue, 24 Oct 2000 10:24:53 -0400 (EDT) Date: Tue, 24 Oct 2000 16:34:55 +0200 (IST) From: Hugo Krawczyk To: "David A. McGrew" cc: Steve Bellovin , ipsec@lists.tislabs.com Subject: Re: speed of HMAC vs. Rijndael-CBCMAC? In-Reply-To: <39F091FB.A40D9109@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The delay in publishing the UMAC draft has been my fault. I have finally submitted it. I will send a message about this algorithm when the draft gets actually posted in the internet-drafts directory. While UMAC speed and security are great it certainly does not provide the benefit of code elimination. UMAC requires Rijndael plus non-trivial additional code (see http://www.cs.ucdavis.edu/~rogaway/umac/ where optimized code is provided -- currently using RC6) Hugo On Fri, 20 Oct 2000, David A. McGrew wrote: > Steve, > > Steve Bellovin wrote: > > > > Has anyone done any measurements on the relative speeds of a CBC-MAC > > using Rijndael (AES) vs. HMAC-MD5 or HMAC-SHA1? Rijndael is very fast, > > and we may be able to eliminate some code in our implementations. > > > > --Steve Bellovin > > code elimination would be good. I'd favor the use of UMAC over CBC MAC > though. UMAC is designed to work with AES, is provably secure, and is > staggeringly fast. UMAC is well described at > http://www.cs.ucdavis.edu/~rogaway/umac/. The creators of UMAC intended > to submit a draft on their mechanism, though I don't think that they > have done so yet. > > I guess that you're not at the NIST workshop either - or are you always > online ;-) > > David > From owner-ipsec@lists.tislabs.com Tue Oct 24 10:35:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09000; Tue, 24 Oct 2000 10:35:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14953 Tue, 24 Oct 2000 12:22:13 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854AB6D@hhdata3.cdsemea.baltimore.com> From: Chris Trobridge To: ipsec Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Date: Tue, 24 Oct 2000 17:33:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Isn't the biggest difference that whilst you need to ensure that the peer receives the correct self-signed public key out-of-band (authenticity requirement), if a secret key is used then there is an additional confidentiality requirement. A self-signed certicate also includes an implicit integrity check which is also important. This all means that handling of self-signed certificates is much less onerous than pre-shared secert keys. Chris > Note that the vulnerabilities of pre-shared key that you refer to > only apply to the case of a WEAK KEY (such as a password-derived key). > It says nothing about the security of the pre-shared mode (main > or agressive) when using a strong key. > In such a case there is no security problem! > (There is always a security problem if you do not choose your keys > correctly or you do not know how to manage them securely). > > In any case preshared mode (main or aggressive) was NOT designed to be > used with passwords. A password-based protocol needs a > specialized design > (either a new mode for IKE or the proposals of ipsra). > > Hugo From owner-ipsec@lists.tislabs.com Tue Oct 24 11:24:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10859; Tue, 24 Oct 2000 11:24:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15286 Tue, 24 Oct 2000 13:22:04 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 24 Oct 2000 13:34:41 -0400 Message-Id: <0010241734.AA23710@secpwr.watson.ibm.com> To: ipsec@lists.tislabs.com, CTrobridge@baltimore.com Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: WUh1VZtvyGoZCbmesqRxkA== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Each party still has to protect the secrecy and integrity of its own secret key in the signature mode. I fail to see any big difference in protecting the secret key and the pre-shared key. Pau-Chen > From owner-ipsec@lists.tislabs.com Tue Oct 24 13:08:30 2000 > Message-Id: <1FD60AE4DB6CD2118C420008C74C27B854AB6D@hhdata3.cdsemea.baltimore.com> > From: Chris Trobridge > To: ipsec > Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) > Date: Tue, 24 Oct 2000 17:33:18 +0100 > Mime-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2650.21) > Content-Type: text/plain; charset="iso-8859-1" > Sender: owner-ipsec@lists.tislabs.com > Precedence: bulk > Content-Length: 1095 > Status: RO > > Isn't the biggest difference that whilst you need to ensure that the peer > receives the correct self-signed public key out-of-band (authenticity > requirement), if a secret key is used then there is an additional > confidentiality requirement. > > A self-signed certicate also includes an implicit integrity check which is > also important. > > This all means that handling of self-signed certificates is much less > onerous than pre-shared secert keys. > > Chris > > > Note that the vulnerabilities of pre-shared key that you refer to > > only apply to the case of a WEAK KEY (such as a password-derived key). > > It says nothing about the security of the pre-shared mode (main > > or agressive) when using a strong key. > > In such a case there is no security problem! > > (There is always a security problem if you do not choose your keys > > correctly or you do not know how to manage them securely). > > > > In any case preshared mode (main or aggressive) was NOT designed to be > > used with passwords. A password-based protocol needs a > > specialized design > > (either a new mode for IKE or the proposals of ipsra). > > > > Hugo > From owner-ipsec@lists.tislabs.com Tue Oct 24 11:27:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10902; Tue, 24 Oct 2000 11:27:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15279 Tue, 24 Oct 2000 13:21:41 -0400 (EDT) Date: Tue, 24 Oct 2000 19:33:27 +0200 (IST) From: Hugo Krawczyk To: Chris Trobridge cc: ipsec Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854AB6D@hhdata3.cdsemea.baltimore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What you say is true. It means that with preshared key you have a scalability problem. And this is why public-key cryptography and certificates are so great. I am all for it. Still this does not mean that pre-shared keys (and pre-shared mode) are inherently insecure as some of the msgs to this list seem to imply. Well managed pre-shared keys (and this is only possible in relatively small scale) may be better than wrongly-managed certificates (as in today's SSL reality) Hugo On Tue, 24 Oct 2000, Chris Trobridge wrote: > Isn't the biggest difference that whilst you need to ensure that the peer > receives the correct self-signed public key out-of-band (authenticity > requirement), if a secret key is used then there is an additional > confidentiality requirement. > > A self-signed certicate also includes an implicit integrity check which is > also important. > > This all means that handling of self-signed certificates is much less > onerous than pre-shared secert keys. > > Chris > > > Note that the vulnerabilities of pre-shared key that you refer to > > only apply to the case of a WEAK KEY (such as a password-derived key). > > It says nothing about the security of the pre-shared mode (main > > or agressive) when using a strong key. > > In such a case there is no security problem! > > (There is always a security problem if you do not choose your keys > > correctly or you do not know how to manage them securely). > > > > In any case preshared mode (main or aggressive) was NOT designed to be > > used with passwords. A password-based protocol needs a > > specialized design > > (either a new mode for IKE or the proposals of ipsra). > > > > Hugo > From owner-ipsec@lists.tislabs.com Tue Oct 24 13:02:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13232; Tue, 24 Oct 2000 13:02:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15643 Tue, 24 Oct 2000 14:51:33 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Chris Trobridge'" , "'ipsec'" Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Date: Tue, 24 Oct 2000 14:53:45 -0400 Message-Id: <000b01c03deb$bd0c9060$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854AB6D@hhdata3.cdsemea.baltimore.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The authenticity requirement is always equally or more difficult to satisfy than the confidentiality requirement so the point is moot. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Chris Trobridge > Sent: Tuesday, October 24, 2000 12:33 PM > To: ipsec > Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) > > > Isn't the biggest difference that whilst you need to ensure > that the peer > receives the correct self-signed public key out-of-band (authenticity > requirement), if a secret key is used then there is an additional > confidentiality requirement. > > A self-signed certicate also includes an implicit integrity > check which is > also important. > > This all means that handling of self-signed certificates is much less > onerous than pre-shared secert keys. > > Chris > > > Note that the vulnerabilities of pre-shared key that you refer to > > only apply to the case of a WEAK KEY (such as a > password-derived key). > > It says nothing about the security of the pre-shared mode (main > > or agressive) when using a strong key. > > In such a case there is no security problem! > > (There is always a security problem if you do not choose your keys > > correctly or you do not know how to manage them securely). > > > > In any case preshared mode (main or aggressive) was NOT > designed to be > > used with passwords. A password-based protocol needs a > > specialized design > > (either a new mode for IKE or the proposals of ipsra). > > > > Hugo > From owner-ipsec@lists.tislabs.com Wed Oct 25 03:33:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00870; Wed, 25 Oct 2000 03:33:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18162 Wed, 25 Oct 2000 05:12:13 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854AB77@hhdata3.cdsemea.baltimore.com> From: Chris Trobridge To: andrew.krywaniuk@alcatel.com, "'ipsec'" Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Date: Wed, 25 Oct 2000 10:24:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not convinced of this at all. There are many ways to verify that the correct key has been transferred - an attacker would have to defeat them all. Confidentiality is muh more fragile. Chris > The authenticity requirement is always equally or more > difficult to satisfy > than the confidentiality requirement so the point is moot. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Chris Trobridge > > Sent: Tuesday, October 24, 2000 12:33 PM > > To: ipsec > > Subject: RE: Safety of pre-shared keys? (Re: Reliable > delete notifies) > > > > > > Isn't the biggest difference that whilst you need to ensure > > that the peer > > receives the correct self-signed public key out-of-band > (authenticity > > requirement), if a secret key is used then there is an additional > > confidentiality requirement. > > > > A self-signed certicate also includes an implicit integrity > > check which is > > also important. > > > > This all means that handling of self-signed certificates is > much less > > onerous than pre-shared secert keys. > > > > Chris > > > > > Note that the vulnerabilities of pre-shared key that you refer to > > > only apply to the case of a WEAK KEY (such as a > > password-derived key). > > > It says nothing about the security of the pre-shared mode (main > > > or agressive) when using a strong key. > > > In such a case there is no security problem! > > > (There is always a security problem if you do not choose your keys > > > correctly or you do not know how to manage them securely). > > > > > > In any case preshared mode (main or aggressive) was NOT > > designed to be > > > used with passwords. A password-based protocol needs a > > > specialized design > > > (either a new mode for IKE or the proposals of ipsra). > > > > > > Hugo > > > From owner-ipsec@lists.tislabs.com Wed Oct 25 03:33:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00882; Wed, 25 Oct 2000 03:33:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18146 Wed, 25 Oct 2000 05:07:39 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854AB76@hhdata3.cdsemea.baltimore.com> From: Chris Trobridge To: pau@watson.ibm.com, ipsec@lists.tislabs.com, Chris Trobridge Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Date: Wed, 25 Oct 2000 10:19:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With a private key, the private key can be generated, used and stored entirely within a tamper proof enclosure. The pre-shared secret key can be treated likewise but must also be exported to peers. Thus the exposure of the secret key is greater than the private key. It can't be any less. Depending on how secure the transport mechanism is, it could be the weakest point in the system. Chris > Each party still has to protect the secrecy and integrity of > its own secret key in the signature mode. > > I fail to see any big difference in protecting the secret key > and the pre-shared key. > > Pau-Chen > > > From owner-ipsec@lists.tislabs.com Tue Oct 24 13:08:30 2000 > > Message-Id: > <1FD60AE4DB6CD2118C420008C74C27B854AB6D@hhdata3.cdsemea.baltimore.com> > > From: Chris Trobridge > > To: ipsec > > Subject: RE: Safety of pre-shared keys? (Re: Reliable > delete notifies) > > Date: Tue, 24 Oct 2000 17:33:18 +0100 > > Mime-Version: 1.0 > > X-Mailer: Internet Mail Service (5.5.2650.21) > > Content-Type: text/plain; > charset="iso-8859-1" > > Sender: owner-ipsec@lists.tislabs.com > > Precedence: bulk > > Content-Length: 1095 > > Status: RO > > > > Isn't the biggest difference that whilst you need to ensure > that the peer > > receives the correct self-signed public key out-of-band > (authenticity > > requirement), if a secret key is used then there is an additional > > confidentiality requirement. > > > > A self-signed certicate also includes an implicit integrity > check which is > > also important. > > > > This all means that handling of self-signed certificates is > much less > > onerous than pre-shared secert keys. > > > > Chris > > > > > Note that the vulnerabilities of pre-shared key that you refer to > > > only apply to the case of a WEAK KEY (such as a > password-derived key). > > > It says nothing about the security of the pre-shared mode (main > > > or agressive) when using a strong key. > > > In such a case there is no security problem! > > > (There is always a security problem if you do not choose your keys > > > correctly or you do not know how to manage them securely). > > > > > > In any case preshared mode (main or aggressive) was NOT > designed to be > > > used with passwords. A password-based protocol needs a > > > specialized design > > > (either a new mode for IKE or the proposals of ipsra). > > > > > > Hugo > > > From owner-ipsec@lists.tislabs.com Wed Oct 25 04:02:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01298; Wed, 25 Oct 2000 04:02:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18372 Wed, 25 Oct 2000 06:04:07 -0400 (EDT) Message-Id: <200010251016.GAA23219@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com, saag@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-krovetz-umac-01.txt Date: Wed, 25 Oct 2000 06:16:02 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : UMAC: Message Authentication Code using Universal Hashing Author(s) : T. Krovetz et al. Filename : draft-krovetz-umac-01.txt Pages : 39 Date : 24-Oct-00 This specification describes how to generate an authentication tag (also called a 'MAC') using the UMAC message authentication code. UMAC is designed to be very fast to compute, in software, on contemporary processors. Measured speeds are as low as 1.0 cycles per byte. The heart of UMAC is a universal hash function, UHASH, which relies on addition and multiplication of 16-bit, 32-bit, or 64-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, UHASH is applied to the message and key to produce a short, fixed-length, hash value, and this hash value is then XOR-ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis and its only 'cryptographic' use is a block cipher, AES, to generate the pseudorandom pads and internal key material. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krovetz-umac-01.txt Internet-Drafts are also 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-krovetz-umac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-krovetz-umac-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: <20001024110923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-krovetz-umac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-krovetz-umac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001024110923.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 25 04:58:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02189; Wed, 25 Oct 2000 04:58:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18590 Wed, 25 Oct 2000 06:53:45 -0400 (EDT) Date: Wed, 25 Oct 2000 13:05:54 +0200 (Israel Standard Time) From: Arne Ansper To: Andrew Krywaniuk cc: "'Chris Trobridge'" , "'ipsec'" Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) In-Reply-To: <000b01c03deb$bd0c9060$d23e788a@andrewk3.ca.newbridge.com> Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The authenticity requirement is always equally or more difficult to satisfy > than the confidentiality requirement so the point is moot. I don't agree. One must have a write access to some data in order to break its authenticity. In order to break it's confidentiality read access is sufficient. Read access is usually much easier to gain than write access. Examples: If one can snoop the network but not inject new packets, then he cannot break authenticity but can break confidentiality. If one can read swap file or /dev/kmem or backup tape then one can break the confidentiality of running system. On the other hand one needs a write access to running system to break the authenticity. The whole point of the Diffie-Hellman key exchange is to create confidential communication channel using authentic communication channel. Arne Ansper From owner-ipsec@lists.tislabs.com Wed Oct 25 12:03:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14907; Wed, 25 Oct 2000 12:03:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20143 Wed, 25 Oct 2000 13:26:34 -0400 (EDT) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Arne Ansper'" , "Andrew Krywaniuk" Cc: "'Chris Trobridge'" , "'ipsec'" Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Date: Wed, 25 Oct 2000 13:29:41 -0400 Message-Id: <001d01c03ea9$298b15f0$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Arne: > If one can snoop the network but not inject new packets, then > he cannot > break authenticity but can break confidentiality. Unless of course the packets are encrypted. My previous statement doesn't apply unless you try... If the channel is somehow magically protected against spoofing, but not against snooping then an unauthenticated Diffie-Hellman is sufficient to generate a secure encryption key. My whole point here was that if you already have an authenticated channel then setting up encryption is trivial. Therefore, the confidentiality requirement is equally or less difficult to satisfy than the authentication requirement. Chris: > There are many ways to verify that the correct key has been > transferred - an > attacker would have to defeat them all. Confidentiality is muh more > fragile. Only if you assume that multiple weak authentications can add up to a strong authentication. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Oct 26 08:24:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26352; Thu, 26 Oct 2000 08:24:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23405 Thu, 26 Oct 2000 09:48:38 -0400 (EDT) Message-ID: <39F7970C.9A415894@sookmyung.ac.kr> Date: Thu, 26 Oct 2000 11:29:32 +0900 From: Gwangsoo Rhee X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Q] IPSEC Newbie Question on ISAKMP/Oakley Resolution document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2412 makes many references to ISAKMP/Oakley Resolution document. Could anyone tell me which document it is, please? Many thanks. -- --------------------------------------- Gwangsoo Rhee tel: +82-2-710-9429 fax: 710-9296 HP: 011-9691-9541 --------------------------------------- From owner-ipsec@lists.tislabs.com Thu Oct 26 09:47:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05967; Thu, 26 Oct 2000 09:47:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23796 Thu, 26 Oct 2000 11:41:35 -0400 (EDT) Date: Thu, 26 Oct 2000 17:53:34 +0200 (IST) From: Hugo Krawczyk To: ipsec list , TLS list , saag@lists.tislabs.com Subject: Re: I-D ACTION:draft-krovetz-umac-01.txt In-Reply-To: <200010251016.GAA23219@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As recently announced, the draft draft-krovetz-umac-01.txt is available from the Internet-Drafts directory. This document contains a full specification of the "UMAC" Message Authentication Code (i.e a function that provides data integrity verification for entities that share a key). This is the result of a three-year project involving several researchers. A paper describing the mathematical foundations of the algorithm was published more than a year ago in CRYPTO '99 [1]. UMAC was designed to provide strong authenticity guarantees while being flexible, provably secure, and **as fast as possible** on modern (and emerging) processors. Experiments show that UMAC achieves software speeds that are many times the speed of HMAC-SHA1. A quite unique feature of UMAC is that it lets you easily trade performance and security: from weak authentication against Denial of Service at GigaByte/second to the strongest authentication for the real paranoids at 100's of MegaBytes/second. For the most speed-demanding applications, as they emerge, I believe that UMAC provides a solution that is superior to current algorithms based on cryptographic hash functions (e.g. HMAC) or block ciphers (e.g. CBC-MAC). See the the UMAC homepage, http://www.cs.ucdavis.edu/~rogaway/umac, for additional information, including some performance details. Hugo PS: A word about UMAC's security. UMAC's security analysis is based on two factors: 1) The 20-year old methodology (due to Carter and Wegman) for building MAC functions on the basis of universal hashing. 2) The availability of a strong cipher (e.g. AES). The result of this analysis is that the only way that the proven security bounds for UMAC could fail is by breaking the underlying cipher (say Rijndael). As long as this cipher is unbroken so is UMAC. In this sense, UMAC does not need to be subject to cryptanalytical scrutiny before it can be used; you just need to believe that the underlying block cipher is secure. (See more information in [1] and in the draft's Security Considerations) [1] J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway. "UMAC: Fast and secure message authentication". Advances in Cryptology - CRYPTO '99. Lecture Notes in Computer Science, vol. 1666, Springer-Verlag, 1999, pp. 216-233. From owner-ipsec@lists.tislabs.com Sat Oct 28 05:30:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10685; Sat, 28 Oct 2000 05:30:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA00625 Sat, 28 Oct 2000 06:47:46 -0400 (EDT) Message-Id: <200010281059.MAA26617@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joern Sierwald cc: ipsec@lists.tislabs.com Subject: Re: Identity Type In-reply-to: Your message of Mon, 23 Oct 2000 19:57:28 +0200. <3.0.5.32.20001023195728.03471eb0@smtp.datafellows.com> Date: Sat, 28 Oct 2000 12:59:12 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: OK, here we go again. Others have seen this before, but the email is not that long, really. => as this question is a major source of interoperability problems I really believe someone (you?) should publish this kind of stuff as an I-D ASAP and try to get this as an RFC (informational?) at the next IETF meeting. It should be noted that these are my personal opinions, not a standard. => the son-of-ike is supposed to fix this but a short document can be available (ie. published as an RFC) very soon. Is the responder has a "group" policy to allow several hosts with volatile IP addresses to connect, the use of aggressive mode and ID types USER_FQDN and KEY_ID is recommended. => USER_FQDN has the same format than a NAI (RFC 2486) then it is my preferate today even if we should not encourage to confuse user authentication and IKE/device authentication. However, USER_FQDN is a very useful ID because end users are able to understand and remember them. => this is another argument in favor of USER_FQDN... One could even argue that USER_FQDN is not a valid ID and that email addresses must be encoded using DER_ASN1_GN. I don't think so. => I agree. Quick Mode ========== QM IDs act as selectors for packets. src and dst addresses of IP packets transmitted through the SA must match the negotiated IDs. While it is possible to not send IDs in QM, it is not recommended. => do you mean it is not recommended to send or to not send? IPV4_ADDR, IPV4_ADDR_SUBNET, IPV4_ADDR_RANGE, IPV6_ADDR, IPV6_ADDR_SUBNET, IPV6_ADDR_RANGE may be used in QM. IPv4 and IPv6 may not be mixed. ADDR, RANGE and SUBNET may be mixed. => I'd like to have a rationate for QM IDs explaining for instance that a FQDN is ambiguous/expensive (ie. a resolution of the name to addresses gives an unexpected address or several addresses) or simply not useful (ie. a resolution gives the IP address of phase one). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Oct 30 09:55:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17295; Mon, 30 Oct 2000 09:55:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07191 Mon, 30 Oct 2000 10:53:00 -0500 (EST) X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: dbh@enterasys.com Cc: Ayers@enterasys.com, Mike , "'snmpv3@lists.tislabs.com'" Subject: Re: UTF-8 References: <39F980DB.BDCBEBBD@enterasys.com> Date: 30 Oct 2000 09:30:22 +0100 In-Reply-To: David Harrington's message of "27 Oct 2000 16:22:01 +0200" Message-ID: Lines: 28 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Harrington writes: David> I am working with the chairs of the various working groups to establish David> one UTF8String that can be used throughout the snmp community. If any David> other working groups have defined a utf8string convention, please have David> the chair make me aware of your documents and any special requirements David> for your usage. Grep'ing for `utf.*8' in all MIBs defined in RFCs I found these definitions and usages of definitions. Maybe it helps to complete your list. SNMP-FRAMEWORK-MIB defines SnmpAdminString SNMP-TARGET-MIB defines SnmpTagValue FLOW-METER-MIB defines and uses UTF8OwnerString Job-Monitoring-MIB defines and uses JmUTF8StringTC NETWORK-SERVICES-MIB defines and uses DistinguishedName RMON-MIB defines and uses OwnerString SLAPM-MIB defines and uses SlapmPolicyRuleName SYSAPPL-MIB defines and uses LongUtf8String and Utf8String APPLICATION-MIB imports SYSAPPL-MIB::LongUtf8String DIRECTORY-SERVER-MIB imports NETWORK-SERVICES-MIB::DistinguishedName DSA-MIB imports NETWORK-SERVICES-MIB::DistinguishedName RMON2-MIB imports RMON-MIB::OwnerString SMON-MIB imports RMON-MIB::OwnerString RTP-MIB imports SYSAPPL-MIB::Utf8String TN3270E-MIB imports SYSAPPL-MIB::LongUtf8String WWW-MIB imports SYSAPPL-MIB::LongUtf8String From owner-ipsec@lists.tislabs.com Mon Oct 30 17:31:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26963; Mon, 30 Oct 2000 17:31:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09120 Mon, 30 Oct 2000 19:18:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 30 Oct 2000 19:25:29 -0500 To: Hugo Krawczyk From: Stephen Kent Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) Cc: ipsec Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, In principle pre-shared keys could be strong, but in practice folks tend to use weak keys, e.g., passwords. So, the question before us is whether to remove support for pre-shared keys as a means of trying to save people from themselves. Of course, many vendors are eager to accommodate perceived user requirements, and so some may elect to offer the facility anyway, despite any standards compliance issues. Steve From owner-ipsec@lists.tislabs.com Tue Oct 31 04:41:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA16299; Tue, 31 Oct 2000 04:41:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10811 Tue, 31 Oct 2000 06:24:10 -0500 (EST) Date: Tue, 31 Oct 2000 13:36:05 +0200 (IST) From: Hugo Krawczyk To: Stephen Kent cc: ipsec Subject: RE: Safety of pre-shared keys? (Re: Reliable delete notifies) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 30 Oct 2000, Stephen Kent wrote: > Hugo, > > In principle pre-shared keys could be strong, but in practice folks > tend to use weak keys, e.g., passwords. So, the question before us > is whether to remove support for pre-shared keys as a means of > trying to save people from themselves. Of course, many vendors are > eager to accommodate perceived user requirements, and so some may > elect to offer the facility anyway, despite any standards compliance > issues. > > Steve > I understand this point. However, if you read the messages to this list they seem to imply that using pre-shared keys is weak by design and not just weak by wrong usage. I wanted to clarify that point. Yet, my personal opinion is that this mode should stay. It has important functionality ranging from simple debugging and interoperability tests (and alleviating DoS risks) to usages that provide significant cryptographic strength. Indeed, when well managed, a strong shared key has cryptographic advantages over public key modes. Probably very few know but we designed the pre-shared mode with the property that in order to find the key material generated by this mode you need break BOTH the Diffie-Helman algorithm AND the PRF function. This is in CONTRAST to signature mode where the break of DH is sufficient. Now if you believe that DH will never be broken then the two are equivalent. I like to be on the safe side (especially with the latest winds that call for EC groups with VERY LITTLE safety margin). Another advantage of shared keys (if well managed) is that they will usually tend to have a shorter life span than private keys for which there is a certified public key. The absolute reason in my view to prefer public-key based systems is SCALABILITY. Thus, I have no doubt that PK techniques need to be supported and recommended for general use. But this does not mean that you have to kill pre-shared mode in a well-designed standard. After all if people are so security irresponsible to completely misuse this mode then they can do many other stupid things (e.g., why not use 32-bit DH exponents -- it gives you a convenient and fast DH exchange and your peer cannot even check that you are doing so!) And regarding passwords: if the standard will provide a well-defined well-designed password-based authentication mode I believe people will use that and not pre-shared mode. As we all know such a password-based mode can be added to IKE or decoupled via the proposed ipsra mechanisms. So far it seems to me that people like to talk about these issues and less to take the steps to really advance such a method in the standards process. Hugo