From owner-ipsec@lists.tislabs.com Wed Jan 2 08:23:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02GN5315757; Wed, 2 Jan 2002 08:23:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14496 Wed, 2 Jan 2002 10:17:21 -0500 (EST) Message-Id: <200112312232.fBVMW2606625@marajade.sandelman.ottawa.on.ca> From: "Michael Richardson" To: design@lists.freeswan.org, ipsec@lists.tislabs.com cc: internet-drafts@ietf.org Subject: revision 04 of opportunistic draft available Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 31 Dec 2001 17:32:01 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Revision 04 of the draft can be found at: http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic-04-change.txt Other formats,with and without change bars, older revisions are at: http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/ Summary of changes: 1) new intro from Sandy Harris 2) figures are all now numbered thanks to a new xml2rfc (Thanks Marshall) 3) SG-C had a funny internal IP address. Fixed now. 4) messages 5G2 and 5G3 were missing from the IKE exchange diagram. message 5E3 was incorrectly labelled as being encrypted. 5) some rewording of Aging section: lifespan description and Delete usage. 6) a number of SHOULDs have been made MUSTs. 7) note about KX record added. 8) addiional text about multihomed situation added. 9) warning about not trusted OE tunnels repeated in security considerations. While this draft could be published as-is, a major stylistic change has been requested, which is under progress. I wanted to get the nits out before anything was changed. ] ON HUMILITY: to err is human. To moo, bovine. | 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"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPDDnSoqHRg3pndX9AQEojQP/coiEOmZvfuCwa6IHT6hIyr+xK7WI4inv 6IknjriOYpRJ7wfY9RRUXLMIORxElQ6hDhmP/szZRbWQ4qHqEDnBd/9nYj+lVPKA iLh3ANS94O79iCS6iqpKLectiL0FcKF3CxyMUYqR6M+lz0SNVehlwR3LmC6ap++A P55OVHFNbPQ= =CUlW -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jan 3 14:42:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03MgR324626; Thu, 3 Jan 2002 14:42:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17379 Thu, 3 Jan 2002 16:21:55 -0500 (EST) From: "Jeremy Rodriguez" To: Subject: S\WAN Date: Thu, 3 Jan 2002 16:35:06 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anyone know of a free Linux S\WAN? I need IPSec and have looked at freeswan.org , but they it is still buggy. Any suggestions? Thanks in Advance, Jeremy From owner-ipsec@lists.tislabs.com Fri Jan 4 14:59:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04Mxf323696; Fri, 4 Jan 2002 14:59:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19455 Fri, 4 Jan 2002 16:34:21 -0500 (EST) Date: Fri, 4 Jan 2002 16:44:36 -0500 From: "Michael H. Warfield" To: Jeremy Rodriguez Cc: ipsec@lists.tislabs.com Subject: Re: S\WAN Message-ID: <20020104164436.A17785@alcove.wittsend.com> Mail-Followup-To: Jeremy Rodriguez , ipsec@lists.tislabs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jan 03, 2002 at 04:35:06PM -0500, Jeremy Rodriguez wrote: > Does anyone know of a free Linux S\WAN? > I need IPSec and have looked at freeswan.org , but they it is still buggy. Yeah, well, Windows XP/NT/2K are all still buggy. Linux is still buggy. Damn near everything is still buggy for some value of "buggy". The 1.94 release of FreeSWAN has a couple of problems that are fixed in the snapshots, but I've been running FreeSWAN in a production environment for over 2 years. Bug for bug, if M$ and put XP out with a cayanga security hole like they did, I would not call FreeSWAN "buggy". Still under development, yes. But pretty solid in my book. > Any suggestions? Yeah, get a handle on the concept of "buggy". > Thanks in Advance, > Jeremy Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Sun Jan 6 18:34:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g072YD308090; Sun, 6 Jan 2002 18:34:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22739 Sun, 6 Jan 2002 20:25:05 -0500 (EST) Message-Id: <200201070124.ADF71964@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 06 Jan 2002 17:33:25 -0800 To: sheila.frankel@nist.gov, skelly@SonicWALL.com, rob.glenn@nist.gov From: Scott Fluhrer Subject: Suggested modification to AES privacy draft Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I have a modification to draft-ietf-ipsec-ciph-aes-cbc-03.txt that I would recommend. The text under consideration (in section 3) currently reads: The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random. Common practice is to use random data for the first IV and the last block of encrypted data from an encryption process as the IV for the next encryption process. My objection is with the last sentence -- with this common practice, an attacker who can select packets to be sent through the SA can verify the plaintext of blocks he did not originate, allowing him to read low entropy messages that he should not have access to. My suggestion for revising the paragraph is: The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random, and MUST be unpredictable. Here are the details of an attack against privacy that is possible if the next IV is the last ciphertext block (or, by extension, if the IV is predictable): - Suppose the attacker (Eve) can send packets through the SA. This attacker may be a legitimate user that is not authorized to read all the traffic that is routed through the SA. - Suppose that the attacker has a line monitor that can read the encrypted packets. - Suppose that Bob (an innocent user) telnets to computer system Alice via the SA, and enters his password. His password is sent to Alice as a series of TCP packets, with each TCP packet holding one character of the password. - Further suppose that Eve knows Bob's TCP stack, and so she can guess everything within the TCP header except the data being transmitted (or at least, that part of the header that is encrypted within the same block). Now, Eve considers an encrypted TCP packet that contains a password character. Let us call the ciphertext block that contains that actual password character C_n, and the ciphertext block immediately previous to that as C_{n-1}. If we call the (unknown) plaintext block that contains the password character P_n, then by how CBC mode works: C_n = E_k( P_n ^ C_{n-1} ) where E_k is the AES encryption of a block using the SA's key, and ^ is xor. Now, Eve guesses the value of the password character. Since she knows the rest of the TCP header, she can form the value Q_n which is the value of the plaintext block (that is, P_n = Q_n) if her guess is value. To validate her guess, she examines the last ciphertext block of the last packet, which will be used as the IV for the next ciphertext block, which we will denote as IV. Then, she forms a packet whose first block is the value: IV ^ C_{n-1} ^ Q_n (Note that she may not be able to transmit that as the first block of an IP packet or transport header -- constraints (such as the IP version number being either 4 or 6) may prevent her from using that. When this happens, she can either attack a different password character, or send an arbitrary packet to reset the IV. That has the effect of causing this attack require Eve send more packets to perform this attack). She sends the packet through the SA, and so the encrypted first block (which she can see) is: D_0 = E_k( IV ^ C_{n-1} ^ Q_n ^ IV ) = E_k( Q_n ^ C_{n-1} ) If her guess is correct, that is, if P_n = Q_n, then C_n = D_0. Because both C_n and D_0 appear in the encrypted text, she can verify whether this occurs, and so she knows her guess of the password character is correct. If there are 96 possibilities for a password character, then by transmitting 96 such packets, Eve can rederive a single password character. Hence, if Bob uses a 10 character password, then only 960 packets are required for Eve to rederive the entire password. I would claim that this attack on privacy is unacceptable, as none of the assumptions that this attack makes are about things that the security of IPSec should rely on. Therefore, I claim that the common practice of reusing the previous ciphertext block (which allows this attack), or otherwise selecting IVs in a predictable manner, should be prohibited. -- scott From owner-ipsec@lists.tislabs.com Sun Jan 6 23:13:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g077Df315186; Sun, 6 Jan 2002 23:13:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23251 Mon, 7 Jan 2002 01:17:24 -0500 (EST) To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-esp-v3-01.txt: extended sequence number 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 From: Jun-ichiro itojun Hagino Date: Mon, 07 Jan 2002 15:24:55 +0900 Message-Id: <20020107062456.EC19B7BA@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've got some question regarding to extended sequence number documented in ESPv3 (01 draft). clarification is appreciated. In section 2.2.1, it is mentioned that higher 32bit of extended sequence number is included in ICV. If this is the case, I guess the use of extended sequence number MUST be negotiated by SA management protocol (instead of "SHOULD" in 01) as the use of extended sequence number changes the wire packet format used for ICV computation. if one end uses extended sequence number and the other doesn't, they will compute ICV differently. packet diagram in section 2 seems a little bit confusing with respect to extended sequence number case (sequence number in the diagram has only 32bits). itojun From owner-ipsec@lists.tislabs.com Mon Jan 7 00:21:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g078Lw325347; Mon, 7 Jan 2002 00:21:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA23360 Mon, 7 Jan 2002 02:36:13 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: Cc: Subject: draft-ietf-ipsec-esp-v3-01.txt: extended sequence number 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 From: "Jun-ichiro itojun Hagino" Date: Mon, 07 Jan 2002 15:24:55 +0900 Message-ID: <20020107062456.EC19B7BA@starfruit.itojun.org> X-OriginalArrivalTime: 07 Jan 2002 07:46:46.0531 (UTC) FILETIME=[75107D30:01C1974F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've got some question regarding to extended sequence number documented in ESPv3 (01 draft). clarification is appreciated. In section 2.2.1, it is mentioned that higher 32bit of extended sequence number is included in ICV. If this is the case, I guess the use of extended sequence number MUST be negotiated by SA management protocol (instead of "SHOULD" in 01) as the use of extended sequence number changes the wire packet format used for ICV computation. if one end uses extended sequence number and the other doesn't, they will compute ICV differently. packet diagram in section 2 seems a little bit confusing with respect to extended sequence number case (sequence number in the diagram has only 32bits). itojun From owner-ipsec@lists.tislabs.com Mon Jan 7 07:39:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Fdh323820; Mon, 7 Jan 2002 07:39:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25020 Mon, 7 Jan 2002 09:35:53 -0500 (EST) To: Scott Fluhrer Cc: sheila.frankel@nist.gov, skelly@SonicWALL.com, rob.glenn@nist.gov, ipsec@lists.tislabs.com Subject: Re: Suggested modification to AES privacy draft References: <200201070124.ADF71964@mira-sjcm-3.cisco.com> From: Derek Atkins Date: 07 Jan 2002 09:46:13 -0500 In-Reply-To: Scott Fluhrer's message of "Sun, 06 Jan 2002 17:33:25 -0800" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fluhrer writes: > - Suppose the attacker (Eve) can send packets through the SA. This > attacker may be a legitimate user that is not authorized to read > all the traffic that is routed through the SA. [snip] > I would claim that this attack on privacy is unacceptable, as > none of the assumptions that this attack makes are about things > that the security of IPSec should rely on. Therefore, I claim > that the common practice of reusing the previous ciphertext > block (which allows this attack), or otherwise selecting IVs > in a predictable manner, should be prohibited. If you make the first assumption, then Eve either: a) lives on the same host as Alice, or b) lives behind the same SG as Alice In the case of a, Eve clearly has root so can get any keying information they want. In the case of b, Eve could just "tcpdump" on the unprotected link between Eve/Alice and the SG, so IPsec isn't going to protect it. I suppose they may be a 'c' in the case of multicast SAs, but those are not a part of the document that you are worrying about. -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 Mon Jan 7 07:49:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Fnw324038; Mon, 7 Jan 2002 07:49:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25221 Mon, 7 Jan 2002 10:12:45 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <20020107062456.EC19B7BA@starfruit.itojun.org> References: <20020107062456.EC19B7BA@starfruit.itojun.org> Date: Mon, 7 Jan 2002 10:17:19 -0500 To: Jun-ichiro itojun Hagino From: Stephen Kent Subject: Re: draft-ietf-ipsec-esp-v3-01.txt: extended sequence number Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk itojun, > I've got some question regarding to extended sequence number documented > in ESPv3 (01 draft). clarification is appreciated. > > In section 2.2.1, it is mentioned that higher 32bit of extended > sequence number is included in ICV. If this is the case, I guess > the use of extended sequence number MUST be negotiated by SA management > protocol (instead of "SHOULD" in 01) as the use of extended sequence > number changes the wire packet format used for ICV computation. > if one end uses extended sequence number and the other doesn't, they > will compute ICV differently. > > packet diagram in section 2 seems a little bit confusing with respect > to extended sequence number case (sequence number in the diagram has > only 32bits). > >itojun You are correct that both ends must know when this feature is used for an SA. We said "SHOULD" vs. "MUST" in case someone wanted to go with manual configuration of this feature, but I would prefer MUST if the WG concurs. Figure 2 shows a bits-on-the-wire format, and so it is appropriate to illustrate a 32-bit sequence number there. Steve From owner-ipsec@lists.tislabs.com Mon Jan 7 07:51:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07FpT324075; Mon, 7 Jan 2002 07:51:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25211 Mon, 7 Jan 2002 10:12:18 -0500 (EST) Date: Mon, 7 Jan 2002 21:05:50 +0530 (IST) From: Sri Siddhartha Kodali To: ipsec@lists.tislabs.com Subject: [ A problem ] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am faced with a different kind of problem.our institute has purchased cisco 7120 and 7140 routers to setup IPSEC tunnels.But the crypto module is not present in the IOS.On doing drastic search we found that Integrated Service Module is not present in slot 5.But we are confused whether we do require ISM for using IPSEC and IKE Cisco has mentioned in one of its manuals that ISM is a hardware encryption module and reduces the load off the router.but we don't find any crypto command to perform software encryption with the router Could some one suggest me about this.The project is on total halt becoz of this Thanking You, Siddharth Kodali siddhu@bits-pilani.ac.in From owner-ipsec@lists.tislabs.com Mon Jan 7 08:58:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Gwe329259; Mon, 7 Jan 2002 08:58:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25353 Mon, 7 Jan 2002 10:55:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Scott Fluhrer" Cc: , , , Subject: Re: Suggested modification to AES privacy draft References: <200201070124.ADF71964@mira-sjcm-3.cisco.com> From: "Derek Atkins" Date: 07 Jan 2002 09:46:13 -0500 In-Reply-To: Scott Fluhrer's message of "Sun, 06 Jan 2002 17:33:25 -0800" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 07 Jan 2002 16:05:18.0593 (UTC) FILETIME=[1A0AEF10:01C19795] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fluhrer writes: > - Suppose the attacker (Eve) can send packets through the SA. This > attacker may be a legitimate user that is not authorized to read > all the traffic that is routed through the SA. [snip] > I would claim that this attack on privacy is unacceptable, as > none of the assumptions that this attack makes are about things > that the security of IPSec should rely on. Therefore, I claim > that the common practice of reusing the previous ciphertext > block (which allows this attack), or otherwise selecting IVs > in a predictable manner, should be prohibited. If you make the first assumption, then Eve either: a) lives on the same host as Alice, or b) lives behind the same SG as Alice In the case of a, Eve clearly has root so can get any keying information they want. In the case of b, Eve could just "tcpdump" on the unprotected link between Eve/Alice and the SG, so IPsec isn't going to protect it. I suppose they may be a 'c' in the case of multicast SAs, but those are not a part of the document that you are worrying about. -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 Mon Jan 7 09:33:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07HXZ300480; Mon, 7 Jan 2002 09:33:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25496 Mon, 7 Jan 2002 11:49:25 -0500 (EST) Message-Id: <200201071648.ADF80112@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 07 Jan 2002 08:57:38 -0800 To: Derek Atkins , Scott Fluhrer From: Scott Fluhrer Subject: Re: Suggested modification to AES privacy draft Cc: sheila.frankel@nist.gov, skelly@SonicWALL.com, rob.glenn@nist.gov, ipsec@lists.tislabs.com In-Reply-To: References: <200201070124.ADF71964@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:46 AM 1/7/02 , Derek Atkins wrote: >Scott Fluhrer writes: > >> - Suppose the attacker (Eve) can send packets through the SA. This >> attacker may be a legitimate user that is not authorized to read >> all the traffic that is routed through the SA. > >[snip] > >> I would claim that this attack on privacy is unacceptable, as >> none of the assumptions that this attack makes are about things >> that the security of IPSec should rely on. Therefore, I claim >> that the common practice of reusing the previous ciphertext >> block (which allows this attack), or otherwise selecting IVs >> in a predictable manner, should be prohibited. > >If you make the first assumption, then Eve either: > a) lives on the same host as Alice, or > b) lives behind the same SG as Alice > >In the case of a, Eve clearly has root so can get any keying >information they want. Why is this the case? I do believe that people without root access can never-the-less transmit packets. > In the case of b, Eve could just "tcpdump" on >the unprotected link between Eve/Alice and the SG, so IPsec isn't >going to protect it. Again, is this true? What if the links have physical security, so Eve can't get access to them? In any case, both of these objections would appear to be "there's something outside of IPSec that happens to protect against the attack". I claim that this is not acceptable -- the security that IPSec provides should only depend on IPSec (and the keying protocol) only -- not on the assumption that everyone that can generate packets can be trusted. > >I suppose they may be a 'c' in the case of multicast SAs, but those >are not a part of the document that you are worrying about. > >-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 Mon Jan 7 09:41:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07HfU300711; Mon, 7 Jan 2002 09:41:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25440 Mon, 7 Jan 2002 11:37:40 -0500 (EST) From: balenson@tislabs.com Date: Mon, 7 Jan 2002 11:39:55 -0500 (EST) Message-Id: <200201071639.g07Gdta29802@raven.gw.tislabs.com> To: ipsec@lists.tislabs.com Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching Sender: owner-ipsec@lists.tislabs.com Precedence: bulk R E G I S T E R N O W ! ! EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002 FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml. 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) hosted by THE INTERNET SOCIETY February 6 - 8, 2002 Catamaran Resort Hotel, San Diego, California NDSS is the premier event for security experts around the world. Come to the 9th Annual NDSS and share in the latest concepts on the Internet security front. Southern California's Catamaran Resort Hotel offers spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny getaway with opportunities to confer with your security counterparts from across the globe. For more information and on line registration go to the NDSS'02 web site: http://www.isoc.org/ndss02. Questions about registration? Contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org. Interested in sponsoring a give-away or meal? Contact Martin Kupres at +1 41 22 807 1444 or send e-mail to sponsorndss@isoc.org. From owner-ipsec@lists.tislabs.com Mon Jan 7 11:14:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07JEm302986; Mon, 7 Jan 2002 11:14:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25756 Mon, 7 Jan 2002 13:26:26 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E02937306@CORPMX14> To: sfluhrer@cisco.com, warlord@mit.edu Cc: sheila.frankel@nist.gov, skelly@SonicWALL.com, rob.glenn@nist.gov, ipsec@lists.tislabs.com Subject: RE: Suggested modification to AES privacy draft Date: Mon, 7 Jan 2002 13:23:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >> - Suppose the attacker (Eve) can send packets through the SA. This > >> attacker may be a legitimate user that is not authorized to read > >> all the traffic that is routed through the SA. > > > >[snip] > > > >> I would claim that this attack on privacy is unacceptable, as > >> none of the assumptions that this attack makes are about things > >> that the security of IPSec should rely on. Therefore, I claim > >> that the common practice of reusing the previous ciphertext > >> block (which allows this attack), or otherwise selecting IVs > >> in a predictable manner, should be prohibited. > > > >If you make the first assumption, then Eve either: > > a) lives on the same host as Alice, or > > b) lives behind the same SG as Alice > > > >In the case of a, Eve clearly has root so can get any keying > >information they want. > Why is this the case? I do believe that people without root access > can never-the-less transmit packets. > > > In the case of b, Eve could just "tcpdump" on > >the unprotected link between Eve/Alice and the SG, so IPsec isn't > >going to protect it. > Again, is this true? What if the links have physical security, so > Eve can't get access to them? > > In any case, both of these objections would appear to be "there's > something outside of IPSec that happens to protect against the > attack". I claim that this is not acceptable -- the security that > IPSec provides should only depend on IPSec (and the keying protocol) > only -- not on the assumption that everyone that can generate > packets can be trusted. The meta-point here is that if Eve can send packets through the SA, there's a good chance that she can also read packets coming through the SA via tools like "tcpdump" ... and obtaining that ability could be significantly easier and more productive than mounting this attack. Asking IPsec to solve this problem is a bit of a stretch - an IPsec gateway is supposed to protect traffic flowing through it from threats originating from the public side of the gateway, but in this scenario, Eve has access to the private side by virtue of being able to send packets through the SA. I would suggest that the wrong tool is being used here; if Alice wants end-to-end security for Bob's password, Alice should be doing something other than using an any-to-any (or sufficiently wildcarded) SA, e.g., - An SA specific to the telnet session based on a host-resident IPsec implementation. - A session-based mechanism like TLS or SSH. In both cases, Eve is unable to send packets through the SA or its equivalent. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Jan 7 11:19:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07JJh303107; Mon, 7 Jan 2002 11:19:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25775 Mon, 7 Jan 2002 13:31:17 -0500 (EST) Date: Mon, 7 Jan 2002 11:41:01 -0700 From: Dave Mitchell To: ipsec@lists.tislabs.com, Sri Siddhartha Kodali Subject: Re: [ A problem ] Message-ID: <20020107114101.A23711@tweek.domain> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from siddhu@bits-pilani.ac.in on Mon, Jan 07, 2002 at 09:05:50PM +0530 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Siddharth, You do not need the ISM in order to use IKE/IPSec. The ISM will just provide hardware based encryption to allow the main proc to do what it is supposed to; route. But, IKE really doesn't slam the processor except during rekeying or high traffic load, so if you only have a small amount of tunnels performance should be okay. You need to grab an export controlled copy of IOS with crypto support in it. Im not sure what the laws are for high grade encryption in India, so get the image that you can use legally. Here's one image you can use that supports 56bit low grade crypto: c7100-is56i-mz.121-9.bin IP IPSEC 56 The crypto images usually have a `z` somewhere within the filename. Here's your guide. http://www.cisco.com/cgi-bin/Software/Iosplanner/Planner-tool/iosplanner.cgi?majorRel=12.1 Hope this helps. -dave On Mon, Jan 07, 2002 at 09:05:50PM +0530, Sri Siddhartha Kodali wrote: > > I am faced with a different kind of problem.our institute has purchased > cisco 7120 and 7140 routers to setup IPSEC tunnels.But the crypto module > is not present in the IOS.On doing drastic search we found that > Integrated Service Module is not present in slot 5.But we are confused > whether we do require ISM for using IPSEC and IKE > > Cisco has mentioned in one of its manuals that ISM is a hardware > encryption module and reduces the load off the router.but we don't > find any crypto command to perform software encryption with the router > Could some one suggest me about this.The project is on total halt becoz > of this > > Thanking You, > > Siddharth Kodali > siddhu@bits-pilani.ac.in > From owner-ipsec@lists.tislabs.com Mon Jan 7 12:32:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07KWm305347; Mon, 7 Jan 2002 12:32:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25921 Mon, 7 Jan 2002 14:40:33 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Suggested modification to AES privacy draft Date: 7 Jan 2002 19:49:04 GMT Organization: University of California, Berkeley Lines: 13 Distribution: isaac Message-ID: References: <200201070124.ADF71964@mira-sjcm-3.cisco.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1010432944 22003 128.32.45.153 (7 Jan 2002 19:49:04 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 7 Jan 2002 19:49:04 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Good catch! I think Scott Fluhrer is 100% correct, and it looks to me like this is a weakness we should be taking very seriously. For purposes of comparison, it looks like the severity of this weakness is close to comparable to the severity of Bellovin's cut-and-paste attacks. Both work only in some scenarios (e.g., a multi-user system using host keying), but unless I'm missing something, both seem to me to be realistic threats and both violate important security goals. I'll note that Bellovin's cut-and-paste attacks were considered to warrant significant changes to the standard to close that weakness; it sounds like it's time to do the same to stop Fluhrer's guessing attack. What will it take to make the suggested changes to the standard? From owner-ipsec@lists.tislabs.com Mon Jan 7 12:37:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07KbY305470; Mon, 7 Jan 2002 12:37:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25927 Mon, 7 Jan 2002 14:42:37 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Suggested modification to AES privacy draft Date: 7 Jan 2002 19:51:11 GMT Organization: University of California, Berkeley Lines: 18 Distribution: isaac Message-ID: References: <200201070124.ADF71964@mira-sjcm-3.cisco.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1010433071 22003 128.32.45.153 (7 Jan 2002 19:51:11 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 7 Jan 2002 19:51:11 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: >Scott Fluhrer writes: >> - Suppose the attacker (Eve) can send packets through the SA. This >> attacker may be a legitimate user that is not authorized to read >> all the traffic that is routed through the SA. [...] > >If you make the first assumption, then Eve either: > a) lives on the same host as Alice, or > b) lives behind the same SG as Alice > >In the case of a, Eve clearly has root so can get any keying >information they want. [...] Uhhh... how so? Your last statement doesn't follow. Consider a multi-user system using host keying, as a simple example. Then if Eve has a (non-root) account on the system, she can easily get data sent through the SA, and Fluhrer's attack looks like it will work. Am I missing something? From owner-ipsec@lists.tislabs.com Mon Jan 7 12:37:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Kbl305502; Mon, 7 Jan 2002 12:37:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25964 Mon, 7 Jan 2002 14:50:53 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Suggested modification to AES privacy draft Date: 7 Jan 2002 19:59:27 GMT Organization: University of California, Berkeley Lines: 36 Distribution: isaac Message-ID: References: <277DD60FB639D511AC0400B0D068B71E02937306@CORPMX14> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1010433567 22003 128.32.45.153 (7 Jan 2002 19:59:27 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 7 Jan 2002 19:59:27 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >The meta-point here is that if Eve can send packets through the SA, >there's a good chance that she can also read packets coming through >the SA via tools like "tcpdump" ... This is not my understanding. My understanding is that, in some scenarios, Eve can eavesdrop on encrypted packets and send traffic over a SA, but not eavesdrop directly on unencrypted packets. A simple example of this is host-keying on a multi-user machine where Eve has an unprivileged account. See Bellovin's paper introducing cut-and-paste attacks. Moreover, it looks to me like this weakness *might* be exploitable even on single-user machines where Eve doesn't have an account. Consider: Many user-level applications act as a server that will relay data sent by the client to a third host. A good example is sendmail. If the victim machine is running a sendmail daemon that acts as an open relay, Eve can connect to port 25 and specify an email with a To: address referring to some third host; the sendmail daemon will then re-transmit this email message to the third host, and if the victim is set up to use an IPSec SA for communications with the third host, this email message will be sent over the SA. Notice that Eve can choose the content of the email message in any way she likes; if she's especially clever, she may even be able to send packets of the form needed for Fluhrer's attack. The point is that here sendmail allows chosen-plaintext attacks, and Fluhrer's attack shows that IPSec does not seem to be secure against chosen-plaintext attacks unless IV's are unpredictable. Of course, sendmail is hardly the only example of an application that will relay messages in a way that might allow chosen-plaintext attacks, so I think it would be prudent to assume that adversaries will have the capability to mount chosen-plaintext attacks on IPSec. Given this, I think we need to fix IPSec and plug the hole. From owner-ipsec@lists.tislabs.com Tue Jan 8 06:52:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08EqJ304462; Tue, 8 Jan 2002 06:52:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27683 Tue, 8 Jan 2002 08:35:10 -0500 (EST) Message-Id: <200201081345.IAA20545@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-04.txt Date: Tue, 08 Jan 2002 08:45:30 -0500 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-04.txt Pages : 7 Date : 07-Jan-02 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, 4096, 6144, and 8192 bit Diffie-Hellman groups. The selection of the primes for theses groups follows the criteria estab- lished by Richard Schroeppel as described in [RFC-2412]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-04.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-04.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: <20020107135052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-modp-groups-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107135052.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jan 8 09:43:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08HhC311023; Tue, 8 Jan 2002 09:43:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28088 Tue, 8 Jan 2002 11:32:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.8520.300125.943921@pkoning.dev.equallogic.com> Date: Tue, 8 Jan 2002 11:41:44 -0500 (EST) From: Paul Koning To: warlord@mit.edu Cc: sfluhrer@cisco.com, sheila.frankel@nist.gov, skelly@SonicWALL.com, rob.glenn@nist.gov, ipsec@lists.tislabs.com Subject: Re: Suggested modification to AES privacy draft References: <200201070124.ADF71964@mira-sjcm-3.cisco.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> Scott Fluhrer writes: >> - Suppose the attacker (Eve) can send packets through the SA. >> This attacker may be a legitimate user that is not authorized to >> read all the traffic that is routed through the SA. Derek> [snip] >> I would claim that this attack on privacy is unacceptable, as none >> of the assumptions that this attack makes are about things that >> the security of IPSec should rely on. Therefore, I claim that the >> common practice of reusing the previous ciphertext block (which >> allows this attack), or otherwise selecting IVs in a predictable >> manner, should be prohibited. Derek> If you make the first assumption, then Eve either: a) lives on Derek> the same host as Alice, or b) lives behind the same SG as Derek> Alice Derek> In the case of a, Eve clearly has root so can get any keying Derek> information they want. In the case of b, Eve could just Derek> "tcpdump" on the unprotected link between Eve/Alice and the Derek> SG, so IPsec isn't going to protect it. You missed a case, and you also overstated (b). The missing case is a SG with more than one LAN coming out of it, where Eve and Alice are on different ports. Second, for (b), most LANs are largely or entirely switched LANs, which means that Eve will be able to see few if any of the plaintext packets from SG to Alice even if Alice and Eve are on the same subnet. paul From owner-ipsec@lists.tislabs.com Tue Jan 8 10:05:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08I5t311816; Tue, 8 Jan 2002 10:05:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28189 Tue, 8 Jan 2002 12:14:24 -0500 (EST) Date: Tue, 8 Jan 2002 12:24:10 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Suggested modification to AES privacy draft In-Reply-To: <15419.8520.300125.943921@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Jan 2002, Paul Koning wrote: > Second, for (b), most LANs are largely or entirely switched LANs... I think that's overstating the case. It may be true that most *new* LANs are largely switched, but there are still a huge number of non-switched LANs in service, especially small ones. Only recently have switch prices fallen to the point that they are interesting even to people without major security or performance concerns. Plain old shared 10Mbit/s Ethernet is good enough to keep an awful lot of people happy. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jan 8 11:38:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08Jbv315374; Tue, 8 Jan 2002 11:37:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28504 Tue, 8 Jan 2002 13:42:52 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: Suggested modification to AES privacy draft Date: Tue, 8 Jan 2002 13:48:27 -0500 Message-ID: <003201c19875$1013e760$1e72788a@andrewk3.ca.alcatel.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: <15419.8520.300125.943921@pkoning.dev.equallogic.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I should point out that this relates to an earlier discussion on this list from August of last year, which is whether it is better to have one SA between two gateways or whether it is better to have separate SAs for each flow. Scott didn't mention his attack back then... maybe he didn't notice it until recently. Several people commented that it better to have a single SA because it thwarts traffic analysis. I pointed out that the only reason I could think of to use multiple SAs was to avoid adaptive chosen plaintext attacks. A couple of people replied that ciphers which are not resistant to these attacks shoudn't be used with IPsec. But Scott's attack shows that it is not enough for the cipher to be resistant to adaptive chosen plaintext attacks. The protocol itself also has to be made resistant to these attacks. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning > Sent: Tuesday, January 08, 2002 11:42 AM > To: warlord@mit.edu > Cc: sfluhrer@cisco.com; sheila.frankel@nist.gov; skelly@SonicWALL.com; > rob.glenn@nist.gov; ipsec@lists.tislabs.com > Subject: Re: Suggested modification to AES privacy draft > > > >>>>> "Derek" == Derek Atkins writes: > > Derek> Scott Fluhrer writes: > >> - Suppose the attacker (Eve) can send packets through the SA. > >> This attacker may be a legitimate user that is not authorized to > >> read all the traffic that is routed through the SA. > > Derek> [snip] > > >> I would claim that this attack on privacy is unacceptable, as none > >> of the assumptions that this attack makes are about things that > >> the security of IPSec should rely on. Therefore, I claim that the > >> common practice of reusing the previous ciphertext block (which > >> allows this attack), or otherwise selecting IVs in a predictable > >> manner, should be prohibited. > > Derek> If you make the first assumption, then Eve either: a) lives on > Derek> the same host as Alice, or b) lives behind the same SG as > Derek> Alice > > Derek> In the case of a, Eve clearly has root so can get any keying > Derek> information they want. In the case of b, Eve could just > Derek> "tcpdump" on the unprotected link between Eve/Alice and the > Derek> SG, so IPsec isn't going to protect it. > > You missed a case, and you also overstated (b). > > The missing case is a SG with more than one LAN coming out of it, > where Eve and Alice are on different ports. > > Second, for (b), most LANs are largely or entirely switched LANs, > which means that Eve will be able to see few if any of the plaintext > packets from SG to Alice even if Alice and Eve are on the same > subnet. > > paul > > From owner-ipsec@lists.tislabs.com Tue Jan 8 14:34:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08MYn322065; Tue, 8 Jan 2002 14:34:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28998 Tue, 8 Jan 2002 16:52:30 -0500 (EST) Date: Tue, 8 Jan 2002 14:52:42 -0700 From: Shane Amante To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-00.txt Message-ID: <20020108145242.A1010@nike.amante.org> Mail-Followup-To: Tero Kivinen , ipsec@lists.tislabs.com References: <20011227232031.A934@nike.amante.org> <15406.55898.329047.676214@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15406.55898.329047.676214@ryijy.hel.fi.ssh.com>; from kivinen@ssh.fi on Sun, Dec 30, 2001 at 11:11:54AM +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, Thanks for the reply to some of my points. Please see below. On Sun, Dec 30, 2001 at 11:11:54AM +0200, Tero Kivinen wrote: > shane@amante.org (Shane Amante) writes: > > 2.6 Cookies > > My observation is that Paragraph 6 ("It may be convenient for the > > IKE-SA identifier ...") seems to be adding more complexity, rather > > than promoting the stated goal of reducing it. Is it too onerous to > > get rid of the feature described in Paragraph 6? > > Actually the feature that allows the responder to change the cookie > also fixes one denial of service attack for the active attacker, which > can listen all packets, and can send packets, but cannot remove > packets in transit. [snip] Very clever. It would be useful for the authors to include your above paragraph in the spec, and a brief description of the attack(s) you outlined, in order to elaborate on "why" the cookie changing feature, in Paragraph 6, provides more value beyond just "convenience". > > 7.7 Certificate Request Payload > > > > Last sentence in this section: "If no certificates exist then no > > further processing is performed-- this is not an error condition of > > the protocol." I recommend that this be considered an error in > > IKEv2, otherwise how is the sender of the CERTREQ going to know > > what was the specific problem with it's request? I recommend the > > following language: > > If no certificates exist, no further processing is performed. A > > NOTIFY MUST be sent to the sender of the CERTREQ informing them of > > this fact using an appropriate error code, (defined below in the > > "error codes" section of IKEv2 memo). > > I hope that you mean that the negotiation still continues as normally, > we just include that notification payload to the reply packet, but do > not consider it as an error condition of the protocol. I think it must > be warning condition only not error condition. OK. I was just trying to point out that a notify MUST be sent by the Responder to let the Initiator know what was wrong with the CERTREQ. [snip] > > 7.10.1 Notify Message Types > > > > Is it recommended that multiple NOTIFY payloads be packed into a > > single Informational exchange? Or, should multiple NOTIFY payloads be > > put in their own, separate IKE messages? > > > > Here are a few more suggestions, which are probably going to be quite > > controversial since they go against the grain of re-using as much > > of IKEv1 as possible: > > I think we should use the format described in the > draft-ietf-ipsec-notifymsg-04.txt (which seems to have expired). I can't find this in the IETF's internet-draft archive, do you or someone else have a pointer or a copy that you could send to me? -shane From owner-ipsec@lists.tislabs.com Tue Jan 8 14:38:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08Mco322191; Tue, 8 Jan 2002 14:38:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28978 Tue, 8 Jan 2002 16:39:36 -0500 (EST) Date: Tue, 8 Jan 2002 13:49:25 -0800 (PST) From: Jan Vilhuber To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: Suggested modification to AES privacy draft In-Reply-To: <003201c19875$1013e760$1e72788a@andrewk3.ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Jan 2002, Andrew Krywaniuk wrote: > I should point out that this relates to an earlier discussion on this list > from August of last year, which is whether it is better to have one SA > between two gateways or whether it is better to have separate SAs for each > flow. Scott didn't mention his attack back then... maybe he didn't notice it > until recently. > > Several people commented that it better to have a single SA because it > thwarts traffic analysis. I pointed out that the only reason I could think > of to use multiple SAs was to avoid adaptive chosen plaintext > attacks. Ultimately, I think that's a pointless discussion: Different people (read: customers from my point of view) will do it differently. The protocol should not dictate how you chose to design your network and policies. jan > A > couple of people replied that ciphers which are not resistant to these > attacks shoudn't be used with IPsec. But Scott's attack shows that it is not > enough for the cipher to be resistant to adaptive chosen plaintext attacks. > The protocol itself also has to be made resistant to these attacks. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning > > Sent: Tuesday, January 08, 2002 11:42 AM > > To: warlord@mit.edu > > Cc: sfluhrer@cisco.com; sheila.frankel@nist.gov; skelly@SonicWALL.com; > > rob.glenn@nist.gov; ipsec@lists.tislabs.com > > Subject: Re: Suggested modification to AES privacy draft > > > > > > >>>>> "Derek" == Derek Atkins writes: > > > > Derek> Scott Fluhrer writes: > > >> - Suppose the attacker (Eve) can send packets through the SA. > > >> This attacker may be a legitimate user that is not authorized to > > >> read all the traffic that is routed through the SA. > > > > Derek> [snip] > > > > >> I would claim that this attack on privacy is unacceptable, as none > > >> of the assumptions that this attack makes are about things that > > >> the security of IPSec should rely on. Therefore, I claim that the > > >> common practice of reusing the previous ciphertext block (which > > >> allows this attack), or otherwise selecting IVs in a predictable > > >> manner, should be prohibited. > > > > Derek> If you make the first assumption, then Eve either: a) lives on > > Derek> the same host as Alice, or b) lives behind the same SG as > > Derek> Alice > > > > Derek> In the case of a, Eve clearly has root so can get any keying > > Derek> information they want. In the case of b, Eve could just > > Derek> "tcpdump" on the unprotected link between Eve/Alice and the > > Derek> SG, so IPsec isn't going to protect it. > > > > You missed a case, and you also overstated (b). > > > > The missing case is a SG with more than one LAN coming out of it, > > where Eve and Alice are on different ports. > > > > Second, for (b), most LANs are largely or entirely switched LANs, > > which means that Eve will be able to see few if any of the plaintext > > packets from SG to Alice even if Alice and Eve are on the same > > subnet. > > > > paul > > > > > -- Jan Vilhuber vilhuber@cisco.com (408) 527-0847 Strategic Cryptographic Development, ITD, Cisco Systems, San Jose From owner-ipsec@lists.tislabs.com Tue Jan 8 16:39:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g090dq325911; Tue, 8 Jan 2002 16:39:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29148 Tue, 8 Jan 2002 18:49:46 -0500 (EST) Message-Id: <3.0.3.32.20020108160000.012fae18@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 08 Jan 2002 16:00:00 -0800 To: Henry Spencer , IP Security List From: Alex Alten Subject: Re: Suggested modification to AES privacy draft In-Reply-To: References: <15419.8520.300125.943921@pkoning.dev.equallogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Not to mention 802.11b. - Alex At 12:24 PM 1/8/2002 -0500, Henry Spencer wrote: >On Tue, 8 Jan 2002, Paul Koning wrote: >> Second, for (b), most LANs are largely or entirely switched LANs... > >I think that's overstating the case. It may be true that most *new* LANs >are largely switched, but there are still a huge number of non-switched >LANs in service, especially small ones. Only recently have switch prices >fallen to the point that they are interesting even to people without major >security or performance concerns. Plain old shared 10Mbit/s Ethernet is >good enough to keep an awful lot of people happy. > > Henry Spencer > henry@spsystems.net > > > -- Alex Alten Alten@NetVista.Com From owner-ipsec@lists.tislabs.com Tue Jan 8 17:24:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g091Oe327195; Tue, 8 Jan 2002 17:24:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29197 Tue, 8 Jan 2002 19:46:19 -0500 (EST) Message-Id: <4.3.2.7.2.20020108194228.04af9bf8@sj-email.cisco.com> X-Sender: brford@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jan 2002 19:53:08 -0500 To: Sri Siddhartha Kodali From: Brian Ford Subject: Re: [ A problem ] Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Siddharth, Please see answers below: At 09:05 PM 1/7/2002 +0530, Sri Siddhartha Kodali wrote: > I am faced with a different kind of problem.our institute has purchased > cisco 7120 and 7140 routers to setup IPSEC tunnels.But the crypto module > is not present in the IOS.On doing drastic search we found that > Integrated Service Module is not present in slot 5.But we are confused > whether we do require ISM for using IPSEC and IKE You do not require an ISM to do IPsec in a 7120 or 7140. > Cisco has mentioned in one of its manuals that ISM is a hardware > encryption module and reduces the load off the router.but we don't > find any crypto command to perform software encryption with the router > Could some one suggest me about this. You probably do not have an IOS software image installed that supports IPsec. You should contact the Cisco TAC or use the Cisco web site (http://www.cisco.com) to obtain an IOS image that supports IPsec. >The project is on total halt becoz > of this > > Thanking You, > > Siddharth Kodali > siddhu@bits-pilani.ac.in Liberty for All, Brian From owner-ipsec@lists.tislabs.com Wed Jan 9 05:41:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09Dfs316471; Wed, 9 Jan 2002 05:41:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00336 Wed, 9 Jan 2002 07:42:58 -0500 (EST) From: juha.ollila@nokia.com Message-ID: To: ipsec@lists.tislabs.com Subject: Multicast and anycast addresses and policy selectors Date: Wed, 9 Jan 2002 14:52:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello! Is it required to support use of anycast and multicast addresses as source IP address policy selectors in IPsec implementations? RFC2401 specifies that the source IP address selector must support anycast and multicast addresses: - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. The last three are used to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations] RFC2373 specifies that source IP address must not be anycast or multicast address: o An anycast address must not be used as the source address of an IPv6 packet. Multicast addresses must not be used as source addresses in IPv6 packets or appear in any routing header. /Juha Ollila From owner-ipsec@lists.tislabs.com Thu Jan 10 11:50:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AJor300318; Thu, 10 Jan 2002 11:50:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03321 Thu, 10 Jan 2002 13:39:20 -0500 (EST) Message-ID: <037801c19a07$6583ce70$45c02ca1@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: Subject: Test vectors for ESP/AES - draft-ietf-ipsec-ciph-aes-cbc-03.txt Date: Thu, 10 Jan 2002 13:48:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0375_01C199DD.7C7B6BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0375_01C199DD.7C7B6BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had a brief email conversation with Scott Kelly regarding test vectors = for ESP packets (not just the NIST vectors for AES) and whether they = could/should be included in this draft. I would like to see them in = there, what does the rest of the community and other authors think? Darren ------=_NextPart_000_0375_01C199DD.7C7B6BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I had a brief email conversation with = Scott Kelly=20 regarding test vectors for ESP packets (not just the NIST = vectors for=20 AES) and whether they could/should be included in this draft.  I = would like=20 to see them in there, what does the rest of the community and other = authors=20 think?
 
