From owner-ipsec@lists.tislabs.com Fri Dec 1 03:06:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10530; Fri, 1 Dec 2000 03:06:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA23285 Fri, 1 Dec 2000 04:19:42 -0500 (EST) Message-ID: <44059615.975662462991.JavaMail.Administrator@hvwww5> Date: Fri, 1 Dec 2000 01:21:02 -0800 (PST) From: Arvind Devarajan To: ipsec@lists.tislabs.com Subject: Request - help needed Cc: x-kernel-l@it.swin.edu.au Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="44060585.975662462976.JavaMail.Administrator@hvwww5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --44060585.975662462976.JavaMail.Administrator@hvwww5 Content-Type: text/plain Content-Transfer-Encoding: 7bit hi, about a month back, i had posted in this list about a project that i have undertaken as a part of my Masters. My functional specifications and the design specifications are done, and, i request the experts here to go through them, and help me in my efforts. i am in IPSec for the past 2 - 3 months only, and, have learnt quiet a bit. with all your help, i was able to come up with the above documents. Please visit this page: www.geocities.com/freipsec - here you'll find those documents. i've got certain doubts on my understanding of IPSec, please go through my Overview of IPsec, in which, i've depicted all my understanding of the protocol. Thanking you for all your help, regards, arvind. ------------------------------------------- Arvind Devarajan < - > Luck is defined as the time when HARD WORK meets OPPORTUNITY! -------------------------------------------------------------------------- Global Internet phone calls, voicemail, fax, e-mail and instant messaging. Sign-up today for FREE account at http://www.hotvoice.com --44060585.975662462976.JavaMail.Administrator@hvwww5-- From owner-ipsec@lists.tislabs.com Fri Dec 1 07:56:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06361; Fri, 1 Dec 2000 07:56:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24115 Fri, 1 Dec 2000 09:08:07 -0500 (EST) From: Mike Carney Message-Id: <200012011409.IAA15953@spirit.sctc.com> Subject: Re: Synchronisation in IKE To: vilhuber@cisco.com (Jan Vilhuber) Date: Fri, 1 Dec 2000 08:09:47 -0600 (CST) Cc: carney@securecomputing.com (Mike Carney), sridharj@future.futsoft.com, antonio.barrera@nokia.com, ipsec@lists.tislabs.com In-Reply-To: from "Jan Vilhuber" at Nov 30, 2000 11:04:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > How about if B initiates a Phase 1 (if it can based on it's static configuration) > > in order to send an protected "unknown SPI" notify message? (Rate limited of > > course). > > > As was pointed out, that could be a denial of service attack, i.e. someone > could be sending you bogus ipsec packets, causing you to initiate a phase 1 > (doing all associated computations). Ahh good point. However the DOS is not too terrible as Phase 1 lifetimes are usually pretty large, and B would only initiate Phase 1's to Gateways for which it has a static policy and no existing Phase 1. Regards, Michael Carney > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Fri Dec 1 10:02:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14896; Fri, 1 Dec 2000 10:02:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24832 Fri, 1 Dec 2000 11:41:29 -0500 (EST) Message-ID: <005301c05bb5$d65a1550$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: References: <200011301051.FAA25467@ietf.org> Subject: DH vs. RSA use for symmetric key exchange Date: Fri, 1 Dec 2000 08:43:30 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Would anyone have some pointers on what percentage of the installed base of IPSEC capable routers _use_ RSA vs. DH for exchanging symmetric keys? A sub goal of this question is to figure out what percentage of such devices use certificates. I would be grateful for any guesses, estimates or pointers to more info. Thanks. Khaja ================================ Khaja E. Ahmed khaja.ahmed@home.com From owner-ipsec@lists.tislabs.com Fri Dec 1 11:40:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21590; Fri, 1 Dec 2000 11:40:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25101 Fri, 1 Dec 2000 13:15:12 -0500 (EST) Date: Fri, 1 Dec 2000 10:15:57 -0800 (PST) From: Jan Vilhuber To: Mike Carney cc: sridharj@future.futsoft.com, antonio.barrera@nokia.com, ipsec@lists.tislabs.com Subject: Re: Synchronisation in IKE In-Reply-To: <200012011409.IAA15953@spirit.sctc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 1 Dec 2000, Mike Carney wrote: > > > > > > How about if B initiates a Phase 1 (if it can based on it's static configuration) > > > in order to send an protected "unknown SPI" notify message? (Rate limited of > > > course). > > > > > As was pointed out, that could be a denial of service attack, i.e. someone > > could be sending you bogus ipsec packets, causing you to initiate a phase 1 > > (doing all associated computations). > > Ahh good point. However the DOS is not too terrible as Phase 1 lifetimes > are usually pretty large, and B would only initiate Phase 1's to Gateways > for which it has a static policy and no existing Phase 1. > True. But I've heard of people talking about gateway discovery. Once you throw something that that into the picture, you might have more of a problem (depends on how gateway discovery is implemented). Also, I'm not entirely convinced that it's not 'too terrible'. If you have lots of configured peers, and you can be fooled to initiate to them all at once, then that's a problem. How big of a problem, I'm not sure. It may not be an issue (especially for those with hardware help). On the other hand of 1000 routers can be coerced to begin a phase 1 with YOU, then that's akin to the distributed denial of service attacks launched recently with ping. It all depends on your paranoia level, I suppose. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 1 13:12:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27590; Fri, 1 Dec 2000 13:12:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25486 Fri, 1 Dec 2000 14:34:39 -0500 (EST) Message-ID: <3A27FB70.64CAD963@storm.ca> Date: Fri, 01 Dec 2000 14:26:40 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Khaja E. Ahmed" CC: ipsec@lists.tislabs.com Subject: Re: DH vs. RSA use for symmetric key exchange References: <200011301051.FAA25467@ietf.org> <005301c05bb5$d65a1550$e4570f18@plstn1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Khaja E. Ahmed" wrote: > > Would anyone have some pointers on what percentage of the installed base of > IPSEC capable routers _use_ RSA vs. DH for exchanging symmetric keys? The question is mis-phrased. IPSEC uses Diffie-Hellman key negotiation for all symmetric keys that are automatically created. The only case where DH is not used is manual mode, where keys are set by the administrators rather than negotiated. The DH exchange must be authenticated and there are several mechanisims for that authentication, including shared secrets, RSA signatures and various forms of certificate. > A sub > goal of this question is to figure out what percentage of such devices use > certificates. > > I would be grateful for any guesses, estimates or pointers to more info. IPSEC background info, lots of links: http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/links.ipsec.html#protocols From owner-ipsec@lists.tislabs.com Fri Dec 1 17:52:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08766; Fri, 1 Dec 2000 17:52:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26255 Fri, 1 Dec 2000 19:09:27 -0500 (EST) Message-ID: <004f01c05bf4$596ae760$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: , , Subject: Next IPsec & L2TP Bakeoff Date: Sat, 2 Dec 2000 02:10:58 +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 Hello, We have come up with the idea that perhaps the next IPsec and L2TP bakeoff could be held in Finland. In order to determine interest for such an event, it would be interesting to get feedback from the members of these lists. In the last bakeoff I think that the consensus was that another bakeoff would be useful. What about the details, such as: * If such an event would be organized, would you be willing to travel to Europe for it? Would you have less or more engineers than in the last bakeoff? * Timing. When do people want a bakeoff? How does June or August 2001 sound? Time is propably running out for the traditional January bakeoff, and in March some people are going to the Connecthathon. * What is the rough idea about things to test? IPsec/IKE? IPv6 & IPsec & IKE (we'd be very interested in that)? L2TP? L2TP/PPP with real dial-in connections? Something else? It seems that suitable locations are in short supply in Finland, though. If we are going to go ahead with this, we need to decide and reserve ASAP. Therefore, we'd be very pleased to get the feedback before the San Diego IETF. Thanks! Jari Arkko, Ericsson Tero Kivinen, SSH From owner-ipsec@lists.tislabs.com Sun Dec 3 16:41:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10704; Sun, 3 Dec 2000 16:41:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00942 Sun, 3 Dec 2000 17:43:07 -0500 (EST) Message-ID: <005d01c05d7a$9dc1f020$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: , Subject: Another DOI on top of ISAKMP/IKE -- draft-arkko-map-doi-00.txt Date: Mon, 4 Dec 2000 00:44:36 +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 Hello. We have produced a new Internet Draft, describing how ISAKMP (and IKE to a large extent, or even KINK) could be reused in the context of protecting one non-IP protocol in mobile networks. We would appreciate getting the group's opinion on this approach. Background: =========== The 3GPP (third generation mobile network standardization forum) is working on security for their MAP protocol. MAP is a central protocol in GSM networks, and continues to be used at least for a while also in 3G networks; perhaps eventually however completely replaced by protocols such as SIP and AAA. As MAP transports sensitive data used e.g. in the authentication of GSM phones, operators are being increasingly concerned that MAP messages are transported in the clear. Now, a security mechanism has been designed to encrypt and integrity protect MAP messages. MAP runs over SS7, ad the security mechanism inserts a header between the SS7 and MAP parts of packets. The network arrangement is typically such that servers from two operator networks (visiting and home) need to talk to each other. Both IP and SS7 connectivity exists. There is a large number of operators. However, the fact that we can encrypt MAP messages is not enough by itself. We also need to configure and create MAP SAs in a scalable manner, and we need to have lifetimes for the use of the SAs. For this we need key management. Our involvement: ================ We'been working on slight modification of the IPSEC DOI in order to use ISAKMP/IKE to negotiate the MAP security associations. It turns out that IKE phase 1 can be used as-is (alternatively KINK), and that phase 2 is modified only with respect to the meaning of the SA data. For details, see the I-D http://search.ietf.org/internet-drafts/draft-arkko-map-doi-00.txt There are also other possible alternatives to implement the same functionality. A completely new and MAP-specific key management protocol over IP has also been discussed but we'd rather reuse IKE since that is used also for other purposes, is quite complete, can be deployed fast, and we could reuse implementations. An alternative protocol could also be developed solely on top of SS7. And then to the issues on which we'd like your opinion: =========================================== 1) What is your technical opinion of the approach? 2) If we decide to go for this approach within the mobile networks, how should this work proceed in the IETF world? An informational RFC? Will these be allowed while some standards track IPsec/IKE modifications are on hold? What is the process for getting a new Informational RFC? 3) Should we discuss this in San Diego? 4) What about possible future assignments of numbers from the spaces defined by a new DOI? Jari Arkko From owner-ipsec@lists.tislabs.com Mon Dec 4 04:16:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10472; Mon, 4 Dec 2000 04:16:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA02192 Mon, 4 Dec 2000 05:26:44 -0500 (EST) Message-ID: <015d01c05ddd$0273c130$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Sandy Harris" Cc: References: <200011301051.FAA25467@ietf.org> <005301c05bb5$d65a1550$e4570f18@plstn1.sfba.home.com> <3A27FB70.64CAD963@storm.ca> Subject: Re: DH vs. RSA use for symmetric key exchange Date: Mon, 4 Dec 2000 02:28:57 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you sandy. While we are on ignorance abatement: 1.) Can someone point me to either a discussion archive or other material on man in the middle attacks on IKE? 2.) Anyone have a feel for what percentage of VPN ( or other IPsec) deployment uses RSA public key Certificates for authentication? Forgive me if I am asking "much answered" questions. I am just getting into IPsec. Thank you. Khaja ----- Original Message ----- From: "Sandy Harris" To: "Khaja E. Ahmed" Cc: Sent: Friday, December 01, 2000 11:26 AM Subject: Re: DH vs. RSA use for symmetric key exchange > "Khaja E. Ahmed" wrote: > > > > Would anyone have some pointers on what percentage of the installed base of > > IPSEC capable routers _use_ RSA vs. DH for exchanging symmetric keys? > > The question is mis-phrased. > > IPSEC uses Diffie-Hellman key negotiation for all symmetric keys that are > automatically created. The only case where DH is not used is manual mode, > where keys are set by the administrators rather than negotiated. > > The DH exchange must be authenticated and there are several mechanisims > for that authentication, including shared secrets, RSA signatures and various > forms of certificate. > > > A sub > > goal of this question is to figure out what percentage of such devices use > > certificates. > > > > I would be grateful for any guesses, estimates or pointers to more info. > > IPSEC background info, lots of links: > http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/links.ipsec.html#pro tocols From owner-ipsec@lists.tislabs.com Mon Dec 4 06:21:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21310; Mon, 4 Dec 2000 06:21:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02558 Mon, 4 Dec 2000 07:58:07 -0500 (EST) Message-Id: <200012020149.RAA25771@road.xisp.net> To: ipsec@lists.tislabs.com, l2tp@ipsec.org Cc: kivinen@ssh.fi, anfreema@cisco.com, jari.arkko@ericsson.com Cc: gnu@toad.com Subject: IPsec/etc. Bakeoff in Finland Reply-To: hugh@xisp.net Date: Fri, 01 Dec 2000 17:49:27 -0800 From: Hugh Daniel Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- If the Finnish bakeoff were held within two or three weeks of the London IETF then I think attendance would be quite high, I would push for all of my team members to be there as we could do actual work out there in the free world. The only problem is that this a far away in time. Still count the FreeS/WAN team in. ||ugh Daniel hugh@toad.com Systems Testing & Project mis-Management The Linux FreeS/WAN Project http://www.freeswan.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOihVJlZpdJR7FBQRAQGFdQQAg9SLGLeUKiMFYTxsE/AsqwqTxaY9Tvri uVSU6XqXWC3ZxNHFUYG85Na9FTDw7AkDY/V7k5HzwFepua/YIMoDFRLDH6tTRcoq WaC7eocZASH/620R6jNEB/uEwvBKpnC6iAqo8gcsNgt5PJMq6uaySXMhc7KuMzGx e0Sexe9Iq+k= =OPfi -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 4 06:59:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24040; Mon, 4 Dec 2000 06:59:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02802 Mon, 4 Dec 2000 08:46:07 -0500 (EST) Message-ID: <496A8683261CD211BF6C0008C733261A963A83@email.quarrytech.com> From: "Ballou, Ken" To: ipsec@lists.tislabs.com Subject: Questions about RFC 2409 and Quick Mode identities Date: Sun, 3 Dec 2000 17:05:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think I need more words to clarify the identities in IKE Quick Mode. I'm puzzling over the fourth paragraph on page 17 of RFC 2409 (starting with "The identities of the SAs negotiated in Quick Mode"). At the top of page 18, in the definition of Quick Mode, I see optional IDci and IDcr identities on both the initiator and responder side. Since the notation is the same in both columns, does that mean the values of these identites have to be the same? That interpretation doesn't make sense to me. I would have read this as "the initiator wants to create an outbound SA for traffic whose source is the IDci and whose destination is the IDcr in the first message." Then, the responder says "OK, and I want to create an outbound SA whose source is the IDcr and whose destination is the IDci in my response message." I don't immediately see why the initiator's (IDci, IDcr) pair must match the responder's. Also, since the inbound end is the side that specifies the SPI value, I assume that in the first Quick Mode message, the initiator specifies the SPI that will be used for the SA the responder requests in the second message? Similarly, in the second message, the responder assigns an SPI to the SA selected from the initiator's proposal list in the first message? Thank you in advance for any help. - Ken From owner-ipsec@lists.tislabs.com Mon Dec 4 07:01:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24223; Mon, 4 Dec 2000 07:01:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02796 Mon, 4 Dec 2000 08:45:08 -0500 (EST) Message-ID: <496A8683261CD211BF6C0008C733261A963A82@email.quarrytech.com> From: "Ballou, Ken" To: ipsec@lists.tislabs.com Subject: Questions about RFC2401 and SPDs Date: Sun, 3 Dec 2000 16:53:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm trying to understand the IPsec RFCs (especially RFC 2401) in detail. I'd like to ask specific questions about the following scenario. Suppose I have two hosts, A and B. Each host has exactly one network interface. Suppose I have the following two outbound SPD entries on host A, in this order of precedence: 1. TCP traffic from any port on A to the telnet port 23 on B is to be protected by ESP confidentiality using triple-DES and AH using HMAC-SHA1, both applied in transport mode. 2. TCP traffic from any port on A to any port on B is to be protected by AH using HMAC-SHA1 in transport mode. => Question 1: Suppose the first TCP traffic from A to B is not telnet. Then, SPD rule 2 will apply to this traffic. Let's suppose that the result is that A negotiates an outbound SA (call it SA #1) with B. Now, suppose a user on host A tries to open a telnet session to host B, matching SPD rule 1. Is it permissible for A to negotiate just an SA to carry ESP-protected traffic, and then to form an SA bundle comprising this SA and SA #1 to apply to the telnet traffic? => Question 2: Assume as above that host A first negotiates outbound SA #1 with host B to carry AH-protected traffic. Suppose now that when the telnet connection from host A to host B is made, host A negotiates two SAs (SA #2 to carry ESP-protected traffic, SA #3 to carry AH-protected traffic). May host A then ignore SA #3 and instead use an SA bundle comprising SA #1 and SA #2 to carry the telnet traffic? In both cases, what are the applicable RFC citations? Thanks in advance for any help. I'm afraid right now the score is IPsec RFCs "N", Ken zero (and N is getting large :-) - Ken From owner-ipsec@lists.tislabs.com Mon Dec 4 10:35:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13008; Mon, 4 Dec 2000 10:35:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03511 Mon, 4 Dec 2000 11:54:28 -0500 (EST) Message-ID: <3A2BCC33.7E21539F@storm.ca> Date: Mon, 04 Dec 2000 11:54:11 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Khaja E. Ahmed" CC: ipsec@lists.tislabs.com Subject: Re: DH vs. RSA use for symmetric key exchange References: <200011301051.FAA25467@ietf.org> <005301c05bb5$d65a1550$e4570f18@plstn1.sfba.home.com> <3A27FB70.64CAD963@storm.ca> <015d01c05ddd$0273c130$e4570f18@plstn1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Khaja E. Ahmed" wrote: > 1.) Can someone point me to either a discussion archive or other material on > man in the middle attacks on IKE? There's a brief discussion in the glossary for FreeS/WAN, a Linux IPSEC implementation: http://www.freeswan.org/freeswan_trees/freeswan-1.8/doc/glossary.html#middle Links at the top of that document point to other glossaries, including an RFC Internet Security Glossary: http://www.rfc-editor.org/rfc/rfc2828.txt It gives: $ man-in-the-middle (I) A form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data in order to masquerade as one or more of the entities involved in a communication association. (See: hijack attack, piggyback attack.) (C) For example, suppose Alice and Bob try to establish a session key by using the Diffie-Hellman algorithm without data origin authentication service. A "man in the middle" could (a) block direct communication between Alice and Bob and then (b) masquerade as Alice sending data to Bob, (c) masquerade as Bob sending data to Alice, (d) establish separate session keys with each of them, and (e) function as a clandestine proxy server between them in order to capture or modify sensitive information that Alice and Bob think they are sending only to each other. From owner-ipsec@lists.tislabs.com Mon Dec 4 11:43:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18290; Mon, 4 Dec 2000 11:43:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03720 Mon, 4 Dec 2000 12:59:23 -0500 (EST) Message-ID: <003001c05e1c$3e2fa920$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Sandy Harris" , References: <200011301051.FAA25467@ietf.org> <005301c05bb5$d65a1550$e4570f18@plstn1.sfba.home.com> <3A27FB70.64CAD963@storm.ca> <015d01c05ddd$0273c130$e4570f18@plstn1.sfba.home.com> <3A2BCC33.7E21539F@storm.ca> Subject: Re: DH vs. RSA use for symmetric key exchange Date: Mon, 4 Dec 2000 10:01:35 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks again Sandy for the very useful pointers. I do wonder though... In a situation where one or both parties of a key exchange session has (have) an RSA public key certificate what is the advantage of using DH to exchange keys and then using RSA to authenticate the party? Why not do what happens in SSL / TLS? Use the RSA public key to exchange the symmetric key. Is one approach computationally more efficient than the other? Clearly IKE does not support use of RSA to do key exchange today. Is there a reason why this was not implemented / supported in IKE? Is this a useful thing to explore? Would there be any advantage to allowing / supporting both methods of exchanging keys? Khaja From owner-ipsec@lists.tislabs.com Mon Dec 4 15:41:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04103; Mon, 4 Dec 2000 15:41:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04369 Mon, 4 Dec 2000 17:15:33 -0500 (EST) Message-Id: <200012042216.OAA11058@cisco.com> X-Sender: sfluhrer@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 04 Dec 2000 14:13:22 -0800 To: "Khaja E. Ahmed" , "Sandy Harris" , From: Scott Fluhrer Subject: Re: DH vs. RSA use for symmetric key exchange In-Reply-To: <003001c05e1c$3e2fa920$e4570f18@plstn1.sfba.home.com> References: <200011301051.FAA25467@ietf.org> <005301c05bb5$d65a1550$e4570f18@plstn1.sfba.home.com> <3A27FB70.64CAD963@storm.ca> <015d01c05ddd$0273c130$e4570f18@plstn1.sfba.home.com> <3A2BCC33.7E21539F@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:01 AM 12/4/00 , Khaja E. Ahmed wrote: >Thanks again Sandy for the very useful pointers. > >I do wonder though... > >In a situation where one or both parties of a key exchange session has >(have) an RSA public key certificate what is the advantage of using DH to >exchange keys and then using RSA to authenticate the party? Why not do what >happens in SSL / TLS? Use the RSA public key to exchange the symmetric key. >Is one approach computationally more efficient than the other? Clearly IKE >does not support use of RSA to do key exchange today. Is there a reason why >this was not implemented / supported in IKE? Well, one problem with using RSA to do key exchange is if the RSA private key is compromised sometime in the future. With that, the attacker can go through his archives of recorded IKE/IPSec sessions, and decrypt all those sessions that used that key to exchange the symmetric keys. In other words, a session is secure if the private key is not compromised *and* if it will never be compromised in the future. With DH, that attack is not possible; the attacker can impersonate/do MITM attacks from that point on, but he is no closer to decrypting archived messages. >Is this a useful thing to explore? Would there be any advantage to >allowing / supporting both methods of exchanging keys? You really want to make IKE *more* complex??? -- poncho From owner-ipsec@lists.tislabs.com Mon Dec 4 15:41:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04104; Mon, 4 Dec 2000 15:41:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04301 Mon, 4 Dec 2000 16:43:10 -0500 (EST) Date: Mon, 4 Dec 2000 16:44:39 -0500 Message-Id: <200012042144.eB4Lidc14373@snap.thunk.org> To: ipsec@lists.tislabs.com Subject: IPSEC Agenda Topics From: tytso@mit.edu Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk These are the only people who have sent me e-mail requesting time for the San Diego IPSEC working group meeting. Please contact me ASAP if you have some additional topics you would like to propose and lead for the working group. (Notably missing from the list are SNMP MIB and Son-of-IKE topics...) - Ted Steve Kent 15-20 minutes extensions to IPSEC to accomodate higher speed nets, including a new AES-based mode NAT === Markus Stenberg 5-10 minutes stenberg-ipsec-nat-traversal-01.. say 5min? Ari Huttunen 5-10 minutes draft-huttunen-ipsec-esp-in-udp-00.txt Jayant 5-10 minutes draft-shukla-ipsec-nat-qos-compatible-security-00.txt From owner-ipsec@lists.tislabs.com Tue Dec 5 07:14:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21318; Tue, 5 Dec 2000 07:14:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07090 Tue, 5 Dec 2000 07:54:55 -0500 (EST) Message-Id: <3.0.6.32.20001205081723.02fd7db0@eketsv01.cubis.de> X-Sender: martius@eketsv01.cubis.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 05 Dec 2000 08:17:23 +0100 To: "Jari Arkko" , , From: Kai Martius Subject: Re: Next IPsec & L2TP Bakeoff In-Reply-To: <004f01c05bf4$596ae760$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, At 02:10 02.12.00 +0200, Jari Arkko wrote: >* If such an event would be organized, would you be willing > to travel to Europe for it? Would you have less or more > engineers than in the last bakeoff? I'd really appreciate such an event in Finland (the first bakeoff in Europe?), also the suggested timeframe after the London IETF. >* What is the rough idea about things to test? IPsec/IKE? IPv6 > & IPsec & IKE (we'd be very interested in that)? L2TP? L2TP/PPP > with real dial-in connections? Something else? Hopefully, the freeSWAN-project moves forward with IPv6 integration into the kernel until then - we'd have a great testing opportunity then... certificate-based stuff might also be an issue for interop testing (all kinds of cert management protocols). Kai -- Kai Martius secunet Security Networks AG, Dresden / Germany From owner-ipsec@lists.tislabs.com Tue Dec 5 08:05:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28295; Tue, 5 Dec 2000 08:04:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07384 Tue, 5 Dec 2000 09:14:02 -0500 (EST) Message-ID: From: Tim Jenkins To: "'tytso@mit.edu'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Agenda Topics Date: Tue, 5 Dec 2000 09:06:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As for the SNMP MIB, there have been next to no comments (one) on the versions submitted. I have one change to make, and that is to make all table indices not accessible. I didn't get this submitted before the cut-off, so they'll be submitted in late December or in the new year. Anyway, the lack of response to the last versions suggests that a) Everyone thinks they're perfect, (yeah, right) or b) No one cares, or c) Some other answer. In any case, no presentation is warranted due to the lack of activity. > -----Original Message----- > From: tytso@mit.edu [mailto:tytso@mit.edu] > Sent: Monday, December 04, 2000 4:45 PM > To: ipsec@lists.tislabs.com > Subject: IPSEC Agenda Topics > > > > These are the only people who have sent me e-mail requesting time for > the San Diego IPSEC working group meeting. > > Please contact me ASAP if you have some additional topics you > would like > to propose and lead for the working group. (Notably missing from the > list are SNMP MIB and Son-of-IKE topics...) > > - Ted > > > Steve Kent 15-20 minutes extensions to IPSEC to accomodate > higher speed nets, including a new > AES-based mode > > NAT > === > > Markus Stenberg 5-10 minutes > stenberg-ipsec-nat-traversal-01.. say 5min? > > Ari Huttunen 5-10 minutes draft-huttunen-ipsec-esp-in-udp-00.txt > > Jayant 5-10 minutes > draft-shukla-ipsec-nat-qos-compatible-security-00.txt > From owner-ipsec@lists.tislabs.com Tue Dec 5 11:32:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15825; Tue, 5 Dec 2000 11:32:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08157 Tue, 5 Dec 2000 12:39:44 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Stephen Kent'" Cc: Subject: RE: On transport-level policy enforcement (was Re: RFC 2401...) Date: Tue, 5 Dec 2000 12:30:15 -0500 Message-Id: <001f01c05ee1$09bae630$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We wrote the > generic checking description we didn't know how to cache SPD rules in > such circumstances. We now have ways of doing that which do not > violate the SPD ordering assumption. The next rev of 2401 will update > the inbound processing discussion accordingly. Steve, If you'd like to discuss how this will be done, either on the list or at the meeting, I think several of us would be interested. My instinct tells me that this is going to require some extra rules that limit the ways in which policy can be expressed, and I'm wondering what they are. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > Sent: Monday, November 27, 2000 4:18 PM > To: Dan McDonald > Cc: ipsec@lists.tislabs.com > Subject: Re: On transport-level policy enforcement (was Re: > RFC 2401...) > > > Dan, > > I was away for a week, and terribly far behind, so this reply is way > of out order, but ... > > Your analysis of how to do the checking is fine for a native host > implementation where per-connection state is already available. In a > security gateway, the problem is a bit different. We wrote the > generic checking description we didn't know how to cache SPD rules in > such circumstances. We now have ways of doing that which do not > violate the SPD ordering assumption. The next rev of 2401 will update > the inbound processing discussion accordingly. We can also divide > the discussion into SG vs. native host environments, to simplify > matters. > > Steve > From owner-ipsec@lists.tislabs.com Thu Dec 7 05:26:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21895; Thu, 7 Dec 2000 05:26:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA14257 Thu, 7 Dec 2000 06:22:45 -0500 (EST) Date: Thu, 7 Dec 2000 13:23:40 +0200 (IST) From: Hugo Krawczyk To: "Khaja E. Ahmed" cc: ipsec list Subject: Re: DH vs. RSA use for symmetric key exchange In-Reply-To: <003001c05e1c$3e2fa920$e4570f18@plstn1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Khaja, you make some valid points below. IKE could have accomodated a non-PFS (perfect forward secrecy) mode that would dispense of the cost of a DH exchange. A suggestion like that appeared once as an internet draft that is now expired. Such a mode would be useful in some situations. Particularly those that do not require confidentiality but just authentication. However, the current high-priority goal is to streamline IKE such that implementation complexity is lowered and inter-operability improved. In this state of affairs adding new modes is not productive. Hugo > Thanks again Sandy for the very useful pointers. > > I do wonder though... > > In a situation where one or both parties of a key exchange session has > (have) an RSA public key certificate what is the advantage of using DH to > exchange keys and then using RSA to authenticate the party? Why not do what > happens in SSL / TLS? Use the RSA public key to exchange the symmetric key. > Is one approach computationally more efficient than the other? Clearly IKE > does not support use of RSA to do key exchange today. Is there a reason why > this was not implemented / supported in IKE? Is this a useful thing to > explore? Would there be any advantage to allowing / supporting both methods > of exchanging keys? > > Khaja > > From owner-ipsec@lists.tislabs.com Thu Dec 7 13:26:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29524; Thu, 7 Dec 2000 13:26:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15798 Thu, 7 Dec 2000 14:09:07 -0500 (EST) Message-Id: <200012071909.eB7J9na115218@thunk.east.sun.com> From: Bill Sommerfeld To: "Khaja E. Ahmed" cc: "Hugo Krawczyk" , "ipsec list" Subject: Re: DH vs. RSA use for symmetric key exchange In-reply-to: Your message of "Thu, 07 Dec 2000 10:45:14 PST." <01d601c0607d$d66efbb0$e4570f18@plstn1.sfba.home.com> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 07 Dec 2000 14:09:48 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Is PFS intended to cover the risk associated with an RSA private key being > compromised? If so, I assume it would apply to DH keys as well if they get > reused. An optimization in IKE ( I think ) is the ability to reuse DH keys > to establish multiple SAs and generate multiple keys. Is there any > recommendation on how many SAs can be generated or for how long a DH key can > be used? I've never previously seen a suggestion that IKE should use non-ephemeral DH keys, so it's fair to say, "one DH key, one (phase 1) SA" and "one DH key, one (phase 2 with pfs) SA". - Bill From owner-ipsec@lists.tislabs.com Thu Dec 7 13:58:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00874; Thu, 7 Dec 2000 13:58:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15742 Thu, 7 Dec 2000 13:43:00 -0500 (EST) Message-ID: <01d601c0607d$d66efbb0$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Hugo Krawczyk" , "ipsec list" References: Subject: Re: DH vs. RSA use for symmetric key exchange Date: Thu, 7 Dec 2000 10:45:14 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for taking the time to explain Hugo. I fully understand the desire to keep IKE's complexity as low as possible. In particular, as Schneier points out in his review the more complicated a protocol, the greater the likelihood of security flaws in it. I therefore understand why this was not implemented. I would like to make sure I understand the point you made about PFS though. I thought that using RSA to exchange keys would introduce a "simple" mode that would eliminate DH entirely. Especially where an RSA key certificate is being used for authentication the initiator already has to implement path processing and other complex PKI logic. In such a situation if we just drop DH and use RSA instead to exchange the keys _this_ _particular_ exchange becomes simpler. Also, I was under the impression that it would ensure PFS rather than detract from it. I thought PFS has to do with not using material from (or related to) a previous key to generate each subsequent key. Do we here use PFS to mean that the symmetric key should not only not be derived from a previous key but must not be encrypted with the same key as before? Is PFS intended to cover the risk associated with an RSA private key being compromised? If so, I assume it would apply to DH keys as well if they get reused. An optimization in IKE ( I think ) is the ability to reuse DH keys to establish multiple SAs and generate multiple keys. Is there any recommendation on how many SAs can be generated or for how long a DH key can be used? An slightly related and more practical question: The appropriate method / approach of benchmarking an IPSec implementation is likely to be somewhat complex. Given the flexibility of how SAs can be established, modes employed etc information like "able to establish n IPSec sessions per second" is very incomplete! Are 10 IPSec SAs being established per IKE SA or one? What is the ratio of DH exchanges to IKE SAs to IPSec SAs? I am guessing that per DH exchange more than one IKE SA can be established. Per IKE SA more than one IPSec SA can be established. Is this correct? Khaja ----- Original Message ----- From: "Hugo Krawczyk" To: "Khaja E. Ahmed" Cc: "ipsec list" Sent: Thursday, December 07, 2000 3:23 AM Subject: Re: DH vs. RSA use for symmetric key exchange > Khaja, you make some valid points below. > IKE could have accomodated a non-PFS (perfect forward secrecy) mode that > would dispense of the cost of a DH exchange. A suggestion like that > appeared once as an internet draft that is now expired. Such a mode would > be useful in some situations. Particularly those that do not require > confidentiality but just authentication. However, the current > high-priority goal is to streamline IKE such that implementation > complexity is lowered and inter-operability improved. In this > state of affairs adding new modes is not productive. > > Hugo > > > > > Thanks again Sandy for the very useful pointers. > > > > I do wonder though... > > > > In a situation where one or both parties of a key exchange session has > > (have) an RSA public key certificate what is the advantage of using DH to > > exchange keys and then using RSA to authenticate the party? Why not do what > > happens in SSL / TLS? Use the RSA public key to exchange the symmetric key. > > Is one approach computationally more efficient than the other? Clearly IKE > > does not support use of RSA to do key exchange today. Is there a reason why > > this was not implemented / supported in IKE? Is this a useful thing to > > explore? Would there be any advantage to allowing / supporting both methods > > of exchanging keys? > > > > Khaja > > > > > > From owner-ipsec@lists.tislabs.com Thu Dec 7 17:46:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08323; Thu, 7 Dec 2000 17:46:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16798 Thu, 7 Dec 2000 18:41:34 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Khaja E. Ahmed'" , "'Hugo Krawczyk'" , "'ipsec list'" Subject: RE: DH vs. RSA use for symmetric key exchange Date: Thu, 7 Dec 2000 18:32:21 -0500 Message-Id: <003d01c060a5$f30c3df0$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 Importance: Normal In-Reply-To: <01d601c0607d$d66efbb0$e4570f18@plstn1.sfba.home.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I thought PFS has to do with not using material from (or related to) a > previous key to generate each subsequent key. Do we here use > PFS to mean > that the symmetric key should not only not be derived from a > previous key > but must not be encrypted with the same key as before? As I pointed out in a thread a few months ago (see http://www.vpnc.org/ietf-ipsec/mail-archive/msg01761.html), the meaning of PFS has changed over the years. The original PFS property (which ensures that stored traffic cannot be decrypted if a private key is eventually compromised) is much more important than the modern "QM PFS" property (which is a less secure optimization of phase 1 rekeying). Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Dec 7 18:00:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08597; Thu, 7 Dec 2000 18:00:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16916 Thu, 7 Dec 2000 19:28:07 -0500 (EST) Message-ID: <022c01c060ae$0e21b540$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: Cc: "Hugo Krawczyk" , "ipsec list" References: <200012071909.eB7J9na115218@thunk.east.sun.com> Subject: Re: DH vs. RSA use for symmetric key exchange Date: Thu, 7 Dec 2000 16:30:23 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In reading the first half of para 3 on page 6 of RFC.2409 I arrived at the understanding that the ratio need _not_ be 1:1:1. The para is below: " With the use of ISAKMP phases, an implementation can accomplish very fast keying when necessary. A single phase 1 negotiation may be used for more than one phase 2 negotiation. Additionally a single phase 2 negotiation can request multiple Security Associations. With these optimizations, an implementation can see less than one round trip per SA as well as less than one DH exponentiation per SA. " Did I misunderstand it? Khaja ----- Original Message ----- From: "Bill Sommerfeld" To: "Khaja E. Ahmed" Cc: "Hugo Krawczyk" ; "ipsec list" Sent: Thursday, December 07, 2000 11:09 AM Subject: Re: DH vs. RSA use for symmetric key exchange > > Is PFS intended to cover the risk associated with an RSA private key being > > compromised? If so, I assume it would apply to DH keys as well if they get > > reused. An optimization in IKE ( I think ) is the ability to reuse DH keys > > to establish multiple SAs and generate multiple keys. Is there any > > recommendation on how many SAs can be generated or for how long a DH key can > > be used? > > I've never previously seen a suggestion that IKE should use > non-ephemeral DH keys, so it's fair to say, "one DH key, one (phase 1) > SA" and "one DH key, one (phase 2 with pfs) SA". > > - Bill > From owner-ipsec@lists.tislabs.com Fri Dec 8 01:28:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA10067; Fri, 8 Dec 2000 01:28:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17762 Fri, 8 Dec 2000 02:27:01 -0500 (EST) Message-ID: <3A308D46.30EFD529@storm.ca> Date: Fri, 08 Dec 2000 02:27:02 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec list Subject: Re: DH vs. RSA use for symmetric key exchange References: <01d601c0607d$d66efbb0$e4570f18@plstn1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Khaja E. Ahmed" wrote: > I thought that using RSA to exchange keys would introduce a "simple" mode > that would eliminate DH entirely. Yes, but it would thereby lose much of the security. Suppose I've broken RSA or acquired your RSA keys by whatever means -- breaking into your system, bribing or coercing someone, a tempest attack, ... Suppose I've also built an archive of all your traffic for the last several weeks and am planning to keep monitoring you. If your session keys are protected only by RSA encryption, the game ends there. I can immediately decrypt all the archived session keys and read the archived traffic. I can also read future traffic (as long as those RSA keys remain in play) as easily as the person you're communicating with can. That is, if I get your RSA keys, your security just became zero. One failure breaks the whole system. However, if RSA is used only to authenticate a Diffie-Hellman key negotiation then losing your RSA keys only exposes you to attacks on the authentication. I can pose as one player and fool the other. This is a disaster, but does not completely destroy your security. With only one key I cannot pose as any player except that one and I may not know enough to pose convincingly as that one. If I have both keys and can intercept or re-route packets appropriately (which requires some non-trivial subversion of the network, e.g. DNS or routers) then I can conduct an active man-in-the-middle that gets me one session key, and therefore of course everything encrypted with it. However, I have to repeat that man-in-the-middle attack, in real time and undetected, every time you change keys. Moreover, I cannot conduct such an attack at all against all that lovely traffic I've archived. So with RSA authentication of DH key negotiations, security is partly maintained even if the RSA keys are compromised. You're still in trouble, but at least you're still secure against passive attacks -- even with the RSA keys a passive snoop gets no session keys, short of breaking DH -- and the enemy cannot read archived messages. Moreover, the attacker still has work to do before he reads any traffic. He has to conduct a successful impersonation or a man-in-the-middle attack. > ... Especially where an RSA key certificate > is being used for authentication the initiator already has to implement path > processing and other complex PKI logic. In such a situation if we just drop > DH and use RSA instead to exchange the keys _this_ _particular_ exchange > becomes simpler. It may simplify this exchange, but not the protocol. To make RSA encryption of session keys as secure as DH negotiation with RSA authentication you would have to add some mechanism for frequent changes of the RSA keys with secure and authenticated notification of partners. I'm not sure if this is possible. Certainly the resulting protocol would be more complex than what we have. From owner-ipsec@lists.tislabs.com Fri Dec 8 05:51:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04519; Fri, 8 Dec 2000 05:51:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18464 Fri, 8 Dec 2000 06:41:53 -0500 (EST) Message-ID: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Subject: IPv6 Neighbour Solicitation messages and IPsec Date: Fri, 8 Dec 2000 13:43:30 +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 I'm wondering if there are any documents that specify rules regarding the use of IPsec in the context of IPv6 Neighbor Solicitations and possibly other ICMPv6 messages. As defined by http://www.ietf.org/rfc/rfc2461.txt, and http://www.ietf.org/rfc/rfc2462.txt such IPv6 messages are needed to perform the address resolution, address autoconfiguration, and duplicate address detection tasks. It seems that in some cases these messages can be unicast messages between the two nodes. (When the messages are multicast, IPsec doesn't apply.) It also seems that regular packets can't flow until the ICMPv6 packets have been exchanged, making sure the nodes know the link layer addresses and that no duplicate addresses are in use. I've run in to an interesting chicken-and-egg problem in this area as I'm developing an IPv6 IPsec implementation. If I set my policies in a way that all traffic in a LAN/WLAN should be protected with IPsec, then even some of these ICMPv6 messages are trapped by IPsec. In order to establish a security association, IKE needs to exchange a few UDP packets. However, if normal traffic can't flow until the ICMPv6 messages are exchanged, how can the UDP packets get through? In IPv4, this problem doesn't exist as either the corresponding functionality does not exist (duplicate address detection) or runs at a lower layer (ARP). http://www.ietf.org/rfc/rfc2401.txt talks a lot of IPv6 and ICMP, but doesn't seem to help in this matter. Also, the SPD requirements outlined in this RFC do not seem to be general enough to distinguish e.g. Neighbour Solicitations from Echo Requests, making it hard to define the policies in a suitable way. Can some folks who have done this before let me know how this should work, point to some existing documentation, or perhaps correct my understanding of the ICMPv6 operations. Thanks, Jari Arkko Ericsson From owner-ipsec@lists.tislabs.com Fri Dec 8 07:24:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12976; Fri, 8 Dec 2000 07:24:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19014 Fri, 8 Dec 2000 08:32:20 -0500 (EST) Date: Fri, 8 Dec 2000 15:31:43 +0200 (IST) From: Hugo Krawczyk To: "Khaja E. Ahmed" cc: ipsec list Subject: Re: DH vs. RSA use for symmetric key exchange In-Reply-To: <01d601c0607d$d66efbb0$e4570f18@plstn1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I thought that using RSA to exchange keys would introduce a "simple" mode > that would eliminate DH entirely. Especially where an RSA key certificate > is being used for authentication the initiator already has to implement path > processing and other complex PKI logic. In such a situation if we just drop > DH and use RSA instead to exchange the keys _this_ _particular_ exchange > becomes simpler. This is correct regarding the _particular_ exchange but not the general complexity of the protocol (especially when there is so MUCH confusion around about the cryptographic functionality and soundnes of these protocols). I will not be surprised if one day in the future such a DH-less mode be incorporated and used but now it is not the time. > Also, I was under the impression that it would ensure PFS > rather than detract from it. It will completely destroy the PFS principle that states that "the exposure of long-term key material should not compromise short-term keys". One thing to note, however, is that in the case of IKE if you skip the DH exchange and derive keys from the RSA encrypted key material then (contrary to what Sandy wrote) an attacker that finds your RSA private key CANNOT read all your traffic. It rather needs the private keys of BOTH sides to the exchange. This is still not PFS but much better than the scenario described by Sandy. > > I thought PFS has to do with not using material from (or related to) a > previous key to generate each subsequent key. Do we here use PFS to mean > that the symmetric key should not only not be derived from a previous key > but must not be encrypted with the same key as before? > > Is PFS intended to cover the risk associated with an RSA private key being > compromised? If so, I assume it would apply to DH keys as well if they get > reused. An optimization in IKE ( I think ) is the ability to reuse DH keys > to establish multiple SAs and generate multiple keys. Is there any > recommendation on how many SAs can be generated or for how long a DH key can > be used? Reusing DH keys is not specified in IKE. But the ipsec-veterans may remember that Photuris allowed for it. One interesting issue is that regardless of the sepcification, an implementation can choose to do such re-use without anything being discovered by the other party. IKE was designed to ensure that even under such re-use the derived key material is different in each session (as the derivation involves fresh per-session nonces). You may find some further information and answers to some of your questions in my SKEME paper (an on-line copy should still be available from http://www.research.ibm.com/security/skeme.ps) Hugo From owner-ipsec@lists.tislabs.com Fri Dec 8 09:54:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26609; Fri, 8 Dec 2000 09:54:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19385 Fri, 8 Dec 2000 11:21:44 -0500 (EST) Message-ID: <3A310B4D.45AADB91@gmx.net> Date: Fri, 08 Dec 2000 17:24:45 +0100 From: Patrick Lotti Reply-To: Patrick.Lotti@computer.org X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en,de,ko,ja,pl,fr,zh,zh-CN,zh-TW MIME-Version: 1.0 To: ipsec list Subject: Re: DH vs. RSA use for symmetric key exchange References: <200012071909.eB7J9na115218@thunk.east.sun.com> <022c01c060ae$0e21b540$e4570f18@plstn1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Khaja E. Ahmed" wrote: > In reading the first half of para 3 on page 6 of RFC.2409 I arrived at the > understanding that the ratio need _not_ be 1:1:1. > > The para is below: > > " With the use of ISAKMP phases, an implementation can accomplish very > fast keying when necessary. A single phase 1 negotiation may be used > > for more than one phase 2 negotiation. Additionally a single phase 2 > > negotiation can request multiple Security Associations. With these > > optimizations, an implementation can see less than one round trip per > > SA as well as less than one DH exponentiation per SA. " > > Did I misunderstand it? You're right with: One DH can be used to establish multiple SAs. But: The DH (ISAKMP SA) is valid for 8hours only, by default. Then IKE will change the DH automatically for you, minimizing security risks. As there's NO proof of DH/RSA to be un-breakable, i.e. 100% safe, it is adviceable to change the used keys after a certain amout of time (or data encrypted with). For "hard" PFS, a new DH is used for each SA. But this is not really practical as is it hardly improves your security (in many cases). Just follow Andrew for the latest PFS definition: ---cut here--- As I pointed out in a thread a few months ago (see http://www.vpnc.org/ietf-ipsec/mail-archive/msg01761.html), the meaning of PFS has changed over the years. ---cut here Patrick > > > Khaja > > ----- Original Message ----- > From: "Bill Sommerfeld" > To: "Khaja E. Ahmed" > Cc: "Hugo Krawczyk" ; "ipsec list" > > Sent: Thursday, December 07, 2000 11:09 AM > Subject: Re: DH vs. RSA use for symmetric key exchange > > > > Is PFS intended to cover the risk associated with an RSA private key > being > > > compromised? If so, I assume it would apply to DH keys as well if they > get > > > reused. An optimization in IKE ( I think ) is the ability to reuse DH > keys > > > to establish multiple SAs and generate multiple keys. Is there any > > > recommendation on how many SAs can be generated or for how long a DH key > can > > > be used? > > > > I've never previously seen a suggestion that IKE should use > > non-ephemeral DH keys, so it's fair to say, "one DH key, one (phase 1) > > SA" and "one DH key, one (phase 2 with pfs) SA". > > > > - Bill > > From owner-ipsec@lists.tislabs.com Fri Dec 8 09:58:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26880; Fri, 8 Dec 2000 09:58:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19347 Fri, 8 Dec 2000 11:05:22 -0500 (EST) Message-Id: <200012081604.RAA58587@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec In-reply-to: Your message of Fri, 08 Dec 2000 13:43:30 +0200. <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> Date: Fri, 08 Dec 2000 17:04:29 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I'm wondering if there are any documents that specify rules regarding the use of IPsec in the context of IPv6 Neighbor Solicitations and possibly other ICMPv6 messages. => there was a nice presentation by Dan McDonald at a previous IETF about this (Adelaide, 47th, "Link shared secrets for ND") but no draft... I've run in to an interesting chicken-and-egg problem in this area as I'm developing an IPv6 IPsec implementation. => yes, ND should bypass the IPsec policy in some cases, for instance if the policy applies to any protocol, including ICMPv6. Also, the SPD requirements outlined in this RFC do not seem to be general enough to distinguish e.g. Neighbour Solicitations from Echo Requests, making it hard to define the policies in a suitable way. => there is a discussion about the PF_KEY API in order to solve this issue (is this API good for SPD setup is another point). Can some folks who have done this before let me know how this should work, point to some existing documentation, or perhaps correct my understanding of the ICMPv6 operations. => open issue, near no work about it! Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Dec 8 11:29:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03114; Fri, 8 Dec 2000 11:29:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19594 Fri, 8 Dec 2000 12:44:07 -0500 (EST) Message-ID: <031401c0613e$ccb82260$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Hugo Krawczyk" Cc: "ipsec list" References: Subject: Re: DH vs. RSA use for symmetric key exchange Date: Fri, 8 Dec 2000 09:46:31 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you. Khaja ----- Original Message ----- From: "Hugo Krawczyk" To: "Khaja E. Ahmed" Cc: "ipsec list" Sent: Friday, December 08, 2000 5:31 AM Subject: Re: DH vs. RSA use for symmetric key exchange > > > > I thought that using RSA to exchange keys would introduce a "simple" mode > > that would eliminate DH entirely. Especially where an RSA key certificate > > is being used for authentication the initiator already has to implement path > > processing and other complex PKI logic. In such a situation if we just drop > > DH and use RSA instead to exchange the keys _this_ _particular_ exchange > > becomes simpler. > > This is correct regarding the _particular_ exchange but not the general > complexity of the protocol (especially when there is so MUCH confusion around > about the cryptographic functionality and soundnes of these protocols). > I will not be surprised if one day in the future such a DH-less mode > be incorporated and used but now it is not the time. > > > Also, I was under the impression that it would ensure PFS > > rather than detract from it. > > It will completely destroy the PFS principle that states that > "the exposure of long-term key material should not compromise > short-term keys". One thing to note, however, is that in the case of > IKE if you skip the DH exchange and derive keys from the > RSA encrypted key material then (contrary to what Sandy wrote) > an attacker that finds your RSA private key CANNOT read all your traffic. > It rather needs the private keys of BOTH sides to the exchange. > This is still not PFS but much better than the scenario described by > Sandy. > > > > > I thought PFS has to do with not using material from (or related to) a > > previous key to generate each subsequent key. Do we here use PFS to mean > > that the symmetric key should not only not be derived from a previous key > > but must not be encrypted with the same key as before? > > > > Is PFS intended to cover the risk associated with an RSA private key being > > compromised? If so, I assume it would apply to DH keys as well if they get > > reused. An optimization in IKE ( I think ) is the ability to reuse DH keys > > to establish multiple SAs and generate multiple keys. Is there any > > recommendation on how many SAs can be generated or for how long a DH key can > > be used? > > Reusing DH keys is not specified in IKE. But the ipsec-veterans may remember > that Photuris allowed for it. One interesting issue is that regardless > of the sepcification, an implementation can choose to do such re-use without > anything being discovered by the other party. IKE was designed to ensure > that even under such re-use the derived key material is different in each > session (as the derivation involves fresh per-session nonces). > > You may find some further information and answers to some of your > questions in my SKEME paper (an on-line copy should still be available > from http://www.research.ibm.com/security/skeme.ps) > > Hugo > > > > From owner-ipsec@lists.tislabs.com Fri Dec 8 14:46:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14073; Fri, 8 Dec 2000 14:46:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19999 Fri, 8 Dec 2000 15:28:44 -0500 (EST) Message-ID: <02cc01c06166$5e65c420$88a245ab@venkatp> From: "Venkat RK Reddy" To: References: <005d01c05d7a$9dc1f020$8a1b6e0a@arenanet.fi> Subject: MAC on ISAKMP Proposals Date: Fri, 8 Dec 2000 14:29:46 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Iam a newbie here, pardon me for this dumb question. Do ISAKMP do MAC on main mode so as to prevent an attacker take control over the responder's selection of transform payloads sent to it ?? If not, what is the design consideration of not doing the MAC ?? I would appreciate if someone could point me to some kind of discussion/whitepaper over this issue. Thanks, Venkat. From owner-ipsec@lists.tislabs.com Mon Dec 11 01:30:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA15932; Mon, 11 Dec 2000 01:30:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA25946 Mon, 11 Dec 2000 02:24:21 -0500 (EST) Date: Mon, 11 Dec 2000 08:25:57 +0100 From: Stefan Schlott To: ipsec@lists.tislabs.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec Message-ID: <20001211082557.A2125@orca.informatik.uni-ulm.de> References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Fri, Dec 08, 2000 at 01:43:30PM +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, > I'm wondering if there are any documents that specify rules regarding the > use of IPsec in the context of IPv6 Neighbor Solicitations and possibly > other ICMPv6 messages. > (...) > I've run in to an interesting chicken-and-egg problem in this area as I'm > developing an IPv6 IPsec implementation. If I set my policies in a way that > all traffic in a LAN/WLAN should be protected with IPsec, then even some of these > ICMPv6 messages are trapped by IPsec. IKE uses its own protection mechanisms and should be allowed to pass IPsec unprocessed. During my efforts to implement IPsec (or, at least, some basic functions of it) for the IPv6 stack of Linux, I finally allowed all ICMP messages to pass unprocessed - securing ICMP broke too many things; this is certainly not an optimal solution, but it'll have to be sufficient for the moment. I don't think it will make much sense to process some kind of ICMP messages (e.g. ping). Enforcing IPsec on other ICMP messages will break interoperability with non-IPsec hosts, and making IPsec simply optional doesn't make sense imho. Stefan. -- *--- please cut here... -------------------------------------- thanks! ---* |-> E-Mail: stefan.schlott@informatik.uni-ulm.de PGP-Key: 0x2F36F4FE <-| | If Bill Gates had a dime for every time a Windows box crashed... oh, | | wait a minute -- he already does. | | -- Seen on Slashdot (19.04.2000) | *-------------------------------------------------------------------------* From owner-ipsec@lists.tislabs.com Mon Dec 11 02:01:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17110; Mon, 11 Dec 2000 02:01:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA26178 Mon, 11 Dec 2000 03:41:07 -0500 (EST) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9C8D@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE notifications Date: Mon, 11 Dec 2000 10:42:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, One curiosity, when an encrypted informational messaged in received and decoded successfully must the negotiation be always aborted or resend the last message until the retransmission count is reached? Currently I'm basically logging the messages but I don't do anything with them, but I was thinking that maybe it would be better to just abort the negotiaton because it's not really possible to recover from the error because usually they are due to configuration errors. A short answer will suffice. Thanks! Toni From owner-ipsec@lists.tislabs.com Mon Dec 11 04:27:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22178; Mon, 11 Dec 2000 04:27:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26605 Mon, 11 Dec 2000 06:00:20 -0500 (EST) Message-ID: From: Rohit Khosla To: "'ipsec@lists.tislabs.com'" Subject: Aggresive mode connection Date: Mon, 11 Dec 2000 16:45:39 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am trying to setup aggresive mode session between OpenBSD and VPNet box but my SA is getting negotiated using main mode. I don't know whats happening??? Can anybody tell me why is it behaving so?? Thanks, Rohit. From owner-ipsec@lists.tislabs.com Mon Dec 11 05:00:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22816; Mon, 11 Dec 2000 05:00:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26687 Mon, 11 Dec 2000 06:27:12 -0500 (EST) Reply-To: From: "sridharj" To: , Subject: RE: IKE notifications Date: Mon, 11 Dec 2000 16:51:58 +0530 Message-Id: <000501c06364$941298a0$6e0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A051A9C8D@eseis06nok> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmmm... in our implementation we are retransmitting... . you are right that (most of the)error occur due to config errors -----Original Message----- From: owner-ipsec@lists.tislabs.com Hi, One curiosity, when an encrypted informational messaged in received and decoded successfully must the negotiation be always aborted or resend the last message until the retransmission count is reached? Currently I'm basically logging the messages but I don't do anything with them, but I was thinking that maybe it would be better to just abort the negotiaton because it's not really possible to recover from the error because usually they are due to configuration errors. A short answer will suffice. Thanks! Toni From owner-ipsec@lists.tislabs.com Mon Dec 11 06:27:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25249; Mon, 11 Dec 2000 06:27:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26877 Mon, 11 Dec 2000 07:39:44 -0500 (EST) Date: Mon, 11 Dec 2000 09:36:37 +0800 (CST) From: YaNan Guo To: ipsec@lists.tislabs.com Subject: Give me a example to test AH header! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello: I do not know how to test AH header. Now i have 2 machine, one is 3ffe:3216:2101:2151::2(fxzhang), the other is 3ffe:3216:2101:2152::5(ajax). The famous scientists want to see the function of AH and ESP. I design a ftp session for ESP. But I do not know how to test AH header. Both machine installed freebsd3.4 and kame-20000417-snapshot. I will use setkey to test AH. Who can give me a demostration method? For example, before using AH ipsec header, hacker can do ....; then after using AH, hacker can not do...., like this. Need other software to act as Hacker-attacking software ? How to perform it vividly and make these scientists feel kame is really COOL! By the way, these scientists are not good at computer networks. So the method must be clear and simple. Thanks! I am very glad to hear from you ! From owner-ipsec@lists.tislabs.com Mon Dec 11 12:10:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05208; Mon, 11 Dec 2000 12:10:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28146 Mon, 11 Dec 2000 13:17:14 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 11 Dec 2000 11:16:54 -0700 From: "Hilarie Orman" To: , Cc: , Subject: Re: IKE should not do policy [Re: Query : PF_KEY related] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA28143 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IPSP WG has several drafts relating to discovery and negotiation of IPSec Policy. In general, IKE cannot always make an offer that will result in establishing an SA, even when the parties involved have mutually acceptable policies. The problem is exacerbated when multiple gateways are involved. IPSP was created to solve this problem. Other IPSP drafts relate to the information model for representing configuration policy and its instantiation for specific repositories, such as COPS. Commentary on the IPSP drafts by hardcore IPSec'ers is welcome. Hilarie IPSP co-chair From owner-ipsec@lists.tislabs.com Mon Dec 11 12:11:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05254; Mon, 11 Dec 2000 12:11:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28197 Mon, 11 Dec 2000 13:31:41 -0500 (EST) From: "Joseph D. Harwood" To: "Ipsec" Subject: RE: IPv6 Neighbour Solicitation messages and IPsec Date: Mon, 11 Dec 2000 08:22:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C0634B.708D9D80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20001211082557.A2125@orca.informatik.uni-ulm.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C0634B.708D9D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Has not securing ICMP messages caused any interoperability problems that you've heard of? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stefan Schlott > Sent: Sunday, December 10, 2000 11:26 PM > To: ipsec@lists.tislabs.com > Subject: Re: IPv6 Neighbour Solicitation messages and IPsec > > > Hello, > > > I'm wondering if there are any documents that specify rules > regarding the > > use of IPsec in the context of IPv6 Neighbor Solicitations and possibly > > other ICMPv6 messages. > > (...) > > I've run in to an interesting chicken-and-egg problem in this > area as I'm > > developing an IPv6 IPsec implementation. If I set my policies > in a way that > > all traffic in a LAN/WLAN should be protected with IPsec, then > even some of these > > ICMPv6 messages are trapped by IPsec. > IKE uses its own protection mechanisms and should be allowed to pass IPsec > unprocessed. During my efforts to implement IPsec (or, at least, > some basic > functions of it) for the IPv6 stack of Linux, I finally allowed all ICMP > messages to pass unprocessed - securing ICMP broke too many things; this > is certainly not an optimal solution, but it'll have to be sufficient for > the moment. I don't think it will make much sense to process some kind > of ICMP messages (e.g. ping). Enforcing IPsec on other ICMP messages will > break interoperability with non-IPsec hosts, and making IPsec simply > optional doesn't make sense imho. > > Stefan. > > -- > *--- please cut here... -------------------------------------- > thanks! ---* > |-> E-Mail: stefan.schlott@informatik.uni-ulm.de PGP-Key: > 0x2F36F4FE <-| > | If Bill Gates had a dime for every time a Windows box > crashed... oh, | > | wait a minute -- he already does. > | > | -- Seen on Slashdot (19.04.2000) > | > *----------------------------------------------------------------- > --------* > ------=_NextPart_000_0003_01C0634B.708D9D80 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0003_01C0634B.708D9D80-- From owner-ipsec@lists.tislabs.com Mon Dec 11 13:32:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06892; Mon, 11 Dec 2000 13:32:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28411 Mon, 11 Dec 2000 14:49:42 -0500 (EST) Message-ID: <3A353089.734F00E4@gmx.net> Date: Mon, 11 Dec 2000 20:52:41 +0100 From: Patrick Lotti Reply-To: Patrick.Lotti@computer.org X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en,de,ko,ja,pl,fr,zh,zh-CN,zh-TW MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Give me a example to test AH header! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, perhaps you can implement a "buggy" repeater, doing the man-in-the- middle-attack, with a setup like this: fxzhang repeater ajax | | | | --------- ------- I think a linux box should be able to do this, (with raw reading and writing?). The software to copy data between the interfaces then should include a filter that would change some bytes, and recalc. the IP checksum. To make it easy, and keep on ftp: Let the filter exchange "love" vs. "hate", and transmit a love-letter via ftp. I think only very active hackers and govs _might_ have such software... If your presentation is not interactive you can "fake" everything, that'll have much less work! Patrick YaNan Guo wrote: > Hello: > I do not know how to test AH header. > Now i have 2 machine, one is 3ffe:3216:2101:2151::2(fxzhang), > the other is 3ffe:3216:2101:2152::5(ajax). > The famous scientists want to see the function of AH and ESP. > I design a ftp session for ESP. But I do not know how to test > AH header. > Both machine installed freebsd3.4 and kame-20000417-snapshot. > I will use setkey to test AH. > Who can give me a demostration method? For example, before > using AH ipsec header, hacker can do ....; then after using > AH, hacker can not do...., like this. > Need other software to act as Hacker-attacking software ? > How to perform it vividly and make these scientists feel > kame is really COOL! By the way, these scientists are not good > at computer networks. So the method must be clear and simple. > > Thanks! I am very glad to hear from you ! From owner-ipsec@lists.tislabs.com Tue Dec 12 01:51:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA16807; Tue, 12 Dec 2000 01:51:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA00206 Tue, 12 Dec 2000 02:41:54 -0500 (EST) Date: Tue, 12 Dec 2000 08:43:32 +0100 From: Stefan Schlott To: ipsec@lists.tislabs.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec Message-ID: <20001212084332.B2948@orca.informatik.uni-ulm.de> References: <20001211082557.A2125@orca.informatik.uni-ulm.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jharwood@vesta-corp.com on Mon, Dec 11, 2000 at 08:22:02AM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, > Has not securing ICMP messages caused any interoperability problems that > you've heard of? Well, being honestly - I haven't gotten so far yet :-) I ran into "intra-operability" problems (i.e. communication with a non-IPsec Linux box), so I decided to allow ICMP messages to pass unprocessed. I _think_ there should be no interoperability problems if these messages are not secured. As I already stated, it is not necessary to secure several kind of ICMPs (e.g. ping). Regarding some other types (e.g. Neighborhood discovery, PMTU detection), authentication might be useful; but: - as long as you accept both authenticated and unauthenticated messages, the whole system is vulnerable to faked messages - there is no method known to me to handle IPsec broadcasts (which would be necessary for securing neighborhood messages, correct?) - If some kind of key exchange is necessary, and the messages exceed the minimum PMTU of IPv6, it is quite possible that you run into trouble when trying to secure PMTU messages. Looking at that list, I doubt it is possible to use IPsec on ICMP in a useful way... Stefan. -- *--- please cut here... -------------------------------------- thanks! ---* |-> E-Mail: stefan.schlott@informatik.uni-ulm.de PGP-Key: 0x2F36F4FE <-| | Heh, heh, I have an "NSA Hitachi" monitor on my desk... Must have a | | hidden camera in it? | | -- Seen in the thread "NSA and MS windows" on sci.crypt (06.09.1999) | *-------------------------------------------------------------------------* From owner-ipsec@lists.tislabs.com Tue Dec 12 04:32:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08536; Tue, 12 Dec 2000 04:32:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00610 Tue, 12 Dec 2000 05:51:32 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IKE attributes consistency. X-Mailer: Cue version 0.6 (001128-1517/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20001212195528P.sakane@ydc.co.jp> Date: Tue, 12 Dec 2000 19:55:28 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 30 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are all of IKE attributes always consistent ? No, there is one exception. IPCOMP proposal does not convey PFS group number in its attribute even if phase 2 needs PFS, although RFC2409 5.5 Phase 2 - Quick Mode says the following: All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST apply to every SA in the negotiation. To circumvent the issue, draft-shacham-ippcp-rfc2393bis-06.txt has the folowing text in section 4.1. When IPComp is negotiated as part of a Protection Suite, all the logically related offers must be consistent. However, an IPComp proposal SHOULD NOT include attributes that are not applicable to IPComp. An IPComp proposal MUST NOT be rejected because it does not include attributes of other protocols in the Protection Suite that are not relevant to IPComp. When an IPComp proposal includes such attributes, those attributes MUST be ignored when setting the IPCA, and therefore ignored in the operation of IPComp. we need a consistent rule all over the attribute parsing, so: (1) we always attach the same attributes, for all transforms. (2) apply suggestion in ippcp draft section 4.1 to all transforms. if there's no attribute, ignore it (if it is mandatory, bark). //KAME Project From owner-ipsec@lists.tislabs.com Tue Dec 12 04:33:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08612; Tue, 12 Dec 2000 04:33:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00606 Tue, 12 Dec 2000 05:51:29 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Proposal in IKE and IP packet format X-Mailer: Cue version 0.6 (001128-1517/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20001212195513W.sakane@ydc.co.jp> Date: Tue, 12 Dec 2000 19:55:13 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 120 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We can use six pattern of security protocol and mode. That is ESP tunnel, ESP transport, AH tunnel, AH transport, IPCOMP tunnel, IPCOMP transport. IPsec stack (probably in the operating system kernel) and IKE (usually implemented as a daemon) have different standpoint: - As ESP/AH/IPCOMP are separate protocol, IPsec stack can use any combination of them. For inbound, it is much easier to handle them as totally different protocol, as we dispatch based on protocol type. For outbound it is also the case. KAME stack can configure any combination, for example, "IP AH AH AH AH payload". - RFC2409 requires mode of operation (tunnel/transport) to be the same across all the transforms. If we see "tunnel mode" in transports (note: plural!), we need to encapsulate only once - even though we see "tunnel mode" attribute multiple times, we encapsulate only once. So, though IPsec stack can be very flexible (and it is easier to implement!) IKE limits possible combinations. No document (yet) talked about the relationship between the combination of IP packet format, and IKE proposals/transforms. Here is the table of IKE proposal and the IP packet format. Does it make sense that we follow the table if we use IKE ? The table will eliminate the ambiguity we found in bakeoffs - some of us interpreted IKE "tunnel/transport mode" attribute differently. In adition, is it legal for a responder to modify the order of proposal? For example, is the following story legal? Should the initiator accept such a proposal? - the intiator proposes ESP transport as 1st proposal and AH transport as 2nd proposal, - then the responder reply AH as 1st proposal and ESP as 2nd proposal. //KAME Project ==== The table of proposal and IP packet format: *1: MUST be rejected because all of modes in each proposals have to be equal. *2: MUST be rejected because it makes no sense. A. single proposal 1st proposal packet format ---------------- ---------------------- ESP tunnel => IP2 ESP IP1 payload ESP transport => IP1 ESP payload AH tunnel => IP2 AH IP1 payload AH transport => IP1 AH payload IPCOMP tunnel => IP2 IPCOMP IP1 payload IPCOMP transport => IP1 IPCOMP payload B. two proposals and same proposal number. 1st proposal 2nd proposal packet format ---------------- ---------------- ----------------------- ESP tunnel & ESP tunnel => *2 ESP tunnel & ESP transport => *2 ESP tunnel & AH tunnel => IP2 AH ESP IP1 payload ESP tunnel & AH transport => *1 ESP tunnel & IPCOMP tunnel => IP2 ESP IPCOMP IP1 payload ESP tunnel & IPCOMP transport => *1 ESP transport & ESP tunnel => *2 ESP transport & ESP transport => *2 ESP transport & AH tunnel => *1 ESP transport & AH transport => IP1 AH ESP payload ESP transport & IPCOMP tunnel => *1 ESP transport & IPCOMP transport => IP1 ESP IPCOMP payload AH tunnel & ESP tunnel => IP2 AH ESP IP1 payload AH tunnel & ESP transport => *1 AH tunnel & AH tunnel => *2 AH tunnel & AH transport => *2 AH tunnel & IPCOMP tunnel => IP2 AH IPCOMP IP1 payload AH tunnel & IPCOMP transport => *1 AH transport & ESP tunnel => *1 AH transport & ESP transport => IP1 AH ESP payload AH transport & AH tunnel => *2 AH transport & AH transport => *2 AH transport & IPCOMP tunnel => *1 AH transport & IPCOMP transport => IP1 AH IPCOMP payload IPCOMP tunnel & ESP tunnel => IP2 ESP IPCOMP IP1 payload IPCOMP tunnel & ESP transport => *1 IPCOMP tunnel & AH tunnel => IP2 AH IPCOMP IP1 payload IPCOMP tunnel & AH transport => *1 IPCOMP tunnel & IPCOMP tunnel => *2 IPCOMP tunnel & IPCOMP transport => *2 IPCOMP transport & ESP tunnel => *1 IPCOMP transport & ESP transport => IP1 ESP IPCOMP payload IPCOMP transport & AH tunnel => *1 IPCOMP transport & AH transport => IP1 AH IPCOMP payload IPCOMP transport & IPCOMP tunnel => *2 IPCOMP transport & IPCOMP transport => *2 C. three proposals and same proposal number. (most of the bogus combintions are omitted) 1st proposal 2nd proposal 3rd proposal packet format ---------------- ---------------- ---------------- --------------------- ESP tunnel & AH tunnel & IPCOMP tunnel => IP2 AH ESP IPCOMP IP1 ESP tunnel & AH tunnel & IPCOMP transport => *1 ESP tunnel & AH transport & IPCOMP tunnel => *1 ESP tunnel & AH transport & IPCOMP transport => *1 ESP transport & AH tunnel & IPCOMP tunnel => *1 ESP transport & AH tunnel & IPCOMP transport => *1 ESP transport & AH transport & IPCOMP tunnel => *1 ESP transport & AH transport & IPCOMP transport => IP1 AH ESP IPCOMP AH tunnel & ESP tunnel & IPCOMP tunel => IP2 AH ESP IPCOMP IP1 AH tunnel & ESP tunnel & IPCOMP transport => *1 AH tunnel & ESP transport & IPCOMP tunel => *1 AH tunnel & ESP transport & IPCOMP transport => *1 AH transport & ESP tunnel & IPCOMP tunel => *1 AH transport & ESP tunnel & IPCOMP transport => *1 AH transport & ESP transport & IPCOMP tunel => *1 AH transport & ESP transport & IPCOMP transport => IP1 AH ESP IPCOMP IPCOMP tunnel & ESP tunnel & IPCOMP tunel => IP2 AH ESP IPCOMP IP1 IPCOMP tunnel & ESP tunnel & IPCOMP transport => *1 IPCOMP tunnel & ESP transport & IPCOMP tunel => *1 IPCOMP tunnel & ESP transport & IPCOMP transport => *1 IPCOMP transport & ESP tunnel & IPCOMP tunel => *1 IPCOMP transport & ESP tunnel & IPCOMP transport => *1 IPCOMP transport & ESP transport & IPCOMP tunel => *1 IPCOMP transport & ESP transport & IPCOMP transport => IP1 AH ESP IPCOMP From owner-ipsec@lists.tislabs.com Tue Dec 12 09:21:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29558; Tue, 12 Dec 2000 09:21:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01376 Tue, 12 Dec 2000 10:05:34 -0500 (EST) Message-ID: <3A362BA2.D7EF1481@piuha.net> Date: Tue, 12 Dec 2000 15:44:02 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Schlott Cc: ipsec@lists.tislabs.com, steve.hanna@East.Sun.COM, aidan.williams@motorola.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stefan Schlott wrote: > functions of it) for the IPv6 stack of Linux, I finally allowed all ICMP > messages to pass unprocessed - securing ICMP broke too many things; this > is certainly not an optimal solution, but it'll have to be sufficient for > the moment. I don't think it will make much sense to process some kind This is a good first approximation to get things going. But I think it would be useful to try and understand the ICMP issue in a bit more detail. I'm thinking of a document that specifies how each ICMPv6 message should be treated in terms of IPsec. There are a bunch of interesting cases. For instance, * Ping. This is very useful for testing IPsec connections as well, having it not inside IPsec would lose that functionality. Not to mention the fact that on my computer, ping6 seems to be the *only* IPv6 application. * Path MTU discovery. Consider the following case: (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) Assume N1 wants to send traffic to N2, part of the path goes through an insecure network part, secured using VPNGWs 1 and 2. And now Path MTU discovery is in progress between N1 and N2. Assume the smallest MTU is at R2. Then an ICMPv6 Packet Too Big message must be sent back towards the VPNGW2. Should that message go to the tunnel? I think it should. * Multicast messages. Their own story. Also, yesterday I was in the Zero Conf WG meeting and saw that Steve Hanna and Aidan Williams were talking about the use of IPsec in securing some of the early configuration messages in a ZC network. Their problems are quite similar to what we're experiencing in the v6/IPsec case, namely that it is hard to use UDP in IKE, for instance, to build an SA for messages that are going to select IP addresses. Their solution seemed to be the use of manually configured IPsec, which enables also the protection of multicast destined traffic or packets with src address of zero (and avoids IKE in a home appliance, which I think is a good thing). Jari From owner-ipsec@lists.tislabs.com Wed Dec 13 06:15:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19837; Wed, 13 Dec 2000 06:15:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04966 Wed, 13 Dec 2000 06:52:09 -0500 (EST) From: "Pavle Vuletic" To: "IPsec" Subject: ISAKMP control messages Date: Wed, 13 Dec 2000 12:51:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C06503.74AA50C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C06503.74AA50C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! This is the first time that I'm posting a message to this list, so excuse me if these issues have already been commented here. I've been working on an implementation of VPN based on IPsec (OpenBSD) for my Masters degree. I tried to resolve scaling problem in big IPsec VPNs, and to enable remote monitoring (for example, getting the status of all IPsec or IKE security associations on one remote VPN gateway), management (restart, stop or start key exchange on any VLL on remote VPN gateway, or some other control functions, like new quick mode exchange) and configuration of VPN gateways, from one, central server. My idea is to extend ISAKMP in such a way to make it a full signaling protocol (like other telecommunication signaling protocols) for IPsec security associations. Remote configuration exchange is done as in 'The ISAKMP Configuration Method' draft. I used something similar for the exchange of monitoring and management messages (new, Control Payload). Finally, my VPN prototype is configured and controlled from one place (central server). Addition or removal of one VPN gateway can be easily done, by changing only central server configuration. All VLLs between all VPN gateways are configured, monitored and controlled from one central server in a secure manner, since ISAKMP security associations are used for this traffic. Central server does not know IPsec session keys between two VPN gateways (they use DH algorithm), so eventual breaking into it, does not reveal traffic between these VPN gateways. This works fine, but I would like to know if there are some hidden security flaws in this design, that I omitted. Anyway, I think that this kind of ISAKMP extension, that makes it a full signaling protocol is worth examining. I am interested if someone has used this approach before (please send me then some pointers), and I'd like to hear pros and cons for it. Thanks in advance, Pavle Vuletic Belgrade University Computer Centre ------=_NextPart_000_000A_01C06503.74AA50C0 Content-Type: text/x-vcard; name="Pavle Vuletic.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Pavle Vuletic.vcf" BEGIN:VCARD VERSION:2.1 N:Vuletic;Pavle FN:Pavle Vuletic ORG:RCUB TITLE:B.Sc.E.E. TEL;WORK;VOICE:+381-11-434-596, +381-11-321-840H TEL;HOME;VOICE:+381-11-136-069 TEL;CELL;VOICE:+381-63-237-359 ADR;WORK:;;Kumanovska bb;Belgrade;Serbia;11000;Yugoslavia LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Kumanovska bb=3D0D=3D0ABelgrade, = Serbia 11000=3D0D=3D0AYugoslavia ADR;HOME:;;Bulevar Mihajla Pupina 13/12;Belgrade;Serbia;11070 LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Bulevar Mihajla Pupina = 13/12=3D0D=3D0ABelgrade, Serbia 11070 EMAIL;PREF;INTERNET:vpavle@rcub.bg.ac.yu REV:20001213T102425Z END:VCARD ------=_NextPart_000_000A_01C06503.74AA50C0-- From owner-ipsec@lists.tislabs.com Wed Dec 13 21:07:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07699; Wed, 13 Dec 2000 21:07:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07471 Wed, 13 Dec 2000 22:06:54 -0500 (EST) Date: Thu, 14 Dec 2000 12:07:03 +0900 From: Yutaka SAKAI To: sakane@ydc.co.jp Subject: Re: Proposal in IKE and IP packet format Cc: ipsec@lists.tislabs.com In-Reply-To: <20001212195513W.sakane@ydc.co.jp> References: <20001212195513W.sakane@ydc.co.jp> Message-Id: <20001214120513.6899.SAKAI@e3.jrc.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.01 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, I feel that there are some "cut and paste" misses in "3rd proposal" column of table C. Is this feeling correct? regards, Yutaka From owner-ipsec@lists.tislabs.com Wed Dec 13 23:15:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA16024; Wed, 13 Dec 2000 23:15:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07775 Thu, 14 Dec 2000 00:35:01 -0500 (EST) From: FRousseau@chrysalis-its.com Message-ID: <918C70B01822D411A87400B0D0204DFFAD7CE6@panda.chrysalis-its.com> To: ietf-smime@imc.org, ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com Cc: ietf-pkix@imc.org Subject: New Time and Space Based Key Size Equivalents for RSA and Diffie- Hellman Date: Thu, 14 Dec 2000 00:36:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0658F.D7D4218A" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0658F.D7D4218A Content-Type: text/plain; charset="iso-8859-1" I am sorry for the multiple postings, but I thought this particular subject, although probably quite controversial, might be of interest to the many peoples following these mailing lists, especially because of the upcoming adoption of the AES algorithm by many IETF protocols. As symmetric keys grow, they can be attacked by more processors without a change in processor technology since the memory requirements for breaking symmetric keys remain trivial. However, for the Number Field Sieve (NFS) algorithm, which is currently the most efficient method to break RSA keys, this is not true. Based on this premise, the "time and space" based RSA key size equivalents previously published in the RSA Labs Bulletin #13 of April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have recently been extended to cover all the AES symmetric key sizes in the latest draft of ANSI X9.44, which will eventually become the ANSI standard for RSA key transport: Time and Space Symmetric Equivalent Key Size RSA Key Size (in bits) (in bits) 64 450 128 1620 192 2500 256 4200 These "time and space" based key sizes equivalents assume that both time and memory are binding constraints in order to break RSA keys. This same draft also indicates that beyond RSA key sizes of 768 bits one can no longer effectively utilize 32-bit processors with the NFS algorithm because the required memory exceeds what can be addressed in 32 bits; one is forced to use 64-bit machines. Beyond RSA key sizes of about 2500 bits, the memory requirements for the NFS algorithm exceed what can be addressed even on 64 bit machines. For your information, here are also the estimated "time" only based RSA key size equivalents for solving the NFS problem from the same ANSI draft: Time Only Symmetric Equivalent Key Size RSA Key Size (in bits) (in bits) 64 512 128 2550 192 6700 256 13500 Note that either of these sets of RSA key size equivalents could be used with Diffie-Hellman for solving the value of "p" since the NFS algorithm is also the most efficient method to break Diffie-Hellman algorithm today. Note also that these time only equivalents numbers are slightly smaller than those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, 6700 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in Hilarie Orman's Internet Draft (i.e. draft-orman-public-key-lengths-01.txt). Shouldn't IETF standards mention these new "time and space" based key size equivalents in addition to existing "time" only based key size equivalents, and possibly even suggest that "time and space" based key size equivalents be used for RSA and Diffie-Hellman? Why mandate larger equivalent key sizes when smaller equivalent key sizes can probably suffice? Food for thought! Cheers, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01C0658F.D7D4218A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Time and Space Based Key Size Equivalents for RSA and = Diffie-Hellman