Darren
 
 
------=_NextPart_000_0375_01C199DD.7C7B6BD0-- From owner-ipsec@lists.tislabs.com Sun Jan 13 21:55:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0E5ts321799; Sun, 13 Jan 2002 21:55:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09271 Sun, 13 Jan 2002 23:51:21 -0500 (EST) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: Minutes for the SLC IPSEC meeting Phone: (781) 391-3464 Message-Id: Date: Mon, 14 Jan 2002 00:01:40 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Enclosed please find draft minutes of the IPSEC wg meeting in Salt Lake City. My apologies for the lateness of these minutes; between the holidays and my also serving on nomcom, things have been just a little hectic as of late. Please look these over and make any comments as soon as possible, as minutes are due at the Secretariat by 5:00 Eastern on Monday. Many thanks!! - Ted Minutes of IPSEC wg Meeting, December 2001 These minutes were based off of notes graciously taken and submitted by David Black, from EMC. Wednesday, December 12, 2001 (15:30 -- 17:30) Agenda Bashing (Ts'o) The following agenda was presented and discussed: Wednesday, December 12, 2001 (15:30 -- 17:30) * Agenda Bashing (Ts'o) * SCTP/IPsec draft (Angelos) * IPSEC over NAT (Dixon) * IP Storage Security (Aboba) * AES Cipher document(s) (Herbert / Frankel) * Revised ESP (Kent) * IPSEC performance (Angelos) * Suggested Identity draft (Sommerfeld) * Transport Mode for Virtual Networks (Touch) * IKE Implementation Issues (Richardson) * Son-Of-Ike Requirements (Madson) Thursday, December 13, 2001 (9:00 -- 11:30) * JFK proposal (Angelos / Bellovin) * IKE V2 proposal (Radia / Dan Harkins) * IKE-SIGMA (Hugo / Bitan) * Requirements and Comparison of SOI approaches (Kaufman) * SOI Performance comparison (Rescorla) * Son-Of-Ike Requirements (Madson) * Open Mike Period SCTP/IPsec draft (Angelos Keromytis, Columbia University) ========================================================= Slides available in postscript. Angelos gave a description of the issues raised in WG last call. The main issue was to rename ID_RECURSE to ID_LIST for clarity. A new draft will be issued to address this and a few other minor issues, and the document will then be sent to the IESG. IPSEC over NAT (William Dixon, Microsoft) The NAT Traversal documents are in last call. There was recently implementation testing among 8 vendors against various NAT devices. What was tested was L2TP in IPsec transport mode and in tunnel mode based on IKE extensions of IKE-CFG/XAUTH or IPSRA DHCP. The results from this testing revealed some problems. Certificate fragmentation was a major cause of problems. In addition, some devices seem to be looking at IKE cookie states and hence cause NAT traversal not to work. A list of possible approaches to avoid fragmentation was discussed. Some testers implemented fragmentation avoidance via multiple UDP packets (fragment above UDP to avoid IP fragmenting below UDP). Something will likely need to be done here, since fragmentation will be a real deployment obstacle. IP Storage Security (Bernard Aboba, Microsoft) ============================================== Slides available in Powerpoint format. IP Storage WG has adopted IKE and IPsec as basic security mechanisms. The IPS working group has dependencies on various IPSEC and IPSRA wg I-D's, including IPsec transforms (3DES, HMAC-SHA1, AES-CTR, and AES CBC MAC w/XCBC), and tunnel mode config/auth (draft-ietf-ipsec-dhcp-13.txt - being done in IPSRA WG) A number of issues are under discussion. Please read draft-ietf-ips-security-06.txt and send comments to the IPS WG mailing list (ips@ece.cmu.edu) or the draft authors (iscsi-security@external.cisco.com). AES Cipher document(s) (Sheila Frankel, NIST and Howard Herbert, Intel) Three AES Cipher documents were discussed (one encryption, and two MAC algorithms): 1. AES cipher: CBC with random IV. 128 bit key is mandatory, 192 and 256 are optional, key length attribute is mandatory in IKE Phase 1 and Phase 2. Have suggested DH groups for various AES key lengths, and authors will resolve this with other different key length recommendations (e.g., Hilary Orman's key length comparison draft). 2. HMAC-SHA-256: Motivation is to increase the key space so that rekeying frequency can be reduced. The hash is truncated to 96 bits to avoid packet size changes. 3. AES-XCBC-MAC-96: Problem is that CBC MAC isn't secure for variable length messages. XCBC corrects this and has no patent issues --- do not confuse this with a new proposed "combined" AES confidentiality+integrity mode that does have serious IP issues. Comments from one of the original XCBC authors will be incorporated, test vectors added, and next version of draft is due in January 2002. Revised ESP (Steve Kent, BBN/Verizon) ===================================== Steve presented some proposed changes to ESP. The changes had a few clarifications (such as using "integrity" instead of "authentication"), and a number of substantive changes: * Sequence number extension - This is needed to support higher speed systems, and anticipates AES and its longer lived connections. New sequence numbers are 64 bits, but only 32 bits are carried in each packet. The next version of the draft will have in its appendix a suggestion on how to deal with the rare case where 2^32 packets from one SA are dropped. * Support for combined modes - New algorithms have emerged that can do integrity and confidentiality in one pass. This requires slight changes to ESP packet format - algorithm has to specify how it checks integrity, as this can't be specified once for all possible combined modes. * Improved traffic flow confidentiality - only for tunnel mode, most effective between a pair of security gateways. Have expanded the allowed padding (put "junk" behind the IP packet, and encapsulated IP header's length field will automatically cause receiver to ignore the "junk"). Also suggest a convention that the next header field of "59" in the ESP frame be used to indicate that there is no IP packet --- this allows dummy packets to be sent and discarded quickly to obfuscate traffic analysis. There were some discussions about fragmentation, and whether we can "just say no" to fragments. Steve Kent observed that fragmentation in IPsec has disastrous performance implications, and causes receiver administration issues because port selectors can't be applied to fragments (have to reassemble), which in turn leads to a denial of service vulnerability based on consumption of reassembly resources (e.g., buffers). Also see NAT discussion about other problems caused by fragments. Several problems with simply getting rid of fragments were raised as the discussion continued: * Some systems still don't do Path MTU discovery and this is made worse by firewalls that discard ICMP and hence break Path MTU discovery. * IKE/NAT problem only affects IKE messages that carry certificates. That's a much smaller scope than ESP in general. * We have no choice but to deal with fragments on reception, as one can't be sure sender send DF or some intermediate system paid attention to it. Not sending fragments is a good idea. * Some firewalls don't like either fragmentation or ICMP, making the situation impossible as fragments get dropped and Path MTU discovery doesn't work. (Steve Kent observed that if the firewall is broken regardless, we should do the simplest thing in ESP. Steve then discussed other document revisions which he is planning to do: * AH - revision early next year based on ESP revisions (e.g., extended sequence numbers) * Architecture document - revision before Yokohama to simplify processing model, reduce requirements for nested SAs, remove MUST for AH, selector changes (e.g., along lines SCTP needs, plus allow ICMP selectors). There was a discussion about whether or not the distinction between tunnel and transport modes could be eliminated. Steve Kent responded that the problem is making sure that the right selector checks happen; Joe Touch's VPN draft is a good model to follow. Steve rejected a proposal to remove the tunneling specification from IPSEC, and to simply reference some other specification (such as IP-IP tunnel), on the grounds that encapsulation/decapsulation decision on whether or not to propagate fields have security consequences, and thus need to be made based on local security policy decisions. IPSEC performance (Angelos Keromytis, Columbia University) ========================================================== Slides available in postscript format. Angelos gave a presentation which measured the performance of IPSEC using DES, 3DES, and AES in various scenarios, using both hardware and software implementations. Suggested Identity draft (Bill Sommerfeld, Sun) =============================================== Bill Sommerfeld discussed an individual I-D submission (draft-keromytis-ike-id-00.txt) which adds a suggested identity field to the IKE negotiation. This addresses the problem of how to figure out which IKE identity to use when there's more than one. The field is added to initiator's message 5 and HASH_I. Allows initiator to suggest which id responder should use to avoid confusion. This is needed for for User-to-User keying and Responder-initiated rekeying. Bill would like this to be adopted as a WG draft. He requested that the working group read the I-D and comment on mailing list. Transport Mode for Virtual Networks (Joe Touch, USC/ISI) ======================================================== Slides are available in Powerpoint and PDF format. Joe gave a presentation on issues relating to using tunnel-mode IPSEC and hop-by-hop routing. This causes complications because you either need to violate layering one way or another (for example, the routing layer has to update IPSEC configuration as the routing changes). Joe presented a solution which uses IP-IP encapsulation (RFC 2003) and IPSEC transport mode. The result is syntactically identical to IPSEC tunnel mode, although security checks which are done upon receipt and decapsulation of the packet are different. Joe then asked the question of how the working group should handle draft-touch-ipsec-vpn-*.txt. Should it become an informational RFC, or a BCP? He also requested that the next revision of RFC2401 require transport mode in gateways and allow the approach which he outlined. He also requested that in the son-of-ike proposals, that tunnel configuration be separated from keying. There was then a discussion about the order in which key selection and forwarding should be done. The resolution is that having forwarding select a virtual interface and using SPD per virtual interface is allowable by current documents (this is what Joe wants), but the current 2401 text could be clarified. IKE Implementation Issues (Michael Richardson) ============================================== Slides available in Postscript format. Michael Richardson discussed draft-spencer-ike-implementation-00.txt, which documents a number of implementation issues noted by the Free S/WAN developers. The first major issue is whether "unique" IKE message Id's have to be truly unique, or whether they just need to be generated in a pseudo-random fashion, and simply "probably unique". Many implementations do the latter, and the RFC's are ambiguous on this point. Michael would like the RFC's to be changed to make it clear that implementations must keep track of every message id ever issued by an implementation to guarantee uniqueness. The second issue related to how rekeying phase 2 SA's should be handled, and Michael proposed a scheme where the new Phase 2 SA is starts getting used immediately for transmission as it is negotiated, but the old SA is kept for in-flight messages. The Draft also contains a bunch of other things about IKE (e.g., pieces of IKE that Free S/WAN didn't implement, and whose absence has not caused interoperability issues). Son-Of-Ike Requirements (Cheryl Madson, Cisco) ============================================== Cheryl Madson discussed her I-D, draft-ietf-ipsec-son-of-ike-requirements-00.txt. The goals of this document were to describe the characteristics of an optimal protocol, and to provide scoping by describing the scenarios which the protocol must be able to accommodate. Explicit non-goals were (a) discussing security requirements (which is tough to do in a fashion which is meaningful, but which doesn't favor one proposal or another), and (b) determining the exact split of responsibility between Son-of-Ike and other protocols for the entire set of things that are needed to set up a secure connection. Cheryl listed the following desirable characteristics: 1. Extensibility. Can't add payloads to IKEv1, as it results in failure of negotiation. Vendor-ID has been used to work around this, but it's not a good solution. 2. Modularity. 3. Improved Convergence. It's too easy for IKEv1 participants to get out of sync with each other (e.g., SA deletion, error conditions) 4. Simplicity, both in terms of overall protocol functionality extent, and ease of accomplishing a particular function. 5. Better discussion/specification of authentication to deal with "IKE requires X.509" myth and remove sources of interoperability problems. A proposed way of accommodating this would be to allow authentication to be plugged in via companion drafts, while keeping the base draft as simple as possible. Document currently contains the following scenarios (list is incomplete): * Site to site VPN * Remote access * End to end * Mobile IP The working group is asked to review the document, and propose additional scenarios as appropriate. Thursday, December 13, 2001 (9:00 -- 11:30) ========================================== JFK proposal (Angelos / Bellovin) ================================= JFK Design Process - Steve Bellovin, AT&T Labs - Research --------------------------------------------------------- Slides available in Postscript and PDF format. Steve Bellovin started by describing the design principles that were used in writing JFK. The JFK team decided that patching code to preserve IKE is the wrong thing to do - IKE is already too complex, and complexity leads to security bugs. Wanted provable correctness, DoS mitigation, no negotiation. Orthogonal design and clean, well-defined interfaces to cryptographic core. IKEv2 authors have done a great job in simplifying IKE, but the result is still too complex. Current draft documents only the cryptographic core, if WG views this direction as valuable, a complete version of the draft will be available for Minneapolis. JFK currently requires certificates. IKE's multiple modes were also removed. Current pre-shared (secret) key approaches are to be replaced with self-signed certificates or IPSRA certificate retrieval. For legacy authentication, IPSRA or KINK should be used. Phase 1 vs. phase 2 distinction was also removed. This was motivated in part by DES weakness that required frequent rekeying - AES does not have this problem. The JFK design team is prepared to modify JFK to match developing state of requirements, since the requirements draft is still a work-in-progress. JFK Protocol - Angelos Keromytis, Columbia University ----------------------------------------------------- Slides available in Postscript format. Angelos described the actual details of the JFK protocol. In essence, JFK uses a two round trip protocol. The responder keeps no state between receipt of messages 1 and 3 to avoid denial of service attacks. More details are present in the slides and in JFK I-D. Angelos noted that the draft describes keying a unidirectional SA, but it would be straightforward to key a pair of keys (one for each direction) as IKEv2 does. One notational error was noted in the slides; there were four exponentials used (g^x, g^y, g^i, and g^r), but there should have been only two exponentials in use. (g^x and g^y should have been g^i and g^j, respectively). In JFK, the Responder exposes her identity in Message 2, but the Initiator's identity is protected. To protect responder's identity, pick up Hugo Krawczyk and Ran Cannetti's suggestion to incorporate SIGMA ideas into JFK - this protocol is being called LBJ. 4 implementations of JFK are being done by students at Columbia - 2 in Java, 1 in C, 1 in Perl. The Java implementations are interoperating, C and Perl aren't quite there yet. About 3 weeks of student effort so far. C and Perl implementations are running into crypto library issues (e.g., padding is different in different libraries). Converting a JFK implementation to LBJ took a student about a day. The sizes of the messages are at most a few hundred bytes plus the certificates. Comment: JFK has imperfect forward secrecy. Same D-H exponent used across multiple exchanges with forward secrecy established once that exponent is replaced. Perfect forward secrecy would require state to be kept after receipt of message 1. Comment: Can IKE payload formats be used? Yes, message format in JFK draft was chosen for expediency and is simpler than IKE's, but can use IKE's payload formats. Comment: Phase 2 can be useful for more than rekeying, and ability to amortize cost of public key operations is valuable. This needs to be taken up in requirements discussion. Proof of security is in the works - not completely done yet. IKE V2 proposal (Radia / Dan Harkins) ===================================== Slides available in Postscript format. Most of the work in IKEv2 was in the rest of the stuff that surrounds the cryptographic exchange. IKEv2 also has a 4-message exchange, but this other stuff is at least as important. The goals of IKEv2 were listed as follows: * Consolidate RFCs 2407, 2408, and 2409 into a single document. * No gratuitous changes, but simplify as appropriate (e.g., phase 2 has been kept, now 1 possible phase 1 exchange as opposed to 8 in IKEv1). * Fix ambiguities and bugs. * Add flexibility where necessary (e.g., selectors) * Reduce latency by reducing message count. * Allow stateless cookies IKE SA + IPsec SA in established in 4 messages based on public signature keys. Both identities are hidden from passive attackers. Subsequent child SA's require two messages to set up. All messages are request/response, and messages have sequence numbers. Multiple concurrent requests can be issued in parallel. Version numbers and critical flag defined to enable future changes and extensions, to provide for forward compatibility. Traffic selectors have been generalized. Responder can narrow ranges. Cookies (initiator-responder pair) are used to identify IKE SAs. In IKEv2 SA lifetimes are NOT negotiated. Either side can rekey at any time, and rekeying the IKE SA inherits all of the child SA's. No dangling SA's are allowed. If an unauthenticated ICMP/IKE message raises a suspicion about a dead peer, this is checked by sending a reliable IKE message; if there is no response, the SA is deleted. The way IKEV2 messages are encrypted and integrity protected is done using the ESP format, but this was simply a reuse of the syntax, and not the protocol. This caused some confusion because some people thought this resulted in a bootstrapping problem, where as it was merely the intention of the document authors to be lazy and not need to reinvent the wheel. The next version of the IKEv2 draft will copy the ESP syntax by value instead of by reference to eliminate this confusion. IKEv1 has a problem with security parameter negotiation in that each additional parameter to be negotiated results in an exponential explosion of possibilities. To address this, IKEv2 uses a "chinese menu" approach --- i.e., any of these encryption transforms with any of these integrity transforms. The following comments were made by members of the working group: * Rekeying IKE SA should use PFS. * Critical bit on options has been abused to defeat interoperability in other protocols IKE-SIGMA (Sara Bitan, Technion) ================================ Sara Bitan gave this presentation since Hugo was not able to attend the IETF meeting. The focus of IKE-SIGMA is crypto design, similar to JFK. Get this right, then add the rest of the structure, which is orthogonal to the core key exchange crypto protocol. SIGMA supplies full or windowed PFS, identity protection (against active or passive attacks) and DoS resistance. The protocol is flexible to allow choices in these areas. The presentation was a walk through of the cryptographic thinking that leads to the design of the SIGMA exchanges. Strong binding of identities of the participants to the key exchange is an important theme - leads to a requirement for each sender to MAC its own identity in the protocol. Several variants of SIGMA protocol based on different choices of security properties/features were described. Requirements and Comparison of SOI approaches (Kaufman) ======================================================= Slides available in Powerpoint format. Charlie Kaufman gave a presentation which compared the security properties of the various SOI approaches, as described in the I-D at the time of the meeting. The differences between the various protocols' security properties can be broken into a number of different areas: Performance - number of messages, number of exponentiations, size of messages, amount of data that needs processing. There were no major performance difference in computational time among proposed new protocols. Stateless cookie - defense against computational denial of service attack. This is easy to do with two extra messages. IKEv1 doesn't support this. JFK can piggyback this (no extra messages). SIGMA puts in two extra messages when under attack. IKEv2 can do either. Identity hiding - again, easy to do with extra messages. Discussion of identity hiding properties, consequences. JFK exposes Bob's identity, no other protocol exposes either identity. JFK and SIGMA as published are subject to polling attacks (poll IP address, discover Bob is there), but IKEv1 and IKEv2 allow Alice to be tricked into revealing her identity - this is a "no-free-lunch" tradeoff as one or the other has to be possible based on who reveals their identity first. Dead Peer detection - relying on ICMP opens up a denial of service attack based on forging ICMP messages. IKEv2 bans dangling SAs and relies on ping over IKE SA to avoid this. Other protocols don't say anything, but this is also not a problem in practice (yet). Putting ping into ESP and AH may be an alternative. Plausible Deniability. JFK - can prove that the two named parties intentionally talked to each other. Others can prove that each named party talked to someone. Use of pre-shared key (or IKE encryption key) can make it impossible to ever prove anything. Parameter Negotiation - seems to be necessary for various reasons. Need to avoid active attack that results in weakened crypto. JFK has Bob choose IKE parameters, will add ESP/AH negotiation later. IKEv2 has same abilities as IKEv1, SIGMA continues IKEv1 approach. IKEv2 intends to replace RFC 2407, 2408, and 2409. Other two currently supplement them, but JFK intends to get to same level of completeness as IKEv2 SOI Performance comparison (Eric Rescorla) ========================================== Eric Rescorla gave a presentation which counted the number of messages and cryptographic operations (i.e., D-H key agreement, RSA private key operations, etc.) to give a comparison of the various SOI proposals. Son-Of-Ike Requirements (Cheryl Madson, Cisco) ============================================== After the presentation of the SOI proposals, Cheryl Madson returned to lead a continued discussion on the requirements draft. One of the key areas which still needs more effort in the requirements draft is the scenarios description to provide protocol scoping. The individual scenarios need refinement; in addition a model to evaluate the scenario is still needed. There is also a need to figure out where the homes are for things that IKE will not do that are still important and get those specs done in the same timeframe as Son-of-IKE. If some of this is involved in connection establishment, the state machine specification should accommodate this. In general, we want minimal message size and count, minimal processing expense (including light-weight devices and restart hit after crash on a large server). Open Mike Period ================ Jeff Wong (Cisco): Limit amount of policy provisioning in IKE to stuff absolutely required to set up IPsec SA and tunnel (if used). Policy provisioning in general is arbitrarily complex. Hilarie Orman (Novell/Volera): Move all policy stuff into a separate protocol, e.g., see the IPSRA work. William Dixon (Microsoft): Scenarios are the most important piece of the requirement discussion. Cheryl: Want all the help that I can get in this area. Michael Thomas (Cisco): Most IKE problems are in the mundane protocol operations stuff, not the crypto itself. Recovery from restart avalanches is an important issue in practice today - KINK is in better shape on this than IKE, and needs to be looked to for examples. Phil Hallam-Baker (Verisign): XKASS is a serious proposal in XML world - may or may not be appropriate for IPsec based on requirements. Need to think about whether credential needs to include identity information, as identity hiding is easy if there's no identity to hide. Paul Hoffman (VPN Consortium): Transition from and coexistence with IKEv1 in a non-confusing fashion is important. Steve Bellovin (AT&T Labs Research): Strongly agree that the non-crypto stuff needs attention (Steve is one of the JFK folks). Cathy Meadows (??): Wants clarity on JFK vs. IKEv2 requirements/philosophies/approaches to SA negotiation. Steve Bellovin: Can WG please tell us what the requirements are? Absent that, JFK will pursue an approach of "here's what I want" responded to with "Yes" or "No and here's why". Aim is to reduce options/negotiations. Radia Perlman: IKEv2 follows general approach of IKEv1 with compaction and simplification. Could also follow TLS approach of offering entire suites as opposed to independently negotiating components. Locking down to a single crypto suite seems to be too restrictive. William Dixon (Microsoft): A real scenario for identity hiding is that Microsoft would not like to reveal that a home PC is owned by MS and used by an MS employee, as hackers are specifically targeting those. Eric Rescorla (??): Have seen four key exchange protocols and four variants, and they are similar at a high level (e.g., number of round trips). What if we started with the protocol infrastructure and then plugged in the crypto (any of these proposals seems workable)? Uri Blumenthal (Lucent Bell Labs): Legacy authentication will live on for a long time - please do not limit new algorithm to public key. Markku Saavla (sp? Siemens): Can we identify scenarios that are out-of-scope in addition to scenarios that we do need to support? Cheryl: Something like that - scenarios in requirements draft were intended as the "absolutely crucial to support" ones. Charlie Kaufman (IBM): IKEv2 copied IKEv1 syntax to avoid changing things. JFK picked up a new, cleaner syntax, but this issue is fundamentally a matter of taste. How can we avoid spending too much time in this sort of rathole? Suggests that negotiation approach needs to be resolved early (e.g., reduce everything to a small number of crypto suites, and force things like "vanity crypto" to use vendor payloads). Cheryl: Use of suites simplifies protocol analysis. ???: Managed IP service provider is concerned about credential management and delivery - need a pre-shared mode of some form, as this is easy to manage. Please consider credential delivery and management as part of Son-of-IKE. John Ionnadis (??): Split requirements into three categories - Cryptographic, Operational, and Policy (e.g., negotiation). Pursue these more or less independently and in parallel. Barbara Fraser (Cisco, co-chair): Yes, something like that is important to structuring the discussion and draft (or drafts). Scenario discussion is also important to this. Ted Ts'o (IBM, co-chair): Yes, discuss these independently on mailing list and close them independently. Dan Harkins (??): Would like to delete some of the proposal parsing stuff from IKE (AH and/or ESP and/or IPcomp). Kathy Meadows (??): Supports this, suggests formal language for expressing proposals. Jeff Schiller (Security AD): If WG spends too long debating proposals, AD will consider shutting it down. This area is reasonably well-understood and hence coming up with a reasonable solution should happen in short order. WG chairs will be asked to come up with a schedule, and hold WG to it. From owner-ipsec@lists.tislabs.com Sun Jan 13 23:21:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0E7Kx327108; Sun, 13 Jan 2002 23:20:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09366 Mon, 14 Jan 2002 01:14:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Theodore Ts'o" To: Subject: Minutes for the SLC IPSEC meeting Phone: (781) 391-3464 Message-ID: Date: Mon, 14 Jan 2002 00:01:40 -0500 X-OriginalArrivalTime: 14 Jan 2002 06:25:27.0734 (UTC) FILETIME=[41F76560:01C19CC4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Enclosed please find draft minutes of the IPSEC wg meeting in Salt Lake City. My apologies for the lateness of these minutes; between the holidays and my also serving on nomcom, things have been just a little hectic as of late. Please look these over and make any comments as soon as possible, as minutes are due at the Secretariat by 5:00 Eastern on Monday. Many thanks!! - Ted Minutes of IPSEC wg Meeting, December 2001 These minutes were based off of notes graciously taken and submitted by David Black, from EMC. Wednesday, December 12, 2001 (15:30 -- 17:30) Agenda Bashing (Ts'o) The following agenda was presented and discussed: Wednesday, December 12, 2001 (15:30 -- 17:30) * Agenda Bashing (Ts'o) * SCTP/IPsec draft (Angelos) * IPSEC over NAT (Dixon) * IP Storage Security (Aboba) * AES Cipher document(s) (Herbert / Frankel) * Revised ESP (Kent) * IPSEC performance (Angelos) * Suggested Identity draft (Sommerfeld) * Transport Mode for Virtual Networks (Touch) * IKE Implementation Issues (Richardson) * Son-Of-Ike Requirements (Madson) Thursday, December 13, 2001 (9:00 -- 11:30) * JFK proposal (Angelos / Bellovin) * IKE V2 proposal (Radia / Dan Harkins) * IKE-SIGMA (Hugo / Bitan) * Requirements and Comparison of SOI approaches (Kaufman) * SOI Performance comparison (Rescorla) * Son-Of-Ike Requirements (Madson) * Open Mike Period SCTP/IPsec draft (Angelos Keromytis, Columbia University) ========================================================= Slides available in postscript. Angelos gave a description of the issues raised in WG last call. The main issue was to rename ID_RECURSE to ID_LIST for clarity. A new draft will be issued to address this and a few other minor issues, and the document will then be sent to the IESG. IPSEC over NAT (William Dixon, Microsoft) The NAT Traversal documents are in last call. There was recently implementation testing among 8 vendors against various NAT devices. What was tested was L2TP in IPsec transport mode and in tunnel mode based on IKE extensions of IKE-CFG/XAUTH or IPSRA DHCP. The results from this testing revealed some problems. Certificate fragmentation was a major cause of problems. In addition, some devices seem to be looking at IKE cookie states and hence cause NAT traversal not to work. A list of possible approaches to avoid fragmentation was discussed. Some testers implemented fragmentation avoidance via multiple UDP packets (fragment above UDP to avoid IP fragmenting below UDP). Something will likely need to be done here, since fragmentation will be a real deployment obstacle. IP Storage Security (Bernard Aboba, Microsoft) ============================================== Slides available in Powerpoint format. IP Storage WG has adopted IKE and IPsec as basic security mechanisms. The IPS working group has dependencies on various IPSEC and IPSRA wg I-D's, including IPsec transforms (3DES, HMAC-SHA1, AES-CTR, and AES CBC MAC w/XCBC), and tunnel mode config/auth (draft-ietf-ipsec-dhcp-13.txt - being done in IPSRA WG) A number of issues are under discussion. Please read draft-ietf-ips-security-06.txt and send comments to the IPS WG mailing list (ips@ece.cmu.edu) or the draft authors (iscsi-security@external.cisco.com). AES Cipher document(s) (Sheila Frankel, NIST and Howard Herbert, Intel) Three AES Cipher documents were discussed (one encryption, and two MAC algorithms): 1. AES cipher: CBC with random IV. 128 bit key is mandatory, 192 and 256 are optional, key length attribute is mandatory in IKE Phase 1 and Phase 2. Have suggested DH groups for various AES key lengths, and authors will resolve this with other different key length recommendations (e.g., Hilary Orman's key length comparison draft). 2. HMAC-SHA-256: Motivation is to increase the key space so that rekeying frequency can be reduced. The hash is truncated to 96 bits to avoid packet size changes. 3. AES-XCBC-MAC-96: Problem is that CBC MAC isn't secure for variable length messages. XCBC corrects this and has no patent issues --- do not confuse this with a new proposed "combined" AES confidentiality+integrity mode that does have serious IP issues. Comments from one of the original XCBC authors will be incorporated, test vectors added, and next version of draft is due in January 2002. Revised ESP (Steve Kent, BBN/Verizon) ===================================== Steve presented some proposed changes to ESP. The changes had a few clarifications (such as using "integrity" instead of "authentication"), and a number of substantive changes: * Sequence number extension - This is needed to support higher speed systems, and anticipates AES and its longer lived connections. New sequence numbers are 64 bits, but only 32 bits are carried in each packet. The next version of the draft will have in its appendix a suggestion on how to deal with the rare case where 2^32 packets from one SA are dropped. * Support for combined modes - New algorithms have emerged that can do integrity and confidentiality in one pass. This requires slight changes to ESP packet format - algorithm has to specify how it checks integrity, as this can't be specified once for all possible combined modes. * Improved traffic flow confidentiality - only for tunnel mode, most effective between a pair of security gateways. Have expanded the allowed padding (put "junk" behind the IP packet, and encapsulated IP header's length field will automatically cause receiver to ignore the "junk"). Also suggest a convention that the next header field of "59" in the ESP frame be used to indicate that there is no IP packet --- this allows dummy packets to be sent and discarded quickly to obfuscate traffic analysis. There were some discussions about fragmentation, and whether we can "just say no" to fragments. Steve Kent observed that fragmentation in IPsec has disastrous performance implications, and causes receiver administration issues because port selectors can't be applied to fragments (have to reassemble), which in turn leads to a denial of service vulnerability based on consumption of reassembly resources (e.g., buffers). Also see NAT discussion about other problems caused by fragments. Several problems with simply getting rid of fragments were raised as the discussion continued: * Some systems still don't do Path MTU discovery and this is made worse by firewalls that discard ICMP and hence break Path MTU discovery. * IKE/NAT problem only affects IKE messages that carry certificates. That's a much smaller scope than ESP in general. * We have no choice but to deal with fragments on reception, as one can't be sure sender send DF or some intermediate system paid attention to it. Not sending fragments is a good idea. * Some firewalls don't like either fragmentation or ICMP, making the situation impossible as fragments get dropped and Path MTU discovery doesn't work. (Steve Kent observed that if the firewall is broken regardless, we should do the simplest thing in ESP. Steve then discussed other document revisions which he is planning to do: * AH - revision early next year based on ESP revisions (e.g., extended sequence numbers) * Architecture document - revision before Yokohama to simplify processing model, reduce requirements for nested SAs, remove MUST for AH, selector changes (e.g., along lines SCTP needs, plus allow ICMP selectors). There was a discussion about whether or not the distinction between tunnel and transport modes could be eliminated. Steve Kent responded that the problem is making sure that the right selector checks happen; Joe Touch's VPN draft is a good model to follow. Steve rejected a proposal to remove the tunneling specification from IPSEC, and to simply reference some other specification (such as IP-IP tunnel), on the grounds that encapsulation/decapsulation decision on whether or not to propagate fields have security consequences, and thus need to be made based on local security policy decisions. IPSEC performance (Angelos Keromytis, Columbia University) ========================================================== Slides available in postscript format. Angelos gave a presentation which measured the performance of IPSEC using DES, 3DES, and AES in various scenarios, using both hardware and software implementations. Suggested Identity draft (Bill Sommerfeld, Sun) =============================================== Bill Sommerfeld discussed an individual I-D submission (draft-keromytis-ike-id-00.txt) which adds a suggested identity field to the IKE negotiation. This addresses the problem of how to figure out which IKE identity to use when there's more than one. The field is added to initiator's message 5 and HASH_I. Allows initiator to suggest which id responder should use to avoid confusion. This is needed for for User-to-User keying and Responder-initiated rekeying. Bill would like this to be adopted as a WG draft. He requested that the working group read the I-D and comment on mailing list. Transport Mode for Virtual Networks (Joe Touch, USC/ISI) ======================================================== Slides are available in Powerpoint and PDF format. Joe gave a presentation on issues relating to using tunnel-mode IPSEC and hop-by-hop routing. This causes complications because you either need to violate layering one way or another (for example, the routing layer has to update IPSEC configuration as the routing changes). Joe presented a solution which uses IP-IP encapsulation (RFC 2003) and IPSEC transport mode. The result is syntactically identical to IPSEC tunnel mode, although security checks which are done upon receipt and decapsulation of the packet are different. Joe then asked the question of how the working group should handle draft-touch-ipsec-vpn-*.txt. Should it become an informational RFC, or a BCP? He also requested that the next revision of RFC2401 require transport mode in gateways and allow the approach which he outlined. He also requested that in the son-of-ike proposals, that tunnel configuration be separated from keying. There was then a discussion about the order in which key selection and forwarding should be done. The resolution is that having forwarding select a virtual interface and using SPD per virtual interface is allowable by current documents (this is what Joe wants), but the current 2401 text could be clarified. IKE Implementation Issues (Michael Richardson) ============================================== Slides available in Postscript format. Michael Richardson discussed draft-spencer-ike-implementation-00.txt, which documents a number of implementation issues noted by the Free S/WAN developers. The first major issue is whether "unique" IKE message Id's have to be truly unique, or whether they just need to be generated in a pseudo-random fashion, and simply "probably unique". Many implementations do the latter, and the RFC's are ambiguous on this point. Michael would like the RFC's to be changed to make it clear that implementations must keep track of every message id ever issued by an implementation to guarantee uniqueness. The second issue related to how rekeying phase 2 SA's should be handled, and Michael proposed a scheme where the new Phase 2 SA is starts getting used immediately for transmission as it is negotiated, but the old SA is kept for in-flight messages. The Draft also contains a bunch of other things about IKE (e.g., pieces of IKE that Free S/WAN didn't implement, and whose absence has not caused interoperability issues). Son-Of-Ike Requirements (Cheryl Madson, Cisco) ============================================== Cheryl Madson discussed her I-D, draft-ietf-ipsec-son-of-ike-requirements-00.txt. The goals of this document were to describe the characteristics of an optimal protocol, and to provide scoping by describing the scenarios which the protocol must be able to accommodate. Explicit non-goals were (a) discussing security requirements (which is tough to do in a fashion which is meaningful, but which doesn't favor one proposal or another), and (b) determining the exact split of responsibility between Son-of-Ike and other protocols for the entire set of things that are needed to set up a secure connection. Cheryl listed the following desirable characteristics: 1. Extensibility. Can't add payloads to IKEv1, as it results in failure of negotiation. Vendor-ID has been used to work around this, but it's not a good solution. 2. Modularity. 3. Improved Convergence. It's too easy for IKEv1 participants to get out of sync with each other (e.g., SA deletion, error conditions) 4. Simplicity, both in terms of overall protocol functionality extent, and ease of accomplishing a particular function. 5. Better discussion/specification of authentication to deal with "IKE requires X.509" myth and remove sources of interoperability problems. A proposed way of accommodating this would be to allow authentication to be plugged in via companion drafts, while keeping the base draft as simple as possible. Document currently contains the following scenarios (list is incomplete): * Site to site VPN * Remote access * End to end * Mobile IP The working group is asked to review the document, and propose additional scenarios as appropriate. Thursday, December 13, 2001 (9:00 -- 11:30) ========================================== JFK proposal (Angelos / Bellovin) ================================= JFK Design Process - Steve Bellovin, AT&T Labs - Research --------------------------------------------------------- Slides available in Postscript and PDF format. Steve Bellovin started by describing the design principles that were used in writing JFK. The JFK team decided that patching code to preserve IKE is the wrong thing to do - IKE is already too complex, and complexity leads to security bugs. Wanted provable correctness, DoS mitigation, no negotiation. Orthogonal design and clean, well-defined interfaces to cryptographic core. IKEv2 authors have done a great job in simplifying IKE, but the result is still too complex. Current draft documents only the cryptographic core, if WG views this direction as valuable, a complete version of the draft will be available for Minneapolis. JFK currently requires certificates. IKE's multiple modes were also removed. Current pre-shared (secret) key approaches are to be replaced with self-signed certificates or IPSRA certificate retrieval. For legacy authentication, IPSRA or KINK should be used. Phase 1 vs. phase 2 distinction was also removed. This was motivated in part by DES weakness that required frequent rekeying - AES does not have this problem. The JFK design team is prepared to modify JFK to match developing state of requirements, since the requirements draft is still a work-in-progress. JFK Protocol - Angelos Keromytis, Columbia University ----------------------------------------------------- Slides available in Postscript format. Angelos described the actual details of the JFK protocol. In essence, JFK uses a two round trip protocol. The responder keeps no state between receipt of messages 1 and 3 to avoid denial of service attacks. More details are present in the slides and in JFK I-D. Angelos noted that the draft describes keying a unidirectional SA, but it would be straightforward to key a pair of keys (one for each direction) as IKEv2 does. One notational error was noted in the slides; there were four exponentials used (g^x, g^y, g^i, and g^r), but there should have been only two exponentials in use. (g^x and g^y should have been g^i and g^j, respectively). In JFK, the Responder exposes her identity in Message 2, but the Initiator's identity is protected. To protect responder's identity, pick up Hugo Krawczyk and Ran Cannetti's suggestion to incorporate SIGMA ideas into JFK - this protocol is being called LBJ. 4 implementations of JFK are being done by students at Columbia - 2 in Java, 1 in C, 1 in Perl. The Java implementations are interoperating, C and Perl aren't quite there yet. About 3 weeks of student effort so far. C and Perl implementations are running into crypto library issues (e.g., padding is different in different libraries). Converting a JFK implementation to LBJ took a student about a day. The sizes of the messages are at most a few hundred bytes plus the certificates. Comment: JFK has imperfect forward secrecy. Same D-H exponent used across multiple exchanges with forward secrecy established once that exponent is replaced. Perfect forward secrecy would require state to be kept after receipt of message 1. Comment: Can IKE payload formats be used? Yes, message format in JFK draft was chosen for expediency and is simpler than IKE's, but can use IKE's payload formats. Comment: Phase 2 can be useful for more than rekeying, and ability to amortize cost of public key operations is valuable. This needs to be taken up in requirements discussion. Proof of security is in the works - not completely done yet. IKE V2 proposal (Radia / Dan Harkins) ===================================== Slides available in Postscript format. Most of the work in IKEv2 was in the rest of the stuff that surrounds the cryptographic exchange. IKEv2 also has a 4-message exchange, but this other stuff is at least as important. The goals of IKEv2 were listed as follows: * Consolidate RFCs 2407, 2408, and 2409 into a single document. * No gratuitous changes, but simplify as appropriate (e.g., phase 2 has been kept, now 1 possible phase 1 exchange as opposed to 8 in IKEv1). * Fix ambiguities and bugs. * Add flexibility where necessary (e.g., selectors) * Reduce latency by reducing message count. * Allow stateless cookies IKE SA + IPsec SA in established in 4 messages based on public signature keys. Both identities are hidden from passive attackers. Subsequent child SA's require two messages to set up. All messages are request/response, and messages have sequence numbers. Multiple concurrent requests can be issued in parallel. Version numbers and critical flag defined to enable future changes and extensions, to provide for forward compatibility. Traffic selectors have been generalized. Responder can narrow ranges. Cookies (initiator-responder pair) are used to identify IKE SAs. In IKEv2 SA lifetimes are NOT negotiated. Either side can rekey at any time, and rekeying the IKE SA inherits all of the child SA's. No dangling SA's are allowed. If an unauthenticated ICMP/IKE message raises a suspicion about a dead peer, this is checked by sending a reliable IKE message; if there is no response, the SA is deleted. The way IKEV2 messages are encrypted and integrity protected is done using the ESP format, but this was simply a reuse of the syntax, and not the protocol. This caused some confusion because some people thought this resulted in a bootstrapping problem, where as it was merely the intention of the document authors to be lazy and not need to reinvent the wheel. The next version of the IKEv2 draft will copy the ESP syntax by value instead of by reference to eliminate this confusion. IKEv1 has a problem with security parameter negotiation in that each additional parameter to be negotiated results in an exponential explosion of possibilities. To address this, IKEv2 uses a "chinese menu" approach --- i.e., any of these encryption transforms with any of these integrity transforms. The following comments were made by members of the working group: * Rekeying IKE SA should use PFS. * Critical bit on options has been abused to defeat interoperability in other protocols IKE-SIGMA (Sara Bitan, Technion) ================================ Sara Bitan gave this presentation since Hugo was not able to attend the IETF meeting. The focus of IKE-SIGMA is crypto design, similar to JFK. Get this right, then add the rest of the structure, which is orthogonal to the core key exchange crypto protocol. SIGMA supplies full or windowed PFS, identity protection (against active or passive attacks) and DoS resistance. The protocol is flexible to allow choices in these areas. The presentation was a walk through of the cryptographic thinking that leads to the design of the SIGMA exchanges. Strong binding of identities of the participants to the key exchange is an important theme - leads to a requirement for each sender to MAC its own identity in the protocol. Several variants of SIGMA protocol based on different choices of security properties/features were described. Requirements and Comparison of SOI approaches (Kaufman) ======================================================= Slides available in Powerpoint format. Charlie Kaufman gave a presentation which compared the security properties of the various SOI approaches, as described in the I-D at the time of the meeting. The differences between the various protocols' security properties can be broken into a number of different areas: Performance - number of messages, number of exponentiations, size of messages, amount of data that needs processing. There were no major performance difference in computational time among proposed new protocols. Stateless cookie - defense against computational denial of service attack. This is easy to do with two extra messages. IKEv1 doesn't support this. JFK can piggyback this (no extra messages). SIGMA puts in two extra messages when under attack. IKEv2 can do either. Identity hiding - again, easy to do with extra messages. Discussion of identity hiding properties, consequences. JFK exposes Bob's identity, no other protocol exposes either identity. JFK and SIGMA as published are subject to polling attacks (poll IP address, discover Bob is there), but IKEv1 and IKEv2 allow Alice to be tricked into revealing her identity - this is a "no-free-lunch" tradeoff as one or the other has to be possible based on who reveals their identity first. Dead Peer detection - relying on ICMP opens up a denial of service attack based on forging ICMP messages. IKEv2 bans dangling SAs and relies on ping over IKE SA to avoid this. Other protocols don't say anything, but this is also not a problem in practice (yet). Putting ping into ESP and AH may be an alternative. Plausible Deniability. JFK - can prove that the two named parties intentionally talked to each other. Others can prove that each named party talked to someone. Use of pre-shared key (or IKE encryption key) can make it impossible to ever prove anything. Parameter Negotiation - seems to be necessary for various reasons. Need to avoid active attack that results in weakened crypto. JFK has Bob choose IKE parameters, will add ESP/AH negotiation later. IKEv2 has same abilities as IKEv1, SIGMA continues IKEv1 approach. IKEv2 intends to replace RFC 2407, 2408, and 2409. Other two currently supplement them, but JFK intends to get to same level of completeness as IKEv2 SOI Performance comparison (Eric Rescorla) ========================================== Eric Rescorla gave a presentation which counted the number of messages and cryptographic operations (i.e., D-H key agreement, RSA private key operations, etc.) to give a comparison of the various SOI proposals. Son-Of-Ike Requirements (Cheryl Madson, Cisco) ============================================== After the presentation of the SOI proposals, Cheryl Madson returned to lead a continued discussion on the requirements draft. One of the key areas which still needs more effort in the requirements draft is the scenarios description to provide protocol scoping. The individual scenarios need refinement; in addition a model to evaluate the scenario is still needed. There is also a need to figure out where the homes are for things that IKE will not do that are still important and get those specs done in the same timeframe as Son-of-IKE. If some of this is involved in connection establishment, the state machine specification should accommodate this. In general, we want minimal message size and count, minimal processing expense (including light-weight devices and restart hit after crash on a large server). Open Mike Period ================ Jeff Wong (Cisco): Limit amount of policy provisioning in IKE to stuff absolutely required to set up IPsec SA and tunnel (if used). Policy provisioning in general is arbitrarily complex. Hilarie Orman (Novell/Volera): Move all policy stuff into a separate protocol, e.g., see the IPSRA work. William Dixon (Microsoft): Scenarios are the most important piece of the requirement discussion. Cheryl: Want all the help that I can get in this area. Michael Thomas (Cisco): Most IKE problems are in the mundane protocol operations stuff, not the crypto itself. Recovery from restart avalanches is an important issue in practice today - KINK is in better shape on this than IKE, and needs to be looked to for examples. Phil Hallam-Baker (Verisign): XKASS is a serious proposal in XML world - may or may not be appropriate for IPsec based on requirements. Need to think about whether credential needs to include identity information, as identity hiding is easy if there's no identity to hide. Paul Hoffman (VPN Consortium): Transition from and coexistence with IKEv1 in a non-confusing fashion is important. Steve Bellovin (AT&T Labs Research): Strongly agree that the non-crypto stuff needs attention (Steve is one of the JFK folks). Cathy Meadows (??): Wants clarity on JFK vs. IKEv2 requirements/philosophies/approaches to SA negotiation. Steve Bellovin: Can WG please tell us what the requirements are? Absent that, JFK will pursue an approach of "here's what I want" responded to with "Yes" or "No and here's why". Aim is to reduce options/negotiations. Radia Perlman: IKEv2 follows general approach of IKEv1 with compaction and simplification. Could also follow TLS approach of offering entire suites as opposed to independently negotiating components. Locking down to a single crypto suite seems to be too restrictive. William Dixon (Microsoft): A real scenario for identity hiding is that Microsoft would not like to reveal that a home PC is owned by MS and used by an MS employee, as hackers are specifically targeting those. Eric Rescorla (??): Have seen four key exchange protocols and four variants, and they are similar at a high level (e.g., number of round trips). What if we started with the protocol infrastructure and then plugged in the crypto (any of these proposals seems workable)? Uri Blumenthal (Lucent Bell Labs): Legacy authentication will live on for a long time - please do not limit new algorithm to public key. Markku Saavla (sp? Siemens): Can we identify scenarios that are out-of-scope in addition to scenarios that we do need to support? Cheryl: Something like that - scenarios in requirements draft were intended as the "absolutely crucial to support" ones. Charlie Kaufman (IBM): IKEv2 copied IKEv1 syntax to avoid changing things. JFK picked up a new, cleaner syntax, but this issue is fundamentally a matter of taste. How can we avoid spending too much time in this sort of rathole? Suggests that negotiation approach needs to be resolved early (e.g., reduce everything to a small number of crypto suites, and force things like "vanity crypto" to use vendor payloads). Cheryl: Use of suites simplifies protocol analysis. ???: Managed IP service provider is concerned about credential management and delivery - need a pre-shared mode of some form, as this is easy to manage. Please consider credential delivery and management as part of Son-of-IKE. John Ionnadis (??): Split requirements into three categories - Cryptographic, Operational, and Policy (e.g., negotiation). Pursue these more or less independently and in parallel. Barbara Fraser (Cisco, co-chair): Yes, something like that is important to structuring the discussion and draft (or drafts). Scenario discussion is also important to this. Ted Ts'o (IBM, co-chair): Yes, discuss these independently on mailing list and close them independently. Dan Harkins (??): Would like to delete some of the proposal parsing stuff from IKE (AH and/or ESP and/or IPcomp). Kathy Meadows (??): Supports this, suggests formal language for expressing proposals. Jeff Schiller (Security AD): If WG spends too long debating proposals, AD will consider shutting it down. This area is reasonably well-understood and hence coming up with a reasonable solution should happen in short order. WG chairs will be asked to come up with a schedule, and hold WG to it. From owner-ipsec@lists.tislabs.com Tue Jan 15 18:02:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G22k314954; Tue, 15 Jan 2002 18:02:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14325 Tue, 15 Jan 2002 19:58:42 -0500 (EST) Message-Id: <200201152349.g0FNnIk02898@marajade.sandelman.ottawa.on.ca> To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: Minutes for the SLC IPSEC meeting In-reply-to: Your message of "Mon, 14 Jan 2002 00:01:40 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 15 Jan 2002 18:49:17 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Theodore" == Theodore Ts'o writes: Theodore> Michael Richardson discussed draft-spencer-ike-implementation-00.txt, which Theodore> documents a number of implementation issues noted by the Free S/WAN Theodore> developers. The first major issue is whether "unique" IKE message Id's have Theodore> to be truly unique, or whether they just need to be generated in a Theodore> pseudo-random fashion, and simply "probably unique". Many implementations do Theodore> the latter, and the RFC's are ambiguous on this point. Michael would like Theodore> the RFC's to be changed to make it clear that implementations must keep Theodore> track of every message id ever issued by an implementation to guarantee Theodore> uniqueness. Perhaps I was unclear verbally. The draft is clear. If the IDs are guaranteed to be unique, then an implementation can simply record all message IDs received from a given peer (potentially 10, maybe 15 before phase 1 rekeys) and this gets rid of all ISAKMP replay attack issues. See the draft (draft-spencer-ike-implementation-01.txt) ] ON HUMILITY: to err is human. To moo, bovine. | 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 Wed Jan 16 05:26:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GDQh329683; Wed, 16 Jan 2002 05:26:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15591 Wed, 16 Jan 2002 07:24:52 -0500 (EST) Subject: IPSEC in a IPv4/IPv6 mixed scenario From: =?ISO-8859-1?Q?M=E1rio?= Jorge Nunes Filipe To: ipsec mailing list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IxvPis1oiUuOed2iEdt9" X-Mailer: Evolution/1.0.1 Date: 16 Jan 2002 12:34:54 +0000 Message-Id: <1011184496.8306.44.camel@neptuno> Mime-Version: 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=-IxvPis1oiUuOed2iEdt9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello I'm doing a small research about IPSEC and I've already read the RFC's and latest drafts, but there is a question that still remains: - Is it possible to use IPSEC on a IPv4/Ipv6 scenario. To clarify this a bit, imagine the "Road Warrior" scenario. Is it possible to have the road warrior with IPv4 connecting to the corporate SG wich is running IPv6 applying one of the transition mechanisn in between? If it is possible wich are the transition mechanisms that apply? My feeling is that this is not possible, but you guy's are the experts and I thought that maybe you could shed some light on this matter. Thank you very much for your help P.S: If this is a know issue, could you please provide some pointers... --=20 Mario Filipe=20 mjnf@uevora.pt http://neptuno.sc.uevora.pt/~mjnf=20 --=-IxvPis1oiUuOed2iEdt9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Para mais informações veja http://www.gnupg.org iD8DBQA8RXNuVm7HI0r66XkRApD2AKDJg1BLUBtE9zjBOMaWArNpDwsw3ACgqb0n 70QQ6GPVzF23nlhtYdQuzrg= =JecW -----END PGP SIGNATURE----- --=-IxvPis1oiUuOed2iEdt9-- From owner-ipsec@lists.tislabs.com Wed Jan 16 08:18:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GGIW306651; Wed, 16 Jan 2002 08:18:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15976 Wed, 16 Jan 2002 10:30:22 -0500 (EST) Message-ID: <005101c19ea4$301e45c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: =?iso-8859-1?Q?M=E1rio_Jorge_Nunes_Filipe?= , "ipsec mailing list" References: <1011184496.8306.44.camel@neptuno> Subject: Re: IPSEC in a IPv4/IPv6 mixed scenario Date: Wed, 16 Jan 2002 17:40:56 +0200 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 This is possible, by encapsulating IPv6 packets destined to your intranet in IPv4 IPsec packets. No additional transition mechanisms are needed. I don't know though if all extensions defined by the IPsec Remote Access WG are available for IPv6. This might limit some functionality, but basic IPsec and IKE should work in the situation that you mention. Also, in general IPsec doesn't deal well with something modifying packets in between. Hence a transition mechanism sitting in the network between your end points might not be possible. Jari From owner-ipsec@lists.tislabs.com Wed Jan 16 08:22:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GGM1306731; Wed, 16 Jan 2002 08:22:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16007 Wed, 16 Jan 2002 10:43:10 -0500 (EST) Subject: Re: IPSEC in a IPv4/IPv6 mixed scenario From: =?ISO-8859-1?Q?M=E1rio?= Jorge Nunes Filipe To: Jari Arkko Cc: ipsec mailing list In-Reply-To: <005101c19ea4$301e45c0$8a1b6e0a@arenanet.fi> References: <1011184496.8306.44.camel@neptuno> <005101c19ea4$301e45c0$8a1b6e0a@arenanet.fi> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GPyyFxYdrSqZ0P0nMah0" X-Mailer: Evolution/1.0.1 Date: 16 Jan 2002 15:53:30 +0000 Message-Id: <1011196411.13379.7.camel@neptuno> Mime-Version: 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=-GPyyFxYdrSqZ0P0nMah0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Qua, 2002-01-16 at 15:40, Jari Arkko wrote: >=20 > This is possible, by encapsulating IPv6 packets destined to your > intranet in IPv4 IPsec packets. No additional transition mechanisms > are needed. >=20 > I don't know though if all extensions defined by the IPsec Remote > Access WG are available for IPv6. This might limit some functionality, > but basic IPsec and IKE should work in the situation that you mention. >=20 > Also, in general IPsec doesn't deal well with something modifying > packets in between. Hence a transition mechanism sitting in the > network between your end points might not be possible. Hi Jari This were in fact my feelings since some RFC's mention some immutable fields in the headers wich I know get changed with some of the transition mechanisms, but I was just checking to be sure. Thank you --=20 Mario Filipe=20 mjnf@uevora.pt http://neptuno.sc.uevora.pt/~mjnf=20 --=-GPyyFxYdrSqZ0P0nMah0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Para mais informações veja http://www.gnupg.org iD8DBQA8RaH6Vm7HI0r66XkRAqXsAJ9JaOYvtM5/7DnWXRsNoBuxCADxbwCgiobN IdA6qjOPgWEw0xzQHq/+eE0= =06dl -----END PGP SIGNATURE----- --=-GPyyFxYdrSqZ0P0nMah0-- From owner-ipsec@lists.tislabs.com Thu Jan 17 19:25:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I3Pt307662; Thu, 17 Jan 2002 19:25:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19162 Thu, 17 Jan 2002 21:17:19 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> Date: Thu, 17 Jan 2002 20:33:07 -0500 To: "William Dixon" From: Stephen Kent Subject: RE: IP Storage and IPsec encapsulation Cc: , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:39 PM -0800 11/29/01, William Dixon wrote: >Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require >a transport layer interface definition for using IPSec security - in the >iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port >connection, deal with the binding of the authentication credential to >the traffic in the SA, allow/disallow iSCSI awareness of IKE SA >credentials, and IKE QM/IPSec SA state, and deal with the programmatic >policy addition to an otherwise admin defined SPD. > >Practically, shipping products that use IKE and IPSec in either mode for >TCP connection security means a well defined "policy" so that client >(iSCSI initiator) and server (iSCSI target) side products interoperate >with just credentials configured properly, ala web-based usage of SSL/TLS. Wiliam, I apologize that your message got buried in my inbox for about 65 weeks. I don't fully understand the issues you are raising here, perhaps because of your extremely concise exposition in the first paragraph :-). IPsec already knows how to manage SAs at the granularity of TCP port pairs. IPsec does not say where the credentials used by IKE come from; a TLI could provide them. you have not made clear what features of the IPsec specs preclude what you want to do. of course, I'm more interested in that what needs to be accomplished, and why, rather that how you would like to accomplish it. BTW, it's IPsec, not IPSec. Steve From owner-ipsec@lists.tislabs.com Fri Jan 18 11:03:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IJ3v301631; Fri, 18 Jan 2002 11:03:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20445 Fri, 18 Jan 2002 12:54:18 -0500 (EST) Message-ID: <00b201c1a04a$9353a0c0$af64a8c0@pace.stpp.soft.net> From: "Amol Deshmukh" To: Subject: Generation of IV for ESP Date: Fri, 18 Jan 2002 23:34:28 +0530 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 Hi, I had a question about the generation of IV for ESP mode. I have come across following Situations in the various IPsec Implementations: 1) Implicit IV is used by generating it at the respective peers by use of SEQ_ID.i.e IV[0-3] = Seq-id; IV[4-7] = ~Seq-id; Which is the most standard way to use in Implicit IV case? Or How is the IV generated so that there are no interoperatibility issues with different IPsec implementations? Will the using of sequence ID for generation of IV solve this issue? I would be thankful if you could help me with the above query. Regards, -Amol. From owner-ipsec@lists.tislabs.com Fri Jan 18 14:39:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IMdG306568; Fri, 18 Jan 2002 14:39:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20708 Fri, 18 Jan 2002 14:57:41 -0500 (EST) Message-ID: <007401c1a05c$4aa8dae0$4a2c12ce@JinME> From: "Jin Zhang" To: "Theodore Ts'o" , References: Subject: Re: Minutes for the SLC IPSEC meeting Date: Fri, 18 Jan 2002 12:11:18 -0800 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 X-OriginalArrivalTime: 25 Jan 2002 20:06:05.0912 (UTC) FILETIME=[B8C05D80:01C1A5DB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Any website I can download the slides or papers? I checked http://www.ietf.org/html.charters/ipsec-charter.html, and http://web.mit.edu/tytso/www/ipsec/ and only found information till 1998. Where is the information between 1998 and 2001? Thanks, Jin ----- Original Message ----- From: "Theodore Ts'o" To: Sent: Sunday, January 13, 2002 9:01 PM Subject: Minutes for the SLC IPSEC meeting > > > Enclosed please find draft minutes of the IPSEC wg meeting in Salt Lake > City. My apologies for the lateness of these minutes; between the > holidays and my also serving on nomcom, things have been just a little > hectic as of late. > > Please look these over and make any comments as soon as possible, as > minutes are due at the Secretariat by 5:00 Eastern on Monday. Many > thanks!! > > - Ted > > From owner-ipsec@lists.tislabs.com Fri Jan 18 21:23:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0J5NS315091; Fri, 18 Jan 2002 21:23:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21606 Fri, 18 Jan 2002 23:18:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <00b201c1a04a$9353a0c0$af64a8c0@pace.stpp.soft.net> References: <00b201c1a04a$9353a0c0$af64a8c0@pace.stpp.soft.net> Date: Fri, 18 Jan 2002 23:26:22 -0500 To: "Amol Deshmukh" From: Stephen Kent Subject: Re: Generation of IV for ESP Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:34 PM +0530 1/18/02, Amol Deshmukh wrote: >Hi, > >I had a question about the generation of IV for ESP mode. > >I have come across following Situations in the various >IPsec Implementations: >1) Implicit IV is used by generating it at the >respective peers by use of SEQ_ID.i.e > IV[0-3] = Seq-id; > IV[4-7] = ~Seq-id; > >Which is the most standard way to use in Implicit IV >case? Or How is the IV generated so that there are >no interoperatibility issues with different IPsec >implementations? > Will the using of sequence ID for generation of IV >solve this issue? > >I would be thankful if you could help me with the >above query. > To use an implicit IV, one should negotiate a crypto algorithm and mode that is defined to use such an IV. The RFC defining such a mode will specify how to construct the IV. Note that the default crypto modes defined for IPsec do not use an implicit IV, and there have been recommendations to not use an IV of the sort you describe, since it represents a small IV space. Steve From owner-ipsec@lists.tislabs.com Thu Jan 24 06:43:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OEhQ318835; Thu, 24 Jan 2002 06:43:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02776 Thu, 24 Jan 2002 08:36:47 -0500 (EST) From: Harjit_Singh@notes.tcs.treas.gov X-Lotus-FromDomain: TCS To: ipsec@lists.tislabs.com Message-ID: <85256B4A.00533296.00@notes.tcs.treas.gov> Date: Wed, 23 Jan 2002 10:12:50 -0500 Subject: Problem with GRE TUNNELS and using IPSEC encryptor Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I will appreciate any help on this case. I have a scenario where I have setup VPN connection between two sites using GRE tunnels running over Cylink IPSEC encryptors. I have EIGRP routing protocol running over the GRE tunnels for routing information. It so happens that after the connection has been up for few hours, GRE tunnels seem to get hung up. This problem gets resolved if the tunnel is restarted or some times by power cycling the encryptors. What could be possibly causing the encryptors to hang up GRE tunnels? Does any one have any feed back on this. Sunny (Tel# 703-747-9677) From owner-ipsec@lists.tislabs.com Sat Jan 26 16:21:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0R0LZ300524; Sat, 26 Jan 2002 16:21:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09343 Sat, 26 Jan 2002 18:17:11 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Sat, 26 Jan 2002 15:27:51 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Thoughts on identity attacks Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Some users want to have their identities hidden when they use IPsec because they do not want an attacker to know with whom they are communicating. This is a summary discussion from the mailing list, the WG sessions in Salt Lake City, and side conversations. 1. Attacks to get identities There are two types of attacks that can mounted to find out the identity of one or both of the parties in a key exchange protocol: - Passive attacks look for identities that passed in the clear during the negotiation. In a passive attack, neither party can detect that the identity is being seen. - Active attacks find identities by being a man-in-the-middle or by replacing the responder in the negotiation. The attacker proceeds through the key negotiation with the attackee until the attackee has revealed its identity. In a well-designed system, the negotiation will fail after the attackee has revealed its identity because the attacker cannot spoof the identity of the originally-intended system. The attackee might then suspect that there was an attack because the other side failed before it gave its identity. Therefore, an active attack cannot be persistent because it would prevent all legitimate access to the desired IPsec system. 2. Properties of identities In certificate-based IPsec, the identities are those that are bound in each side's certificates. For reasons of history but not necessity, the identities in these certificates are usually a human and/or company name, an IP address, a DNS name, or an email address. However, PKIX certificates can contain any sort of identity, including opaque blobs, in the subjectAltName using the otherName or registeredID types. 3. Who needs identity protection In key negotiations, the IP address of each IPsec system is always known to a passive or active attacker. The identities being protected by the key negotiation system are those in the certificates or identification payloads. Typically, an IPsec system that is at the same IP address over a long period of time does not need identity protection because an attacker can use other means (such as traceroute and reverse DNS lookup) to determine its identity. Identity protection is most useful to users with dynamic IP addresses, usually users whose IP address is assigned by DHCP or by a variety of different ISPs. The four cases for a negotiation are: Stationary initiator, stationary responder -- This is typical of gateway-to-gateway VPNs. Identity protection would not achieve much here. Mobile initiator, stationary responder -- This is a typical remote-access scenario. Even though the responder's identity can probably be determined by other means, the initiator can get value from identity protection. Stationary initiator, mobile responder -- For the initiator to be able to find the responder, there must have been some recent prior contact between the two parties. This could, for example, be a rekeying of an existing SA. In this case, the responder would want its identity protected. Mobile initiator, mobile responder -- For the initiator to be able to find the responder, there must have been some recent prior contact between the two parties. This could, for example, be a rekeying of an existing SA. In this case, each side would want its identity protected. 4. Identity protection in the current proposals The following describes IKE and the different proposals for its successors. IKEv1, IKEv2 draft 00, and LBJ (a proposal briefly made by Angelos in Salt Lake City that will be an option in JFK draft 01) all have the same properties. There is no passive attack possible, and an active attack is possible against the initiator's identity. Such an attack will reveal the identity but will cause the negotiation to fail in the next message. In JFK draft 00, there is a passive attack on the responder's identity, but no active attack possible on the initiator. SIGMA has proposals that match each of the above two identity protections. 5. Personal observations The model in JFK draft 00 (expose the responder's identity in order to protect the initiator's identity from active attacks) only works if the initiator never turns into a responder. However, in JFK draft 00, there is a strong chance that the original responder will want to rekey the SA, at which point the original initiator will have to expose its identity. The only ways around this are to change the protocol to never allow the original responder to rekey (very bad from a security policy standpoint), or to add some mechanism whereby the two parties can agree to who will reveal their identity first (bad from a complexity standpoint). Although IKEv1, IKEv2 draft 00, and LBJ expose the initiator's identity to an active attack, that attack seems unlikely to be common. The man-in-the-middle would have to be intermittent, and even then would raise suspicion every time the attack was successful. These solutions also solve the "original responder rekeys first" problem of JFK draft 00. Further, when talking to someone who hasn't investigated identity attacks, it is much easier to explain "no passive attacks" than it is to explain "a passive attack against one of the two parties is OK because the other party gets better protection". If the parties in a negotiation are worried about an attack on their identities, they can use PKIX identities that will give the attacker little or no information about the real identities. This sometimes means that the CA that they mutually trust needs to issue certificates with identities other than the typical ones, but any reasonable CA system should be able to do this. Further, depending on the level of worry, the parties can get new certificates with new identities as often as they wish (or as often as their mutually-trusted CA can handle). From owner-ipsec@lists.tislabs.com Mon Jan 28 22:45:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T6jA303736; Mon, 28 Jan 2002 22:45:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA15785 Tue, 29 Jan 2002 00:33:21 -0500 (EST) Message-ID: <005101c1a887$d9f8ff30$af64a8c0@pace.stpp.soft.net> From: "Amol Deshmukh" To: References: <00b201c1a04a$9353a0c0$af64a8c0@pace.stpp.soft.net> Subject: Options field in Outer IP Header Date: Tue, 29 Jan 2002 11:13:15 +0530 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 Hi, This is regarding the Options field in the outer IP Header for IPsec Tunnel mode. In RFC2401, section 5.1.2.1 gives the Header construction for Tunnel mode. For the Options field, the following line has been printed. Header fields Outer Header Inner Header Options never copied no change I have a doubt. Does this mean: 1> IPsec never copies the Options field from the inner Header nor does it construct them for the Outer Header ? 2> IPsec always attaches an outer IP Header of 20 bytes ? 3> It is not the responsibility of IPsec to attach the Options field for the Outer IP header ? I would be really thankful if you could help me with this. Thanks and Regards, Amol. From owner-ipsec@lists.tislabs.com Tue Jan 29 01:44:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T9ia326507; Tue, 29 Jan 2002 01:44:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16473 Tue, 29 Jan 2002 03:52:27 -0500 (EST) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) From: "Amey Gokhale" Subject: Re: Options field in Outer IP Header To: "Amol Deshmukh" Cc: ipsec@lists.tislabs.com Date: Tue, 29 Jan 2002 09:03:12 +0000 X-Postmaster: Sent from Postmaster http://www.postmaster.co.uk/, the world's premier free web-based email service, based in London, England. X-Postmaster-Trace: Account name: agokhale; Local time: Tue Jan 29 09:03:12 2002; Local host: pmweb5.uk1.bibliotech.net; Remote host: 202.54.40.40; Referer site: www.postmaster.co.uk X-Complaints-To: Administrator@postmaster.co.uk Message-Id: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk you guessed it right amol, outer IP header doesn;t copy inner IP header's option fields. for him, it is just a normal IP payload which has to be encapsulated, whtever may be the inner header/payload contents. but it doesn;t imply tht options are not constructed for outer IP header. if the environment needs every packet to be attached with security options....in tht case outer header will attach it;s own option fields. But option fields of inner IP header will not be copied in outer IP header. any corrections r welcome. regards, amey On Tue, 29 Jan 2002 11:13:15 +0530 "Amol Deshmukh" wrote: > Hi, > > This is regarding the Options field in the outer IP Header for IPsec > Tunnel mode. > In RFC2401, section 5.1.2.1 gives the Header construction for Tunnel > mode. For the Options field, the following line has been printed. > > Header fields Outer Header Inner Header > Options never copied no change > > I have a doubt. Does this mean: > 1> IPsec never copies the Options field from the inner Header nor > does it construct them for the Outer Header ? > 2> IPsec always attaches an outer IP Header of 20 bytes ? > 3> It is not the responsibility of IPsec to attach the Options field for the > Outer IP header ? > > I would be really thankful if you could help me with this. > > Thanks and Regards, > Amol. > > > > From owner-ipsec@lists.tislabs.com Tue Jan 29 11:08:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TJ8I327601; Tue, 29 Jan 2002 11:08:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17782 Tue, 29 Jan 2002 12:49:22 -0500 (EST) Message-ID: <3C56E316.1020508@isi.edu> Date: Tue, 29 Jan 2002 09:59:50 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020115 X-Accept-Language: en, de MIME-Version: 1.0 To: Amey Gokhale CC: Amol Deshmukh , ipsec@lists.tislabs.com Subject: Re: Options field in Outer IP Header References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080702050203020100070007" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms080702050203020100070007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit You may also want to look at RFC2003, which describes IPIP encapsulation in more detail (and is what IPsec tunnel mode is based on). Lars Amey Gokhale wrote: > you guessed it right amol, outer IP header doesn;t copy inner IP header's option fields. for him, it is just a normal IP payload which has to be encapsulated, whtever may be the inner header/payload contents. > > but it doesn;t imply tht options are not constructed for outer IP header. if the environment needs every packet to be attached with security options....in tht case outer header will attach it;s own option fields. But option fields of inner IP header will not be copied in outer IP header. > > any corrections r welcome. > regards, > amey > > On Tue, 29 Jan 2002 11:13:15 +0530 > "Amol Deshmukh" wrote: > >>Hi, >> >> This is regarding the Options field in the outer IP Header for IPsec >>Tunnel mode. >> In RFC2401, section 5.1.2.1 gives the Header construction for Tunnel >>mode. For the Options field, the following line has been printed. >> >>Header fields Outer Header Inner Header >>Options never copied no change >> >>I have a doubt. Does this mean: >>1> IPsec never copies the Options field from the inner Header nor >> does it construct them for the Outer Header ? >>2> IPsec always attaches an outer IP Header of 20 bytes ? >>3> It is not the responsibility of IPsec to attach the Options field for the >> Outer IP header ? >> >>I would be really thankful if you could help me with this. >> >>Thanks and Regards, >>Amol. >> >> >> >> >> -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms080702050203020100070007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDEyOTE3NTk1MFowIwYJKoZIhvcNAQkEMRYEFFeLfyUYdsICsurX8EoxNVgDgiLQMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAN68DUQFZcb5tMXZiLLTcGAvazOx61+1ZkFq1q1NCz2xrt2+r6K3O9/xzdZEeRy8un ZuxduQhuvRLx9Nf9KNf7YUuqN2ZcV51yvWgl8dGIVJMU7PCJuHbdsNuhisnLdcb+cOTzQCFB KvgbjC2s2bHy2MuM3gU0ZPd01gYTEVX28gAAAAAAAA== --------------ms080702050203020100070007-- From owner-ipsec@lists.tislabs.com Wed Jan 30 01:14:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0U9El304746; Wed, 30 Jan 2002 01:14:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA19698 Wed, 30 Jan 2002 03:02:57 -0500 (EST) Message-ID: <20020130081348.55721.qmail@web20402.mail.yahoo.com> Date: Wed, 30 Jan 2002 00:13:48 -0800 (PST) From: kaustubh kumbhalkar Subject: router advertisements To: ipsec MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hello this is regarding the ipv6 implmentation for linux kernel ver 2.4.17. i wanted to know how the router advertisement part has been implmented in the neighbor discovery. i was reffering to the file 'ndisc.c' which implements neighbor discovery functionalities.here i could not find the sending of router advertisement. has it been implemented in an other file. thanks a lot, regards kaustubh. __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Wed Jan 30 05:27:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UDRJ325106; Wed, 30 Jan 2002 05:27:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA20365 Wed, 30 Jan 2002 07:31:13 -0500 (EST) Date: Wed, 30 Jan 2002 21:41:32 +0900 Message-ID: From: KANDA Mitsuru / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?= To: kaustubh kumbhalkar Cc: ipsec Subject: Re: router advertisements In-Reply-To: <20020130081348.55721.qmail@web20402.mail.yahoo.com> References: <20020130081348.55721.qmail@web20402.mail.yahoo.com> X-GnuPG-fingerprint: 9A35 D378 F084 9EA4 EFBA 925B 1C93 B376 F0EF BE59 MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Why did you ask linux ipv6 implementation issue in this "ipsec" list? At Wed, 30 Jan 2002 00:13:48 -0800 (PST), kaustubh kumbhalkar wrote: > > hello > this is regarding the ipv6 implmentation for linux > kernel ver 2.4.17. > i wanted to know how the router advertisement part has > been implmented in the neighbor discovery. > i was reffering to the file 'ndisc.c' which implements > neighbor discovery functionalities.here i could not > find the sending of router advertisement. > has it been implemented in an other file. > thanks a lot, > regards > kaustubh. Just info: In linux kernel, there is no sending RA part. Generally, people use radvd or zebra to send RA packets. -mk From owner-ipsec@lists.tislabs.com Wed Jan 30 06:56:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UEuh300132; Wed, 30 Jan 2002 06:56:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20554 Wed, 30 Jan 2002 09:00:48 -0500 (EST) To: kkumbhalkar@yahoo.com Cc: ipsec@lists.tislabs.com Subject: Re: router advertisements In-Reply-To: <20020130081348.55721.qmail@web20402.mail.yahoo.com> References: <20020130081348.55721.qmail@web20402.mail.yahoo.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Capitol Reef) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020130201106S.yoshfuji@wide.ad.jp> Date: Wed, 30 Jan 2002 20:11:06 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 13 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In article <20020130081348.55721.qmail@web20402.mail.yahoo.com> (at Wed, 30 Jan 2002 00:13:48 -0800 (PST)), kaustubh kumbhalkar says: > this is regarding the ipv6 implmentation for linux > kernel ver 2.4.17. > i wanted to know how the router advertisement part has > been implmented in the neighbor discovery. This is wrong list to ask your question... Anyway, just FYI, . -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-ipsec@lists.tislabs.com Wed Jan 30 10:26:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UIQF306862; Wed, 30 Jan 2002 10:26:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21104 Wed, 30 Jan 2002 12:06:39 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 30 Jan 2002 09:17:21 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Fwd: I-D ACTION:draft-ietf-pkix-okid-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. In December, there was a great deal of discussion on this list about how to get rid of preshared secrets in the SuccessorToIKE protocol using self-signed certificates. One of the problem with self-signed certificates today is that there is not standard way of identifying them on the telephone or written out-of-band communications. The following new Internet Draft, being discussed in the PKIX WG, would solve that problem. With this new protocol, using self-signed certificates should be about as easy as proper use of preshared secrets. If it isn't, please let me know so I can improve the document. Thanks! >To: IETF-Announce: ; >Cc: ietf-pkix@IMC.ORG >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-pkix-okid-00.txt >Date: Wed, 30 Jan 2002 07:02:15 -0500 >Sender: nsyracus@cnri.reston.va.us > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Public-Key Infrastructure (X.509) >Working Group of the IETF. > > Title : Out-of-Band Key Identifier Protocol (OKID) > Author(s) : P. Hoffman > Filename : draft-ietf-pkix-okid-00.txt > Pages : > Date : 29-Jan-02 > >In general, certificates need not be communicated with communication or >storage media that are integrity-secure or authentic. This is because >certificates are digitally signed and users are expected to validate the >signatures using configured trust anchors. However, distribution of >trust anchor certificates, or distribution of self-signed end-entity >certificates, requires a mechanism for establishing the authenticity of >the public key contained in such certificates. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-pkix-okid-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-pkix-okid-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-pkix-okid-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. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 30 14:53:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UMrE313003; Wed, 30 Jan 2002 14:53:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21772 Wed, 30 Jan 2002 16:44:22 -0500 (EST) From: jerry.wang@tumbleweed.com X-Server-Uuid: 6E802067-ECFC-4FC2-A617-DD5220DD9CBB Message-ID: <00b401c1a9d8$be1cc0b0$6401a8c0@samwise> To: ipsec@lists.tislabs.com Subject: interoperability of IPSec between solaris 8 and win2k Date: Wed, 30 Jan 2002 16:54:50 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-WSS-ID: 1046B39E362294-01-01 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01C1A9AE.D4BBB6C0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C1A9AE.D4BBB6C0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I am testing the interoperability of IPSec between the native support = from solaris 8 and win2k. It seems not possible due to the fact that = solaris 8's ipsec implementation is not full-fledged, and it only allows = for manual keyed sa. Also the length of the keys is dependent on the = authentication and encryption algorithm on solaris 8 while win2k doesn't = seem to have this constraint. Win2k configuration tool only allows for = authentication key to be manually configured, not encryption key.=20 So I can't see how these two would work together. Does anyone have a = similar experiment and draw the same or opposite conclusions? Thanks. ------=_NextPart_000_00B1_01C1A9AE.D4BBB6C0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
 
I am testing the interoperability of = IPSec between=20 the native support from solaris 8 and win2k. It seems not possible due = to the=20 fact that solaris 8's ipsec implementation is not full-fledged, and it = only=20 allows for manual keyed sa. Also the length of the keys is dependent on = the=20 authentication and encryption algorithm on solaris 8 while win2k = doesn't=20 seem to have this constraint. Win2k configuration tool only allows for=20 authentication key to be manually configured, not encryption key.=20
 
So I can't see how these two would work = together.=20 Does anyone have a similar experiment and draw the same or opposite = conclusions?=20 Thanks.
 
------=_NextPart_000_00B1_01C1A9AE.D4BBB6C0-- From owner-ipsec@lists.tislabs.com Thu Jan 31 09:41:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VHfs320282; Thu, 31 Jan 2002 09:41:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23962 Thu, 31 Jan 2002 11:31:07 -0500 (EST) Message-ID: <004e01c1aa76$250ee300$6501a8c0@samwise> From: "Jerry Wang" To: Subject: free ipsec implementation or VPN that runs both on solaris and on windows Date: Thu, 31 Jan 2002 11:41:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C1AA4C.37758690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C1AA4C.37758690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know of such a product? Thanks. ------=_NextPart_000_004B_01C1AA4C.37758690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does anyone know of such a product?=20 Thanks.
------=_NextPart_000_004B_01C1AA4C.37758690--