I am sorry for the multiple postings, but I thought = this particular subject, although probably quite controversial, might = be of interest to the many peoples following these mailing lists, = especially because of the upcoming adoption of the AES algorithm by = many IETF protocols.

As symmetric keys grow, they can be attacked by more = processors without a change in processor technology since the memory = requirements for breaking symmetric keys remain trivial.  However, = for the Number Field Sieve (NFS) algorithm, which is currently the most = efficient method to break RSA keys, this is not true.  Based on = this premise, the "time and space" based RSA key size = equivalents previously published in the RSA Labs Bulletin #13 of April = 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have recently = been extended to cover all the AES symmetric key sizes in the latest = draft of ANSI X9.44, which will eventually become the ANSI standard for = RSA key transport:

        =         =         Time and = Space
Symmetric       =         Equivalent
Key Size        =         RSA Key Size
(in bits)       =         (in bits)

64      =         =         450
128     =         =         1620
192     =         =         2500
256     =         =         4200

These "time and space" based key sizes = equivalents assume that both time and memory are binding constraints in = order to break RSA keys.  This same draft also indicates that = beyond RSA key sizes of 768 bits one can no longer effectively utilize = 32-bit processors with the NFS algorithm because the required memory = exceeds what can be addressed in 32 bits; one is forced to use 64-bit = machines.  Beyond RSA key sizes of about 2500 bits, the memory = requirements for the NFS algorithm exceed what can be addressed even on = 64 bit machines.

For your information, here are also the estimated = "time" only based RSA key size equivalents for solving the = NFS problem from the same ANSI draft:

        =         =         Time = Only
Symmetric       =         Equivalent
Key Size        =         RSA Key Size
(in bits)       =         (in bits)

64      =         =         512
128     =         =         2550
192     =         =         6700
256     =         =         13500

Note that either of these sets of RSA key size = equivalents could be used with Diffie-Hellman for solving the value of = "p" since the NFS algorithm is also the most efficient method = to break Diffie-Hellman algorithm today.  Note also that these = time only equivalents numbers are slightly smaller than those from ANSI = X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, 6700 vs 7680 = for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in = Hilarie Orman's Internet Draft (i.e. = draft-orman-public-key-lengths-01.txt).

Shouldn't IETF standards mention these new "time = and space" based key size equivalents in addition to existing = "time" only based key size equivalents, and possibly even = suggest that "time and space" based key size equivalents be = used for RSA and Diffie-Hellman?  Why mandate larger equivalent = key sizes when smaller equivalent key sizes can probably = suffice?

Food for thought!

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01C0658F.D7D4218A-- From owner-ipsec@lists.tislabs.com Wed Dec 13 23:22:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA17172; Wed, 13 Dec 2000 23:22:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07809 Thu, 14 Dec 2000 00:40:33 -0500 (EST) To: sakai@e3.jrc.co.jp Cc: ipsec@lists.tislabs.com Subject: Re: Proposal in IKE and IP packet format In-Reply-To: Your message of "Thu, 14 Dec 2000 12:07:03 +0900" <20001214120513.6899.SAKAI@e3.jrc.co.jp> References: <20001214120513.6899.SAKAI@e3.jrc.co.jp> X-Mailer: Cue version 0.6 (001128-1517/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20001214144427X.sakane@ydc.co.jp> Date: Thu, 14 Dec 2000 14:44:27 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 6 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I feel that there are some "cut and paste" misses > in "3rd proposal" column of table C. > Is this feeling correct? Sorry, I wrote some wrong lines. But you can get my aim, can't you ? From owner-ipsec@lists.tislabs.com Thu Dec 14 02:10:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA23291; Thu, 14 Dec 2000 02:10:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA08378 Thu, 14 Dec 2000 03:08:20 -0500 (EST) Date: Thu, 14 Dec 2000 17:08:28 +0900 From: Yutaka SAKAI To: sakane@ydc.co.jp Subject: Re[2]: Proposal in IKE and IP packet format Cc: ipsec@lists.tislabs.com In-Reply-To: <20001214144427X.sakane@ydc.co.jp> References: <20001214120513.6899.SAKAI@e3.jrc.co.jp> <20001214144427X.sakane@ydc.co.jp> Message-Id: <20001214145157.F8CE.SAKAI@e3.jrc.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.01 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If I wasn't understandable, I wouldn't be notifiable. If I couldn't ever be courageous, I wouldn't deserve to be notifiable. as if Raymond Chandler ;-) regards, Yutaka "Shoichi 'Ne' Sakane" wrote: > > I feel that there are some "cut and paste" misses > > in "3rd proposal" column of table C. > > Is this feeling correct? > > Sorry, I wrote some wrong lines. > But you can get my aim, can't you ? From owner-ipsec@lists.tislabs.com Thu Dec 14 02:48:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27639; Thu, 14 Dec 2000 02:48:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08638 Thu, 14 Dec 2000 04:12:05 -0500 (EST) Date: Wed, 13 Dec 2000 11:10:25 -0800 From: Jason R Thorpe To: ipsec@lists.tislabs.com Subject: Other IKE implementations with GSSAPI support? Message-ID: <20001213111025.D2350@dr-evil.49thietf.org> Reply-To: thorpej@zembu.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We (KAME/Wasabi Systems/Zembu Labs) have implemented the GSSAPI auth method for IKE described in draft-ietf-ipsec-isakmp-gss-auth-06.txt in the KAME "racoon" IKE daemon, using the KTH Heimdal Kerberos 5 GSSAPI implementation. The code is available from the KAME CVS repository via anoncvs (the ink is still wet, so it's not yet in any of the KAME snapshot kits). We're interested in any feedback as to interoperability with other IKE implementations implementing the draft. Actually, we're interested in just knowing with other IKE implementations implement the draft, as well. >From the wording of the draft, I would assume that some recent, but probably not publically available, Win2k IKE supports it... In the KAME IKE, there is some concern as to Win2k interoperability, as Win2k is using unicode strings (the byte-order of which is not clearly defined in the draft, BTW) for the GSSAPI endpoint names, and there is some question as to whether or not Kerberos libraries are going to accept them. Shar and enjoy. -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Thu Dec 14 09:24:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02032; Thu, 14 Dec 2000 09:24:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09825 Thu, 14 Dec 2000 10:37:43 -0500 (EST) To: thorpej@zembu.com Cc: ipsec@lists.tislabs.com In-reply-to: thorpej's message of Wed, 13 Dec 2000 11:10:25 PST. <20001213111025.D2350@dr-evil.49thietf.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Other IKE implementations with GSSAPI support? From: Jun-ichiro itojun Hagino Date: Fri, 15 Dec 2000 00:38:53 +0900 Message-Id: <20001214153853.683D37E23@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >We (KAME/Wasabi Systems/Zembu Labs) have implemented the GSSAPI auth >method for IKE described in draft-ietf-ipsec-isakmp-gss-auth-06.txt >in the KAME "racoon" IKE daemon, using the KTH Heimdal Kerberos 5 >GSSAPI implementation. The code is available from the KAME CVS >repository via anoncvs (the ink is still wet, so it's not yet in any >of the KAME snapshot kits). hold a moment, till next Monday. >We're interested in any feedback as to interoperability with other IKE >implementations implementing the draft. Actually, we're interested in >just knowing with other IKE implementations implement the draft, as well. >>From the wording of the draft, I would assume that some recent, but >probably not publically available, Win2k IKE supports it... In the >KAME IKE, there is some concern as to Win2k interoperability, as Win2k >is using unicode strings (the byte-order of which is not clearly defined >in the draft, BTW) for the GSSAPI endpoint names, and there is some >question as to whether or not Kerberos libraries are going to accept them. if "unicode string" means UTF-8, there should be no problem as long as we use ASCII (or iso-8859-1) letters. in draft-ietf-isakmp-gss-auth-06.txt, there's no mention if it is UTF-8, UCS2 or UCS4, though (it should be clearly declared somewhere). itojun From owner-ipsec@lists.tislabs.com Thu Dec 14 09:45:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02382; Thu, 14 Dec 2000 09:44:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09432 Thu, 14 Dec 2000 09:55:08 -0500 (EST) Date: Wed, 13 Dec 2000 11:10:25 -0800 From: Jason R Thorpe To: ipsec@lists.tislabs.com Subject: Other IKE implementations with GSSAPI support? Message-ID: <20001213111025.D2350@dr-evil.49thietf.org> Reply-To: thorpej@zembu.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We (KAME/Wasabi Systems/Zembu Labs) have implemented the GSSAPI auth method for IKE described in draft-ietf-ipsec-isakmp-gss-auth-06.txt in the KAME "racoon" IKE daemon, using the KTH Heimdal Kerberos 5 GSSAPI implementation. The code is available from the KAME CVS repository via anoncvs (the ink is still wet, so it's not yet in any of the KAME snapshot kits). We're interested in any feedback as to interoperability with other IKE implementations implementing the draft. Actually, we're interested in just knowing with other IKE implementations implement the draft, as well. >From the wording of the draft, I would assume that some recent, but probably not publically available, Win2k IKE supports it... In the KAME IKE, there is some concern as to Win2k interoperability, as Win2k is using unicode strings (the byte-order of which is not clearly defined in the draft, BTW) for the GSSAPI endpoint names, and there is some question as to whether or not Kerberos libraries are going to accept them. Shar and enjoy. -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Thu Dec 14 10:49:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07585; Thu, 14 Dec 2000 10:49:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10206 Thu, 14 Dec 2000 12:04:23 -0500 (EST) Date: Thu, 14 Dec 2000 09:00:29 -0800 From: Jason R Thorpe To: ipsec@lists.tislabs.com Subject: Re: Other IKE implementations with GSSAPI support? Message-ID: <20001214090029.A1635@dr-evil.49thietf.org> Reply-To: thorpej@zembu.com References: <20001213111025.D2350@dr-evil.49thietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001213111025.D2350@dr-evil.49thietf.org>; from thorpej@zembu.com on Wed, Dec 13, 2000 at 11:10:25AM -0800 Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Dec 13, 2000 at 11:10:25AM -0800, Jason R Thorpe wrote: ...apologies for the duplicate... -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Thu Dec 14 12:08:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11963; Thu, 14 Dec 2000 12:08:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10398 Thu, 14 Dec 2000 13:05:11 -0500 (EST) Message-Id: <200012141807.TAA85435@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves Cc: mobile-ip@standard.nortelnetworks.com, ipsec@lists.tislabs.com Subject: mobile IPv6 and IPsec ESP tunnels Date: Thu, 14 Dec 2000 19:07:12 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to write ASAP (id-editor should accept new I-D since yesterday?) a draft explaining how to use mobile IPv6 (and other mobility signaling) for IPsec ESP tunnels, ie. how to move one end of a bidirectional tunnel using ESP (a very common usage of IPsec). Richard, I should need your help for wording, this document will be for IPv6, mobile and IPsec communities which are not known for their colaboration (:-). Regards Francis.Dupont@enst-bretagne.fr PS: the raw idea is if you already have an ESP tunnel then mobility can be supported without any new overhead (you need typically 3 addresses and you can use 4). The issue is about the signaling, ie. how to update the address of one end (outer source or destination) after a movement. From owner-ipsec@lists.tislabs.com Thu Dec 14 12:41:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14352; Thu, 14 Dec 2000 12:41:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10521 Thu, 14 Dec 2000 13:54:18 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 14 Dec 2000 10:54:34 -0700 From: "Bob Jueneman" To: , , , Cc: Subject: Re: New Time and Space Based Key Size Equivalents for RSA and Diffie-Hellman Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2C77224E.3352213B" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2C77224E.3352213B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Francois, I haven't followed the latest thinking on breaking algorithms such as RSA, = so I'll take your word for the fact that the Number Field Sieve is = currently the most efficient algorithm. But isn't it at least possible = that there might be other methods that although less efficient than the = NFS on a single machine, might be more well-suited to a distributed = attack? Likewise, would other algorithms be less constrained by a 64-bit = addressing limitation? Interesting point, though, in any case. Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. >>> 12/13/00 10:36PM >>> I am sorry for the multiple postings, but I thought this particular = subject, although probably quite controversial, might be of interest to = the many peoples following these mailing lists, especially because of the = upcoming adoption of the AES algorithm by many IETF protocols. As symmetric keys grow, they can be attacked by more processors without a = change in processor technology since the memory requirements for breaking = symmetric keys remain trivial. However, for the Number Field Sieve (NFS) = algorithm, which is currently the most efficient method to break RSA keys, = this is not true. Based on this premise, the "time and space" based RSA = key size equivalents previously published in the RSA Labs Bulletin #13 of = April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have = recently been extended to cover all the AES symmetric key sizes in the = latest draft of ANSI X9.44, which will eventually become the ANSI standard = for RSA key transport: Time and Space=20 Symmetric Equivalent=20 Key Size RSA Key Size=20 (in bits) (in bits)=20 64 450=20 128 1620=20 192 2500=20 256 4200=20 These "time and space" based key sizes equivalents assume that both time = and memory are binding constraints in order to break RSA keys. This same = draft also indicates that beyond RSA key sizes of 768 bits one can no = longer effectively utilize 32-bit processors with the NFS algorithm = because the required memory exceeds what can be addressed in 32 bits; one = is forced to use 64-bit machines. Beyond RSA key sizes of about 2500 = bits, the memory requirements for the NFS algorithm exceed what can be = addressed even on 64 bit machines. For your information, here are also the estimated "time" only based RSA = key size equivalents for solving the NFS problem from the same ANSI draft: Time Only=20 Symmetric Equivalent=20 Key Size RSA Key Size=20 (in bits) (in bits)=20 64 512=20 128 2550=20 192 6700=20 256 13500=20 Note that either of these sets of RSA key size equivalents could be used = with Diffie-Hellman for solving the value of "p" since the NFS algorithm = is also the most efficient method to break Diffie-Hellman algorithm today. = Note also that these time only equivalents numbers are slightly smaller = than those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 = bits, 6700 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the = numbers in Hilarie Orman's Internet Draft (i.e. draft-orman-public-key-leng= ths-01.txt). Shouldn't IETF standards mention these new "time and space" based key size = equivalents in addition to existing "time" only based key size equivalents,= and possibly even suggest that "time and space" based key size equivalents= be used for RSA and Diffie-Hellman? Why mandate larger equivalent key = sizes when smaller equivalent key sizes can probably suffice? Food for thought!=20 Cheers,=20 Francois=20 ___________________________________=20 Francois Rousseau=20 Director of Standards and Conformance=20 Chrysalis-ITS=20 1688 Woodward Drive=20 Ottawa, Ontario, CANADA, K2C 3R7=20 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419=20 http://www.chrysalis-its.com Fax. (613) 723-5078=20 --=_2C77224E.3352213B Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Francois,
 
I haven't followed the latest thinking on breaking = algorithms=20 such as RSA, so I'll take your word for the fact that the Number Field = Sieve is=20 currently the most efficient algorithm.  But isn't it at least = possible=20 that there might be other methods that although  less efficient than = the=20 NFS on a single machine, might be more well-suited to a distributed=20 attack?  Likewise, would other algorithms be less constrained by a = 64-bit=20 addressing limitation?
 
Interesting point, though, in any case.
 
Regards,
 
Bob
 
Robert R. Jueneman
Security Architect
Novell, Inc.


>>> <FRousseau@chrysalis-its.com> 12/13/00 = 10:36PM=20 >>>

I am sorry for the multiple postings, but I thought = this=20 particular subject, although probably quite controversial, might be of = interest=20 to the many peoples following these mailing lists, especially because of = the=20 upcoming adoption of the AES algorithm by many IETF protocols.

As symmetric keys grow, they can be attacked by more = processors=20 without a change in processor technology since the memory requirements = for=20 breaking symmetric keys remain trivial.  However, for the Number = Field=20 Sieve (NFS) algorithm, which is currently the most efficient method to = break RSA=20 keys, this is not true.  Based on this premise, the "time and space" = based=20 RSA key size equivalents previously published in the RSA Labs Bulletin #13 = of=20 April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins= /)=20 have recently been extended to cover all the AES symmetric key sizes in = the=20 latest draft of ANSI X9.44, which will eventually become the ANSI standard = for=20 RSA key transport:

       =20        =20         Time and = Space=20
Symmetric      =20         Equivalent
Key Size       =20         RSA Key Size
(in bits)      =20         (in bits)

64     =20        =20         450
128           &n= bsp;=20         1620
192           &n= bsp;=20         2500
256           &n= bsp;=20         4200

These "time and space" based key sizes equivalents = assume that=20 both time and memory are binding constraints in order to break RSA = keys. =20 This same draft also indicates that beyond RSA key sizes of 768 bits one = can no=20 longer effectively utilize 32-bit processors with the NFS algorithm = because the=20 required memory exceeds what can be addressed in 32 bits; one is forced to = use=20 64-bit machines.  Beyond RSA key sizes of about 2500 bits, the = memory=20 requirements for the NFS algorithm exceed what can be addressed even on 64 = bit=20 machines.

For your information, here are also the estimated "time" = only=20 based RSA key size equivalents for solving the NFS problem from the same = ANSI=20 draft:

       =20        =20         Time Only= =20
Symmetric      =20         Equivalent
Key Size       =20         RSA Key Size
(in bits)      =20         (in bits)

64     =20        =20         512
128           &n= bsp;=20         2550
192           &n= bsp;=20         6700
256           &n= bsp;=20         13500

Note that either of these sets of RSA key size equivalent= s could=20 be used with Diffie-Hellman for solving the value of "p" since the NFS = algorithm=20 is also the most efficient method to break Diffie-Hellman algorithm = today. =20 Note also that these time only equivalents numbers are slightly smaller = than=20 those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, = 6700=20 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in = Hilarie=20 Orman's Internet Draft (i.e. draft-orman-public-key-lengths-01.txt).=

Shouldn't IETF standards mention these new "time and = space"=20 based key size equivalents in addition to existing "time" only based key = size=20 equivalents, and possibly even suggest that "time and space" based key = size=20 equivalents be used for RSA and Diffie-Hellman?  Why mandate = larger=20 equivalent key sizes when smaller equivalent key sizes can probably=20 suffice?

Food for thought!

Cheers,

Francois
___________________________________
Fran= cois=20 Rousseau
Director of Standards and Conformance=20
Chrysalis-ITS
1688 Woodward=20= Drive
Ottawa, Ontario, CANADA, K2C 3R7 =
frousseau@chrysalis-its.com      Tel. = (613)=20 723-5076 ext. 419
http://www.chrysalis-its.com = ;   =20 Fax. (613) 723-5078

--=_2C77224E.3352213B-- From owner-ipsec@lists.tislabs.com Thu Dec 14 17:36:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA23103; Thu, 14 Dec 2000 17:36:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11139 Thu, 14 Dec 2000 18:41:40 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3A362BA2.D7EF1481@piuha.net> References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> <3A362BA2.D7EF1481@piuha.net> Date: Thu, 14 Dec 2000 17:17:58 -0500 To: jarkko@piuha.net From: Stephen Kent Subject: Re: IPv6 Neighbour Solicitation messages and IPsec Cc: Stefan Schlott , ipsec@lists.tislabs.com, steve.hanna@East.Sun.COM, aidan.williams@motorola.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari, >Stefan Schlott wrote: > > > functions of it) for the IPv6 stack of Linux, I finally allowed all ICMP > > messages to pass unprocessed - securing ICMP broke too many things; this > > is certainly not an optimal solution, but it'll have to be sufficient for > > the moment. I don't think it will make much sense to process some kind > >This is a good first approximation to get things going. But I think >it would be >useful to try and understand the ICMP issue in a bit more detail. I'm >thinking of a document that specifies how each ICMPv6 message should be >treated in terms of IPsec. There are a bunch of interesting cases. >For instance, > > * Ping. This is very useful for testing IPsec connections as well, > having it not inside IPsec would lose that functionality. > Not to mention the fact that on my computer, ping6 seems to > be the *only* IPv6 application. > > * Path MTU discovery. Consider the following case: > > (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) > > Assume N1 wants to send traffic to N2, part of the path > goes through an insecure network part, secured using > VPNGWs 1 and 2. And now Path MTU discovery is in > progress between N1 and N2. Assume the smallest MTU > is at R2. Then an ICMPv6 Packet Too Big message must be > sent back towards the VPNGW2. Should that message > go to the tunnel? I think it should. There is nothing to prohibit transmission of this ICMP message via the security gateways, if appropriate SPD entries exist. From owner-ipsec@lists.tislabs.com Fri Dec 15 13:50:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16733; Fri, 15 Dec 2000 13:50:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17083 Fri, 15 Dec 2000 14:07:05 -0500 (EST) Date: Fri, 15 Dec 2000 21:08:36 +0200 (EET) Message-Id: <200012151908.VAA10745@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Shoichi 'Ne' Sakane" Cc: ipsec@lists.tislabs.com, shacham@shacham.net, bobmonsour@home.com, royp@cisco.com, matt@3am-software.com Subject: IKE attributes consistency. In-Reply-To: <20001212195528P.sakane@ydc.co.jp> References: <20001212195528P.sakane@ydc.co.jp> X-Mailer: VM 6.34 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shoichi 'Ne' Sakane writes: > we need a consistent rule all over the attribute parsing, so: > (1) we always attach the same attributes, for all transforms. > (2) apply suggestion in ippcp draft section 4.1 to all transforms. > if there's no attribute, ignore it (if it is mandatory, bark). The group parameter is attached to quick mode itself not to any protocol inside the SA proposals. Thats why it the RFC2409 says it MUST be included in all proposals. I think we should keep it that way, and fix the draft-shacham-ippcp-rfc2393bis-06 to say that at least group parameter MUST be accepted there. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Dec 15 15:39:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20330; Fri, 15 Dec 2000 15:39:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17449 Fri, 15 Dec 2000 17:37:44 -0500 (EST) Message-ID: <10C8636AE359D4119118009027AE9987031A9059@FMSMSX34> From: "Walker, Jesse" To: "'Tero Kivinen'" Cc: ipsec@lists.tislabs.com Subject: MODP groups draft concern Date: Fri, 15 Dec 2000 14:39:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, This e-mail asks whether it is appropriate at this time to include the suggested 8192-bit MODP group in the draft. If I correctly understood your presentation at the San Diego IPsec meeting, not only do we not know whether the proposed 8192-bit modulus is a Sophie-Germain prime, but we don't even know if it is prime. If this is true, then we aren't at all certain of its security properties, so don't know whether it meets its design goal of providing the level of security suggested as necessary for AES-192. Probabalistic assurances are something we have never agreed to before for well-known IKE groups. In the past our standard has been the modulus for any well-known group must be a verified Sophie-Germaine prime. This criteria has served us well for every well-known group to date. Why abandon it now? I can think of at least three plausible ways forward: a. The IPsec community could dedicate resources to help verify that the value is indeed a Sophie-Germain prime (assuming it is). In the eventuality of a successful verification, it would be appropriate for the value to remain in the draft. Many would see this as the most desirable outcome, because we would possess a value anyone could use, safe in the knowledge that it actually provides the level of security we hope it does. b. If we can't certify it is a Sophie-Germain prime, or even a prime, we should remove it from the draft altogether, because we don't know whether it actually provides the expected level of security. The reasoning here would be to defer prescribing a value this large until sufficient resources exist to determine whether a proposed candidate meets the selection criteria. Probabalistic assurances might be sufficient for private phase 2 groups, but not for the well-known groups defined by the standard. We certainly expect potential attackers to concentrate their resources on resolving the issue for us, and if by dumb luck it turns out the value is not Sophie-Germain or not even prime (probabilities are only probabilities, after all), consumers of IPsec technology would not be harmed by a false sense of security. There will always be lingering doubt and risk until the probability of being a Sophie-Germain prime is shown to be exactly 1. c. We could widen the rules, as the draft implicitly does now, to accept values with only probabalistic assurances. My e-mail objects to this path, because we have not yet discussed the issue and reached a consensus within the community that this has acceptable risk. At the very least, we need to make this kind of selection criteria explicit instead of implicit, and if we allow probabilistic assurances, we need to document the probabilities we are talking about. I find this the least desirable of the three possibilities enumerated here, because we would have to qualify the 8K value as not providing the same sense of security as the existing smaller prime values already used by IKE; we think but aren't sure it really satisifies the requirements for being a good Diffie-Hellman group modulus. And I don't know have a clue as to how to get this message through the filter of the marketeers to the ultimate consumers of IPsec, who need to understand the probabilities and issues very clearly to make informed tradeoffs about when it is prudent to use the 8K group (or rather alleged group, since we don't know it's prime). The users of our technology are not just cryptographers and security specialists, and it is an understatement to say I am sanguine about the wisdom of forcing our customers to consider these kinds of tradeoffs. It is not obvious to me that the need for an 8K or larger group is sufficiently urgent to abandon our long standing criteria. Let the verification algorithm crank a few months or years or however long is necessary to tell us whether the value has the right properties we need for security. We can standardize a new 8K group whenever this completes with a verified Sophie-Germain prime, or generates a Schnorr group, or whatever we define as safe. Until then, let's not tell the world this value is OK to use by including it in the draft, because we just don't know. -- Jesse Walker From owner-ipsec@lists.tislabs.com Sun Dec 17 23:44:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA10375; Sun, 17 Dec 2000 23:44:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA21881 Mon, 18 Dec 2000 01:21:16 -0500 (EST) Message-ID: <3A3DACE1.CDF6EB3E@juniper.net> Date: Sun, 17 Dec 2000 22:21:21 -0800 From: Abraham Shacham X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: "Shoichi 'Ne' Sakane" , ipsec@lists.tislabs.com, shacham@shacham.net, bobmonsour@home.com, royp@cisco.com, matt@3am-software.com, ippcp@external.cisco.com Subject: Re: IKE attributes consistency. References: <20001212195528P.sakane@ydc.co.jp> <200012151908.VAA10745@torni.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, The attached paragraph from rfc2393bis reflects the consensus of the developers in the town hall meeting at the VPN/IPsec bakeoff in San Diego in January 2000. In a long discussion, two attributes -- encapsulation (transport/tunnel) and lifetime -- were identified as relevant to IPComp. It was explicitly decided that not including non relevant attributes MUST NOT cause rejection of an IPComp proposal. One of the reasons for the decision was that _no_ implementation was expecting the non relevant attributes in an IPComp proposal. Keeping the liberal spirit alive, receivers should quietly ignore irrelevant attributes. The decision was posted to the ippcp and ipsec lists and later reflected in the rfc2393bis I-D. In the bakeoff of September 2000, the consensus was still to support that understanding. Regards, avram When IPComp is negotiated as part of a Protection Suite, all the logically related offers must be consistent. However, an IPComp proposal SHOULD NOT include attributes that are not applicable to IPComp. An IPComp proposal MUST NOT be rejected because it does not include attributes of other protocols in the Protection Suite that are not relevant to IPComp. When an IPComp proposal includes such attributes, those attributes MUST be ignored when setting the IPCA, and therefore ignored in the operation of IPComp. Tero Kivinen wrote: > Shoichi 'Ne' Sakane writes: > > we need a consistent rule all over the attribute parsing, so: > > (1) we always attach the same attributes, for all transforms. > > (2) apply suggestion in ippcp draft section 4.1 to all transforms. > > if there's no attribute, ignore it (if it is mandatory, bark). > > The group parameter is attached to quick mode itself not to any > protocol inside the SA proposals. Thats why it the RFC2409 says it > MUST be included in all proposals. I think we should keep it that way, > and fix the draft-shacham-ippcp-rfc2393bis-06 to say that at least > group parameter MUST be accepted there. > -- > kivinen@ssh.fi Work : +358 303 9870 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 18 06:28:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24965; Mon, 18 Dec 2000 06:28:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22896 Mon, 18 Dec 2000 08:17:54 -0500 (EST) X-Originating-IP: [194.100.113.203] Reply-To: silvere@iki.fi From: "Sami Vaarala" To: shacham@juniper.net, kivinen@ssh.fi Cc: sakane@ydc.co.jp, ipsec@lists.tislabs.com, shacham@shacham.net, bobmonsour@home.com, royp@cisco.com, matt@3am-software.com, ippcp@external.cisco.com Subject: Re: IKE attributes consistency. Date: Mon, 18 Dec 2000 15:19:13 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Dec 2000 13:19:13.0328 (UTC) FILETIME=[1D3E6B00:01C068F5] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, >It was explicitly decided that not including non relevant attributes MUST >NOT >cause rejection of an IPComp proposal. One of the reasons for the >decision >was that _no_ implementation was expecting the non relevant attributes >in an IPComp proposal. Keeping the liberal spirit alive, receivers should >quietly ignore irrelevant attributes. The decision was posted to the >ippcp and ipsec lists and later reflected in the rfc2393bis I-D. [...] Why not change the quick mode consistency requirements to the following: 1. the sender SHOULD include a d-h group attribute in every transform. 2. each occurrence of the d-h group attribute MUST have the same value. 3. the receiver MUST accept the sa payload if there are no conflicts in the occurrences of the d-h group attribute, regardless of the number of occurrences of the attribute. Thus it is acceptable to: a) have no d-h group attributes => meaning: no d-h b) have one or more d-h group attributes in any transforms => use d-h group; the same d-h group applies to all proposals. The receiver MUST check that all occurrences have the same value. 4. if there are conflicting d-h group attributes in the proposals (different values) => proposal must be rejected; the receiver MUST check for this condition. This is the most liberal reception guideline I can think of wrt ike qm d-h group. Sami -- Sami Vaarala / Pygmy Projects - We make it small! www.iki.fi/~silvere / silvere@iki.fi / No matter where you go, there you are. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-ipsec@lists.tislabs.com Mon Dec 18 08:47:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12827; Mon, 18 Dec 2000 08:47:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23425 Mon, 18 Dec 2000 10:37:32 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14910.12195.410747.957528@taulu.hel.fi.ssh.com> Date: Mon, 18 Dec 2000 17:39:15 +0200 From: Tero Kivinen To: "Walker, Jesse" Cc: ipsec@lists.tislabs.com Subject: MODP groups draft concern In-Reply-To: <10C8636AE359D4119118009027AE9987031A9059@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A9059@FMSMSX34> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 34 min X-Total-Time: 31 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Walker, Jesse writes: > This e-mail asks whether it is appropriate at this time to include the > suggested 8192-bit MODP group in the draft. If I correctly understood your > presentation at the San Diego IPsec meeting, not only do we not know whether > the proposed 8192-bit modulus is a Sophie-Germain prime, but we don't even > know if it is prime. If this is true, then we aren't at all certain of its > security properties, so don't know whether it meets its design goal of > providing the level of security suggested as necessary for AES-192. > Probabalistic assurances are something we have never agreed to before for > well-known IKE groups. In the past our standard has been the modulus for any > well-known group must be a verified Sophie-Germaine prime. This criteria has > served us well for every well-known group to date. Why abandon it now? Because I haven't had enough time to check the prime. My search program searches the primes by using Miller-Rabin test with limit 200. This gives the information that number is not prime the propability of 1/4^200 == 1/2582249878086908589655919172003011874329705792829223512830659356540647622016841194629645353280137831435903171972747493376. I agree, that might not be enough for some people to use the group, but those should verify all the groups given in the draft themselfs anyways, and not to trust somebody else to verify the groups for them. You should also remember that almost all RSA key pairs are generated by using the propabilistic primes. Also when generating those primes the limit is normally used only up to 20 or so... So it is much more likely that your RSA key pair is weak than this group being weak. Anyways I will try to run the tests on it if I just have enough cpu to do it. > I can think of at least three plausible ways forward: > > a. The IPsec community could dedicate resources to help verify that the > value is indeed a Sophie-Germain prime (assuming it is). In the eventuality > of a successful verification, it would be appropriate for the value to > remain in the draft. Many would see this as the most desirable outcome, > because we would possess a value anyone could use, safe in the knowledge > that it actually provides the level of security we hope it does. If you have spare alpha machine available, just go to http://ultralix.polytechnique.fr/~morain/Prgms/ecpp.english.html and fetch the ECPP program we have been using. The only problem is that it is only available for the alpha machines, thus limiting the number of machines that can run it. Also running it can take lots of time... > It is not obvious to me that the need for an 8K or larger group is > sufficiently urgent to abandon our long standing criteria. Let the > verification algorithm crank a few months or years or however long is > necessary to tell us whether the value has the right properties we need for > security. We can standardize a new 8K group whenever this completes with a > verified Sophie-Germain prime, or generates a Schnorr group, or whatever we > define as safe. Until then, let's not tell the world this value is OK to use > by including it in the draft, because we just don't know. I am going to leave it in the draft for now on, but if I don't have the verification for it when we are going to RFC, then I will consider things more. I might end up having two RFC, one with the proven groups and second with those checked only using propabilistic methods. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 18 12:04:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24223; Mon, 18 Dec 2000 12:04:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23901 Mon, 18 Dec 2000 13:39:12 -0500 (EST) Message-ID: <000801c067c9$033b9de0$0a01a8c0@hwrd1.md.home.com> From: "Tim Lee" To: Subject: Re: IPSec vs. SSL Date: Sat, 16 Dec 2000 20:30:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C0679F.1960A900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0679F.1960A900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are there any situations where it is useful to have IPSec in addition to = SSL? ------=_NextPart_000_0005_01C0679F.1960A900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are there any situations where it is = useful to have=20 IPSec in addition to SSL?
------=_NextPart_000_0005_01C0679F.1960A900-- From owner-ipsec@lists.tislabs.com Mon Dec 18 12:54:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27347; Mon, 18 Dec 2000 12:54:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24081 Mon, 18 Dec 2000 14:38:51 -0500 (EST) To: "Tim Lee" Cc: Subject: Re: IPSec vs. SSL References: <000801c067c9$033b9de0$0a01a8c0@hwrd1.md.home.com> From: Derek Atkins Date: 18 Dec 2000 14:40:29 -0500 In-Reply-To: "Tim Lee"'s message of "Sat, 16 Dec 2000 20:30:58 -0500" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Tim Lee" writes: > Are there any situations where it is useful to have IPSec in addition to = Yes, if you have an application-level gateway or proxy.. You can proxy the SSL but you cannot proxy IPSec end-to-end. -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 Dec 18 15:22:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02571; Mon, 18 Dec 2000 15:22:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24538 Mon, 18 Dec 2000 17:27:16 -0500 (EST) Message-ID: <001701c06942$a7b30820$01b12304@ffb5b> From: "jshukla" To: "Tim Lee" , References: <000801c067c9$033b9de0$0a01a8c0@hwrd1.md.home.com> Subject: Re: IPSec vs. SSL Date: Mon, 18 Dec 2000 14:34:15 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C068FF.98E186C0" 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 a multi-part message in MIME format. ------=_NextPart_000_0014_01C068FF.98E186C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable virtual private networks (VPNs). ~Jayant ----- Original Message -----=20 From: Tim Lee=20 To: ipsec@lists.tislabs.com=20 Sent: Saturday, December 16, 2000 5:30 PM Subject: Re: IPSec vs. SSL Are there any situations where it is useful to have IPSec in addition = to SSL? ------=_NextPart_000_0014_01C068FF.98E186C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
virtual private networks (VPNs).
 
~Jayant
----- Original Message -----
From:=20 Tim = Lee
Sent: Saturday, December 16, = 2000 5:30=20 PM
Subject: Re: IPSec vs. = SSL

Are there any situations where it is = useful to=20 have IPSec in addition to SSL?
------=_NextPart_000_0014_01C068FF.98E186C0-- From owner-ipsec@lists.tislabs.com Mon Dec 18 15:37:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02839; Mon, 18 Dec 2000 15:37:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24511 Mon, 18 Dec 2000 17:18:03 -0500 (EST) Message-ID: <007e01c06951$6aadb3d0$5d4bfea9@venkatp> From: "Venkat RK Reddy" To: Subject: Fw: IPSec vs. SSL Date: Mon, 18 Dec 2000 16:19:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C0690E.5C82D2B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C0690E.5C82D2B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPSec's advantage over SSL: It has more flexibility on choosing the = authentication mechanisms (like the PreSharedKey), and therefore makes = it difficult for the attacker to do man in the middle. SSL is based = only on public key and with tools (like dsniff2.3), its possible to do = man in the middle breaking SSL. SSL's advantage over IPSec: In SSL, the client and the server exchage * = hash * over the "initial handshake" and therefore is difficult for an = attacker to control (change the proposals that the client has sent so = that the server chooses the proposals that attacker sends or whatever) = the main mode "initial" handshake. More discussion on this would be enlightening and appreciated. ----- Original Message -----=20 From: Tim Lee=20 To: ipsec@lists.tislabs.com=20 Sent: Saturday, December 16, 2000 5:30 PM Subject: Re: IPSec vs. SSL Are there any situations where it is useful to have IPSec in addition = to SSL? ------=_NextPart_000_007B_01C0690E.5C82D2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IPSec's advantage over SSL: It has = more=20 flexibility on choosing the authentication mechanisms (like the = PreSharedKey),=20 and therefore makes it difficult for the attacker to do man in the = middle. =20 SSL is based only on public key and with tools (like dsniff2.3), its = possible to=20 do man in the middle breaking SSL.
 
SSL's advantage over IPSec: In SSL, the = client and=20 the server exchage * hash * over the "initial handshake" and therefore = is=20 difficult for an attacker to control (change the proposals that the = client=20 has sent so that the server chooses the proposals that attacker sends or = whatever) the main mode "initial" handshake.
 
More discussion on this would be = enlightening and=20 appreciated.
 
----- Original Message -----
From:=20 Tim = Lee
To: ipsec@lists.tislabs.com
Sent: Saturday, December 16, = 2000 5:30=20 PM
Subject: Re: IPSec vs. = SSL

Are there any situations where it is = useful to=20 have IPSec in addition to SSL?
------=_NextPart_000_007B_01C0690E.5C82D2B0-- From owner-ipsec@lists.tislabs.com Mon Dec 18 17:26:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05087; Mon, 18 Dec 2000 17:26:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24888 Mon, 18 Dec 2000 19:17:22 -0500 (EST) Subject: Re: Fw: IPSec vs. SSL To: "Venkat RK Reddy" Cc: From: "Paul Heber" Date: Tue, 19 Dec 2000 11:15:58 +1000 Message-ID: X-MIMETrack: Serialize by Router on QFSYDMST02/QANTAS(Release 5.0.5 |September 22, 2000) at 19/12/2000 11:13:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA24885 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you look at the wording "In addition" then SSL V3 could be a better solution or even TLS rather than both SSL and IPSec. Encryption of encrypted packets is not a good look. I agree that with SSL and tools such as Dsniff the man in the middle is an issue. IPSec will fix this problem, but then you start limiting the scalability of implementation. Look at a server that needs to be accessible from 100 points accross an open IP community. If you must run IPSec then you must run 100 Tunnels from 100 end points. This gets worse the more open that you want the secure network, say all 100 need to talk securely to all of the connections, it become n*n-1 tunnels and surely this is un-manageable from a business perspective. SSL encrypts as it goes and at the application level or TLS at the Transport level, hence there are no scalability issues here. (It is all a Risk vs Business benefit statement.) Sure if the data MUST not be accessible and it is highly confidential then IPSec maybe a good option, but then why use SSL on top of that. The other pitfall with IPSec that needs to be considered is the structure of your environment and the addressing used internally. IPSec does not work with NAT, however there are ways around this, but your security then does not become end to end like SSL or TLS. From: "Venkat RK Reddy" @lists.tislabs.com on 18/12/2000 16:19 PST Sent by: owner-ipsec@lists.tislabs.com To: cc: Subject: Fw: IPSec vs. SSL IPSec's advantage over SSL: It has more flexibility on choosing the authentication mechanisms (like the PreSharedKey), and therefore makes it difficult for the attacker to do man in the middle.  SSL is based only on public key and with tools (like dsniff2.3), its possible to do man in the middle breaking SSL. SSL's advantage over IPSec: In SSL, the client and the server exchage * hash * over the "initial handshake" and therefore is difficult for an attacker to control (change the proposals that the client has sent so that the server chooses the proposals that attacker sends or whatever) the main mode "initial" handshake. More discussion on this would be enlightening and appreciated. ----- Original Message ----- From: Tim Lee To: ipsec@lists.tislabs.com Sent: Saturday, December 16, 2000 5:30 PM Subject: Re: IPSec vs. SSL Are there any situations where it is useful to have IPSec in addition to SSL? From owner-ipsec@lists.tislabs.com Mon Dec 18 17:51:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05662; Mon, 18 Dec 2000 17:51:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25024 Mon, 18 Dec 2000 20:02:22 -0500 (EST) Date: Mon, 18 Dec 2000 20:03:33 -0500 (EST) From: Henry Spencer To: Paul Heber cc: ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Dec 2000, Paul Heber wrote: > Look at a server that needs to be accessible from 100 points accross an > open IP community. If you must run IPSec then you must run 100 Tunnels from > 100 end points. This gets worse the more open that you want the secure > network, say all 100 need to talk securely to all of the connections, it > become n*n-1 tunnels and surely this is un-manageable from a business > perspective. Why? There is no reason why all of them have to exist simultaneously, unless there is actually traffic flowing on all of them... and in any case, there is no n*n-1 on any single machine. You could equally say that there would have to be n*n-1 TCP connections involved, and nobody complains about that. I agree that n*n-1 gets troublesome if there needs to be explicit per-tunnel management or configuration, but there is no fundamental requirement for that. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 18 17:58:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05900; Mon, 18 Dec 2000 17:58:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25079 Mon, 18 Dec 2000 20:10:53 -0500 (EST) Subject: Re: Fw: IPSec vs. SSL To: Henry Spencer Cc: ipsec@lists.tislabs.com From: "Paul Heber" Date: Tue, 19 Dec 2000 12:08:28 +1000 Message-ID: X-MIMETrack: Serialize by Router on QFSYDMST02/QANTAS(Release 5.0.5 |September 22, 2000) at 19/12/2000 12:05:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, You are right there is no fundamental need unless the business requires it. Purely an example of scalability and control using IPSec rather than SSL. SSL is dynamic wheras IPSec needs setup and maintenance. Paul Heber From: Henry Spencer on 18/12/2000 20:03 EST To: Paul Heber cc: ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL On Tue, 19 Dec 2000, Paul Heber wrote: > Look at a server that needs to be accessible from 100 points accross an > open IP community. If you must run IPSec then you must run 100 Tunnels from > 100 end points. This gets worse the more open that you want the secure > network, say all 100 need to talk securely to all of the connections, it > become n*n-1 tunnels and surely this is un-manageable from a business > perspective. Why? There is no reason why all of them have to exist simultaneously, unless there is actually traffic flowing on all of them... and in any case, there is no n*n-1 on any single machine. You could equally say that there would have to be n*n-1 TCP connections involved, and nobody complains about that. I agree that n*n-1 gets troublesome if there needs to be explicit per-tunnel management or configuration, but there is no fundamental requirement for that. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 18 18:08:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06125; Mon, 18 Dec 2000 18:08:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25108 Mon, 18 Dec 2000 20:20:22 -0500 (EST) Date: Mon, 18 Dec 2000 20:21:32 -0500 (EST) From: Henry Spencer To: Paul Heber cc: ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Dec 2000, Paul Heber wrote: >> I agree that n*n-1 gets troublesome if there needs to be explicit >> per-tunnel management or configuration, but there is no fundamental >> requirement for that. > > You are right there is no fundamental need unless the business requires it. I didn't say "unless the business requires it". I said "no fundamental requirement", and I meant it. There is no reason why a human should have to configure all those tunnels by hand, any more than he would have to configure the corresponding set of TCP connections by hand. Think abstraction, mechanization, lazy evaluation: say in general terms what is permitted, and let the software set up the details as required, perhaps only when needed. (I'm not saying that current software *supports* this well yet, but that can be fixed.) > SSL is dynamic wheras IPSec needs setup and maintenance. Why? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 18 18:33:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06805; Mon, 18 Dec 2000 18:33:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25180 Mon, 18 Dec 2000 20:44:19 -0500 (EST) Subject: Re: Fw: IPSec vs. SSL To: Henry Spencer Cc: ipsec@lists.tislabs.com From: "Paul Heber" Date: Tue, 19 Dec 2000 12:42:22 +1000 Message-ID: X-MIMETrack: Serialize by Router on QFSYDMST02/QANTAS(Release 5.0.5 |September 22, 2000) at 19/12/2000 12:39:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > SSL is dynamic wheras IPSec needs setup and maintenance. Why? Depends upon the implementation of the software, as to this setup and maintenance requirement. From: Henry Spencer on 18/12/2000 20:21 EST To: Paul Heber cc: ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL On Tue, 19 Dec 2000, Paul Heber wrote: >> I agree that n*n-1 gets troublesome if there needs to be explicit >> per-tunnel management or configuration, but there is no fundamental >> requirement for that. > > You are right there is no fundamental need unless the business requires it. I didn't say "unless the business requires it". I said "no fundamental requirement", and I meant it. There is no reason why a human should have to configure all those tunnels by hand, any more than he would have to configure the corresponding set of TCP connections by hand. Think abstraction, mechanization, lazy evaluation: say in general terms what is permitted, and let the software set up the details as required, perhaps only when needed. (I'm not saying that current software *supports* this well yet, but that can be fixed.) > SSL is dynamic wheras IPSec needs setup and maintenance. Why? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 18 19:32:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07938; Mon, 18 Dec 2000 19:32:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25317 Mon, 18 Dec 2000 21:46:48 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Paul Heber" Cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Dec 2000 21:48:35 -0500 Message-Id: <20001219024836.136D035DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Paul Heber " writes: > >> SSL is dynamic wheras IPSec needs setup and maintenance. > >Why? > >Depends upon the implementation of the software, as to this setup and >maintenance requirement. I'm sorry, I still don't understand. SSL has a key setup phase, too. To me, the difference is ease of deployment versus scope of protection. SSL is easier to deploy, because it lives solely at user level. It does not need any kernel mods, source code, etc., and is reasonably portable between operating systems. On the other hand, with SSL you have to secure one application at a time. You can't protect entire subnets. There are trivial denial of service attacks by active attackers; they simply need to inject a single TCP packet. And there's no way to protect UDP. If IPsec had been widely available, there would have been no need for SSL. But it wasn't there; that left a gaping ecological niche that SSL filled quite nicely. --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Dec 18 20:44:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA09330; Mon, 18 Dec 2000 20:44:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25612 Mon, 18 Dec 2000 22:53:28 -0500 (EST) Subject: Re: Fw: IPSec vs. SSL To: "Steven M. Bellovin" Cc: "Paul Heber" , Henry Spencer , ipsec@lists.tislabs.com From: "Paul Heber" Date: Tue, 19 Dec 2000 14:50:36 +1000 Message-ID: X-MIMETrack: Serialize by Router on QFSYDMST02/QANTAS(Release 5.0.5 |September 22, 2000) at 19/12/2000 02:47:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I was not talking about the key setup phase for SSL, nor the key exchange on IPSec, but more the products that we have trialed, where configuration has to be done manually before IPSec will work. Whereas SSL is cert based on the server with Key Setup from the client being trusted by third party. I agree SSL is less secure and needs to be done from individual servers as well, so the encryption has to be done at multiple points and servers, but is also much simpler to deploy. Ever tried running IPSec on demand in an Internet Cafe PC, getting access to certain Internal pages securely. (SSL still has uses) I agree with the last point, however SSL will still have uses within the public arena such as for Web page security. Paul Heber From: "Steven M. Bellovin" @research.att.com on 18/12/2000 21:48 EST Sent by: smb@research.att.com To: "Paul Heber" cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL In message , "Paul Heber " writes: > >> SSL is dynamic wheras IPSec needs setup and maintenance. > >Why? > >Depends upon the implementation of the software, as to this setup and >maintenance requirement. I'm sorry, I still don't understand. SSL has a key setup phase, too. To me, the difference is ease of deployment versus scope of protection. SSL is easier to deploy, because it lives solely at user level. It does not need any kernel mods, source code, etc., and is reasonably portable between operating systems. On the other hand, with SSL you have to secure one application at a time. You can't protect entire subnets. There are trivial denial of service attacks by active attackers; they simply need to inject a single TCP packet. And there's no way to protect UDP. If IPsec had been widely available, there would have been no need for SSL. But it wasn't there; that left a gaping ecological niche that SSL filled quite nicely. --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Dec 18 22:32:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11915; Mon, 18 Dec 2000 22:32:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA25771 Tue, 19 Dec 2000 00:26:44 -0500 (EST) Message-ID: <012d01c0698d$3a5c5a10$5d4bfea9@venkatp> From: "Venkat RK Reddy" To: Cc: "Henry Spencer" , "Steven M. Bellovin" References: <20001219024836.136D035DC2@smb.research.att.com> Subject: Re: Fw: IPSec vs. SSL Date: Mon, 18 Dec 2000 23:28:05 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm sorry, I still don't understand. SSL has a key setup phase, too. > > To me, the difference is ease of deployment versus scope of protection. > SSL is easier to deploy, because it lives solely at user level. It > does not need any kernel mods, source code, etc., and is reasonably > portable between operating systems. "Deployment" may not be a critical issue, because its a one time thing. I would add flexibility and purpose like whether the client authentication is needed (optional in SSL), or various options for payload specification and ofcourse application Vs entire subnet > On the other hand, with SSL you have to secure one application at a > time. You can't protect entire subnets. There are trivial > denial of service attacks by active attackers; they simply need to > inject a single TCP packet. And there's no way to protect UDP. I beleive both SSL and IPSec are susceptible to DoS. > If IPsec had been widely available, there would have been no need for > SSL. But it wasn't there; that left a gaping ecological niche that SSL > filled quite nicely. > > > --Steve Bellovin > > From owner-ipsec@lists.tislabs.com Mon Dec 18 23:05:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15757; Mon, 18 Dec 2000 23:05:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25860 Tue, 19 Dec 2000 01:08:17 -0500 (EST) Message-ID: <00e901c06982$79944900$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Steven M. Bellovin" , "Paul Heber" Cc: "Paul Heber" , "Henry Spencer" , References: Subject: Re: Fw: IPSec vs. SSL Date: Mon, 18 Dec 2000 22:11:07 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Paul Heber" > I agree that with SSL and tools such > as Dsniff the man in the middle is an issue. I am not quite sure I understand how SSL is susceptible to the man in the middle attack. Could you explain this a bit more or point me to some write-up on this. If the client encrypts a session key with the public key of a server pretty much the only thing that can decrypt the key is the server which has the private key corresponding to the public key in the certificate. I don't see how a man in the middle attack can be launched here. ----- Original Message ----- From: "Paul Heber" > I agree SSL is less secure and needs to be done from individual servers as > well, so the encryption has to be done at multiple points and servers, but > is also much simpler to deploy. Why is SSL less secure? Digital certificate based server authentication, 1024 bit RSA keys for encryption of the session key, a perfectly secure session key establishment mechanism, 3DES encryption. Where is the security weakness. Could you please explain or point me to some analysis of weaknesses you are referring to. In fact with client auth I see no reason why it is in any way less secure than IPSec. Khaja From owner-ipsec@lists.tislabs.com Mon Dec 18 23:24:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20215; Mon, 18 Dec 2000 23:24:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25898 Tue, 19 Dec 2000 01:26:18 -0500 (EST) X-Originating-IP: [194.100.113.203] Reply-To: silvere@iki.fi From: "Sami Vaarala" To: shacham@shacham.net, silvere@iki.fi Cc: kivinen@ssh.fi, sakane@ydc.co.jp, ipsec@lists.tislabs.com, bobmonsour@home.com, royp@cisco.com, matt@3am-software.com, ippcp@external.cisco.com Subject: Re: IKE attributes consistency. Date: Tue, 19 Dec 2000 08:27:36 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Dec 2000 06:27:36.0363 (UTC) FILETIME=[C71E5FB0:01C06984] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Sami, > >What if the sender elects NOT to include >the d-h group attribute in one of the transforms? If there is at least one d-h group attribute in the whole sa payload (in any transform), then you interpret it to mean that you ARE using d-h in any case, and that there MUST be a KE payload in the message. >avram > >On Mon, 18 Dec 2000, Sami Vaarala wrote: > > > Hi, > > > > >It was explicitly decided that not including non relevant attributes >MUST > > >NOT > > >cause rejection of an IPComp proposal. One of the reasons for the > > >decision > > >was that _no_ implementation was expecting the non relevant attributes > > >in an IPComp proposal. Keeping the liberal spirit alive, receivers >should > > >quietly ignore irrelevant attributes. The decision was posted to the > > >ippcp and ipsec lists and later reflected in the rfc2393bis I-D. > > [...] > > > > Why not change the quick mode consistency requirements to the > > following: > > > > 1. the sender SHOULD include a d-h group attribute in every > > transform. > > 2. each occurrence of the d-h group attribute MUST have the > > same value. > > 3. the receiver MUST accept the sa payload if there are no > > conflicts in the occurrences of the d-h group attribute, > > regardless of the number of occurrences of the attribute. > > Thus it is acceptable to: > > a) have no d-h group attributes => meaning: no d-h > > b) have one or more d-h group attributes in any > > transforms => use d-h group; the same d-h group > > applies to all proposals. The receiver MUST check > > that all occurrences have the same value. > > 4. if there are conflicting d-h group attributes in the proposals > > (different values) => proposal must be rejected; the receiver > > MUST check for this condition. > > > > This is the most liberal reception guideline I can think of wrt > > ike qm d-h group. > > > > Sami > > -- > > Sami Vaarala / Pygmy Projects - We make it small! > > www.iki.fi/~silvere / > > silvere@iki.fi / No matter where you go, there you are. > > > > >_________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at >http://www.hotmail.com. > > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-ipsec@lists.tislabs.com Mon Dec 18 23:44:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA25100; Mon, 18 Dec 2000 23:44:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25938 Tue, 19 Dec 2000 01:38:37 -0500 (EST) Subject: Re: Fw: IPSec vs. SSL To: "Khaja E. Ahmed" Cc: "Steven M. Bellovin" , "Paul Heber" , "Henry Spencer" , From: "Paul Heber" Date: Tue, 19 Dec 2000 17:35:34 +1000 Message-ID: X-MIMETrack: Serialize by Router on QFSYDMST02/QANTAS(Release 5.0.5 |September 22, 2000) at 19/12/2000 05:33:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Khaja, The following article. http://securityportal.com/cover/coverstory20001218.html Paul From: "Khaja E. Ahmed" on 18/12/2000 22:11 PST To: "Steven M. Bellovin" , "Paul Heber" cc: "Paul Heber" , "Henry Spencer" , Subject: Re: Fw: IPSec vs. SSL ----- Original Message ----- From: "Paul Heber" > I agree that with SSL and tools such > as Dsniff the man in the middle is an issue. I am not quite sure I understand how SSL is susceptible to the man in the middle attack. Could you explain this a bit more or point me to some write-up on this. If the client encrypts a session key with the public key of a server pretty much the only thing that can decrypt the key is the server which has the private key corresponding to the public key in the certificate. I don't see how a man in the middle attack can be launched here. ----- Original Message ----- From: "Paul Heber" > I agree SSL is less secure and needs to be done from individual servers as > well, so the encryption has to be done at multiple points and servers, but > is also much simpler to deploy. Why is SSL less secure? Digital certificate based server authentication, 1024 bit RSA keys for encryption of the session key, a perfectly secure session key establishment mechanism, 3DES encryption. Where is the security weakness. Could you please explain or point me to some analysis of weaknesses you are referring to. In fact with client auth I see no reason why it is in any way less secure than IPSec. Khaja From owner-ipsec@lists.tislabs.com Tue Dec 19 00:24:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA00182; Tue, 19 Dec 2000 00:24:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA26020 Tue, 19 Dec 2000 02:26:38 -0500 (EST) Message-ID: <004701c0698d$6d18f030$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Paul Heber" Cc: "Steven M. Bellovin" , "Paul Heber" , "Henry Spencer" , References: Subject: Re: Fw: IPSec vs. SSL Date: Mon, 18 Dec 2000 23:29:30 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In reading the article there appears to be no weakness in the SSL protocol itself that is at issue. What seems to be the concern is that browsers and user desktops are easy to thwart and the platform itself may be untrusted. That combined with use's not paying close attention to the visual cues and security indicators and questions in the UI appear to be what the author is concerned about. The third factor that the author points to is that the lower level software that binds IP addresses to a given MAC address and weaknesses in DNS exacerbate the problem. These are long standing concerns that although very real do not adversely affect ( at present at least) the bulk of SSL usage. I was wondering if the SSL protocol itself has been "broken". That does not seem to be the case. Do let me know if I missed something in the article. Khaja ----- Original Message ----- From: "Paul Heber" To: "Khaja E. Ahmed" Cc: "Steven M. Bellovin" ; "Paul Heber" ; "Henry Spencer" ; Sent: Monday, December 18, 2000 11:35 PM Subject: Re: Fw: IPSec vs. SSL > Khaja, > > The following article. > > http://securityportal.com/cover/coverstory20001218.html > > Paul > > > > From: "Khaja E. Ahmed" on 18/12/2000 22:11 PST > > To: "Steven M. Bellovin" , "Paul Heber" > > cc: "Paul Heber" , "Henry Spencer" > , > Subject: Re: Fw: IPSec vs. SSL > > > ----- Original Message ----- > From: "Paul Heber" > > I agree that with SSL and tools such > > as Dsniff the man in the middle is an issue. > > I am not quite sure I understand how SSL is susceptible to the man in the > middle attack. Could you explain this a bit more or point me to some > write-up on this. If the client encrypts a session key with the public key > of a server pretty much the only thing that can decrypt the key is the > server which has the private key corresponding to the public key in the > certificate. I don't see how a man in the middle attack can be launched > here. > > > ----- Original Message ----- > From: "Paul Heber" > > I agree SSL is less secure and needs to be done from individual servers > as > > > well, so the encryption has to be done at multiple points and servers, > but > > is also much simpler to deploy. > > Why is SSL less secure? Digital certificate based server authentication, > 1024 bit RSA keys for encryption of the session key, a perfectly secure > session key establishment mechanism, 3DES encryption. Where is the > security > weakness. Could you please explain or point me to some analysis of > weaknesses you are referring to. In fact with client auth I see no reason > why it is in any way less secure than IPSec. > > Khaja > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Dec 19 01:27:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09046; Tue, 19 Dec 2000 01:27:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA26299 Tue, 19 Dec 2000 03:46:51 -0500 (EST) Message-ID: From: Ivars Suba To: ipsec@lists.tislabs.com Cc: "'Khaja E. Ahmed'" , "Steven M. Bellovin" , Paul Heber , Henry Spencer Subject: Re: Fw: IPSec vs. SSL Date: Tue, 19 Dec 2000 10:48:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-4" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Mostly SSL security is SSL Server Security. For SSL Server Security Survey loookup http://www.meer.net/~ericm/papers/ssl_servers.html . Let's don't making storm in glass. Cheers, Ivars From owner-ipsec@lists.tislabs.com Tue Dec 19 01:28:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09104; Tue, 19 Dec 2000 01:28:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA26280 Tue, 19 Dec 2000 03:35:54 -0500 (EST) Message-ID: <000801c069a7$bb236d90$5d4bfea9@venkatp> From: "Venkat RK Reddy" To: "Khaja E. Ahmed" Cc: References: <00e901c06982$79944900$e4570f18@plstn1.sfba.home.com> Subject: Re: Fw: IPSec vs. SSL Date: Tue, 19 Dec 2000 02:37:35 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I am not quite sure I understand how SSL is susceptible to the man in the > middle attack. Could you explain this a bit more or point me to some > write-up on this. If the client encrypts a session key with the public key > of a server pretty much the only thing that can decrypt the key is the > server which has the private key corresponding to the public key in the > certificate. I don't see how a man in the middle attack can be launched > here. > Spoof and imitate the CA ;-) From owner-ipsec@lists.tislabs.com Tue Dec 19 08:21:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16191; Tue, 19 Dec 2000 08:21:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27318 Tue, 19 Dec 2000 09:53:47 -0500 (EST) Message-ID: <3A3F276E.D84D9839@piuha.net> Date: Tue, 19 Dec 2000 11:16:30 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.17-icclin i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent Cc: Stefan Schlott , ipsec@lists.tislabs.com, steve.hanna@East.Sun.COM, aidan.williams@motorola.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> <3A362BA2.D7EF1481@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > * Path MTU discovery. Consider the following case: > > > > (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) > > > > Assume N1 wants to send traffic to N2, part of the path > > goes through an insecure network part, secured using > > VPNGWs 1 and 2. And now Path MTU discovery is in > > progress between N1 and N2. Assume the smallest MTU > > is at R2. Then an ICMPv6 Packet Too Big message must be > > sent back towards the VPNGW2. Should that message > > go to the tunnel? I think it should. > > There is nothing to prohibit transmission of this ICMP message via > the security gateways, if appropriate SPD entries exist. You are right, but the context of the discussion was that a proposal was made that all ICMPv6 messages should bypass IPsec processing in order to avoid chicken-and-egg problems with some ICMPv6 messages. I was trying to make the point that _some_ ICMPv6 messages at least in _some_ situations have to go through IPsec. Hence, the "ignore ICMPv6 in IPsec" solution doesn't fly. It was also suggested that perhaps the difference lies in tunnel mode vs transport mode. However, that distinction doesn't solve the problems either... two nodes on the same link could well have tunnel mode policies for all traffic, which would then prevent e.g. duplicate address detection to work, which in turn would prevent all communications. Also, as per RFC 2401 we do not in general have the possibility to specify policies for individual ICMP message types. Finally, one might have expected multicast / unicast addresses to have a significance such that we could say only unicast traffic gets IPsec protection, but apparently this isn't always the case. For instance, when the Neighbour Advertisement message is used as a reply in an address resolution situation, it is a unicast message. Instead, I think we need something else. What was previously lower layer thing such as ARP, is now a proper IP packet in v6. In addition, there is completely new functionality. These must be considered when thinking about which messages should get IPsec protection, and how. The ICMPv6 messages can be classified as follows: No RFC Name End-to-End Required Before UDP works 1 2463 Dest unreach Yes No 2 2463 Packet too big Yes No 3 2463 Time exceeded Yes No 4 2463 Parameter problem Yes No 128 2463 Echo request Yes No 129 2463 Echo reply Yes No 137 2461 Redirect No Yes 133 2461 Router solicit No Yes 134 2461 Router adv No Yes 135 2461 NeighSol/Resol No Yes 136 2461 NeighAdv/Resol No Yes 135 2461 NeighSol/Unreach No No 136 2461 NeighAdv/Unreach No No 135 2462 NeighSol/Autoconf No Yes 136 2462 NeighAdv/Autoconf No Yes Note that Neihbour Solicitation and Advertisement play multiple roles, address resolution, unreachability detection, and autoconfiguration. The crucial thing in the above table is to note which messages are necessary before two IPv6 nodes can exchange packets. For IPsec, the relevant issue is if SAs can be negotiated using IKE which runs on top of UDP. If not, such messages simply can not be protected with dynamic SAs; for instance we can't send UDP messages before address autoconfiguration has determined the suitable addresses to be used and ensured that no duplicate addresses exist on the link. So, what I would propose is that the ICMPv6 messages Redirect, Router Solicitation/Advertisement, and Neighbour Solicitation/Advertisement (except for reachbility detection) are never given normal IPsec treatment. I.e., if I define my policies as always requiring IKE & IPsec for all traffic, then these exceptional messages still go in the clear and without IKE. Furthermore, I would suggest that if protection is needed for the exceptional ICMPv6 message set, then manually configured IPsec SAs be used, enabling also the protection of multicast traffic. However, in order to do things like this, the SPD must have sufficient expressive power to distinguish ICMP messages types and roles. Finally, I would propose that everywhere in the ICMPv6 specifications where it says "AH", tunnel mode ESP would suffice as well. Jari From owner-ipsec@lists.tislabs.com Tue Dec 19 08:21:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16207; Tue, 19 Dec 2000 08:21:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27295 Tue, 19 Dec 2000 09:52:45 -0500 (EST) Date: Mon, 18 Dec 2000 21:16:58 -0800 (PST) From: Avram Shacham X-Sender: shacham@zev.net To: silvere@iki.fi cc: kivinen@ssh.fi, sakane@ydc.co.jp, ipsec@lists.tislabs.com, bobmonsour@home.com, royp@cisco.com, matt@3am-software.com, ippcp@external.cisco.com Subject: Re: IKE attributes consistency. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sami, What if the sender elects NOT to include the d-h group attribute in one of the transforms? avram On Mon, 18 Dec 2000, Sami Vaarala wrote: > Hi, > > >It was explicitly decided that not including non relevant attributes MUST > >NOT > >cause rejection of an IPComp proposal. One of the reasons for the > >decision > >was that _no_ implementation was expecting the non relevant attributes > >in an IPComp proposal. Keeping the liberal spirit alive, receivers should > >quietly ignore irrelevant attributes. The decision was posted to the > >ippcp and ipsec lists and later reflected in the rfc2393bis I-D. > [...] > > Why not change the quick mode consistency requirements to the > following: > > 1. the sender SHOULD include a d-h group attribute in every > transform. > 2. each occurrence of the d-h group attribute MUST have the > same value. > 3. the receiver MUST accept the sa payload if there are no > conflicts in the occurrences of the d-h group attribute, > regardless of the number of occurrences of the attribute. > Thus it is acceptable to: > a) have no d-h group attributes => meaning: no d-h > b) have one or more d-h group attributes in any > transforms => use d-h group; the same d-h group > applies to all proposals. The receiver MUST check > that all occurrences have the same value. > 4. if there are conflicting d-h group attributes in the proposals > (different values) => proposal must be rejected; the receiver > MUST check for this condition. > > This is the most liberal reception guideline I can think of wrt > ike qm d-h group. > > Sami > -- > Sami Vaarala / Pygmy Projects - We make it small! > www.iki.fi/~silvere / > silvere@iki.fi / No matter where you go, there you are. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > From owner-ipsec@lists.tislabs.com Tue Dec 19 08:40:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17550; Tue, 19 Dec 2000 08:40:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27694 Tue, 19 Dec 2000 10:37:47 -0500 (EST) Date: Tue, 19 Dec 2000 08:28:18 -0700 (MST) From: Joel M Snyder Subject: Re: Fw: IPSec vs. SSL In-reply-to: "Your message dated Mon, 18 Dec 2000 21:48:35 -0500" <20001219024836.136D035DC2@smb.research.att.com> To: "Steven M. Bellovin" Cc: Paul Heber , Henry Spencer , ipsec@lists.tislabs.com Message-id: <01JXVRSIBU788Y5T6T@Opus1.COM> Organization: Opus One - +1 520 324 0494 MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Fruit-of-the-day: Buni Comments: Telecommunications and Information Technology Services Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >To me, the difference is ease of deployment versus scope of protection. >SSL is easier to deploy, because it lives solely at user level. It >does not need any kernel mods, source code, etc., and is reasonably >portable between operating systems. >On the other hand, with SSL you have to secure one application at a >time. You can't protect entire subnets. There are trivial >denial of service attacks by active attackers; they simply need to >inject a single TCP packet. And there's no way to protect UDP. I agree that those are the main and key issues. There are two other problems with SSL that I bring up in my class (warning students that these are largely "academic" issues): 1) The key generation in SSL is done by one party, not two, and therefore defects in implementation (such as Netscape had) have especially large effects; with IPSEC, the two parties both contribute equally to key generation which would tend to mitigate these effects (perhaps). 2) The secrecy of an SSL conversation is dependent on the private key of the server (assuming one-way authentication) being FOREVER kept secret; if the private key is exposed, then all old "taped" SSL conversations can be played back and decoded; with IPSEC, the encryption key could be compromised, but in practice such keys are unlikely to be in some persistent storage. Ergo, if I broke into a web server and grabbed the private key, all conversations would be exposed to me. Quick question: how often when a web server is "defaced" do you think the owners think to generate new private keys? jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One From owner-ipsec@lists.tislabs.com Tue Dec 19 08:52:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18500; Tue, 19 Dec 2000 08:52:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27490 Tue, 19 Dec 2000 10:25:06 -0500 (EST) Message-ID: <10C8636AE359D4119118009027AE9987031A9067@FMSMSX34> From: "Walker, Jesse" To: "'Tero Kivinen'" Cc: ipsec@lists.tislabs.com Subject: RE: MODP groups draft concern Date: Tue, 19 Dec 2000 07:26:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero: A probability like 1/4^200 always impresses people but misses the point. There is a class of composite integers for which Miller-Rabin always gives the wrong answer, for any and all bases we try. To be acceptable for our application, I think we would want to verify that the candidate does not belong to this class before accepting the probability as reliably indicating that it has the security properties we desire. And I don't buy the argument that since this kind of probability is good enough for RSA, it must be good enough for the modulus of a standardized Diffie-Hellman group. We expect Miller-Rabin to fail very rarely, but if it does for an RSA prime, so what? Presumably only one principal uses that "prime" to generate its public/private key pair, and presumably it will replace its keys soon enough anyway, at key expiry. In our case, however, we are trying to define a standardized Diffie-Hellman value that is good for all time; if we subsequently discover Miller-Rabin failed, there will be hundreds of thousands or millions of implementations relying on this value. The reach of a failure is potentially much more catostraphic in our case than for RSA. We can compromise everyone's security by failing to do our homework, whereas a Miller-Rabin failure wouldn't necessarily be as bad in the RSA case. I don't know a good characterization of Miller-Rabin pusedo-primes, but since Miller-Rabin is strictly stronger than the Fermat primality test, every value that fails Miller-Rabin must fail Fermat as well and therefore must be a Carmichael number. Let p denote the 8K candidate prime. Since every Carmichael number is the product of at least three distinct primes, it seem like we could get a much warmer feeling that the 8K value is actually prime by doing trial by division for primes up to the cube root of p (ditto for q, where p = 2q + 1). Is computing all 8192/3 = 2731 bit primes within reach? Or does someone know an eaiser way to check that the candidate is not a Miller-Rabin pseudo-prime? -- Jesse -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Monday, December 18, 2000 7:39 AM To: Walker, Jesse Cc: ipsec@lists.tislabs.com Subject: MODP groups draft concern Walker, Jesse writes: > This e-mail asks whether it is appropriate at this time to include the > suggested 8192-bit MODP group in the draft. If I correctly understood your > presentation at the San Diego IPsec meeting, not only do we not know whether > the proposed 8192-bit modulus is a Sophie-Germain prime, but we don't even > know if it is prime. If this is true, then we aren't at all certain of its > security properties, so don't know whether it meets its design goal of > providing the level of security suggested as necessary for AES-192. > Probabalistic assurances are something we have never agreed to before for > well-known IKE groups. In the past our standard has been the modulus for any > well-known group must be a verified Sophie-Germaine prime. This criteria has > served us well for every well-known group to date. Why abandon it now? Because I haven't had enough time to check the prime. My search program searches the primes by using Miller-Rabin test with limit 200. This gives the information that number is not prime the propability of 1/4^200 == 1/25822498780869085896559191720030118743297057928292235128306593565406476220 16841194629645353280137831435903171972747493376. I agree, that might not be enough for some people to use the group, but those should verify all the groups given in the draft themselfs anyways, and not to trust somebody else to verify the groups for them. You should also remember that almost all RSA key pairs are generated by using the propabilistic primes. Also when generating those primes the limit is normally used only up to 20 or so... So it is much more likely that your RSA key pair is weak than this group being weak. Anyways I will try to run the tests on it if I just have enough cpu to do it. > I can think of at least three plausible ways forward: > > a. The IPsec community could dedicate resources to help verify that the > value is indeed a Sophie-Germain prime (assuming it is). In the eventuality > of a successful verification, it would be appropriate for the value to > remain in the draft. Many would see this as the most desirable outcome, > because we would possess a value anyone could use, safe in the knowledge > that it actually provides the level of security we hope it does. If you have spare alpha machine available, just go to http://ultralix.polytechnique.fr/~morain/Prgms/ecpp.english.html and fetch the ECPP program we have been using. The only problem is that it is only available for the alpha machines, thus limiting the number of machines that can run it. Also running it can take lots of time... > It is not obvious to me that the need for an 8K or larger group is > sufficiently urgent to abandon our long standing criteria. Let the > verification algorithm crank a few months or years or however long is > necessary to tell us whether the value has the right properties we need for > security. We can standardize a new 8K group whenever this completes with a > verified Sophie-Germain prime, or generates a Schnorr group, or whatever we > define as safe. Until then, let's not tell the world this value is OK to use > by including it in the draft, because we just don't know. I am going to leave it in the draft for now on, but if I don't have the verification for it when we are going to RFC, then I will consider things more. I might end up having two RFC, one with the proven groups and second with those checked only using propabilistic methods. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Dec 19 08:58:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18786; Tue, 19 Dec 2000 08:58:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27871 Tue, 19 Dec 2000 10:52:48 -0500 (EST) Date: Tue, 19 Dec 2000 08:41:39 -0700 (MST) From: Joel M Snyder Subject: Re: Fw: IPSec vs. SSL In-reply-to: "Your message dated Mon, 18 Dec 2000 23:29:30 -0800" <004701c0698d$6d18f030$e4570f18@plstn1.sfba.home.com> To: "Khaja E. Ahmed" Cc: Paul Heber , "Steven M. Bellovin" , Henry Spencer , ipsec@lists.tislabs.com Message-id: <01JXVS62RO528Y5T6T@Opus1.COM> Organization: Opus One - +1 520 324 0494 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Fruit-of-the-day: Buni References: Comments: Telecommunications and Information Technology Services Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >In reading the article there appears to be no weakness in the SSL protocol >itself that is at issue. What seems to be the concern is that browsers and >user desktops are easy to thwart and the platform itself may be untrusted. The obvious problem with SSL as commonly implemented is that there is one-way authentication, which means that if I can subvert any of the 85 CAs which are "trusted" by your client's browser and get them to issue me a certificate which I don't deserve, then I can do an active man-in-the-middle attack. Subvert is actually a more semantics-laden word than I need to use here: if I can get some buggy ASP which gives out freemail certs from one of those 85 CAs to give me an "www.home.com" cert, then you'll never know what hit you. Obviously, this is not a defect in the protocol, but for exactly the reasons that SSL is often chosen (deployment is so simple because it's built into the browser, interoperability is good, the user doesn't have to do anything, etc.), it is also vulnerable to that kind of attack. But because most SSL is done because of the non-existent threat of eavesdropped credit card numbers, the threat is obviously matched by the cure. jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One From owner-ipsec@lists.tislabs.com Tue Dec 19 09:47:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20220; Tue, 19 Dec 2000 09:47:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28072 Tue, 19 Dec 2000 11:43:19 -0500 (EST) Message-ID: From: Will Harwood To: "'Joel M Snyder'" , "Steven M. Bellovin" Cc: Paul Heber , Henry Spencer , ipsec@lists.tislabs.com Subject: RE: Fw: IPSec vs. SSL Date: Tue, 19 Dec 2000 16:45:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Your comments about SSL seem to apply to the non Diffie-Hellman modes. Whne Diffie-Hellman is used with RSA signing then the session key data is generated by both parties and the long term secrecy is not compromised by the exposure of the private key (although naturally further communication is because man in the middle becomes possible). Will -----Original Message----- From: Joel M Snyder [mailto:Joel.Snyder@Opus1.COM] Sent: Tuesday, December 19, 2000 3:28 PM To: Steven M. Bellovin Cc: Paul Heber; Henry Spencer; ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL >To me, the difference is ease of deployment versus scope of protection. >SSL is easier to deploy, because it lives solely at user level. It >does not need any kernel mods, source code, etc., and is reasonably >portable between operating systems. >On the other hand, with SSL you have to secure one application at a >time. You can't protect entire subnets. There are trivial >denial of service attacks by active attackers; they simply need to >inject a single TCP packet. And there's no way to protect UDP. I agree that those are the main and key issues. There are two other problems with SSL that I bring up in my class (warning students that these are largely "academic" issues): 1) The key generation in SSL is done by one party, not two, and therefore defects in implementation (such as Netscape had) have especially large effects; with IPSEC, the two parties both contribute equally to key generation which would tend to mitigate these effects (perhaps). 2) The secrecy of an SSL conversation is dependent on the private key of the server (assuming one-way authentication) being FOREVER kept secret; if the private key is exposed, then all old "taped" SSL conversations can be played back and decoded; with IPSEC, the encryption key could be compromised, but in practice such keys are unlikely to be in some persistent storage. Ergo, if I broke into a web server and grabbed the private key, all conversations would be exposed to me. Quick question: how often when a web server is "defaced" do you think the owners think to generate new private keys? jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One From owner-ipsec@lists.tislabs.com Tue Dec 19 10:20:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23245; Tue, 19 Dec 2000 10:20:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28129 Tue, 19 Dec 2000 12:03:11 -0500 (EST) Message-ID: <00c901c069dd$fa549530$e4570f18@plstn1.sfba.home.com> From: "Khaja E. Ahmed" To: "Venkat RK Reddy" Cc: References: <00e901c06982$79944900$e4570f18@plstn1.sfba.home.com> <000801c069a7$bb236d90$5d4bfea9@venkatp> Subject: Re: Fw: IPSec vs. SSL Date: Tue, 19 Dec 2000 09:06:07 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am not sure how one does one does this if a CA is a public TTP? Most CA that are worthy of trust by the general public attain the TTP (Trusted Third Party) designation. They do so by proving to large one or more big 6 audit firms that they have a very secure CA. Typically they have many layers of firewalls and intrusion detection systems and some of worlds foremost security experts on their payroll. Most are housed in very secure, physically guarded facilities with multiple enveloping security zones. Often there are concrete walls, bio-metrically controlled steel doors which contain plexan rooms and tempest cages. Then there are CAs like the one I run on my desktop. A free copy of Windows certificate authority that comes with NT 4.0! It wouldn't be mission impossible to steal private key from my desktop, it is in a very public location. I issue certs to friends and colleagues for testing purposes. This can be spoofed and imitated. But is that of any value? If the point is being made that people may use certs from "Joe's Certificate Services", a garage shop operation which is easy to subvert especially if users do not pay attention to cues from the UI on security issue; that is fine and that is how it should be stated. It is the same as saying many people don't lock their cars and doors or use cheap stuff that can be picked easily. We wouldn't say doors and locks are not good enough security for our homes and cars. All I am trying to say is that there isn't sufficient basis to make serious assertions like "SSL is insecure". Khaja ----- Original Message ----- From: "Venkat RK Reddy" To: "Khaja E. Ahmed" Cc: Sent: Tuesday, December 19, 2000 2:37 AM Subject: Re: Fw: IPSec vs. SSL > > > > I am not quite sure I understand how SSL is susceptible to the man in the > > middle attack. Could you explain this a bit more or point me to some > > write-up on this. If the client encrypts a session key with the public > key > > of a server pretty much the only thing that can decrypt the key is the > > server which has the private key corresponding to the public key in the > > certificate. I don't see how a man in the middle attack can be launched > > here. > > > > Spoof and imitate the CA ;-) > From owner-ipsec@lists.tislabs.com Tue Dec 19 11:53:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28813; Tue, 19 Dec 2000 11:53:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28708 Tue, 19 Dec 2000 13:43:54 -0500 (EST) From: Dan McDonald Message-Id: <200012191845.eBJIjbi17626@kebe.Eng.Sun.COM> Subject: Connectathon To: ipsec@lists.tislabs.com Date: Tue, 19 Dec 2000 10:45:37 -0800 (PST) CC: audrey@vanb.com Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello again! I forgot to mention this at the IPsec meeting, but the early bird deadline for Connectathon registration is the end of this calendar year (12/31/2000). I will be posting soon what IPsec technologies will be tested at Connectathon. I'm willing to take suggestions. Finally, for those of you who have asked me C-thon questions, I'm sorry I haven't been more responsive. See http://www.connectathon.org/ for registration details. Thanks, Dan From owner-ipsec@lists.tislabs.com Tue Dec 19 12:08:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29382; Tue, 19 Dec 2000 12:08:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28788 Tue, 19 Dec 2000 14:06:02 -0500 (EST) Message-Id: <200012191907.LAA06931@sfan-ss20.cisco.com> Date: Tue, 19 Dec 2000 11:07:24 -0800 (PST) From: Scott Fluhrer Reply-To: Scott Fluhrer Subject: RE: MODP groups draft concern To: kivinen@ssh.fi, jesse.walker@intel.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FlQ0PCaFbK1Nj7lpgCq9NQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Tero: > > A probability like 1/4^200 always impresses people but misses the point. > There is a class of composite integers for which Miller-Rabin always gives > the wrong answer, for any and all bases we try. To be acceptable for our > application, I think we would want to verify that the candidate does not > belong to this class before accepting the probability as reliably indicating > that it has the security properties we desire. Actually, that is factually wrong: there is *no* composite integer for which Miller-Rabin will give the wrong answer for more than 1/4 of the possible bases (or, in other words, with more than 1/4 probability if we choose the base randomly). Reference: Handbook of Applied Cryptography, Menezes et al, section 4.2.3 (in particular, fact 4.23) Oh, by the way, Tero, have you tested both p and (p-1)/2 for primality 200 times using Miller-Rabin? -- scott From owner-ipsec@lists.tislabs.com Tue Dec 19 12:16:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29978; Tue, 19 Dec 2000 12:16:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28809 Tue, 19 Dec 2000 14:08:24 -0500 (EST) Message-Id: <200012191909.eBJJ9TX104061@thunk.east.sun.com> From: Bill Sommerfeld To: "Matt Crawford" cc: jarkko@piuha.net, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Neighbour Solicitation messages and IPsec In-reply-to: Your message of "Tue, 19 Dec 2000 12:54:36 CST." <200012191854.MAA08694@gungnir.fnal.gov> Reply-to: sommerfeld@East.Sun.COM Date: Tue, 19 Dec 2000 14:09:29 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > which in turn would prevent all communications. Also, as per RFC > > 2401 we do not in general have the possibility to specify policies > > for individual ICMP message types. > > This passed the IESG in RFC 2894 (so it must be true): > > > Note that for the SPD to distinguish Router Renumbering from other > ICMP packets requires the use of the ICMP Type field as a selector. > This is consistent with, although not mentioned by, the Security > Architecture specification [IPSEC]. > > It's no contradiction with what you said, though. It should also be said that many ipsec implementors recognize the need to have special support for icmp in ipsec policy; besides icmp type, there's also the matter of protecting icmp errors using the "same" policy as the traffic that generated them.. - Bill From owner-ipsec@lists.tislabs.com Tue Dec 19 12:31:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01262; Tue, 19 Dec 2000 12:31:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28947 Tue, 19 Dec 2000 14:27:28 -0500 (EST) Message-Id: <200012191854.MAA08694@gungnir.fnal.gov> To: jarkko@piuha.net Cc: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: IPv6 Neighbour Solicitation messages and IPsec In-reply-to: Your message of Tue, 19 Dec 2000 11:16:30 +0200. <3A3F276E.D84D9839@piuha.net> Date: Tue, 19 Dec 2000 12:54:36 -0600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > which in turn would prevent all communications. Also, as per RFC > 2401 we do not in general have the possibility to specify policies > for individual ICMP message types. This passed the IESG in RFC 2894 (so it must be true): Note that for the SPD to distinguish Router Renumbering from other ICMP packets requires the use of the ICMP Type field as a selector. This is consistent with, although not mentioned by, the Security Architecture specification [IPSEC]. It's no contradiction with what you said, though. From owner-ipsec@lists.tislabs.com Tue Dec 19 20:15:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA12699; Tue, 19 Dec 2000 20:15:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA00379 Tue, 19 Dec 2000 22:01:16 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Walker, Jesse" Cc: "'Tero Kivinen'" , ipsec@lists.tislabs.com Subject: Re: MODP groups draft concern Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Dec 2000 22:03:07 -0500 Message-Id: <20001220030308.4419235DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <10C8636AE359D4119118009027AE9987031A9067@FMSMSX34>, "Walker, Jesse" writes: >Is computing all 8192/3 = 2731 bit primes within >reach? No. The Prime Number Theorem states that the number of primes not exceeding x is asymptotic to x/log(x). In this case, that means something close to 2^2731/log(2731). That's a very big number... --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Dec 20 07:53:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08259; Wed, 20 Dec 2000 07:53:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01972 Wed, 20 Dec 2000 09:48:11 -0500 (EST) Message-Id: <3.0.3.32.20001220114606.00b56810@pop.datafellows.com> X-Sender: alexey@pop.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 20 Dec 2000 11:46:06 +0200 To: Scott Fluhrer , kivinen@ssh.fi, jesse.walker@intel.com From: Alexey Kirichenko Subject: RE: MODP groups draft concern Cc: ipsec@lists.tislabs.com In-Reply-To: <200012191907.LAA06931@sfan-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:07 19.12.2000 -0800, Scott Fluhrer wrote: >> Tero: >> >> A probability like 1/4^200 always impresses people but misses the point. >> There is a class of composite integers for which Miller-Rabin always gives >> the wrong answer, for any and all bases we try. To be acceptable for our >> application, I think we would want to verify that the candidate does not >> belong to this class before accepting the probability as reliably indicating >> that it has the security properties we desire. > >Actually, that is factually wrong: there is *no* composite integer for which >Miller-Rabin will give the wrong answer for more than 1/4 of the possible >bases (or, in other words, with more than 1/4 probability if we choose the >base randomly). Reference: Handbook of Applied Cryptography, Menezes et al, >section 4.2.3 (in particular, fact 4.23) Scott is absolutely right, and the proof of this fact can be found in, e.g., Knuth, The Art of Computer Programming, vol.2. Carmichael numbers "fool" only the very basic Fermat's test (when one just checks that a^(n-1) = 1 mod n) Alexey From owner-ipsec@lists.tislabs.com Wed Dec 20 07:55:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08381; Wed, 20 Dec 2000 07:55:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01956 Wed, 20 Dec 2000 09:47:12 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14912.31285.687074.432806@taulu.hel.fi.ssh.com> Date: Wed, 20 Dec 2000 11:21:57 +0200 From: Tero Kivinen To: Scott Fluhrer Cc: jesse.walker@intel.com, ipsec@lists.tislabs.com Subject: RE: MODP groups draft concern In-Reply-To: <200012191907.LAA06931@sfan-ss20.cisco.com> References: <200012191907.LAA06931@sfan-ss20.cisco.com> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fluhrer writes: > Oh, by the way, Tero, have you tested both p and (p-1)/2 for primality > 200 times using Miller-Rabin? Yes. The program I am using to search to primes can also be found from the ssh distribution. The latest ssh distribution can be found from the ftp://ftp.ssh.fi/pub/ssh, and the tar file contains test program lib/sshmath/tests/t-sophie-germain.c that is actually used to generate those primes. The primality tests can be found from the lib/sshmath/sshmp.c: ssh_mp_is_propable_prime / ssh_mp_miller_rabin functions. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Dec 20 07:57:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08495; Wed, 20 Dec 2000 07:57:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02047 Wed, 20 Dec 2000 09:51:11 -0500 (EST) Message-ID: <00a201c06a93$8524eba0$651e10ac@netscreen5> From: "Greg Stark" To: "Walker, Jesse" , "'Tero Kivinen'" Cc: References: <10C8636AE359D4119118009027AE9987031A9067@FMSMSX34> Subject: Re: MODP groups draft concern Date: Wed, 20 Dec 2000 09:45:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jesse, In practice, one cannot achieve the kind of certainty you propose. All computations are subject to failure, even if they software itself is bug-free. How much more common are random bit errors than, say, a composite surviving 200 iterations of Miller-Rabin. I think the only algorithm which can, in reasonable time, prove the primality of such a large prime is the ECPP algorithm Tero mentioned. It is very complicated and I would not be surprised to find bugs in any implementation of it. Miller-Rabin is much simpler. Given the probabilities at play here, it is only fair to analyze the effect that random bit errors might have on the comptutations in ECPP. Might such an error at a critical stage of the ECPP computation lead it to declare a composite prime? Of course! Why have more faith in an ECPP "proven" prime than a Miller-Rabin "probable prime". I guess one could retain the ECPP proof forever as a certificate of primality and subject it to periodic reverification, but I suspect only Francois Morain, Tero, and a few others could actually do so. Is it not conjectured that no composites can survive a small number of Miller-Rabin tests? Or that none can survive a small number of Miller-Rabin and Lucas tests? The number in question is prime with either probability 1 or probability 0, but proving such a large number is prime may be impossible in this universe. Greg Stark, gstark@ethentica.com Chief Security Architect Ethentica, Inc. www.ethentica.com ----- Original Message ----- From: "Walker, Jesse" To: "'Tero Kivinen'" Cc: Sent: Tuesday, December 19, 2000 10:26 AM Subject: RE: MODP groups draft concern > Tero: > > A probability like 1/4^200 always impresses people but misses the point. > There is a class of composite integers for which Miller-Rabin always gives > the wrong answer, for any and all bases we try. To be acceptable for our > application, I think we would want to verify that the candidate does not > belong to this class before accepting the probability as reliably indicating > that it has the security properties we desire. > > And I don't buy the argument that since this kind of probability is good > enough for RSA, it must be good enough for the modulus of a standardized > Diffie-Hellman group. We expect Miller-Rabin to fail very rarely, but if it > does for an RSA prime, so what? Presumably only one principal uses that > "prime" to generate its public/private key pair, and presumably it will > replace its keys soon enough anyway, at key expiry. In our case, however, we > are trying to define a standardized Diffie-Hellman value that is good for > all time; if we subsequently discover Miller-Rabin failed, there will be > hundreds of thousands or millions of implementations relying on this value. > The reach of a failure is potentially much more catostraphic in our case > than for RSA. We can compromise everyone's security by failing to do our > homework, whereas a Miller-Rabin failure wouldn't necessarily be as bad in > the RSA case. > > I don't know a good characterization of Miller-Rabin pusedo-primes, but > since Miller-Rabin is strictly stronger than the Fermat primality test, > every value that fails Miller-Rabin must fail Fermat as well and therefore > must be a Carmichael number. Let p denote the 8K candidate prime. Since > every Carmichael number is the product of at least three distinct primes, it > seem like we could get a much warmer feeling that the 8K value is actually > prime by doing trial by division for primes up to the cube root of p (ditto > for q, where p = 2q + 1). Is computing all 8192/3 = 2731 bit primes within > reach? Or does someone know an eaiser way to check that the candidate is not > a Miller-Rabin pseudo-prime? > > -- Jesse > > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Monday, December 18, 2000 7:39 AM > To: Walker, Jesse > Cc: ipsec@lists.tislabs.com > Subject: MODP groups draft concern > > > Walker, Jesse writes: > > This e-mail asks whether it is appropriate at this time to include the > > suggested 8192-bit MODP group in the draft. If I correctly understood your > > presentation at the San Diego IPsec meeting, not only do we not know > whether > > the proposed 8192-bit modulus is a Sophie-Germain prime, but we don't even > > know if it is prime. If this is true, then we aren't at all certain of its > > security properties, so don't know whether it meets its design goal of > > providing the level of security suggested as necessary for AES-192. > > Probabalistic assurances are something we have never agreed to before for > > well-known IKE groups. In the past our standard has been the modulus for > any > > well-known group must be a verified Sophie-Germaine prime. This criteria > has > > served us well for every well-known group to date. Why abandon it now? > > Because I haven't had enough time to check the prime. My search > program searches the primes by using Miller-Rabin test with limit 200. > This gives the information that number is not prime the propability of > 1/4^200 == > 1/25822498780869085896559191720030118743297057928292235128306593565406476220 > 16841194629645353280137831435903171972747493376. > > I agree, that might not be enough for some people to use the group, > but those should verify all the groups given in the draft themselfs > anyways, and not to trust somebody else to verify the groups for them. > > You should also remember that almost all RSA key pairs are generated > by using the propabilistic primes. Also when generating those primes > the limit is normally used only up to 20 or so... So it is much more > likely that your RSA key pair is weak than this group being weak. > Anyways I will try to run the tests on it if I just have enough cpu to > do it. > > > I can think of at least three plausible ways forward: > > > > a. The IPsec community could dedicate resources to help verify that the > > value is indeed a Sophie-Germain prime (assuming it is). In the > eventuality > > of a successful verification, it would be appropriate for the value to > > remain in the draft. Many would see this as the most desirable outcome, > > because we would possess a value anyone could use, safe in the knowledge > > that it actually provides the level of security we hope it does. > > If you have spare alpha machine available, just go to > > http://ultralix.polytechnique.fr/~morain/Prgms/ecpp.english.html > > and fetch the ECPP program we have been using. The only problem is > that it is only available for the alpha machines, thus limiting the > number of machines that can run it. Also running it can take lots of > time... > > > It is not obvious to me that the need for an 8K or larger group is > > sufficiently urgent to abandon our long standing criteria. Let the > > verification algorithm crank a few months or years or however long is > > necessary to tell us whether the value has the right properties we need > for > > security. We can standardize a new 8K group whenever this completes with a > > verified Sophie-Germain prime, or generates a Schnorr group, or whatever > we > > define as safe. Until then, let's not tell the world this value is OK to > use > > by including it in the draft, because we just don't know. > > I am going to leave it in the draft for now on, but if I don't have > the verification for it when we are going to RFC, then I will consider > things more. I might end up having two RFC, one with the proven groups > and second with those checked only using propabilistic methods. > -- > kivinen@ssh.fi Work : +358 303 9870 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > From owner-ipsec@lists.tislabs.com Wed Dec 20 07:57:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08522; Wed, 20 Dec 2000 07:57:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01940 Wed, 20 Dec 2000 09:46:10 -0500 (EST) Reply-To: From: "walrawi" To: Subject: build the non-kernel FreeS/WAN programs and install them in /usr/local/sbin Date: Tue, 19 Dec 2000 13:35:44 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a very basic question: how do you do the following: "build the non-kernel FreeS/WAN programs and install them in /usr/local/sbin " Thanks From owner-ipsec@lists.tislabs.com Wed Dec 20 08:01:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08817; Wed, 20 Dec 2000 08:01:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01954 Wed, 20 Dec 2000 09:47:10 -0500 (EST) Date: Tue, 19 Dec 2000 21:19:25 -0800 (PST) From: Avram Shacham X-Sender: shacham@zev.net To: silvere@iki.fi cc: kivinen@ssh.fi, sakane@ydc.co.jp, ipsec@lists.tislabs.com, bobmonsour@home.com, royp@cisco.com, matt@3am-software.com, ippcp@external.cisco.com Subject: Re: IKE attributes consistency. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If one of the transforms, say IPComp, may elect not to include the d-h group attribute, how does your suggestion differ from the discussed statement of rfc2393bis? avram On Tue, 19 Dec 2000, Sami Vaarala wrote: > >Sami, > > > >What if the sender elects NOT to include > >the d-h group attribute in one of the transforms? > > If there is at least one d-h group attribute in the whole sa > payload (in any transform), then you interpret it to mean that > you ARE using d-h in any case, and that there MUST be a KE > payload in the message. > > >avram > > > >On Mon, 18 Dec 2000, Sami Vaarala wrote: > > > > > Hi, > > > > > > >It was explicitly decided that not including non relevant attributes > >MUST > > > >NOT > > > >cause rejection of an IPComp proposal. One of the reasons for the > > > >decision > > > >was that _no_ implementation was expecting the non relevant attributes > > > >in an IPComp proposal. Keeping the liberal spirit alive, receivers > >should > > > >quietly ignore irrelevant attributes. The decision was posted to the > > > >ippcp and ipsec lists and later reflected in the rfc2393bis I-D. > > > [...] > > > > > > Why not change the quick mode consistency requirements to the > > > following: > > > > > > 1. the sender SHOULD include a d-h group attribute in every > > > transform. > > > 2. each occurrence of the d-h group attribute MUST have the > > > same value. > > > 3. the receiver MUST accept the sa payload if there are no > > > conflicts in the occurrences of the d-h group attribute, > > > regardless of the number of occurrences of the attribute. > > > Thus it is acceptable to: > > > a) have no d-h group attributes => meaning: no d-h > > > b) have one or more d-h group attributes in any > > > transforms => use d-h group; the same d-h group > > > applies to all proposals. The receiver MUST check > > > that all occurrences have the same value. > > > 4. if there are conflicting d-h group attributes in the proposals > > > (different values) => proposal must be rejected; the receiver > > > MUST check for this condition. > > > > > > This is the most liberal reception guideline I can think of wrt > > > ike qm d-h group. > > > > > > Sami > > > -- > > > Sami Vaarala / Pygmy Projects - We make it small! > > > www.iki.fi/~silvere / > > > silvere@iki.fi / No matter where you go, there you are. > > > > > > > >_________________________________________________________________________ > > > Get Your Private, Free E-mail from MSN Hotmail at > >http://www.hotmail.com. > > > > > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > From owner-ipsec@lists.tislabs.com Wed Dec 20 10:30:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18689; Wed, 20 Dec 2000 10:30:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02821 Wed, 20 Dec 2000 12:16:43 -0500 (EST) Message-Id: <4.3.2.7.0.20001220104248.00c84100@mailhost.sctc.com> X-Sender: smith@mailhost.sctc.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Dec 2000 11:20:26 -0600 To: "Venkat RK Reddy" , From: Rick Smith at Secure Computing Subject: Re: Fw: IPSec vs. SSL In-Reply-To: <007e01c06951$6aadb3d0$5d4bfea9@venkatp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems to me that many of the stated evils of SSL described in the Security portal article by Kurt Seifried would reside in IPSEC as well, if the roles had been reversed. It's obvious that one would be able to forge a server certificate in either world, given the state of the browser certificate infrastructure. There's the risk that someone might insert a bogus CA key in your browser. There's the risk that someone will subvert the API to a CA already in the browser, and yield a cert for an existing site. And, of course, there's the real risk that the attacker will simply submit a new cert that doesn't match *any* of your CAs, and you'll accept it so you can order Johnny's Beanie Babie Star Wars Lego Mindstorms Cabbage Patch Furby in time for holiday shipping. If we were using IPSEC instead of SSL for ordering our holiday gifts, then we'd have to have the same sort of flexibility in IPSEC implementations. That flexibility evolved due to demands of the SSL community, both servers and clients. So the problems would most likely have found their way into IPSEC implementations, if they were as mature and widespread as SSL, and being used for the same applications. Remember, it's impossible to build a theft-proof car. Some folks will always leave the car unlocked, or leave their keys in the ignition, or forget to remove their distributor cap before leaving, etc. Rick. smith@securecomputing.com From owner-ipsec@lists.tislabs.com Wed Dec 20 12:33:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25676; Wed, 20 Dec 2000 12:33:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03198 Wed, 20 Dec 2000 14:08:31 -0500 (EST) Reply-To: From: "walrawi" To: Subject: build the non-kernel FreeS/WAN programs and install them in /usr/local/sbin Date: Wed, 20 Dec 2000 09:20:50 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a very basic question: how do you do the following: "build the non-kernel FreeS/WAN programs and install them in /usr/local/sbin " I used "make oldgo" and I get the following error: cc -O3 -I. -g -Wall -Wpointer-arith -Wcast-qual -Wstrict-prototypes -Wbad-fu nction-cast -c -o optionsfrom.o optionsfrom.c cc -O3 -I. -g -Wall -Wpointer-arith -Wcast-qual -Wstrict-prototypes -Wbad-fu nction-cast -c -o pfkey_v2_build.o pfkey_v2_build.c In file included from pfkey_v2_build.c:57: ../pluto/defs.h:92: gmp.h: No such file or directory make[1]: *** [pfkey_v2_build.o] Error 1 make[1]: Leaving directory `/usr/src/freeswan-1.8/lib' make: *** [programs] Error 2 Thanks From owner-ipsec@lists.tislabs.com Wed Dec 20 15:31:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02202; Wed, 20 Dec 2000 15:31:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03844 Wed, 20 Dec 2000 17:15:39 -0500 (EST) Date: Wed, 20 Dec 2000 17:16:52 -0500 Message-Id: <200012202216.eBKMGqm21739@snap.thunk.org> To: kivinen@ssh.fi CC: jesse.walker@intel.com, ipsec@lists.tislabs.com In-reply-to: <14910.12195.410747.957528@taulu.hel.fi.ssh.com> (message from Tero Kivinen on Mon, 18 Dec 2000 17:39:15 +0200) Subject: Re: MODP groups draft concern From: tytso@mit.edu Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 References: <10C8636AE359D4119118009027AE9987031A9059@FMSMSX34> <14910.12195.410747.957528@taulu.hel.fi.ssh.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Mon, 18 Dec 2000 17:39:15 +0200 From: Tero Kivinen I am going to leave it in the draft for now on, but if I don't have the verification for it when we are going to RFC, then I will consider things more. I might end up having two RFC, one with the proven groups and second with those checked only using propabilistic methods. I don't think that makes any sense. The RFC should certainly call out how the primes for the various groups have been certified/proven/probablistically proven. But I don't think it's worth two separate RFC's! - Ted From owner-ipsec@lists.tislabs.com Wed Dec 20 16:12:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02857; Wed, 20 Dec 2000 16:12:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04014 Wed, 20 Dec 2000 18:07:56 -0500 (EST) Date: Wed, 20 Dec 2000 18:09:09 -0500 (EST) From: Henry Spencer To: walrawi cc: ipsec@lists.tislabs.com Subject: Re: build the non-kernel FreeS/WAN programs and install them in /usr/local/sbin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 20 Dec 2000, walrawi wrote: > I have a very basic question: how do you do the following: > "build the non-kernel FreeS/WAN programs and install them in /usr/local/sbin > " Please post this to linux-ipsec@freeswan.org -- the ipsec@lists.tislabs.com list is for development of the IPsec protocols, not for help requests relating to a particular implementation. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Dec 21 00:09:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22838; Thu, 21 Dec 2000 00:09:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA04846 Thu, 21 Dec 2000 01:45:56 -0500 (EST) Message-ID: <6494652.977381265593.JavaMail.Administrator@hvwww3> Date: Wed, 20 Dec 2000 22:47:45 -0800 (PST) From: Arvind Devarajan To: ipsec@lists.tislabs.com Subject: Placement of IPSec... Cc: freipsec@egroups.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6495331.977381265562.JavaMail.Administrator@hvwww3" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --6495331.977381265562.JavaMail.Administrator@hvwww3 Content-Type: text/plain Content-Transfer-Encoding: 7bit hi, i just had a doubt - where is IPSec placed in the network stack? conceptually, IPSec should be placed like this (please comment if wrong): +----------------+ | IP other functions | | (Like routing, etc.) | +----------------+ | | | IPSec | +-----------------+ | | | IP Fragmentation and | | Re-assembly | +-----------------+ this means, IP will have to be broken down, to insert IPSec. Does this mean that IPSec cannot be inserted if i do not have the IP code? supposing i do not have the IP code. i'll go for the Bump-In-Stack or Bump-In-Wire implementation, which means i'll have to duplicate re-assembly and fragmentation code from IP. this will hinder performance. can someone throw some light on this - is it possible to have IPSec in BIS or BIW, without duplication of IP functionality, or, is there any other way that i can insert IPSec without having IP code? thanking you, arvind. ------------------------------------------- Arvind Devarajan < - > E-mail: arvindd@india.com OR arvindd@hotvoice.com Get my PGP public key from http://arvind.freipsec.org/ -------------------------------------------------------------------------- Global Internet phone calls, voicemail, fax, e-mail and instant messaging. Sign-up today for FREE account at http://www.hotvoice.com --6495331.977381265562.JavaMail.Administrator@hvwww3-- From owner-ipsec@lists.tislabs.com Thu Dec 21 00:10:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22862; Thu, 21 Dec 2000 00:10:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA04881 Thu, 21 Dec 2000 02:09:51 -0500 (EST) X-Originating-IP: [194.100.113.203] Reply-To: silvere@iki.fi From: "Sami Vaarala" To: shacham@shacham.net, silvere@iki.fi Cc: kivinen@ssh.fi, sakane@ydc.co.jp, ipsec@lists.tislabs.com, bobmonsour@home.com, royp@cisco.com, matt@3am-software.com, ippcp@external.cisco.com Subject: Re: IKE attributes consistency. Date: Thu, 21 Dec 2000 09:11:07 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Dec 2000 07:11:07.0328 (UTC) FILETIME=[30338400:01C06B1D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >If one of the transforms, say IPComp, may elect >not to include the d-h group attribute, how does your >suggestion differ from the discussed statement of >rfc2393bis? rfc2393bis guidelines are one specific instance of my suggestion, but it covers more than that. I think the qm d-h attribute handling is a design flaw and the suggestion is a liberal way of dealing with it in a practical implementation. It's too bad there is no attribute list that applies to the SA payload as a whole... Sami -- Sami Vaarala / Pygmy Projects - We make it small! www.iki.fi/~silvere / silvere@iki.fi / No matter where you go, there you are. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-ipsec@lists.tislabs.com Thu Dec 21 05:28:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23914; Thu, 21 Dec 2000 05:28:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05572 Thu, 21 Dec 2000 06:53:33 -0500 (EST) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) From: "Amey Gokhale" Subject: Re: Placement of IPSec... To: Arvind Devarajan Cc: ipsec@lists.tislabs.com, freipsec@egroups.com Date: Thu, 21 Dec 2000 11:55:22 +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: Thu Dec 21 11:55:22 2000; Local host: pmweb7.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 hello all, What Mr.Arvind says is true for BIS implementation of IPSec.The major issue in BIS implementation is duplicaiton of effort.It requires implementing most of the features of the network layer, such as fragmentation and route tables.Duplicating functionality leads to undesired complications and it becomes more difficult to handle issues such as fragmentation,PMTU and routing. BIW implementation is one of the two types of router implementation along with the native implementation. In BIW ,IPSec is implemented in a device that is attached to the physical interface of the router.This device normally does not run any routing algorithm but is used only to secure packets.So here no duplication of effort is required for fragmentation and route tables. But BIW is not a long term solution as it is not viable to have a device attached to every interface of the router. Another issue with router implementation is IPSec contexts. As the router has to store huge routing tables and normally does not have huge disks for virtual memory support, maintaining too many IPSec contexts is an issue. i may be wrong so plz. correct me if i am wrong. thanks in advance From owner-ipsec@lists.tislabs.com Thu Dec 21 05:47:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24970; Thu, 21 Dec 2000 05:47:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05704 Thu, 21 Dec 2000 07:42:04 -0500 (EST) Message-ID: <6485947.977402667765.JavaMail.tester@hvwww88> Date: Thu, 21 Dec 2000 04:44:27 -0800 (PST) From: Arvind Devarajan To: agokhale@postmaster.co.uk Subject: [Re:] Re: Placement of IPSec... Cc: ipsec@lists.tislabs.com, freipsec@egroups.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6486597.977402667718.JavaMail.tester@hvwww88" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --6486597.977402667718.JavaMail.tester@hvwww88 Content-Type: text/plain Content-Transfer-Encoding: 7bit hi, i still cannot understand why BITW implementation need not do any fragmentation, re-assembly. in my opinion, both BITW and BITS implementations should suffer the same sort of overheads. the IPSec RFC 2401 clearly mentions that IPSec processing is to be done only on complete packets - this directly means that even BITW implementations need to do re-assembly/fragmentation (or, have i understood it wrongly?) please clarify my doubt... regards, arvind. On Thu, 21 Dec 2000 11:55:22 +0000 Amey Gokhale wrote: >hello all, > >What Mr.Arvind says is true for BIS implementation of >IPSec.The major issue in BIS implementation is duplicaiton >of effort.It requires implementing most of the features of >the network layer, such as fragmentation and route >tables.Duplicating functionality leads to undesired >complications and it becomes more difficult to handle >issues such as fragmentation,PMTU and routing. > >BIW implementation is one of the two types of router >implementation along with the native implementation. >In BIW ,IPSec is implemented in a device that is attached >to the physical interface of the router.This device >normally does not run any routing algorithm but is used >only to secure packets.So here no duplication of >effort is required for fragmentation and route tables. > >But BIW is not a long term solution as it is not viable to >have a device attached to every interface of the router. > >Another issue with router implementation is IPSec contexts. >As the router has to store huge routing tables and normally >does not have huge disks for virtual memory support, >maintaining too many IPSec contexts is an issue. > >i may be wrong so plz. correct me if i am wrong. >thanks in advance > > ------------------------------------------- Arvind Devarajan < - > E-mail: arvindd@india.com OR arvindd@hotvoice.com Get my PGP public key from http://arvind.freipsec.org/ -------------------------------------------------------------------------- Global Internet phone calls, voicemail, fax, e-mail and instant messaging. Sign-up today for FREE account at http://www.hotvoice.com --6486597.977402667718.JavaMail.tester@hvwww88-- From owner-ipsec@lists.tislabs.com Thu Dec 21 06:18:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25627; Thu, 21 Dec 2000 06:18:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05837 Thu, 21 Dec 2000 08:20:44 -0500 (EST) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) From: "Amey Gokhale" Subject: Re: [Re:] Re: Placement of IPSec... To: Arvind Devarajan Cc: agokhale@postmaster.co.uk, ipsec@lists.tislabs.com Date: Thu, 21 Dec 2000 13:22:38 +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: Thu Dec 21 13:22:38 2000; Local host: pmweb7.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 hello, Mr arvind..this may throw some more light on ur doubt...i m taking the contents from RFC2401 only.... 3.3...b----read source code sentence... "Bump-in-the-stack" (BITS) implementations, where IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Source code access for the IP stack is not required in this context, making this implementation approach appropriate for use with legacy systems. This approach, when it is adopted, is usually employed in hosts. also i request to read appendix B.2 Fragmentation part of RFC2401 and read the note below it...which talks about IPSec implementation not integrated into an IP implementation.. correct me if i m wrong Thanks in advance From owner-ipsec@lists.tislabs.com Wed Dec 27 04:46:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03042; Wed, 27 Dec 2000 04:46:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA19761 Wed, 27 Dec 2000 05:41:02 -0500 (EST) Reply-To: From: "Awan Kumar Sharma" To: "IpsecMailingList (E-mail)" Subject: Collision in IPSec SA negotiation Date: Wed, 27 Dec 2000 16:14:59 +0530 Message-Id: <000401c06ff2$12950a20$6d0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C07020.2C566DE0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C07020.2C566DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I am having a doubt and would be thankful if anybody could help me out of this. Let us take the examples where IPsec operates as a security gateway. In this case, security gateway P has got one Security Policy for traffic from host A in network X to host B in network Y with security gateway as Q. Initially they won't have any SA to use. Now when traffic originates from A for B, P decides to establish an IPSec SA between host A in network X and host B in network Y. If at the same time, traffic originates from B for A, Security gateway for Y i.e. Q. Q will see that there is no SA for this traffic, so it will also start SA negotiation. So, now we have two SA negotiations going on for the same traffic between two security gateways. Is this a normal behavior. If yes, which SA will be used for protecting the traffic. If no, how to prevent this type of SA negotiation collision. Thanks and Regards, Awan Kumar Sharma. ------=_NextPart_000_0005_01C07020.2C566DE0 Content-Type: text/x-vcard; name="Awan Kumar Sharma (E-mail).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Awan Kumar Sharma (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Sharma;Awan FN:Awan Kumar Sharma (E-mail) ORG:Future Software Ltd.;NEC-DF TITLE:Software Engg. TEL;WORK;VOICE:+91 (4330550) - 437 TEL;HOME;VOICE:+91 (044) 8205625 ADR;WORK:;;480-481, Mount Road,;Chennai;Tamil Nadu;;India LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:480-481, Mount = Road,=3D0D=3D0AChennai, Tamil Nadu=3D0D=3D0AIndia EMAIL;PREF;INTERNET:awank@future.futsoft.com REV:20001110T092335Z END:VCARD ------=_NextPart_000_0005_01C07020.2C566DE0-- From owner-ipsec@lists.tislabs.com Wed Dec 27 10:37:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24365; Wed, 27 Dec 2000 10:37:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20716 Wed, 27 Dec 2000 11:10:31 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14922.5361.35484.804125@taulu.hel.fi.ssh.com> Date: Wed, 27 Dec 2000 18:12:33 +0200 From: Tero Kivinen To: Cc: "IpsecMailingList (E-mail)" Subject: Collision in IPSec SA negotiation In-Reply-To: <000401c06ff2$12950a20$6d0c000a@future.futsoft.com> References: <000401c06ff2$12950a20$6d0c000a@future.futsoft.com> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Awan Kumar Sharma writes: > Is this a normal behavior. Yes. > If yes, which SA will be used for protecting the traffic. Doesn't care. Both are valid SAs for the data, so you can use either one. Easiest thing is to just ignore this issue when talking with other machines (it is so rare). When talking with your own machines this can be deterministic (rekeying etc), so add some simple local fix that will make sure this never happens (normally people use so that the rekeying interval of the original initiator is little shorter than actually negotiated, thus original initiator will start the rekeying first in the next time also, and the responder will not start rekeying because initiator already did that). -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Dec 27 11:32:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28149; Wed, 27 Dec 2000 11:32:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21008 Wed, 27 Dec 2000 13:02:43 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A3F276E.D84D9839@piuha.net> References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> <3A362BA2.D7EF1481@piuha.net> <3A3F276E.D84D9839@piuha.net> Date: Wed, 27 Dec 2000 13:00:49 -0500 To: jarkko@piuha.net From: Stephen Kent Subject: Re: IPv6 Neighbour Solicitation messages and IPsec Cc: ipsec@lists.tislabs.com, aidan.williams@motorola.com, ipng@sunroof.eng.sun.com Content-Type: multipart/alternative; boundary="============_-1234182169==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1234182169==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Jari, >Stephen Kent wrote: > > > > * Path MTU discovery. Consider the following case: > > > > > > (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) > > > > > > Assume N1 wants to send traffic to N2, part of the path > > > goes through an insecure network part, secured using > > > VPNGWs 1 and 2. And now Path MTU discovery is in > > > progress between N1 and N2. Assume the smallest MTU > > > is at R2. Then an ICMPv6 Packet Too Big message must be > > > sent back towards the VPNGW2. Should that message > > > go to the tunnel? I think it should. > > > > There is nothing to prohibit transmission of this ICMP message via > > the security gateways, if appropriate SPD entries exist. > >You are right, but the context of the discussion was that a proposal >was made that all ICMPv6 messages should bypass IPsec processing in >order to avoid chicken-and-egg problems with some ICMPv6 messages. I >was trying to make the point that _some_ ICMPv6 messages at least >in _some_ situations have to go through IPsec. Hence, the "ignore >ICMPv6 in IPsec" solution doesn't fly. It was also suggested that >perhaps the difference lies in tunnel mode vs transport mode. However, >that distinction doesn't solve the problems either... two nodes on >the same link could well have tunnel mode policies for all traffic, >which would then prevent e.g. duplicate address detection to work, >which in turn would prevent all communications. Also, as per RFC >2401 we do not in general have the possibility to specify policies >for individual ICMP message types. Finally, one might have expected >multicast / unicast addresses to have a significance such that >we could say only unicast traffic gets IPsec protection, but apparently >this isn't always the case. For instance, when the Neighbour >Advertisement message is used as a reply in an address resolution >situation, it is a unicast message. > >Instead, I think we need something else. What was previously lower >layer thing such as ARP, is now a proper IP packet in v6. In addition, >there is completely new functionality. These must be considered >when thinking about which messages should get IPsec protection, >and how. > >The ICMPv6 messages can be classified as follows: > > No RFC Name End-to-End Required Before UDP works > 1 2463 Dest unreach Yes No > 2 2463 Packet too big Yes No > 3 2463 Time exceeded Yes No > 4 2463 Parameter problem Yes No >128 2463 Echo request Yes No >129 2463 Echo reply Yes No >137 2461 Redirect No Yes >133 2461 Router solicit No Yes >134 2461 Router adv No Yes >135 2461 NeighSol/Resol No Yes >136 2461 NeighAdv/Resol No Yes >135 2461 NeighSol/Unreach No No >136 2461 NeighAdv/Unreach No No >135 2462 NeighSol/Autoconf No Yes >136 2462 NeighAdv/Autoconf No Yes > >Note that Neihbour Solicitation and Advertisement play multiple roles, >address resolution, unreachability detection, and autoconfiguration. >The crucial thing in the above table is to note which messages are >necessary before two IPv6 nodes can exchange packets. For IPsec, the >relevant issue is if SAs can be negotiated using IKE which runs on >top of UDP. If not, such messages simply can not be protected with >dynamic SAs; for instance we can't send UDP messages before address >autoconfiguration has determined the suitable addresses to be used >and ensured that no duplicate addresses exist on the link. > >So, what I would propose is that the ICMPv6 messages Redirect, >Router Solicitation/Advertisement, and Neighbour Solicitation/Advertisement >(except for reachbility detection) are never given normal IPsec >treatment. I.e., if I define my policies as always requiring >IKE & IPsec for all traffic, then these exceptional messages still >go in the clear and without IKE. I'm not an IPv6 expert, but it seems that the issue here is who emits the message, not just what ICMP message is being emitted. An IPsec implementation (gateway or host) has an ability to bypass control traffic that it emits, irrespective of SPD contents. So, I would expect that ICMP messages used for neighbor solicitation, advertisement, and autoconfig, etc. would fall into this category. But, such traffic emitted by a host behind a security gateway ought not be bypass in all cases, since doing so creates significant covert channel opportunities. >Furthermore, I would suggest that if protection is needed for the >exceptional ICMPv6 message set, then manually configured IPsec SAs >be used, enabling also the protection of multicast traffic. However, >in order to do things like this, the SPD must have sufficient expressive >power to distinguish ICMP messages types and roles. Today we provide port-level controls, for UDP and TCP traffic, so adding ICMP-specific controls represents a significant change. We'll have to evaluate the requirement for this sort of change very carefully. > >Finally, I would propose that everywhere in the ICMPv6 specifications >where it says "AH", tunnel mode ESP would suffice as well. This last suggestion is a topic for a different debate, and I would suggest not including it in this discussion. Steve --============_-1234182169==_ma============ Content-Type: text/enriched; charset="us-ascii" Jari, Stephen Kent wrote: > > * Path MTU discovery. Consider the following case: > > > > (N1)----(VPNGW1)----(R1)----(VPNGW2)-----(R2)----(N2) > > > > Assume N1 wants to send traffic to N2, part of the path > > goes through an insecure network part, secured using > > VPNGWs 1 and 2. And now Path MTU discovery is in > > progress between N1 and N2. Assume the smallest MTU > > is at R2. Then an ICMPv6 Packet Too Big message must be > > sent back towards the VPNGW2. Should that message > > go to the tunnel? I think it should. > > There is nothing to prohibit transmission of this ICMP message via > the security gateways, if appropriate SPD entries exist. You are right, but the context of the discussion was that a proposal was made that all ICMPv6 messages should bypass IPsec processing in order to avoid chicken-and-egg problems with some ICMPv6 messages. I was trying to make the point that _some_ ICMPv6 messages at least in _some_ situations have to go through IPsec. Hence, the "ignore ICMPv6 in IPsec" solution doesn't fly. It was also suggested that perhaps the difference lies in tunnel mode vs transport mode. However, that distinction doesn't solve the problems either... two nodes on the same link could well have tunnel mode policies for all traffic, which would then prevent e.g. duplicate address detection to work, which in turn would prevent all communications. Also, as per RFC 2401 we do not in general have the possibility to specify policies for individual ICMP message types. Finally, one might have expected multicast / unicast addresses to have a significance such that we could say only unicast traffic gets IPsec protection, but apparently this isn't always the case. For instance, when the Neighbour Advertisement message is used as a reply in an address resolution situation, it is a unicast message. Instead, I think we need something else. What was previously lower layer thing such as ARP, is now a proper IP packet in v6. In addition, there is completely new functionality. These must be considered when thinking about which messages should get IPsec protection, and how. The ICMPv6 messages can be classified as follows: No RFC Name End-to-End Required Before UDP works 1 2463 Dest unreach Yes No 2 2463 Packet too big Yes No 3 2463 Time exceeded Yes No 4 2463 Parameter problem Yes No 128 2463 Echo request Yes No 129 2463 Echo reply Yes No 137 2461 Redirect No Yes 133 2461 Router solicit No Yes 134 2461 Router adv No Yes 135 2461 NeighSol/Resol No Yes 136 2461 NeighAdv/Resol No Yes 135 2461 NeighSol/Unreach No No 136 2461 NeighAdv/Unreach No No 135 2462 NeighSol/Autoconf No Yes 136 2462 NeighAdv/Autoconf No Yes Note that Neihbour Solicitation and Advertisement play multiple roles, address resolution, unreachability detection, and autoconfiguration. The crucial thing in the above table is to note which messages are necessary before two IPv6 nodes can exchange packets. For IPsec, the relevant issue is if SAs can be negotiated using IKE which runs on top of UDP. If not, such messages simply can not be protected with dynamic SAs; for instance we can't send UDP messages before address autoconfiguration has determined the suitable addresses to be used and ensured that no duplicate addresses exist on the link. So, what I would propose is that the ICMPv6 messages Redirect, Router Solicitation/Advertisement, and Neighbour Solicitation/Advertisement (except for reachbility detection) are never given normal IPsec treatment. I.e., if I define my policies as always requiring IKE & IPsec for all traffic, then these exceptional messages still go in the clear and without IKE. I'm not an IPv6 expert, but it seems that the issue here is who emits the message, not just what ICMP message is being emitted. An IPsec implementation (gateway or host) has an ability to bypass control traffic that it emits, irrespective of SPD contents. So, I would expect that ICMP messages used for neighbor solicitation, advertisement, and autoconfig, etc. would fall into this category. But, such traffic emitted by a host behind a security gateway ought not be bypass in all cases, since doing so creates significant covert channel opportunities. Furthermore, I would suggest that if protection is needed for the exceptional ICMPv6 message set, then manually configured IPsec SAs be used, enabling also the protection of multicast traffic. However, in order to do things like this, the SPD must have sufficient expressive power to distinguish ICMP messages types and roles. Today we provide port-level controls, for UDP and TCP traffic, so adding ICMP-specific controls represents a significant change. We'll have to evaluate the requirement for this sort of change very carefully. Finally, I would propose that everywhere in the ICMPv6 specifications where it says "AH", tunnel mode ESP would suffice as well. This last suggestion is a topic for a different debate, and I would suggest not including it in this discussion. Steve --============_-1234182169==_ma============-- From owner-ipsec@lists.tislabs.com Wed Dec 27 15:37:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09043; Wed, 27 Dec 2000 15:37:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21534 Wed, 27 Dec 2000 16:31:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.0.20001220104248.00c84100@mailhost.sctc.com> References: <4.3.2.7.0.20001220104248.00c84100@mailhost.sctc.com> Date: Wed, 27 Dec 2000 16:30:15 -0500 To: Rick Smith at Secure Computing From: Stephen Kent Subject: Re: Fw: IPSec vs. SSL Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Much of this SSL vs. IPsec discussion has been based on unarticulated assumptions, and there have been some explicit technical errors, further confusing the debate. One fair observation is that SSL configuration, from a client perspective, is much easier than for IPsec precisely because SSL does not address access control issues. Even at the server side, access control is an add on, outside scope of SSL. This relates to the observation made earlier re pre-configured CAs in SSL clients. This is a convenience feature that works fairly well for the public access to server model that SSL is designed to support. It is less attractive in an intranet environment, as it creates more opportunities for spoofing. But, even this is not a criticism of SSL, because SSL does not embody any notion of root CAs in clients. All fo that is outside the SSL spec, and is not standardized. So, let's keep in mind the differences between standards and implementations when comparing SSL and IPsec. There are legitimate differences in services and functional requirements between these protocols, and many of these differences relate to the contexts for which each was designed. In some cases they might be competitors, in other cases one offers features that make it incomparable to the other. Steve From owner-ipsec@lists.tislabs.com Thu Dec 28 22:59:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA18481; Thu, 28 Dec 2000 22:59:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26701 Fri, 29 Dec 2000 00:04:15 -0500 (EST) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) From: "Amey Gokhale" Subject: Re: Collision in IPSec SA negotiation To: "IpsecMailingList (E-mail)" Date: Fri, 29 Dec 2000 05:06:20 +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: Fri Dec 29 05:06:20 2000; Local host: pmweb6.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 hello all, I agree with what Mr.Tero says, yes it is a normal behaviour. Since SA are unidirectional, for each traffic (inbound and outbound) there will be different SAs. A---P--------Q---B (SG) (SG) In this scenario A will request for a new tunnel to P for traffic from A to B as well as when B wants to send data to A it will also request for a new tunnel to Q. There will be 2 SAs for A, one for incoming traffic and one for outgoing traffic. Similarly two SAs for B when he wants to send the data to A. For one tunnel(A to B) SA of A for incoming traffic will be same as SA of B for outgoing traffic for that tunnel and SA of A for ougoing traffic will be same as SA of B for incoming traffic. Similar case will be there for other tunnel(B to A). I may be wrong so plz. correct me if i am. Amey