From owner-ipsec@lists.tislabs.com Thu Jul 1 11:36:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05408; Thu, 1 Jul 1999 11:31:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24950 Thu, 1 Jul 1999 11:46:43 -0400 (EDT) Message-ID: <377B8CF5.97443260@juggernautics.com> Date: Thu, 01 Jul 1999 11:44:53 -0400 From: Joel Odom Organization: Juggernautics, LLC X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Encapsulation of IPsec Datagrams - Performance Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Although I am still in the processes of studying IPsec, I have yet to find an answer to this question, although I know that it must be in the RFC's. Suppose that I want to encapsulate an IPsec datagram into another IPsec datagram. For example, if I ha ve a transport mode datagram inside of a tunnel mode datagram. Does the payload data get encrypted twice or only once? In other words, is ESP intelligent enough to determine that it doesn't need to spend CPU cycles encrypting the payload of tunnel mode if it is already encrypted? -- Juggernautics, LLC Computer, Electrical & Mechanical Engineering http://www.juggernautics.com From owner-ipsec@lists.tislabs.com Thu Jul 1 12:44:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06679; Thu, 1 Jul 1999 12:43:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25041 Thu, 1 Jul 1999 12:06:08 -0400 (EDT) Message-Id: <3.0.5.32.19990701120825.00944540@192.168.50.149> X-Sender: qduan@192.168.50.149 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 01 Jul 1999 12:08:25 -0400 To: Stephen Kent From: Qu Duan Subject: Re: question on Matching SAD and Selectors Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.5.32.19990630190935.00947560@192.168.50.149> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Stephen, Thank you very much for answering my questions. Yes, the triple parameter used to look up SAD table for inbound traffic is: destination address, security protocol (AH or ESP), and SPI. I typed wrong. However, my intial question for that point is still there. Please look the last paragraph of your email below, >Inbound packet processing is described in detail on RFC 2401. The fields >from the relevanrt IP header (e.g., the inner IP header for trunnel mode AH >or ESP) MUST be checked against the selectors applied to the SA. If SAD is looked up by the triple paramters of inbound packet, a unique SA will be fund if it is active. Then, how can this happen that the packet's selectors NOT match the revelant selector values in SAD/SPD? (The trple parameter is the KEY of SAD). IF this will not happen, why we shuold match selectors for inbound traffic? What we do if inbound triple (destination address, security protocol , and SPI) match a SAD entry but its selector does not match? By the way, as my understanding, inbound traffic will look up inbound SAD first through the triple; while outbound traffic will look up outbound SPD first then find a SA in outbound SAD; Does this mean inbound SPD not used by inbound traffic at least before IP processing? Thanks Qu At 10:24 AM 7/1/99 -0400, you wrote: > >>I see some ealier research using hash table indexed by SPI (for SPD), >>or indexed by source/destination address (SAD), but the standard RFC2401 >>require two databases for each inbound and outbound: >> >>SPD should be looked up by selectors which have 6 data fields, for ourbound >>traffic; > >Not all selectors will be used in every case, but yes, you do need to be >able to make use of all selector types for outbound traffic. > >>SAD should be indexed by triple (Destination Add, Source Add, and SPI) and >>looked up >> by inbound traffic; > >No, the triple for lookup on inbound traffic is: destination address, >security protocol (AH or ESP), and SPI. > >>Also, does this mean that >> each SAD entry does not have to keep selector data field; >> while inbound packet does not have to match its selector data fields >>with inbound SPD? > >Inbound packet processing is described in detail on RFC 2401. The fields >from the relevanrt IP header (e.g., the inner IP header for trunnel mode AH >or ESP) MUST be checked against the selectors applied to the SA. > >Steve > > From owner-ipsec@lists.tislabs.com Thu Jul 1 12:53:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06746; Thu, 1 Jul 1999 12:52:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25222 Thu, 1 Jul 1999 13:26:53 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.5.32.19990701120825.00944540@192.168.50.149> References: <3.0.5.32.19990630190935.00947560@192.168.50.149> Date: Thu, 1 Jul 1999 13:24:24 -0400 To: Qu Duan From: Stephen Kent Subject: Re: question on Matching SAD and Selectors Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Qu, >However, my intial question for that point is still there. Please look >the last paragraph of your email below, > >>Inbound packet processing is described in detail on RFC 2401. The fields >>from the relevanrt IP header (e.g., the inner IP header for trunnel mode AH >>or ESP) MUST be checked against the selectors applied to the SA. > > >If SAD is looked up by the triple paramters of inbound packet, >a unique SA will be fund if it is active. Then, how can this >happen that the packet's selectors NOT match the revelant >selector values in SAD/SPD? (The trple parameter >is the KEY of SAD). IF this will not happen, why we shuold match selectors >for inbound traffic? Because the sender may have introduced inappropriate traffic on the SA, due to a security failure at their end of the SA. >What we do if inbound triple (destination address, security protocol , and >SPI) >match a SAD entry but its selector does not match? Then you discard the traffic and audit the event. >By the way, as my understanding, inbound traffic will look up inbound SAD >first >through the triple; while outbound traffic will look up outbound SPD >first then >find a SA in outbound SAD; > >Does this mean inbound SPD not used by inbound traffic at least before IP >processing? I don't understand this last question. Steve From owner-ipsec@lists.tislabs.com Thu Jul 1 13:28:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07116; Thu, 1 Jul 1999 13:28:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25389 Thu, 1 Jul 1999 14:13:35 -0400 (EDT) Message-Id: <3.0.5.32.19990701141551.0093a6c0@192.168.50.149> X-Sender: qduan@192.168.50.149 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 01 Jul 1999 14:15:51 -0400 To: Stephen Kent From: Qu Duan Subject: Re: question on Inbound / Outbound SAD/SPD RFC2401 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.5.32.19990701120825.00944540@192.168.50.149> <3.0.5.32.19990630190935.00947560@192.168.50.149> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Steve, Thank you very much. Since you answered my first question, then I have to correct my last question below. Now I know matching the inbound selectors with inbound SAD/SPD after the inbound packet's triple paramter already found match, serve a verify or audit purpose in the case a packet sent over a SA by mistake. But before doing IPsec process, the may not all the selectors values be visible because of using ESP, this verfiy or audit phase can not be done before IPsec processing. So this mean a inbound packet can still be dropped after IP prcoessing becasue its selectors value do not match inbound SPD/SAD (although the triple parameter do match). Do you agree with me? My another question is, by standard we have to distinguish inbound and outbound SPD and SAD, we have to implement 2*2= 4 database (or 4 look up table)? Although there is a lot of overlap, but, SA key exchange/negotiation phase must update both inbound and outbound SAD in a different way, plus both ends must update their SADs at the same time, and do it consistantly. Is such a complexity indended by RFC2401 and ISAKMP? Thanks. Qu >>By the way, as my understanding, inbound traffic will look up inbound SAD >>first through the triple; while outbound traffic will look up outbound SPD >>first then find a SA in outbound SAD; Does this mean inbound SPD not used >>by inbound traffic at least before IP processing? > >I don't understand this last question. > >Steve > > From owner-ipsec@lists.tislabs.com Thu Jul 1 13:47:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07216; Thu, 1 Jul 1999 13:47:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25402 Thu, 1 Jul 1999 14:21:52 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515489@RED-MSG-50> From: Richard Draves To: "'Kamil Sarac'" Cc: ipsec@lists.tislabs.com Subject: RE: IP Authentication Header implementation Date: Thu, 1 Jul 1999 11:17:51 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See http:\\research.microsoft.com\msripv6. We support AH with HMAC-MD5 and source code is available. > -----Original Message----- > From: Kamil Sarac [mailto:ksarac@cs.ucsb.edu] > Sent: Thursday, July 01, 1999 10:01 AM > To: ipsec@lists.tislabs.com > Subject: IP Authentication Header implementation > > > Hello all, > I am a grad student at UC Santa Barbara. I am writing this > note to ask for > your help on IP Authentication Header. > > Unfortunately I am not familiar with Crypto but need to use > HMAC-MD5 for > my project. I am supposed to implement a new protocol MRM (Multicast > Route Monitoring) for end systems. The packet format for MRM is as > follows: > > +-------------------------------------------------------------- > | IP Header | Authentication Header(AH) | UDP Header | MRM Header > +-------------------------------------------------------------- > > Here, I need to use "IPsec Authentication Header with HMAC-MD5 > transformation as the standard authentication algorithm" > (from MRM draft). > I will implement this for SUN (solaris) machines. I will use RAW IP > sockets to create an IP packet and need to have a code to do > AH part for > me. > > My question is: Do you have a sample implementation for doing this > authentication process or do you know any place where I can > find a sample > implementation for this ? > > I will greatly appreciate your help on this. > > - kamil > > > From owner-ipsec@lists.tislabs.com Thu Jul 1 14:02:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07308; Thu, 1 Jul 1999 14:02:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25220 Thu, 1 Jul 1999 13:26:48 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <377B8CF5.97443260@juggernautics.com> Date: Thu, 1 Jul 1999 13:27:21 -0400 To: Joel Odom From: Stephen Kent Subject: Re: Encapsulation of IPsec Datagrams - Performance Question Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joel, > Although I am still in the processes of studying IPsec, I have yet >to find an answer to this question, although I know that it must be in the >RFC's. Suppose that I want to encapsulate an IPsec datagram into another >IPsec datagram. For example, if I ha >ve a transport mode datagram inside of a tunnel mode datagram. Does the >payload data get encrypted twice or only once? In other words, is ESP >intelligent enough to determine that it doesn't need to spend CPU cycles >encrypting the payload of tunnel mode > if it is already encrypted? If encryption is called for in both transport and tunnel mode SPD entries, then the data is encrypted twice, because that's what you specified. If you wanted something else to happen, you need to construct appropriate SPD entries to reflect that. Steve From owner-ipsec@lists.tislabs.com Thu Jul 1 14:03:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07318; Thu, 1 Jul 1999 14:02:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25313 Thu, 1 Jul 1999 13:44:40 -0400 (EDT) Date: Thu, 1 Jul 1999 10:00:36 -0700 (PDT) From: Kamil Sarac X-Sender: ksarac@cab To: ipsec@lists.tislabs.com Subject: IP Authentication Header implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, I am a grad student at UC Santa Barbara. I am writing this note to ask for your help on IP Authentication Header. Unfortunately I am not familiar with Crypto but need to use HMAC-MD5 for my project. I am supposed to implement a new protocol MRM (Multicast Route Monitoring) for end systems. The packet format for MRM is as follows: +-------------------------------------------------------------- | IP Header | Authentication Header(AH) | UDP Header | MRM Header +-------------------------------------------------------------- Here, I need to use "IPsec Authentication Header with HMAC-MD5 transformation as the standard authentication algorithm" (from MRM draft). I will implement this for SUN (solaris) machines. I will use RAW IP sockets to create an IP packet and need to have a code to do AH part for me. My question is: Do you have a sample implementation for doing this authentication process or do you know any place where I can find a sample implementation for this ? I will greatly appreciate your help on this. - kamil From owner-ipsec@lists.tislabs.com Thu Jul 1 14:05:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07334; Thu, 1 Jul 1999 14:05:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25459 Thu, 1 Jul 1999 14:48:41 -0400 (EDT) Message-Id: <199907011800.LAA01617@thunk.epilogue.com> To: Joel Odom cc: ipsec@lists.tislabs.com Subject: Re: Encapsulation of IPsec Datagrams - Performance Question In-Reply-To: Message from Joel Odom of "Thu, 01 Jul 1999 11:44:53 EDT." <377B8CF5.97443260@juggernautics.com> Date: Thu, 01 Jul 1999 11:00:36 -0700 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Although I am still in the processes of studying IPsec, I have > yet to find an answer to this question, although I know that it must > be in the RFC's. Suppose that I want to encapsulate an IPsec > datagram into another IPsec datagram. For example, if I ha ve a > transport mode datagram inside of a tunnel mode datagram. Does the > payload data get encrypted twice or only once? In other words, is > ESP intelligent enough to determine that it doesn't need to spend > CPU cycles encrypting the payload of tunnel mode if it is already > encrypted? No, it gets encrypted twice. This is a feature, not a bug. For one, the transport-mode ipsec packet going into the tunnel may be headed for a different destination than the tunnel endpoint. - Bill From owner-ipsec@lists.tislabs.com Thu Jul 1 14:14:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07418; Thu, 1 Jul 1999 14:14:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25589 Thu, 1 Jul 1999 15:16:21 -0400 (EDT) Message-ID: <02aa01bec3f7$7b428cd0$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Qu Duan" Cc: References: <3.0.5.32.19990630190935.00947560@192.168.50.149> Subject: Re: question on Matching SAD and Selectors Date: Thu, 1 Jul 1999 15:25:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Does this mean inbound SPD not used by inbound traffic at least before IP > >processing? > For Outbound traffic, you must look at the Outbound SPD to find the appropriate IPSec to do. For inbound traffic, the sender found the IPSec so you just look at the up the Triple (SPI, Dest IP, IPSec proto) to authenticate and/or decrypt the packet. This is at the IP layer but before the transport layer. At the transport layer, you look up the Inbound SPD to make sure the proper IPSec was performed for this traffic. Hope this helps, Aaron From owner-ipsec@lists.tislabs.com Thu Jul 1 17:20:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA09417; Thu, 1 Jul 1999 17:20:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26031 Thu, 1 Jul 1999 18:35:57 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.5.32.19990701141551.0093a6c0@192.168.50.149> References: <3.0.5.32.19990701120825.00944540@192.168.50.149> <3.0.5.32.19990630190935.00947560@192.168.50.149> Date: Thu, 1 Jul 1999 18:35:57 -0400 To: Qu Duan From: Stephen Kent Subject: Re: question on Inbound / Outbound SAD/SPD RFC2401 Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Qu, >Thank you very much. Since you answered my first question, then I have to >correct >my last question below. Now I know matching the inbound selectors with >inbound >SAD/SPD after the inbound packet's triple paramter already found match, >serve a verify or audit purpose in the case a packet sent over a SA by >mistake. > >But before doing IPsec process, the may not all the selectors values >be visible because of using ESP, this verfiy or audit phase can not be >done before IPsec processing. So this mean a inbound packet can still be >dropped after IP prcoessing becasue its selectors value do not >match inbound SPD/SAD (although the triple parameter do match). >Do you agree with me? Yes. >My another question is, by standard we have to distinguish inbound and >outbound >SPD and SAD, we have to implement 2*2= 4 database (or 4 >look up table)? Although there is a lot of overlap, but, SA key >exchange/negotiation phase >must update both inbound and outbound SAD in a different way, plus both >ends must update their >SADs at the same time, and do it consistantly. Is such a complexity >indended by RFC2401 >and ISAKMP? Yes. Steve From owner-ipsec@lists.tislabs.com Fri Jul 2 08:06:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20876; Fri, 2 Jul 1999 08:06:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27864 Fri, 2 Jul 1999 09:14:43 -0400 (EDT) Message-ID: <377C8A68.6EEA@bull.net> Date: Fri, 02 Jul 1999 11:46:16 +0200 From: "A.Le_Rouzic" X-Mailer: Mozilla 3.01Gold (X11; I; AIX 2) MIME-Version: 1.0 To: Dave Johnson CC: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: Revised Mobile IPv6 draft available References: <25577.930853668@maredsous.monarch.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, We are also looking at a mobileipv6 plus ipsec implementation in AIX 4.3 as prototype and we met the same difficulties than Itojun and Aaron Griggs. Which IP address to use for the tunnel IP ? Home address or COA address? Where the DES OPT Home address has to be ? We agree with Aaron that the IP home address must be used but this one can be hidden in the case where ESP is used causing the difficulty to retrieve the SA for this address. We think the probleme is where has to be the Home address header extension. It is not described enough in the draft. It is why we suggest to process the destination option Home Address like the Routing header as described in the IPSEC RFC but this should be added in the current IPSEC and MobileIPv6 RFCs or drafts. Like the routing header before the AH or ESP header, that will allow in any case to retrieve the SA with the Home address IP. After, it should be only a implementation issue. About, IPSEC on care-of-address. It can be written as optional or additionnal like also Aaron proposed in a previous mail. It is not possible for us to be in Oslo but we are interested by your conclusion if it impacts future IPSEC and MobileIPv6 specifications. Nevertheless you can transmit to Francis Dupont we are working with. Patrice Romand (Patrice.Romand@bull.net) Aime Le Rouzic (Aime.Lerouzic@bull.net) Dave Johnson wrote: > > >>On Friday of last week, I submitted a revised version of the Mobile IPv6 > >>draft to fix and clear up some of the minor things pointed out at the > >>last meeting and on the mailing list since. I sent an announcement of > >>it to the Mobile IP mailing list then, but I forgot to include the IPng > >>list in my announcement. Here is the list of changes since the > >>previous version of the draft: > > > > There were several questions arose for relationship of mobile-ipv6 > > and ipsec (in here, and ipsec mailing list). Do you have any plan > > to update that part? Without that update we can't make a complete > > implementation of mobile-ipv6 (with security considered). > > > >itojun > > Yes, I believe that is the only remaining place where clarification is > needed, although I haven't had enough time to read through all the > IPsec documents myself enough times, and haven't had a chance to talk > enough with IPsec experts about it, to really get the definitive text > writtin into the draft for this. I hope to be able to talk with > implementers and IPsec experts about this in Oslo. Will you be there? > > Dave > > I will > > Itojun -- ________________________Aime LEROUZIC____________________________ BULL S.A ECHIROLLES FRANCE mailto:Aime.Lerouzic@frec.bull.fr http://www-frec.bull.com tel: +33 (0)4 76 29 75 51 Communications TCPIP http://intranet/lerouzic From owner-ipsec@lists.tislabs.com Fri Jul 2 09:39:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA22902; Fri, 2 Jul 1999 09:39:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28149 Fri, 2 Jul 1999 10:52:57 -0400 (EDT) Date: Fri, 02 Jul 1999 16:51:37 +0200 (MET DST) From: Marcello De Angelis Subject: some questions about IKE To: ipsec@lists.tislabs.com Message-id: X-Envelope-to: ipsec@lists.tislabs.com MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am a engineering student working on my degree's thesis. I'm studiing security protocols, particularly IPSec and IKE. I have some doubts about IKE. I'd like to know if the following assertions about phase 1 authentication are right. 1. When we use a pre-shared Key, if I'm able to calculate SKEYD then I'm really the owner of the pre-shared key. As a consequence, the digest is a proof of authentication because it depends on SKEYD. 2. When we use a public cryptography scheme, if I'm able to calculate SKEYD then I'm the owner of the right private key. In fact SKEYD depends on same values (nonces) that were encrypted with my public key. As a consequence, the digest is a proof of autentication because it depends on SKEYD. 3. When we use a "digital signature" scheme, SKEYD is not a securely secret value, because of a man-in-the-middle-attack. For this reason I send a digital signature of the digest: this signature is a proof of authentication and defeats the man-in-the-middle attack. I apologize for my errors. thanks in advance, Marcello De Angelis. From owner-ipsec@lists.tislabs.com Fri Jul 2 10:15:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23569; Fri, 2 Jul 1999 10:15:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28317 Fri, 2 Jul 1999 11:38:40 -0400 (EDT) Message-ID: <032401bec4a2$3eac0700$634cf526@east.isi.edu> From: "Aaron Griggs" To: "A.Le_Rouzic" Cc: , , References: <25577.930853668@maredsous.monarch.cs.cmu.edu> <377C8A68.6EEA@bull.net> Subject: Re: Revised Mobile IPv6 draft available Date: Fri, 2 Jul 1999 11:47:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We agree with Aaron that the IP home address must be used but this > one can be hidden in the case where ESP is used causing the difficulty > to retrieve the SA for this address. > The triple used to find the SA uses the destination address so this is not a problem when the mobile node sends to the correspondent node (IP(MN->CN)_ESP_HmAddrOpt_Data). The correspondent node receives the ESP packet and uses its own address for the lookup. So the SA is found. When the correspondent nodes sends to the mobile node, there isn't a problem because a routing header is used which is before the ESP header (IP(CN->MN)_RH_ESP_Data). When the mobile node hits the ESP header and does the SA lookup, the destination address is the home address. > We think the probleme is where has to be the Home address header > extension. It is not described enough in the draft. > > It is why we suggest to process the destination option Home Address > like the Routing header as described in the IPSEC RFC but this should > be added in the current IPSEC and MobileIPv6 RFCs or drafts. > > Like the routing header before the AH or ESP header, that will allow > in any case to retrieve the SA with the Home address IP. After, it > should be only a implementation issue. Again, the SA triple uses the destination address and not the source address so the home address option isn't an issue. For the inbound SP verification, make the remote IP address wildcarded so the home address option affect (source address changed from mobile to home) doesn't make the verification fail. Aaron From owner-ipsec@lists.tislabs.com Fri Jul 2 10:20:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23646; Fri, 2 Jul 1999 10:20:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28357 Fri, 2 Jul 1999 11:54:47 -0400 (EDT) To: "Aaron Griggs" cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-reply-to: agriggs's message of Fri, 02 Jul 1999 11:47:51 -0400. <032401bec4a2$3eac0700$634cf526@east.isi.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Sat, 03 Jul 1999 00:49:33 +0900 Message-ID: <26078.930930573@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Like the routing header before the AH or ESP header, that will allow >> in any case to retrieve the SA with the Home address IP. After, it >> should be only a implementation issue. >Again, the SA triple uses the destination address and not the source address >so the home address option isn't an issue. For the inbound SP verification, Source address (whether it is ip6_src or home address option) is still very important. When you negotiate the key with the peer, IKE runs between (src, dst) pair. itojun From owner-ipsec@lists.tislabs.com Fri Jul 2 12:16:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25737; Fri, 2 Jul 1999 12:16:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28721 Fri, 2 Jul 1999 13:20:40 -0400 (EDT) Message-ID: <035301bec4b0$7d2cd190$634cf526@east.isi.edu> From: "Aaron Griggs" To: , "A.Le_Rouzic" Cc: , , References: <25577.930853668@maredsous.monarch.cs.cmu.edu> <377C8A68.6EEA@bull.net> <032401bec4a2$3eac0700$634cf526@east.isi.edu> Subject: Re: Revised Mobile IPv6 draft available Date: Fri, 2 Jul 1999 13:29:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Again, the SA triple uses the destination address and not the source address > so the home address option isn't an issue. For the inbound SP verification, > make the remote IP address wildcarded so the home address option affect > (source address changed from mobile to home) doesn't make the verification > fail. I messed up on this statement. The SP address that can be wildcarded is the local address. I usually specify an SP as bidirectional with a remote and local address. The local address is the source address for outbound traffic and the destination address for inbound traffic. The result of a bidirectional SP is two SAs: one for inbound and one for outbound. The outbound SA has the destination address of the remote machine and the inbound SA has the destination address of the local machine. My implementation only supports manual keys so I require the user to enter a local address. Itojun wrote: >Source address (whether it is ip6_src or home address option) >is still very important. When you negotiate the key >with the peer, IKE runs between (src, dst) pair. Couldn't the source just be selected by the sender? For multiple address on an interface, the best address is selected. My statements above handles specifying a source for the SA. Since I am not implementing IKE, I might be missing something. Aaron From owner-ipsec@lists.tislabs.com Sat Jul 3 20:32:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA08028; Sat, 3 Jul 1999 20:32:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01889 Sat, 3 Jul 1999 21:40:07 -0400 (EDT) Date: Sun, 4 Jul 1999 04:39:45 +0300 (EET DST) Message-Id: <199907040139.EAA14195@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Scott G. Kelly" Cc: Tamir Zegman , ipsec@lists.tislabs.com Subject: notify message payloads In-Reply-To: <377266B0.8371132D@redcreek.com> References: <377266B0.8371132D@redcreek.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott G. Kelly writes: > I have a couple of questions. First, what prompted the selection of the > attribute numbers? I can't find any defined attribute types in the > isakmp doc, and all it says about them is > > o Attribute Type (2 octets) - Unique identifier for each type of > attribute. These attributes are defined as part of the DOI- > specific information. So for notifications I would say the attribute types have separate name space, and the name space used might depend on the notification type itself. For example if the notification type was defined in the DOI document, the name space of the attribute types belongs to that document. So when IPSEC DOI defines the RESPONDER-LIFETIME notification, it defines that the name space for those data attributes inside the notification data is the IPSEC DOI SA data attributes. > In the DOI doc, the only attributes defined are SA attrs. As I see it, > there are two issues here. First, there are (apparently) no attributes > defined for DOI zero (0), though some of our notify messages clearly > could be outside of the ipsec doi. Second, the attributes defined for > the ipsec doi aren't yet segregated into attribute classes. I guess you > could argue that they *are* since there is currently only one class :-) > but on the other hand, there is no mechanism defined for adding new > attributes in a manner which insures adequate contiguous number space > for existing attr class expansion, etc. I think we can just define our own "ISAKMP Notification Attributes" in the "Content Requirements for ISAKMP Notify Messages" document. We should then leave that newly created name space to IANA. > The IKE document says > > 11.1 Attribute Classes > > Attributes negotiated in this protocol are identified by their class. > Requests for assignment of new classes must be accompanied by a > standards-track RFC which describes the use of this attribute. > > but I did a quick search at IANA and didn't find any attribute classes > defined (not even for the ipsec doi). I guess I could have missed > something, in which case someone can correct me, but otherwise, we need > to figure out what to do about this. The IKE document describes the attribute classes (== attribute types) in the Appendix A for the Phase 1 SA payload. The IPSEC DOI defines the attribute types for the quick mode SA. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Jul 3 21:00:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA09920; Sat, 3 Jul 1999 21:00:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01876 Sat, 3 Jul 1999 21:30:30 -0400 (EDT) Date: Sun, 4 Jul 1999 04:30:11 +0300 (EET DST) Message-Id: <199907040130.EAA13637@torni.ssh.fi> From: Tero Kivinen To: ipsec@lists.tislabs.com CC: skelly@redcreek.com Subject: draft-ietf-ipsec-notifymsg-00.txt (long again) Organization: SSH Communications Security Oy Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 73 min X-Total-Time: 99 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I managed to check this out only now. I would really like to see all the notification data fields to have data attribute list instead of fixed fields. That would solve quite a lot of problems. We could add attributes like: type value da type ------------------------------------------------------------------- Type of Offending Payload 1 B Offending Payload Data 2 V Error Position Offset 3 B Error Text Describing the Problem 4 V Error Text Language 5 V Message Id of the Offending Negotiation 6 V Exchange Type of Negotiation 7 B Invalid Flag Bits 8 B ------------------------------------------------------------------- Type of Offending Payload Payload type of the offending payload encoded as 16 bit interger. Offending Payload Data Offeding payload data included the generic header. Note that next payload type points to the next payload, it does not specify the type of this payload. If the payload type is not unique inside the error code the type of offending payload must be given separately. Error Position Offset Byte offset of the error position from the beginning of the offending payload (must be given also). Error Text Describing the Problem Text describing the problem. (ISO-10646 UTF-8 encoding). Error Text Language Error text language tag (as defined in RFC 1766). Message Id of the Offending Negotiation Message id of the offending negotiation encoded has 4 byte value. Exchange Type of Negotiation Exchange type of the offeding negotiation. Encoded as 16 bit integer. Invalid Flag Bits Invalid flags (valid flags are masked out) Encoded as 16 bit integer. That would make processing of the notifications identical for all cases, and we don't have to have special code to handle all different kind of notifications. Also in that case vendors can add special stuff in the notification data without breaking other implementations (we should say that all unknown data attribute types must simply be ignored). Also extending the format later is quite easy, and offers backward compatibility. Also implementations are allowed to just leave out the whole data part if they don't want to fill it in. > 2.1 INVALID-PAYLOAD-TYPE > When present, the Notification Payload MUST have the following > format: > > o Payload Length - set to length of payload + size of data (var) > o DOI - set to the current DOI for this negotiation We might not have DOI yet. SA payload might not yet be parsed, or there might not be SA payload (transactional, information exchange). I would say we should ALWAYS use ISAKMP_DOI (0) here. > o Protocol ID - set to selected Protocol ID from chosen SA Same here, we might not have protocol ID from the SA yet. I would suggest that we always reserve value 0 to be specify error in the isakmp protocol, in which case the SPI will always be the ISAKMP cookies of the offending packet. Note, they might be different from the ones stored in the header. For example if we have ISAKMP SA up and running and we start rekey, which fails, we might send the error message back using the old ISAKMP SA to get protection for the notification, so we must identify the ISAKMP SA somewhere. > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) I would suggest this 0 or 16. The value 0 means that the ISAKMP cookies can be seen from the header (== we are using same ISAKMP SA to send notification back than what cause the problem). > o Notify Message Type - set to INVALID-PAYLOAD-TYPE > o SPI - set to empty or to the sender's inbound > IPSEC SPI So this should be the isakmp cookies (== spi of the ISAKMP SA) or empty. > o Notification Data - contains the subject payload Notification data SHOULD contain the type of offending payload, and it MAY contain offending payload data, error text describing the problem and message id of the offending negotiation. > 2.2 DOI-NOT-SUPPORTED > o DOI - set to the subject (unsupported) DOI I think this should again be ISAKMP DOI. > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > o Notify Message Type - set to DOI-NOT-SUPPORTED > o SPI - set to empty or to the sender's inbound IPSEC SPI If the DOI is unsupported, we cannot parse the SA payload, because we do not know the length and format of the situation field. So we cannot fill in the Protocol id, spi size, and spi from the SA payload. I would suggest we fill them similarly than in INVALID-PAYLOAD-TYPE case above. > o Notification Data - empty This SHOULD contain offending payload data, and message id of the offending negotiation, and it MAY contain error position offset, and error text describing the problem. > 2.3 SITUATION-NOT-SUPPORTED > o Payload Length - set to length of payload + size of data (4) > o DOI - set to DOI included in SA payload with situation > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > o Notify Message Type - set to SITUATION-NOT-SUPPORTED > o SPI - set to empty or to the sender's inbound IPSEC SPI There is really no point filling in the protocol ID, and spi, because we might not yet have selected anything. I would suggest similar handling than above. > o Notification Data - contains unsupported situation value This SHOULD contain Offending Payload Data, and Message Id of the Offending Negotiation, and it MAY contain Error Position Offset, and Error Text Describing the Problem. > 2.4 INVALID-COOKIE > o Payload Length - set to length of payload + size of data (var) > o DOI - set to IPSEC DOI (1) This should defenately be ISAKMP DOI (0). > o Protocol ID - set to PROTO_ISAKMP > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-COOKIE > o SPI - empty And we must fill in the SPI size to 16, and SPI data to cookies of the offending payload so the other end can find the ISAKMP SA that is expired or invalid. > o Notification Data - contains the invalid cookie (size may be > derived from payload length This SHOULD contain Message Id of the Offending Negotiation, and it MAY contain Error Text Describing the Problem. > 2.5 INVALID-MAJOR-VERSION > o Payload Length - set to length of payload + size of data (5) > o DOI - set to DOI under which message was received We haven't parsed the SA payload yet, so we don't know the DOI, so it should be ISAKMP DOI (0). > o Protocol ID - set to PROTO_ISAKMP > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-MAJOR-VERSION > o SPI - empty Again, I would put the ISAKMP SPI (cookies) of the offending packet here (16 bytes). > o Notification Data - contains the message ID, followed by the > invalid version octet This SHOULD contain Message Id of the Offending Negotiation, and it MAY contain Error Text Describing the Problem. The version supported by the other end can be seen from the header of this notification, the sender fills it with his own version number. > 2.6 INVALID-MINOR-VERSION Same than INVALID-MAJOR-VERSION. > 2.7 INVALID-EXCHANGE-TYPE > o Payload Length - set to length of payload + size of data (1) > o DOI - set to DOI under which message was received We do not have DOI yet, so ISAKMP DOI (0). > o Protocol ID - set to PROTO_ISAKMP > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-EXCHANGE-TYPE > o SPI - empty Again, ISAKMP SA SPI here. > o Notification Data - contains the invalid exchange type octet This SHOULD contain Message Id of the Offending Negotiation, and it MAY contain Error Text Describing the Problem. No need to put the invalid exchange type, because the sender can find it from the message id. If we want to put it here, just add one more attribute type. > 2.8 INVALID-FLAGS > o Payload Length - set to length of payload + size of data (1) > o DOI - set to DOI under which message was received > o Protocol ID - set to PROTO_ISAKMP > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-FLAGS > o SPI - empty Same as above, ISAKMP DOI, ISAKMP SA SPI. > o Notification Data - contains the flags octet with only > the unknown/invalid flags bits set (valid bits masked off) I am not sure if that is really needed, but it might be useful. > 2.9 INVALID-MESSAGE-ID > o Payload Length - set to length of payload > o DOI - set to DOI under which message was received > o Protocol ID - set to PROTO_ISAKMP > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-MESSAGE-ID > o SPI - empty Same as above, ISAKMP DOI, ISAKMP SA SPI. > o Notification Data - empty This SHOULD contain Message Id of the Offending Negotiation, and it MAY contain Error Text Describing the Problem. > In this case, the invalid message ID is contained in the ISAKMP > header of the notify message. Somebody already commented this, no need to say more about it. > 2.10 INVALID-PROTOCOL-ID > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet > o Protocol ID - set to invalid protocol ID value I would leave that Protocol ID to 0, and put that invalid protocol value in the data. > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-PROTOCOL-ID > o SPI - empty > o Notification Data - contains the proposal payload in which the > unrecognized protocol ID was found. Notification data SHOULD contain the offending (SA) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. Now the error position offset points inside to the SA payload to the byte which contains the invalid protocol id. > 2.11 INVALID-SPI > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from offending SA > proposal > o SPI Size - set to zero (0) > o Notify Message Type - set to INVALID-SPI > o SPI - empty > o Notification Data - contains the proposal payload in which the > invalid SPI was found. Again I would use similar approach than in INVALID-PROTOCOL-ID, i.e protocol ID 0, empty spi, and notification data SHOULD contain the offending (SA) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.12 INVALID-TRANSFORM-ID > o Payload Length - set to length of payload + size of data (2) > o DOI - set to DOI of received packet > o Protocol ID - set to Protocol ID from proposal containing > subject > transform ID > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > o Notify Message Type - set to INVALID-TRANSFORM-ID > o SPI - set to empty or to the sender's inbound IPSEC SPI > o Notification Data - contains the transform number, followed by > the invalid transform ID. I would make this identical to INVALID-PROTOCOL-ID. > 2.13 ATTRIBUTES-NOT-SUPPORTED > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from subject SA > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > o Notify Message Type - set to ATTRIBUTES-NOT-SUPPORTED > o SPI - set to empty or to the sender's inbound IPSEC SPI > o Notification Data - contains an ISAKMP attribute list consisting > of the unsupported attributes In this case we can use protocol ID, and SPI, but then I would also defined that the SPI must be from the same proposal payload which contains the offending transform (or first of them). Notification data SHOULD contain the offending (SA) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.14 NO-PROPOSAL-CHOSEN > o Payload Length - set to length of payload > o DOI - set to DOI of received packet > o Protocol ID - set to PROTO_ISAKMP > o SPI Size - set to zero (0) Size 16. > o Notify Message Type - set to NO-PROPOSAL-CHOSEN > o SPI - set to the two ISAKMP cookies > o Notification Data - empty Notification data SHOULD contain the Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. There might be use to put SA payload data and error position offset so that the error position offset points to the first byte which didn't match the policy, but it might be too complicated to really be usefull. > 2.15 BAD-PROPOSAL-SYNTAX > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from chosen SA I would put PROTO_ISAKMP here. > o SPI Size - set to zero (0) (SPI is in proposal) Size 16 or 0 depending if the ISAKMP SPI is same than notification packet or not. > o Notify Message Type - set to BAD-PROPOSAL-SYNTAX > o SPI - empty ISAKMP SPI or empty. > o Notification Data - contains the improperly-formed proposal or > transform payload > [Note: There's an ambiguity here due to overloading this error > type. It would be resolved by adding a BAD-TRANSFORM-SYNTAX error, > and only using this one for proposals. Alternatively, we could > add > an identifier to this message to distinguish between the two > cases] I would always put in the SA payload. I.e notification data SHOULD contain the offending (SA) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. Here the offending byte would point to the error inside the SA payload. > 2.16 PAYLOAD-MALFORMED > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet We might not yet have DOI yet, so ISAKMP DOI (0). > o Protocol ID - set to PROTO_ISAKMP Selected protocol if we have it or PROTO_ISAKMP (in which case the SPI must be ISAKMP SA SPI). > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) 0, 2, 4 or 16. We might not yet have IPSEC SPI. > o Notify Message Type - set to PAYLOAD-MALFORMED > o SPI - set to empty or to the sender's inbound IPSEC SPI If protocol ID is PROTO_ISAKMP then this should contain ISAKMP SA SPI (cookies), or if the protocol id is something else (AH/ESP/IPCOMP) then that SPI. > o Notification Data - contains the offending payload > [Note: This overlaps with BAD-PROPOSAL-SYNTAX...] Notification data SHOULD contain the type of offending payload, the offending payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.17 INVALID-KEY-INFORMATION > The INVALID-KEY-INFORMATION error message may be used to communicate > that the key exchange type specified by the key exchange payload is > not supported. There is no key exchange type in the KE payload. There is a key exchange transform ID in the SA payload (KEY_IKE). This should only be sent if the KE payload is invalidly formatted (too short/long etc). > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) Depending of the Protocol ID this should be either 0 or 16 (PROTO_ISAKMP) or 2/4 (IPCOMP/IPSEC). > o Notify Message Type - set to INVALID-KEY-INFORMATION > o SPI - set to empty or to the sender's inbound IPSEC SPI If protocol ID is PROTO_ISAKMP then this should contain ISAKMP SA SPI (cookies), or if the protocol id is something else (AH/ESP/IPCOMP) then that SPI. > o Notification Data - contains the subject key exchange payload Notification data SHOULD contain the offending (KE) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.18 INVALID-ID-INFORMATION > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet > o Protocol ID - set to PROTO_ISAKMP For phase 2 this should be selected Protocol ID, and PROTO_ISAKMP if in phase 1. > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) Size = 0, 2, 4, 16. > o Notify Message Type - set to INVALID-ID-INFORMATION > o SPI - set to empty or to the sender's inbound IPSEC SPI Same stuff here than above. > o Notification Data - contains subject ID payload Notification data SHOULD contain the offending (ID) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.19 INVALID-CERT-ENCODING > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI It cannot be IPSEC SPI, only ISAKMP SPI is valid (0, or 16 bytes). So it must also be PROTO_ISAKMP. > o Notification Data - contains the certificate payload Notification data SHOULD contain the offending (CERT) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.20 INVALID-CERTIFICATE > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI It cannot be IPSEC SPI, only ISAKMP SPI is valid (0, or 16 bytes). So it must also be PROTO_ISAKMP. > o Notification Data - contains subject certificate payload Notification data SHOULD contain the offending (CERT) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.21 CERT-TYPE-UNSUPPORTED > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI Same here. > o Notification Data - contains the subject certificate payload Notification data SHOULD contain the offending (CERT) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.22 INVALID-CERT-AUTHORITY > > The INVALID-CERT-AUTHORITY error message may be used to communicate > that the Certificate Authority in a certificate payload is invalid or > improperly formatted. Not in certificate payload, but in certificate request payload. > Phase: 1 or 2 Phase 1 only. > Differentiator: Cookies, message ID, SPI, CERT payload CR payload. > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI See above > o Notification Data - contains the subject certificate payload Notification data SHOULD contain the offending (CR) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.23 INVALID-HASH-INFORMATION > o Payload Length - set to length of payload + size of data (1) > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI We might not have DOI / protocol / SPI yet. For example this might be the first payload of the quick mode and the first hash payload is invalid... So it should be ok to use PROTO_ISAKMP, and ISAKMP SPI. > o Notification Data - contains the subject hash payload Notification data SHOULD contain the offending (HASH) payload data, error position offset, and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.24 AUTHENTICATION-FAILED > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to zero (0)or four (4) (one IPSEC SPI) > o SPI - set to empty or to the sender's inbound > IPSEC SPI Might not be IPSEC SPI, which failed, so PROTO_ISAKMP, and ISAKMP SA SPI should also be allowed. > o Notification Data - empty Notification data SHOULD contain Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.25 INVALID-SIGNATURE > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI Again ISAKMP SA SPI must also be allowed. > o Notification Data - contains the subject signature payload Notification data SHOULD contain Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.27 NOTIFY-SA-LIFETIME > o SPI Size - set to zero(0) o Notify Message Type - set to > NOTIFY-SA-LIFETIME Formatting error. > o SPI - empty SPI should be the IPSEC or ISAKMP SA SPI. Not empty. > 2.28 CERTIFICATE-UNAVAILABLE > o Payload Length - set to length of payload + size of data (var) > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to zero (0) or four (4) (one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI Normally this is PROTO_ISAKMP, spi size 0 or 16, and ISAKMP SA SPI. > o Notification Data - contains the subject certificate request Notification data SHOULD contain the offending (CR) payload data and Message Id of the Offending Negotiation, and it MAY contain error text describing the problem. > 2.29 UNSUPPORTED-EXCHANGE-TYPE > o DOI - set to DOI of received packet We do not have DOI, so ISAKMP DOI (0). > o Protocol ID - set to selected Protocol ID from chosen SA We do not have protocol, so PROTO_ISAKMP. > o SPI Size - set to zero (0) or four (4)(one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI ISAKMP SA SPI. > o Notification Data - contains the message ID, followed by the > invalid exchange type octet This SHOULD contain Message Id of the Offending Negotiation, and it MAY contain Error Text Describing the Problem. We might want to add that exchange type also here. > 2.30 UNEQUAL-PAYLOAD-LENGTHS > The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate > that message length in the ISAKMP header does not match the sum of > the actual payload lengths. It can also be used when for example data attributes values are longer than transform payload, or spi size causes sa payload to overflow etc. > o Payload Length - set to length of payload + size of data (4) > o DOI - set to DOI of received packet > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to zero (0) or four (4)(one IPSEC SPI) > o SPI - set to empty or to the sender's inbound IPSEC SPI Quite often we do not have DOI or IPSEC SPI, so ISAKMP_DOI / PROTO_ISAKMP / ISAKMP SA SPI should also be allowed. > o Notification Data - contains the actual payload length as a > 32-bit unsigned value. Notification data SHOULD contain the type of offending payload, and it MAY contain offending payload data, error position offset, error text describing the problem and message id of the offending negotiation. If error position offset is given it points to place where the buffer overflow is detected. For example if the spi size is set to 16 bytes, and the generic Notify payload header doesn't include that to size (it has size of 12 bytes) then it points to the SPI size byte inside the notify payload. > 3.1 CONNECTED > o SPI - set to the the sender's inbound IPSEC SPI Selected SPI. In phase 1 ISAKMP SA SPI (or empty), in phase 2 one of the selected SPIs (there can be multiple of them if we have multiple protocols (AH/ESP/IPCOMP)). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Jul 3 22:11:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA14157; Sat, 3 Jul 1999 22:11:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02000 Sat, 3 Jul 1999 23:11:56 -0400 (EDT) Date: Sun, 4 Jul 1999 06:11:44 +0300 (EET DST) Message-Id: <199907040311.GAA19614@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ike-ext-meth-01.txt In-Reply-To: <199906281236.QAA03140@relay1.trustworks.com> References: <199906281236.QAA03140@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 53 min X-Total-Time: 86 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > > 5. Order of Checking > > The order of checks performed for IKE datagram SHOULD be following: > This is true not only for IKE datagrams, but for generic ISAKMP datagram > also. So, the wording should probably be: True, but the document is more concerned about the IKE extensibility than ISAKMP. Also I am not sure if the text is at all acceptable when somebody defines other key exchange method than IKE, and it is very hard to think about that before you see the other protocol. After somebody does that, this document propably needs to be updated anyways... > > There are no separate major and minor version numbers for ISAKMP and > > IKE, so they both share one major/minor version number. Because the > > ISAKMP document describes the generic packet formats etc, changes in the > > ISAKMP part will propably cause major version number to be incremented. > > On the other hand changes in the IKE part propably will keep the generic > > packet formats intact, thus only minor version number might need to be > > incremented. > > Tero, I've been still under impression, that mixing IKE and ISAKMP > versions number is not a good thing. Let us leave ISAKMP major and > minor versions for changes in ISAKMP and encode future IKE versions > as new transform identifiers. Perhaps I should be more clear to say that every time we change minor or major version it is really ISAKMP modification not IKE modifications. The end effect is same, the ISAKMP version number is going to go up every time we make bigger changes to IKE. The document isolates the modifications which need changes to the version numbers (flags, new use of reserved, and maybe new payload types), and they are strictly speaking ISAKMP modifications not IKE modifications. > Otherwise we will have difficulties in > case an alternative KE protocol will be defined within ISAKMP > framework. What meaning shall minor ISAKMP number have in this case? It still defines the packet format of the system. Even if the IKE has added some flags or new use for reserved fields (the criticality flag for payloads) thus causing the new minor version number (== new ISAKMP version), it does not necessary mean that other KE protocols must use that version they can be using the old 1.0 version if the want to. If the other KE protocol also wants to modify the ISAKMP packet structure (lets say they want to add another flag), then they have to take the latests version of ISAKMP, including the changes done because of the IKE update and update from there. Note, that there is no changes in the will bump up the ISAKMP version number without the packet format also changing at the same time. > What meaning shall it have if two (or more) different KE protocols > (different transform identifiers) are proposed by initiator? Good question. Currently I don't think you can do it, because for example the KE payload etc might be completely different depending on the KE protocol. So you cannot really do that in general case. For some limeted use you might be able to do it, for example if you are using the main mode you could do it (only SA payload in the first payload), but unfortunately IKE rfc says that you can have only "single proposal payload in a single SA payload", so if you offer two proposal the other end is propably going to fail immediately. I didn't like that restriction when it was added, and I still dont like it, but it is there. > Moreover, by mixing ISAKMP minor version number with IKE version you > seem to contradict with section 5 of your own draft (order of > checking), because you require to check minor version number before > you even get know that it is really an IKE datagram, not general > ISAKMP datagram. So, you implicitly assume that all ISAKMP datagrams > are IKE datagrams, that is not true (at least in theory). Yes, you are right that, that order of checking applies also for generic ISAKMP packets, but it also applies to IKE packets... The document is still named "IKE Extensions Methods", because that is where the intrest of this document really is. In most cases where there is a string "IKE" you can change to to say "ISAKMP" and you still get things right. > > Phase 1 and phase 2 negotiations are separate negotiations. So phase 1 > > negotiation that creates ISAKMP SA may use version X, and phase 2 > > negotiation done over that ISAKMP SA may use version Y. > > I don't think this is right, especially with your intention to use > minor ISAKMP version number as IKE version number. Future IKE > versions may completely redefine internal cryptographic variables, > so mixing old and new versions may become problematic (consider the > situation when future IKE version will use not SKEYID, but, say, two > variables). I think that negotiated during phase 1 IKE and ISAKMP > versions must be used for all subsequent negotiations under this > ISAKMP SA. There might be limitiations in mixing the version numbers, but in general I would say they it should be allowed. If we redefine SKEYID in phase 1, then that SKEYID is used for later exchanges also, and in that case mixing the versions is not allowed. When somebody makes that kind of modification then they have to disallow that in their document. BTW changing the SKEYID doesn't cause minor number to updated, but that is just one of those limited things you can do by changing the transform id. > > There may be a need to add a criticality flag in the generic payload > > header in the next version of IKE [RFC-2409]. This allows an old version > I think this is probably an ISAKMP issue, not IKE's. > > 13. Reserved Fields > > Lots of payloads in the IKE contain RESERVED fields that are defined to > They are defined in ISAKMP, not in the IKE. Thats why this two cases are the only ones that requires the ISAKMP minor version number to be updated. The current document is written mostly from the IKE standpoint, and it quite often considers IKE and ISAKMP same. It could be quite easily to be exanded it to generic ISAKMP extension method documents, but then I would have to use more time think cases which are not relevant for IKE (which I am not sure if it is going to be that usefull, because I will propably get them all wrong...) I could update it for the next version so that I change almost all instances of "IKE" to "ISAKMP" and add still some more text about IKE transform id, and remove that one paragraph talking about ISAKMP and IKE version numbers. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jul 5 02:44:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA06855; Mon, 5 Jul 1999 02:44:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA04263 Mon, 5 Jul 1999 03:22:53 -0400 (EDT) Message-Id: <199907050722.LAA20287@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: Tero Kivinen Date: Mon, 5 Jul 1999 11:21:39 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: draft-ietf-ipsec-ike-ext-meth-01.txt CC: ipsec@lists.tislabs.com In-reply-to: <199907040311.GAA19614@torni.ssh.fi> References: <199906281236.QAA03140@relay1.trustworks.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 4 Jul 99 at 6:11, Tero Kivinen wrote: > > Otherwise we will have difficulties in > > case an alternative KE protocol will be defined within ISAKMP > > framework. What meaning shall minor ISAKMP number have in this case? > > It still defines the packet format of the system. Even if the IKE has That's what I'm talking about. ISAKMP defines packet format, so its version must reflect only this. IKE (or any other KE protocol) defines how the information contained in that packet is to be used. IKE should't redefine packet format - when such needs arise it must be done within ISAKMP spec. If IKE redefines the way information is used, it must be accompanied by new KE protocol ID (Transform ID within ISAKMP). If that new IKE requires some particular packet format (e.g. ISAKMP version), it must be reflected in its spec and implementations must reject proposals with that Transform ID and lower ISAKMP version. Apart from that IKE versions (encoded in Transform ID) and ISAKMP versions (encoded in ISAKMP header) are independent from each other. > > What meaning shall it have if two (or more) different KE protocols > > (different transform identifiers) are proposed by initiator? > > Good question. Currently I don't think you can do it, because for > example the KE payload etc might be completely different depending on > the KE protocol. So you cannot really do that in general case. Currently only aggressive exchange might not allow to do that. All the others defined in RFC2408 allow that. > For some limeted use you might be able to do it, for example if you > are using the main mode you could do it (only SA payload in the first > payload), but unfortunately IKE rfc says that you can have only > "single proposal payload in a single SA payload", so if you offer two > proposal the other end is propably going to fail immediately. Yes, but KE protocol is currently encoded not in Proposal ID (that, right, must be only one within SA payload and must be equal PROTO_ISAKMP), but in Transform ID. It is absolutely legal to have multiple transforms with (possibly) different IDs within that single proposal payload. Currently only KEY_IKE is defined, but things might change in future. So, my question is still here - what ISAKMP version will mean in that case? I'd prefer it won't be tied with IKE in any case... > > > Phase 1 and phase 2 negotiations are separate negotiations. So phase 1 > > > negotiation that creates ISAKMP SA may use version X, and phase 2 > > > negotiation done over that ISAKMP SA may use version Y. > > > > I don't think this is right, especially with your intention to use > > minor ISAKMP version number as IKE version number. Future IKE > > versions may completely redefine internal cryptographic variables, > > so mixing old and new versions may become problematic (consider the > > situation when future IKE version will use not SKEYID, but, say, two > > variables). I think that negotiated during phase 1 IKE and ISAKMP > > versions must be used for all subsequent negotiations under this > > ISAKMP SA. > > There might be limitiations in mixing the version numbers, but in > general I would say they it should be allowed. If we redefine SKEYID > in phase 1, then that SKEYID is used for later exchanges also, and in > that case mixing the versions is not allowed. When somebody makes that > kind of modification then they have to disallow that in their > document. Doesn't this complicates processing a lot? Sometimes you allow different versions, sometimes - not. What are the reasons for mixing versions in phase 1 and 2? I'd prefer that once we negotiate some version in the very first contact (phase 1), we continue using it. > BTW changing the SKEYID doesn't cause minor number to updated, but > that is just one of those limited things you can do by changing the > transform id. Yes, because it's the real IKE issue - how keys are being determined. > The current document is written mostly from the IKE standpoint, and it > quite often considers IKE and ISAKMP same. It could be quite easily to > be exanded it to generic ISAKMP extension method documents, but then I > would have to use more time think cases which are not relevant for > IKE (which I am not sure if it is going to be that usefull, because I > will propably get them all wrong...) I think it would be valuable. > I could update it for the next version so that I change almost all > instances of "IKE" to "ISAKMP" and add still some more text about IKE > transform id, and remove that one paragraph talking about ISAKMP and > IKE version numbers. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ Regards, Valery. From owner-ipsec@lists.tislabs.com Tue Jul 6 06:21:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA14982; Tue, 6 Jul 1999 06:21:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07771 Tue, 6 Jul 1999 07:13:18 -0400 (EDT) Message-Id: <3781E59B.406D682E@radguard.com> Date: Tue, 06 Jul 1999 14:16:43 +0300 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: ipsec@lists.tislabs.com, ipsra Subject: New draft submitted- IKE Base Mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, A new draft on IKE Base Mode is available at http://www.radguard.com/drafts/draft-ietf-ipsec-ike-base-mode-00.txt , and has been submitted to the internet-drafts registry. The draft follows a presentation made in the last meeting, and has taken into account comments that followed. This might help in solving some of the problems raised on the ipsra list lately. Comments requested. Yael and Sara From owner-ipsec@lists.tislabs.com Tue Jul 6 06:36:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA15208; Tue, 6 Jul 1999 06:36:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07846 Tue, 6 Jul 1999 07:55:53 -0400 (EDT) Message-Id: <199907061155.HAA26585@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ike-base-mode-00.txt Date: Tue, 06 Jul 1999 07:55:10 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IKE Base Mode Author(s) : Y. Dayan, S. Bitan Filename : draft-ietf-ipsec-ike-base-mode-00.txt Pages : 6 Date : 02-Jul-99 This document describes a new Phase I mode for IKE [RFC-2409] based on the ISAKMP [RFC-2408] Base Exchange. The purpose of this new exchange is to allow support of all authentication methods with fixed and non-fixed IP addresses, while offering protection against a denial of service attack aimed at costly operations. It also enables negotiation capabilities beyond those offered by Aggressive Mode (DH/EC group). The exchange consists of only four messages and therefor is useful when performance is crucial. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ike-base-mode-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ike-base-mode-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ike-base-mode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990704115515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ike-base-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ike-base-mode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990704115515.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jul 6 07:55:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17482; Tue, 6 Jul 1999 07:55:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08005 Tue, 6 Jul 1999 09:02:41 -0400 (EDT) To: "Aaron Griggs" cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com In-reply-to: agriggs's message of Fri, 02 Jul 1999 13:29:49 -0400. <035301bec4b0$7d2cd190$634cf526@east.isi.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Sat, 03 Jul 1999 02:27:56 +0900 Message-ID: <27960.930936476@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>Source address (whether it is ip6_src or home address option) >>is still very important. When you negotiate the key >>with the peer, IKE runs between (src, dst) pair. >Couldn't the source just be selected by the sender? For multiple address on >an interface, the best address is selected. My statements above handles >specifying a source for the SA. Since I am not implementing IKE, I might be >missing something. IKE never select the address to use by its own. IKE obeys the address the underlying communication is using. IKE always use the address pair of the underlying communication. If the kernel would like to send a IPsec'ed packet with (src, dst) and found no key with it, it will make a upcall from kernel to IKE daemon for (src, dst) by using PF_KEY interface. IKE daemon will negotiate the key, using the (src, dst) pair. IPv6: "would like to throw a packet with src->dst, let's encrypt it" IPsec: "I have no key with me, need to ask IKE for key" | | kernel to userland message v IKE: "I will negotiate the key for src->dst" The question here is: IPsec part must pick the source address to be used by IKE, and the IPsec part itself, from home address option or genine IPv6 source address. Which is appropriate for which case? itojun From owner-ipsec@lists.tislabs.com Tue Jul 6 09:24:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA19960; Tue, 6 Jul 1999 09:24:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08376 Tue, 6 Jul 1999 10:35:40 -0400 (EDT) Message-Id: <3.0.6.32.19990706155647.0093dec0@stmail01.cubis.de> X-Sender: martius@stmail01.cubis.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 06 Jul 1999 15:56:47 +0200 To: ipsec@lists.tislabs.com From: Kai Martius Subject: New Internet Draft - MIKE Cc: ipsec-policy@mail.timestep.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, [Due to submission deadline I can only make my new Draft available this way for now - submission to internet-drafts registry follows] Abstract This document describes a protocol which allows to authenticate systems and establish Security Associations in networks with different domains of security. The protocol is not only end-to-end, but it involves all participating systems in a single exchange. Further it allows security gateways to derive sub-policies for crossing (encrypted) IPSec-traffic from "conventional" packet filtering rules in a trusted manner. The draft does not only specify a protocol, but it also describes the requirements in complex network environments for a surrounding security policy management. Feel free to get a copy from http://www.imib.med.tu-dresden.de/imib/Internet/ike/draft-martius-ipsec-mike-00.txt (if you have problems reaching this site, I'll send you a copy directly) The draft comes (late ;-) after a presentation in Minneapolis at the IPSec Policy BoF http://www.ietf.org/proceedings/99mar/44th-99mar-ietf-118.html Kai ------------------------------------------------------------------ Kai Martius secunet Security Networks AG, Dresden (previous) homepage, IPSec-related stuff and PGP keys under: http://www.imib.med.tu-dresden.de/imib/personal/kai.html From owner-ipsec@lists.tislabs.com Tue Jul 6 10:49:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21967; Tue, 6 Jul 1999 10:49:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08596 Tue, 6 Jul 1999 12:08:13 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <26078.930930573@coconut.itojun.org> References: agriggs's message of Fri, 02 Jul 1999 11:47:51 -0400. <032401bec4a2$3eac0700$634cf526@east.isi.edu> Date: Tue, 6 Jul 1999 12:08:49 -0400 To: itojun@iijlab.net From: Stephen Kent Subject: Re: Revised Mobile IPv6 draft available Cc: "Aaron Griggs" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Itojun, RFC 2401 et al. are quite clear on this point. The triple used for inbound SA lookups does not include the source address. Steve From owner-ipsec@lists.tislabs.com Tue Jul 6 11:11:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22429; Tue, 6 Jul 1999 11:11:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08674 Tue, 6 Jul 1999 12:39:39 -0400 (EDT) To: Stephen Kent cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-reply-to: kent's message of Tue, 06 Jul 1999 12:08:49 -0400. 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Wed, 07 Jul 1999 01:15:04 +0900 Message-ID: <14563.931277704@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >RFC 2401 et al. are quite clear on this point. The triple used for inbound >SA lookups does not include the source address. I agree that source address is not used in inbound SA lookups. I'm talking about outbound and IKE. itojun From owner-ipsec@lists.tislabs.com Tue Jul 6 12:21:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA23880; Tue, 6 Jul 1999 12:21:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08902 Tue, 6 Jul 1999 13:39:33 -0400 (EDT) Date: Tue, 6 Jul 1999 20:39:27 +0300 (EET DST) Message-Id: <199907061739.UAA26678@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ike-ext-meth-01.txt In-Reply-To: <199907050722.LAA20287@relay1.trustworks.com> References: <199906281236.QAA03140@relay1.trustworks.com> <199907040311.GAA19614@torni.ssh.fi> <199907050722.LAA20287@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > Yes, but KE protocol is currently encoded not in Proposal ID (that, > right, must be only one within SA payload and must be equal > PROTO_ISAKMP), but in Transform ID. It is absolutely legal to have > multiple transforms with (possibly) different IDs within that single > proposal payload. Currently only KEY_IKE is defined, but things might True, I mixed PROTO_ISAKMP with KEY_IKE. > > There might be limitiations in mixing the version numbers, but in > > general I would say they it should be allowed. If we redefine SKEYID ... > Doesn't this complicates processing a lot? No, I don't think so. > Sometimes you allow different versions, sometimes - not. What are > the reasons for mixing versions in phase 1 and 2? I can start with old version of ISAKMP packet format and finish Phase 1 with that, but during that time I can find out from the vendor-id or something that yes the other end supports ISAKMP 1.1 which is needed to do some special exchanges, so I can switch to use ISAKMP 1.1 packet format for later exchanges. The reason I want to start with 1.0 instead of 1.1, might be that the other end might just drop all packets whose version number is not 1.0. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 6 16:30:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA02350; Tue, 6 Jul 1999 16:30:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09827 Tue, 6 Jul 1999 17:57:11 -0400 (EDT) Date: Tue, 6 Jul 1999 16:56:37 -0500 (CDT) From: Tylor Allison X-Sender: allison@stpsowk07.sctc.com To: Dan Harkins cc: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff In-Reply-To: <199906151954.MAA21779@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 15 Jun 1999, Dan Harkins wrote: > *) Misc > > - Does the order of ANDed offers make any difference in IPSec > encapsulation? No it doesn't. I have a few questions regarding this statement. Does this mean that a IKE or IPSEC implementation needs to figure out the most logical ordering to be applied when multiple AND proposals are received (e.g. AH & ESP & IPCOMP)? I'd prefer not to have to hard code this logic into my IKE implementation. What is the reasoning behind this decision? It seems to limit the types of SA bundles that IKE can negotiate and could lead to interop problems (based on vendors' assumptions on what the most logical ordering of AND'd SA combinations means for them). In addition, it makes the policy decisions harder (since AH & ESP & IPCOMP means the same as IPCOMP & ESP & AH) ... OK, the last statement is more of a whine than anything else, but I'd really be interested in other people's thoughts on this issue. Thanks! Tylor --- Tylor Allison tylor_allison@securecomputing.com (651) 628-1554 Secure Computing Corporation From owner-ipsec@lists.tislabs.com Tue Jul 6 18:01:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA07767; Tue, 6 Jul 1999 18:01:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09975 Tue, 6 Jul 1999 19:29:30 -0400 (EDT) Message-Id: <199907062329.QAA15815@potassium.network-alchemy.com> To: Tylor Allison cc: ipsec@lists.tislabs.com Subject: Re: issues from the bakeoff In-reply-to: Your message of "Tue, 06 Jul 1999 16:56:37 CDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15812.931303757.1@network-alchemy.com> Date: Tue, 06 Jul 1999 16:29:18 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A good sample of people's thoughts on this subject can be found in the archives of this list (November '98) the last time it was an "issue". Dan. On Tue, 06 Jul 1999 16:56:37 CDT you wrote > On Tue, 15 Jun 1999, Dan Harkins wrote: > > > > *) Misc > > > > - Does the order of ANDed offers make any difference in IPSec > > encapsulation? No it doesn't. > > I have a few questions regarding this statement. Does this mean that a > IKE or IPSEC implementation needs to figure out the most logical ordering > to be applied when multiple AND proposals are received (e.g. AH & ESP & > IPCOMP)? I'd prefer not to have to hard code this logic into my IKE > implementation. What is the reasoning behind this decision? It seems to > limit the types of SA bundles that IKE can negotiate and could lead to > interop problems (based on vendors' assumptions on what the most logical > ordering of AND'd SA combinations means for them). In addition, it makes > the policy decisions harder (since AH & ESP & IPCOMP means the same as > IPCOMP & ESP & AH) ... > > OK, the last statement is more of a whine than anything else, but I'd > really be interested in other people's thoughts on this issue. > > Thanks! > > Tylor > > --- > Tylor Allison tylor_allison@securecomputing.com (651) 628-1554 > Secure Computing Corporation > From owner-ipsec@lists.tislabs.com Tue Jul 6 18:56:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16678; Tue, 6 Jul 1999 18:56:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10184 Tue, 6 Jul 1999 20:24:21 -0400 (EDT) Message-Id: <3.0.5.32.19990706202707.00960760@192.168.50.149> X-Sender: qduan@192.168.50.149 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 06 Jul 1999 20:27:07 -0400 To: ipsec@lists.tislabs.com From: Qu Duan Subject: IPSEC SA bundle in SAD /RFC2401 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Everyone, Can anyone of you tell me that, by standard for an adjacent SA bundle like [IP] [AH] [ESP] [Upper] I should use two separated SA or use one SA but specify the two ALGs (and two keys)in one SA? If I have to use one SA for AH, one SA for ESP, do AH later, do I have to tell SPD that now the outbound packet's selector value in transport is ESP? Thanks. Qu From owner-ipsec@lists.tislabs.com Tue Jul 6 21:18:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA26895; Tue, 6 Jul 1999 21:18:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10405 Tue, 6 Jul 1999 22:44:59 -0400 (EDT) Message-ID: <004601bec822$a1a45fa0$c9887ac0@krdl.org.sg> From: "Li Ruicong" To: , "Qu Duan" References: <3.0.5.32.19990706202707.00960760@192.168.50.149> Subject: Re: IPSEC SA bundle in SAD /RFC2401 Date: Wed, 7 Jul 1999 10:44:25 +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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Dear Everyone, > > > Can anyone of you tell me that, by standard for an adjacent SA bundle like > > [IP] [AH] [ESP] [Upper] > > I should use two separated SA or use one SA but specify the two ALGs > (and two keys)in one SA? I think you should use two separated SA, one for AH and another for ESP. For example, if your SA bundle like [IP] [AH] [ESP] [ESP] [Upper] you should use three SAs. Regards, Li > > If I have to use one SA for AH, one SA for ESP, do AH later, do I have > to tell SPD that now the outbound packet's selector value in transport > is ESP? > Thanks. > > Qu > From owner-ipsec@lists.tislabs.com Wed Jul 7 01:16:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA06631; Wed, 7 Jul 1999 01:16:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA10691 Wed, 7 Jul 1999 02:37:14 -0400 (EDT) Message-Id: <199907070636.KAA28544@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: Tero Kivinen Date: Wed, 7 Jul 1999 10:36:43 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: draft-ietf-ipsec-ike-ext-meth-01.txt CC: ipsec@lists.tislabs.com In-reply-to: <199907061739.UAA26678@torni.ssh.fi> References: <199907050722.LAA20287@relay1.trustworks.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 6 Jul 99 at 20:39, Tero Kivinen wrote: > Valery Smyslov writes: > > Yes, but KE protocol is currently encoded not in Proposal ID (that, > > right, must be only one within SA payload and must be equal > > PROTO_ISAKMP), but in Transform ID. It is absolutely legal to have > > multiple transforms with (possibly) different IDs within that single > > proposal payload. Currently only KEY_IKE is defined, but things might > > True, I mixed PROTO_ISAKMP with KEY_IKE. Tero, I still would like to get an answer for my original question - if paragraph 4 from section 6 of your draft is right (statement that ISAKMP and IKE share one version number), what will ISAKMP version number mean in case several KE protocols (e.g. several transforms with different TransformIDs) are present in SA? > > Sometimes you allow different versions, sometimes - not. What are > > the reasons for mixing versions in phase 1 and 2? > > I can start with old version of ISAKMP packet format and finish Phase > 1 with that, but during that time I can find out from the vendor-id or > something that yes the other end supports ISAKMP 1.1 which is needed > to do some special exchanges, so I can switch to use ISAKMP 1.1 packet > format for later exchanges. > > The reason I want to start with 1.0 instead of 1.1, might be that the > other end might just drop all packets whose version number is not 1.0. If the other end drops all packets with 1.1, you will have to use 1.0 even in the phase 2. If it doesn't, you may start with 1.1 even in phase 1 and continue to use it in phase 2. The behaviour when peer allows 1.1 only after receiving a familiar VendorID sounds strange to me, because after this he may not obey any ISAKMP version limitations at all and do anything. ISAKMP version defines standard interoperable packet format, while VendorID - non-standard. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ Regards, Valery. From owner-ipsec@lists.tislabs.com Wed Jul 7 12:06:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25425; Wed, 7 Jul 1999 12:06:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12645 Wed, 7 Jul 1999 12:49:23 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'ipsec@lists.tislabs.com'" Subject: parallel vpns Date: Wed, 7 Jul 1999 09:48:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, An IPSec Architecture question. In the following network S1----- -----D1 | | SG1 SG2 | | S2_---- -----D2 I have a setup where a pair of gateways SG1, SG2 are protecting hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns VPN1, VPN1 where S1,D1 belong to VPN1 S2,D2 belong to VPN2 Does IPsec architecture allows for such policy defnitions? ie: multiple VPNs managed by a pair of gateways. If so Can the main mode characterstics for VPN1 and VPN2 be different? Are there any constraints on how they can be different? For example: VPN1 (main mode characterstics) DES, MD5, preshared authentication with secret1 VPN2 (main mode characterstics) DES, MD5, preshared authentication wih secret2 VPN1 and VPN2 are different only in the preshared secret used for authentication purposes. SG1 initiates an IKE request to SG2. How can SG2 determine to which VPN the request belongs looking the SA request? If SG2 were to pick the wrong VPN, then authentication will fail down the line and SG1 will not be able to complete the IKE exchange. I thought about using non-ip identifiers and having different phase 1 identifiers for VPN1 and VPN2, but that leads to different set of problems. What am I missing? Thanks for any input. -- sankar -- From owner-ipsec@lists.tislabs.com Wed Jul 7 13:43:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26493; Wed, 7 Jul 1999 13:43:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12906 Wed, 7 Jul 1999 14:53:19 -0400 (EDT) Message-ID: <3783A290.50F2D1AF@redcreek.com> Date: Wed, 07 Jul 1999 11:55:12 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sankar Ramamoorthi CC: "'ipsec@lists.tislabs.com'" Subject: Re: parallel vpns References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sankar, Comments follow quoted text... Sankar Ramamoorthi wrote: > > Hi, > > An IPSec Architecture question. > In the following network > > S1----- -----D1 > | | > SG1 SG2 > | | > S2_---- -----D2 > > I have a setup where a pair of gateways SG1, SG2 are protecting > hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns > VPN1, VPN1 where > > S1,D1 belong to VPN1 > > S2,D2 belong to VPN2 > > Does IPsec architecture allows for such policy defnitions? > ie: multiple VPNs managed by a pair of gateways. > > If so > Can the main mode characterstics for VPN1 and VPN2 be different? > Are there any constraints on how they can be different? > > For example: > > VPN1 (main mode characterstics) > DES, MD5, preshared authentication with secret1 > > VPN2 (main mode characterstics) > DES, MD5, preshared authentication wih secret2 > > VPN1 and VPN2 are different only in the preshared secret used > for authentication purposes. > > SG1 initiates an IKE request to SG2. How can SG2 > determine to which VPN the request belongs looking the SA > request? > > If SG2 were to pick the wrong VPN, then authentication will > fail down the line and SG1 will not be able to complete > the IKE exchange. > > I thought about using non-ip identifiers and having different phase 1 > identifiers > for VPN1 and VPN2, but that leads to different set of problems. > > What am I missing? > > Thanks for any input. > > -- sankar -- Use agressive mode, with ID_KEY_ID payload to identify the preshared key. Scott From owner-ipsec@lists.tislabs.com Wed Jul 7 16:44:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA29344; Wed, 7 Jul 1999 16:44:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13404 Wed, 7 Jul 1999 18:02:54 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.5.32.19990706202707.00960760@192.168.50.149> Date: Wed, 7 Jul 1999 09:28:39 -0400 To: Qu Duan From: Stephen Kent Subject: Re: IPSEC SA bundle in SAD /RFC2401 Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Qu, AH and ESP each require a separate SA (more properly a pair of SAs for each). Steve From owner-ipsec@lists.tislabs.com Wed Jul 7 19:42:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA16620; Wed, 7 Jul 1999 19:42:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14001 Wed, 7 Jul 1999 21:08:15 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Scott G. Kelly'" , Sankar Ramamoorthi Cc: "'ipsec@lists.tislabs.com'" Subject: RE: parallel vpns Date: Wed, 7 Jul 1999 18:07:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Hi Sankar, > >Comments follow quoted text... > >Sankar Ramamoorthi wrote: >> >> Hi, >> >> An IPSec Architecture question. >> In the following network >> >> S1----- -----D1 >> | | >> SG1 SG2 >> | | >> S2_---- -----D2 >> >> I have a setup where a pair of gateways SG1, SG2 are protecting >> hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns >> VPN1, VPN1 where >> >> S1,D1 belong to VPN1 >> >> S2,D2 belong to VPN2 >> >> Does IPsec architecture allows for such policy defnitions? >> ie: multiple VPNs managed by a pair of gateways. >> >> If so >> Can the main mode characterstics for VPN1 and VPN2 be different? >> Are there any constraints on how they can be different? >> >> For example: >> >> VPN1 (main mode characterstics) >> DES, MD5, preshared authentication with secret1 >> >> VPN2 (main mode characterstics) >> DES, MD5, preshared authentication wih secret2 >> >> VPN1 and VPN2 are different only in the preshared secret used >> for authentication purposes. >> >> SG1 initiates an IKE request to SG2. How can SG2 >> determine to which VPN the request belongs looking the SA >> request? >> >> If SG2 were to pick the wrong VPN, then authentication will >> fail down the line and SG1 will not be able to complete >> the IKE exchange. >> >> I thought about using non-ip identifiers and having different phase 1 >> identifiers >> for VPN1 and VPN2, but that leads to different set of problems. >> >> What am I missing? >> >> Thanks for any input. >> >> -- sankar -- > > >Use agressive mode, with ID_KEY_ID payload to identify the preshared >key. > >Scott Thanks for the suggestion. One problem in this approach is that both parties need to know how to map the preshared key into a opaque stream of bytes. Also I presume you are suggesting ID_KEY_ID as a way of getting identity protection while still having the advantages of using aggressive mode. If so how secure/vulnerable is the identity protection provided by ID_KEY_ID mechanism? -- sankar -- From owner-ipsec@lists.tislabs.com Wed Jul 7 22:00:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA27638; Wed, 7 Jul 1999 22:00:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14203 Wed, 7 Jul 1999 23:17:07 -0400 (EDT) Message-ID: <37841914.7BA9958@mail.sc.cninfo.net> Date: Thu, 08 Jul 1999 11:20:53 +0800 From: chenl Reply-To: chenl@mail.sc.cninfo.net X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586) MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" , linux-ipsec@clinet.fi Subject: What's value of the Next Header in 'tunnel mode' of ESP/AH? Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In transform mode, the Next_Header value of ESP/AH is the upper portocol's ID--TCP/UDP etc. Then, in tunnel mode, what's the Next_Header value? IP (=4) ? Thanks Chen l. From owner-ipsec@lists.tislabs.com Wed Jul 7 22:07:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA27759; Wed, 7 Jul 1999 22:07:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14249 Wed, 7 Jul 1999 23:29:47 -0400 (EDT) Message-ID: <37841C2C.4B363405@mail.sc.cninfo.net> Date: Thu, 08 Jul 1999 11:34:04 +0800 From: chenl Reply-To: chenl@mail.sc.cninfo.net X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586) MIME-Version: 1.0 To: "linux-ipsec@clinet.fi" , "ipsec@lists.tislabs.com" Subject: ESP/AH tunnel mode= ESP/AH transport mode(IP in IP tunnel mode)? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In Linux FreeS/WAN project, they implement the ESP/AH tunnel mode like this: 1. to encapsulate the orginal IP packet in IP-in-IP mode; 2. to apply ESP/AH transport on the encapsulated IP packet. that is: ESP/AH tunnel mode= ESP/AH transport mode(IP in IP tunnel mode) Is this right? Thanks, Chen L. From owner-ipsec@lists.tislabs.com Wed Jul 7 22:48:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA29760; Wed, 7 Jul 1999 22:48:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA14304 Thu, 8 Jul 1999 00:09:16 -0400 (EDT) Date: Thu, 8 Jul 1999 00:08:27 -0400 (EDT) From: Henry Spencer To: chenl cc: Linux IPsec , IP Security List Subject: Re: linux-ipsec: ESP/AH tunnel mode= ESP/AH transport mode(IP in IP tunnel mode)? In-Reply-To: <37841C2C.4B363405@mail.sc.cninfo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 8 Jul 1999, chenl wrote: > that is: > ESP/AH tunnel mode= ESP/AH transport mode(IP in IP tunnel mode) > Is this right? Yes (unless we've overlooked something really obscure). To quote RFC 2401: "A tunnel mode SA is essentially an SA applied to an IP tunnel." (This immediately following an explanation of transport mode.) Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Jul 8 07:44:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA19240; Thu, 8 Jul 1999 07:44:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15804 Thu, 8 Jul 1999 08:42:15 -0400 (EDT) Date: Thu, 8 Jul 1999 08:42:15 -0400 (EDT) Message-Id: <199907081242.IAA15804@lists.tislabs.com> From: Boby_Joseph@3com.com Wed, 7 Jul 1999 13:04:44 -0700 X-Lotus-FromDomain: 3COM To: Sankar Ramamoorthi cc: "'ipsec@lists.tislabs.com'" Message-ID: <882567A7.006E4876.00@hqoutbound.ops.3com.com> Date: Wed, 7 Jul 1999 15:11:02 -0500 Subject: Re: parallel vpns Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers. If you use any other authentication methods you can have multiple VPNs as described in your mail. Sent by: Sankar Ramamoorthi To: "'ipsec @lists.tislabs.com'" cc: (Boby Joseph/MW/US/3Com) Subject: parallel vpns Hi, An IPSec Architecture question. In the following network S1----- -----D1 | | SG1 SG2 | | S2_---- -----D2 I have a setup where a pair of gateways SG1, SG2 are protecting hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns VPN1, VPN1 where S1,D1 belong to VPN1 S2,D2 belong to VPN2 Does IPsec architecture allows for such policy defnitions? ie: multiple VPNs managed by a pair of gateways. If so Can the main mode characterstics for VPN1 and VPN2 be different? Are there any constraints on how they can be different? For example: VPN1 (main mode characterstics) DES, MD5, preshared authentication with secret1 VPN2 (main mode characterstics) DES, MD5, preshared authentication wih secret2 VPN1 and VPN2 are different only in the preshared secret used for authentication purposes. SG1 initiates an IKE request to SG2. How can SG2 determine to which VPN the request belongs looking the SA request? If SG2 were to pick the wrong VPN, then authentication will fail down the line and SG1 will not be able to complete the IKE exchange. I thought about using non-ip identifiers and having different phase 1 identifiers for VPN1 and VPN2, but that leads to different set of problems. What am I missing? Thanks for any input. -- sankar -- From owner-ipsec@lists.tislabs.com Thu Jul 8 08:21:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA19657; Thu, 8 Jul 1999 08:21:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15992 Thu, 8 Jul 1999 09:35:54 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: Date: Wed, 7 Jul 1999 21:57:35 -0400 To: Sankar Ramamoorthi From: Stephen Kent Subject: Re: parallel vpns Cc: "'ipsec@lists.tislabs.com'" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar, >I have a setup where a pair of gateways SG1, SG2 are protecting >hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns >VPN1, VPN1 where > >S1,D1 belong to VPN1 > >S2,D2 belong to VPN2 > >Does IPsec architecture allows for such policy defnitions? >ie: multiple VPNs managed by a pair of gateways. IPsec does not define the term "VPN." if, what you mean is can you cause there to be two distinct sets of SAs established for traffic between S1 and D1 vs. S2 and D2, the answer is yes. One can define different SPD entries that will create separate SAs for these pairs of hosts, and the SAs can use different protocols or protocol combinations, different algorithm suites, and, of course, different keys. Steve From owner-ipsec@lists.tislabs.com Thu Jul 8 10:42:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23613; Thu, 8 Jul 1999 10:42:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16520 Thu, 8 Jul 1999 12:04:25 -0400 (EDT) Date: Thu, 8 Jul 1999 19:04:22 +0300 (EET DST) Message-Id: <199907081604.TAA21712@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ike-ext-meth-01.txt In-Reply-To: <199907070636.KAA28544@relay1.trustworks.com> References: <199907050722.LAA20287@relay1.trustworks.com> <199907061739.UAA26678@torni.ssh.fi> <199907070636.KAA28544@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > Tero, I still would like to get an answer for my original question - > if paragraph 4 from section 6 of your draft is right (statement that > ISAKMP and IKE share one version number), what will ISAKMP version > number mean in case several KE protocols (e.g. several transforms > with different TransformIDs) are present in SA? I removed that part of the draft already. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jul 8 10:44:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23682; Thu, 8 Jul 1999 10:44:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16503 Thu, 8 Jul 1999 11:58:29 -0400 (EDT) Message-ID: <3784CB22.296A1C60@redcreek.com> Date: Thu, 08 Jul 1999 09:00:34 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sankar Ramamoorthi CC: "'ipsec@lists.tislabs.com'" Subject: Re: parallel vpns References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar Ramamoorthi wrote: > > > >Use agressive mode, with ID_KEY_ID payload to identify the preshared > >key. > > > >Scott > > Thanks for the suggestion. > > One problem in this approach is that both parties need to know > how to map the preshared key into a opaque stream of bytes. Yes, this is correct - they must agree in advance. > > Also I presume you are suggesting ID_KEY_ID as a way of getting > identity protection while still having the advantages of using > aggressive mode. If so how secure/vulnerable is the identity > protection provided by ID_KEY_ID mechanism? > No, I don't think this gives you identity protection, since the ID payload is still in the clear. It simply provides a way to use multiple preshared keys between 2 gateways. Also, as Yael pointed out at the last ietf, the key id is easily replayed. Scott From owner-ipsec@lists.tislabs.com Thu Jul 8 11:52:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25208; Thu, 8 Jul 1999 11:52:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16886 Thu, 8 Jul 1999 13:25:57 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Stephen Kent'" , Sankar Ramamoorthi Cc: "'ipsec@lists.tislabs.com'" Subject: RE: parallel vpns Date: Thu, 8 Jul 1999 10:25:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ->From: Stephen Kent [kent@po1.bbn.com] >Sent: Wednesday, July 07, 1999 6:58 PM >To: Sankar Ramamoorthi >Cc: 'ipsec@lists.tislabs.com' >Subject: Re: parallel vpns > >Sankar, > >>I have a setup where a pair of gateways SG1, SG2 are protecting >>hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns >>VPN1, VPN1 where >> >>S1,D1 belong to VPN1 >> >>S2,D2 belong to VPN2 >> >>Does IPsec architecture allows for such policy defnitions? >>ie: multiple VPNs managed by a pair of gateways. > >IPsec does not define the term "VPN." if, what you mean is can you cause Agreed. I meant to use the term 'policy description'. >there to be two distinct sets of SAs established for traffic between S1 and >D1 vs. S2 and D2, the answer is yes. One can define different SPD entries >that will create separate SAs for these pairs of hosts, and the SAs can use >different protocols or protocol combinations, different algorithm suites, >and, of course, different keys. By SA's here you mean IKE SA of IPSec SAs? I do not have a problem creating separate IPSec SA's for these pair of hosts. However to create the IPSec SA, I need to use a key exchange protocol like IKE and I was concerned about the creation of the IKE SA. -- sankar -- From owner-ipsec@lists.tislabs.com Thu Jul 8 11:53:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25240; Thu, 8 Jul 1999 11:53:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16727 Thu, 8 Jul 1999 13:02:40 -0400 (EDT) Message-ID: <3784DA2E.E2C5ECA6@redcreek.com> Date: Thu, 08 Jul 1999 10:04:46 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-notifymsg-00.txt (long again) References: <199907040130.EAA13637@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry to take so long to reply to this. I think I agree with most if not all of your points, and will make the needed changes to the doc. Also, since I have heard no dissent regarding the use of attribute lists to contain the notification fields, I will also incorporate this change. Tero Kivinen wrote: > > I managed to check this out only now. I would really like to see all > the notification data fields to have data attribute list instead of > fixed fields. That would solve quite a lot of problems. We could add > attributes like: > > type value da type > ------------------------------------------------------------------- > Type of Offending Payload 1 B > Offending Payload Data 2 V > Error Position Offset 3 B > Error Text Describing the Problem 4 V > Error Text Language 5 V > Message Id of the Offending Negotiation 6 V > Exchange Type of Negotiation 7 B > Invalid Flag Bits 8 B > ------------------------------------------------------------------- > > Type of Offending Payload > > Payload type of the offending payload encoded as 16 bit > interger. > > Offending Payload Data > > Offeding payload data included the generic header. Note that > next payload type points to the next payload, it does not > specify the type of this payload. If the payload type is not > unique inside the error code the type of offending payload > must be given separately. > > Error Position Offset > > Byte offset of the error position from the beginning of the > offending payload (must be given also). > > Error Text Describing the Problem > > Text describing the problem. (ISO-10646 UTF-8 encoding). > > Error Text Language > > Error text language tag (as defined in RFC 1766). > > Message Id of the Offending Negotiation > > Message id of the offending negotiation encoded has 4 byte > value. > > Exchange Type of Negotiation > > Exchange type of the offeding negotiation. Encoded as 16 bit > integer. > > Invalid Flag Bits > > Invalid flags (valid flags are masked out) Encoded as 16 bit > integer. > > That would make processing of the notifications identical for all > cases, and we don't have to have special code to handle all different > kind of notifications. Also in that case vendors can add special stuff > in the notification data without breaking other implementations (we > should say that all unknown data attribute types must simply be > ignored). > > Also extending the format later is quite easy, and offers backward > compatibility. Also implementations are allowed to just leave out the > whole data part if they don't want to fill it in. > > > 2.1 INVALID-PAYLOAD-TYPE > > When present, the Notification Payload MUST have the following > > format: > > > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to the current DOI for this negotiation > > We might not have DOI yet. SA payload might not yet be parsed, or > there might not be SA payload (transactional, information exchange). I > would say we should ALWAYS use ISAKMP_DOI (0) here. > > > o Protocol ID - set to selected Protocol ID from chosen SA > > Same here, we might not have protocol ID from the SA yet. I would > suggest that we always reserve value 0 to be specify error in the > isakmp protocol, in which case the SPI will always be the ISAKMP > cookies of the offending packet. > > Note, they might be different from the ones stored in the header. For > example if we have ISAKMP SA up and running and we start rekey, which > fails, we might send the error message back using the old ISAKMP SA to > get protection for the notification, so we must identify the ISAKMP SA > somewhere. > > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > I would suggest this 0 or 16. The value 0 means that the ISAKMP > cookies can be seen from the header (== we are using same ISAKMP SA to > send notification back than what cause the problem). > > > o Notify Message Type - set to INVALID-PAYLOAD-TYPE > > o SPI - set to empty or to the sender's inbound > > IPSEC SPI > > So this should be the isakmp cookies (== spi of the ISAKMP SA) or > empty. > > > o Notification Data - contains the subject payload > > Notification data SHOULD contain the type of offending payload, and it > MAY contain offending payload data, error text describing the problem > and message id of the offending negotiation. > > > 2.2 DOI-NOT-SUPPORTED > > o DOI - set to the subject (unsupported) DOI > > I think this should again be ISAKMP DOI. > > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > > o Notify Message Type - set to DOI-NOT-SUPPORTED > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > If the DOI is unsupported, we cannot parse the SA payload, because we > do not know the length and format of the situation field. So we cannot > fill in the Protocol id, spi size, and spi from the SA payload. I > would suggest we fill them similarly than in INVALID-PAYLOAD-TYPE case > above. > > > o Notification Data - empty > > This SHOULD contain offending payload data, and message id of the > offending negotiation, and it MAY contain error position offset, and > error text describing the problem. > > > 2.3 SITUATION-NOT-SUPPORTED > > o Payload Length - set to length of payload + size of data (4) > > o DOI - set to DOI included in SA payload with situation > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > o Notify Message Type - set to SITUATION-NOT-SUPPORTED > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > There is really no point filling in the protocol ID, and spi, because > we might not yet have selected anything. I would suggest similar > handling than above. > > > o Notification Data - contains unsupported situation value > > This SHOULD contain Offending Payload Data, and Message Id of the > Offending Negotiation, and it MAY contain Error Position Offset, and Error > Text Describing the Problem. > > > 2.4 INVALID-COOKIE > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to IPSEC DOI (1) > > This should defenately be ISAKMP DOI (0). > > > o Protocol ID - set to PROTO_ISAKMP > > o SPI Size - set to zero (0) > > o Notify Message Type - set to INVALID-COOKIE > > o SPI - empty > > And we must fill in the SPI size to 16, and SPI data to cookies of the > offending payload so the other end can find the ISAKMP SA that is > expired or invalid. > > > o Notification Data - contains the invalid cookie (size may be > > derived from payload length > > This SHOULD contain Message Id of the Offending Negotiation, and it > MAY contain Error Text Describing the Problem. > > > 2.5 INVALID-MAJOR-VERSION > > o Payload Length - set to length of payload + size of data (5) > > o DOI - set to DOI under which message was received > > We haven't parsed the SA payload yet, so we don't know the DOI, so it > should be ISAKMP DOI (0). > > > o Protocol ID - set to PROTO_ISAKMP > > o SPI Size - set to zero (0) > > o Notify Message Type - set to INVALID-MAJOR-VERSION > > o SPI - empty > > Again, I would put the ISAKMP SPI (cookies) of the offending packet > here (16 bytes). > > > o Notification Data - contains the message ID, followed by the > > invalid version octet > > This SHOULD contain Message Id of the Offending Negotiation, and it > MAY contain Error Text Describing the Problem. > > The version supported by the other end can be seen from the header of > this notification, the sender fills it with his own version number. > > > 2.6 INVALID-MINOR-VERSION > > Same than INVALID-MAJOR-VERSION. > > > 2.7 INVALID-EXCHANGE-TYPE > > o Payload Length - set to length of payload + size of data (1) > > o DOI - set to DOI under which message was received > > We do not have DOI yet, so ISAKMP DOI (0). > > > o Protocol ID - set to PROTO_ISAKMP > > o SPI Size - set to zero (0) > > o Notify Message Type - set to INVALID-EXCHANGE-TYPE > > o SPI - empty > > Again, ISAKMP SA SPI here. > > > o Notification Data - contains the invalid exchange type octet > > This SHOULD contain Message Id of the Offending Negotiation, and it > MAY contain Error Text Describing the Problem. > > No need to put the invalid exchange type, because the sender can find > it from the message id. If we want to put it here, just add one more > attribute type. > > > 2.8 INVALID-FLAGS > > o Payload Length - set to length of payload + size of data (1) > > o DOI - set to DOI under which message was received > > o Protocol ID - set to PROTO_ISAKMP > > o SPI Size - set to zero (0) > > o Notify Message Type - set to INVALID-FLAGS > > o SPI - empty > > Same as above, ISAKMP DOI, ISAKMP SA SPI. > > > o Notification Data - contains the flags octet with only > > the unknown/invalid flags bits set (valid bits masked off) > > I am not sure if that is really needed, but it might be useful. > > > 2.9 INVALID-MESSAGE-ID > > o Payload Length - set to length of payload > > o DOI - set to DOI under which message was received > > o Protocol ID - set to PROTO_ISAKMP > > o SPI Size - set to zero (0) > > o Notify Message Type - set to INVALID-MESSAGE-ID > > o SPI - empty > > Same as above, ISAKMP DOI, ISAKMP SA SPI. > > > o Notification Data - empty > > This SHOULD contain Message Id of the Offending Negotiation, and it > MAY contain Error Text Describing the Problem. > > > In this case, the invalid message ID is contained in the ISAKMP > > header of the notify message. > > Somebody already commented this, no need to say more about it. > > > 2.10 INVALID-PROTOCOL-ID > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > o Protocol ID - set to invalid protocol ID value > > I would leave that Protocol ID to 0, and put that invalid protocol > value in the data. > > > o SPI Size - set to zero (0) > > o Notify Message Type - set to INVALID-PROTOCOL-ID > > o SPI - empty > > o Notification Data - contains the proposal payload in which the > > unrecognized protocol ID was found. > > Notification data SHOULD contain the offending (SA) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > Now the error position offset points inside to the SA payload to the > byte which contains the invalid protocol id. > > > 2.11 INVALID-SPI > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from offending SA > > proposal > > o SPI Size - set to zero (0) > > o Notify Message Type - set to INVALID-SPI > > o SPI - empty > > o Notification Data - contains the proposal payload in which the > > invalid SPI was found. > > Again I would use similar approach than in INVALID-PROTOCOL-ID, i.e > protocol ID 0, empty spi, and notification data SHOULD contain the > offending (SA) payload data, error position offset, and Message Id of > the Offending Negotiation, and it MAY contain error text describing > the problem. > > > 2.12 INVALID-TRANSFORM-ID > > o Payload Length - set to length of payload + size of data (2) > > o DOI - set to DOI of received packet > > o Protocol ID - set to Protocol ID from proposal containing > > subject > > transform ID > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > o Notify Message Type - set to INVALID-TRANSFORM-ID > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > o Notification Data - contains the transform number, followed by > > the invalid transform ID. > > I would make this identical to INVALID-PROTOCOL-ID. > > > 2.13 ATTRIBUTES-NOT-SUPPORTED > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from subject SA > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > o Notify Message Type - set to ATTRIBUTES-NOT-SUPPORTED > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > o Notification Data - contains an ISAKMP attribute list consisting > > of the unsupported attributes > > In this case we can use protocol ID, and SPI, but then I would also > defined that the SPI must be from the same proposal payload which > contains the offending transform (or first of them). > > Notification data SHOULD contain the offending (SA) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.14 NO-PROPOSAL-CHOSEN > > o Payload Length - set to length of payload > > o DOI - set to DOI of received packet > > o Protocol ID - set to PROTO_ISAKMP > > o SPI Size - set to zero (0) > > Size 16. > > > o Notify Message Type - set to NO-PROPOSAL-CHOSEN > > o SPI - set to the two ISAKMP cookies > > o Notification Data - empty > > Notification data SHOULD contain the Message Id of the Offending > Negotiation, and it MAY contain error text describing the problem. > > There might be use to put SA payload data and error position offset so > that the error position offset points to the first byte which didn't > match the policy, but it might be too complicated to really be > usefull. > > > 2.15 BAD-PROPOSAL-SYNTAX > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from chosen SA > > I would put PROTO_ISAKMP here. > > > o SPI Size - set to zero (0) (SPI is in proposal) > > Size 16 or 0 depending if the ISAKMP SPI is same than notification > packet or not. > > > o Notify Message Type - set to BAD-PROPOSAL-SYNTAX > > o SPI - empty > > ISAKMP SPI or empty. > > > o Notification Data - contains the improperly-formed proposal or > > transform payload > > [Note: There's an ambiguity here due to overloading this error > > type. It would be resolved by adding a BAD-TRANSFORM-SYNTAX error, > > and only using this one for proposals. Alternatively, we could > > add > > an identifier to this message to distinguish between the two > > cases] > > I would always put in the SA payload. I.e notification data SHOULD > contain the offending (SA) payload data, error position offset, and > Message Id of the Offending Negotiation, and it MAY contain error text > describing the problem. > > Here the offending byte would point to the error inside the SA > payload. > > > 2.16 PAYLOAD-MALFORMED > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > We might not yet have DOI yet, so ISAKMP DOI (0). > > > o Protocol ID - set to PROTO_ISAKMP > > Selected protocol if we have it or PROTO_ISAKMP (in which case the SPI > must be ISAKMP SA SPI). > > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > 0, 2, 4 or 16. We might not yet have IPSEC SPI. > > > o Notify Message Type - set to PAYLOAD-MALFORMED > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > If protocol ID is PROTO_ISAKMP then this should contain ISAKMP SA SPI > (cookies), or if the protocol id is something else (AH/ESP/IPCOMP) > then that SPI. > > > o Notification Data - contains the offending payload > > [Note: This overlaps with BAD-PROPOSAL-SYNTAX...] > > Notification data SHOULD contain the type of offending payload, the > offending payload data, error position offset, and Message Id of > the Offending Negotiation, and it MAY contain error text describing > the problem. > > > 2.17 INVALID-KEY-INFORMATION > > The INVALID-KEY-INFORMATION error message may be used to communicate > > that the key exchange type specified by the key exchange payload is > > not supported. > > There is no key exchange type in the KE payload. There is a key > exchange transform ID in the SA payload (KEY_IKE). This should only be > sent if the KE payload is invalidly formatted (too short/long etc). > > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > Depending of the Protocol ID this should be either 0 or 16 > (PROTO_ISAKMP) or 2/4 (IPCOMP/IPSEC). > > > o Notify Message Type - set to INVALID-KEY-INFORMATION > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > If protocol ID is PROTO_ISAKMP then this should contain ISAKMP SA SPI > (cookies), or if the protocol id is something else (AH/ESP/IPCOMP) > then that SPI. > > > o Notification Data - contains the subject key exchange payload > > Notification data SHOULD contain the offending (KE) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.18 INVALID-ID-INFORMATION > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > o Protocol ID - set to PROTO_ISAKMP > > For phase 2 this should be selected Protocol ID, and PROTO_ISAKMP if > in phase 1. > > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > Size = 0, 2, 4, 16. > > > o Notify Message Type - set to INVALID-ID-INFORMATION > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > Same stuff here than above. > > > o Notification Data - contains subject ID payload > > Notification data SHOULD contain the offending (ID) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.19 INVALID-CERT-ENCODING > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > It cannot be IPSEC SPI, only ISAKMP SPI is valid (0, or 16 bytes). So > it must also be PROTO_ISAKMP. > > > o Notification Data - contains the certificate payload > > Notification data SHOULD contain the offending (CERT) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.20 INVALID-CERTIFICATE > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > It cannot be IPSEC SPI, only ISAKMP SPI is valid (0, or 16 bytes). So > it must also be PROTO_ISAKMP. > > > o Notification Data - contains subject certificate payload > > Notification data SHOULD contain the offending (CERT) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.21 CERT-TYPE-UNSUPPORTED > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > Same here. > > > o Notification Data - contains the subject certificate payload > > Notification data SHOULD contain the offending (CERT) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.22 INVALID-CERT-AUTHORITY > > > > The INVALID-CERT-AUTHORITY error message may be used to communicate > > that the Certificate Authority in a certificate payload is invalid or > > improperly formatted. > > Not in certificate payload, but in certificate request payload. > > > Phase: 1 or 2 > > Phase 1 only. > > > Differentiator: Cookies, message ID, SPI, CERT payload > > CR payload. > > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > See above > > > o Notification Data - contains the subject certificate payload > > Notification data SHOULD contain the offending (CR) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.23 INVALID-HASH-INFORMATION > > o Payload Length - set to length of payload + size of data (1) > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > We might not have DOI / protocol / SPI yet. For example this might be > the first payload of the quick mode and the first hash payload is > invalid... So it should be ok to use PROTO_ISAKMP, and ISAKMP SPI. > > > o Notification Data - contains the subject hash payload > > Notification data SHOULD contain the offending (HASH) payload data, > error position offset, and Message Id of the Offending Negotiation, > and it MAY contain error text describing the problem. > > > 2.24 AUTHENTICATION-FAILED > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to zero (0)or four (4) (one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound > > IPSEC SPI > > Might not be IPSEC SPI, which failed, so PROTO_ISAKMP, and ISAKMP SA > SPI should also be allowed. > > > o Notification Data - empty > > Notification data SHOULD contain Message Id of the Offending > Negotiation, and it MAY contain error text describing the problem. > > > 2.25 INVALID-SIGNATURE > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > Again ISAKMP SA SPI must also be allowed. > > > o Notification Data - contains the subject signature payload > > Notification data SHOULD contain Message Id of the Offending > Negotiation, and it MAY contain error text describing the problem. > > > 2.27 NOTIFY-SA-LIFETIME > > o SPI Size - set to zero(0) o Notify Message Type - set to > > NOTIFY-SA-LIFETIME > > Formatting error. > > > o SPI - empty > > SPI should be the IPSEC or ISAKMP SA SPI. Not empty. > > > 2.28 CERTIFICATE-UNAVAILABLE > > o Payload Length - set to length of payload + size of data (var) > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to zero (0) or four (4) (one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > Normally this is PROTO_ISAKMP, spi size 0 or 16, and ISAKMP SA SPI. > > > o Notification Data - contains the subject certificate request > > Notification data SHOULD contain the offending (CR) payload data and > Message Id of the Offending Negotiation, and it MAY contain error text > describing the problem. > > > 2.29 UNSUPPORTED-EXCHANGE-TYPE > > o DOI - set to DOI of received packet > > We do not have DOI, so ISAKMP DOI (0). > > > o Protocol ID - set to selected Protocol ID from chosen SA > > We do not have protocol, so PROTO_ISAKMP. > > > o SPI Size - set to zero (0) or four (4)(one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > ISAKMP SA SPI. > > > o Notification Data - contains the message ID, followed by the > > invalid exchange type octet > > This SHOULD contain Message Id of the Offending Negotiation, and it > MAY contain Error Text Describing the Problem. > > We might want to add that exchange type also here. > > > 2.30 UNEQUAL-PAYLOAD-LENGTHS > > The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate > > that message length in the ISAKMP header does not match the sum of > > the actual payload lengths. > > It can also be used when for example data attributes values are longer > than transform payload, or spi size causes sa payload to overflow etc. > > > o Payload Length - set to length of payload + size of data (4) > > o DOI - set to DOI of received packet > > o Protocol ID - set to selected Protocol ID from chosen SA > > o SPI Size - set to zero (0) or four (4)(one IPSEC SPI) > > o SPI - set to empty or to the sender's inbound IPSEC SPI > > Quite often we do not have DOI or IPSEC SPI, so ISAKMP_DOI / > PROTO_ISAKMP / ISAKMP SA SPI should also be allowed. > > > o Notification Data - contains the actual payload length as a > > 32-bit unsigned value. > > Notification data SHOULD contain the type of offending payload, and it > MAY contain offending payload data, error position offset, error text > describing the problem and message id of the offending negotiation. > > If error position offset is given it points to place where the buffer > overflow is detected. For example if the spi size is set to 16 bytes, > and the generic Notify payload header doesn't include that to size (it > has size of 12 bytes) then it points to the SPI size byte inside the > notify payload. > > > 3.1 CONNECTED > > o SPI - set to the the sender's inbound IPSEC SPI > > Selected SPI. In phase 1 ISAKMP SA SPI (or empty), in phase 2 one of > the selected SPIs (there can be multiple of them if we have multiple > protocols (AH/ESP/IPCOMP)). > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jul 8 13:40:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27442; Thu, 8 Jul 1999 13:40:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17228 Thu, 8 Jul 1999 15:05:34 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Date: Thu, 8 Jul 1999 15:07:44 -0400 To: Sankar Ramamoorthi From: Stephen Kent Subject: RE: parallel vpns Cc: "'ipsec@lists.tislabs.com'" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar >By SA's here you mean IKE SA of IPSec SAs? >I do not have a problem creating separate IPSec SA's for these >pair of hosts. However to create the IPSec SA, I need to use >a key exchange protocol like IKE and I was concerned >about the creation of the IKE SA. I was referring to IPsec transit traffic SAs. Steve From owner-ipsec@lists.tislabs.com Fri Jul 9 12:15:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01407; Fri, 9 Jul 1999 12:15:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20837 Fri, 9 Jul 1999 13:35:30 -0400 (EDT) Message-Id: <199907091735.KAA12499@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: Taking AH to Draft Standard MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12495.931541729.1@network-alchemy.com> Date: Fri, 09 Jul 1999 10:35:30 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been a request to take a protocol dependent on AH to Draft Standard and therefore there's a desire advance AH to that level as well. What is needed to do this is statements from various implementors who've been to the bakeoffs and sucessfully interoperated with other people using AH. Can we start a thread to provide this info to our chairmen so they can feed it back our ADs? Info needed, I guess, is the various options that were successfully tested: different algorithms, with and without anti-replay protection, in conjunction with ESP and by itself, in tranport mode and tunnel mode. I'm unaware of any issues relating to AH, or ESP for that matter, that arose at the last 3 or 4 bakeoffs (over a year) but if anyone knows of any now is a good time to mention them. I'm sure we have more than the required two implementations, right? Dan. From owner-ipsec@lists.tislabs.com Fri Jul 9 12:16:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01426; Fri, 9 Jul 1999 12:16:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20789 Fri, 9 Jul 1999 13:27:32 -0400 (EDT) Message-Id: <199907091727.KAA11380@potassium.network-alchemy.com> To: Sankar Ramamoorthi cc: "'ipsec@lists.tislabs.com'" Subject: Re: parallel vpns In-reply-to: Your message of "Wed, 07 Jul 1999 09:48:48 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11373.931541245.1@network-alchemy.com> Date: Fri, 09 Jul 1999 10:27:26 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 07 Jul 1999 09:48:48 PDT you wrote > > Hi, > > An IPSec Architecture question. > In the following network > > > S1----- -----D1 > | | > SG1 SG2 > | | > S2_---- -----D2 > > I have a setup where a pair of gateways SG1, SG2 are protecting > hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns > VPN1, VPN1 where > > S1,D1 belong to VPN1 > > S2,D2 belong to VPN2 > > Does IPsec architecture allows for such policy defnitions? > ie: multiple VPNs managed by a pair of gateways. > > If so > Can the main mode characterstics for VPN1 and VPN2 be different? > Are there any constraints on how they can be different? > > For example: > > VPN1 (main mode characterstics) > DES, MD5, preshared authentication with secret1 > > VPN2 (main mode characterstics) > DES, MD5, preshared authentication wih secret2 > > VPN1 and VPN2 are different only in the preshared secret used > for authentication purposes. The answer is no since there's nothing like a "cert req" payload for pre-shared keys. That's like saying you have two identical token cards and how does your radius server know which one you're using? But the next question is why do you want to do this? The IKE SA is just used to protect IKE traffic. You can use the same IKE SA to generate IPSec SAs for S1->D1 and S2->D2. Do Quick Mode with PFS if you're worried about the keys being related. Dan. From owner-ipsec@lists.tislabs.com Fri Jul 9 13:21:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02610; Fri, 9 Jul 1999 13:21:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20997 Fri, 9 Jul 1999 14:49:23 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 09 Jul 1999 12:46:31 -0600 From: "Hilarie Orman" To: Subject: Re: parallel vpns 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 OAA20994 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there situations where SG's would share all IPSEC SA's, for load balancing, for example? Hilarie From owner-ipsec@lists.tislabs.com Fri Jul 9 17:17:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA06236; Fri, 9 Jul 1999 17:17:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21453 Fri, 9 Jul 1999 18:28:51 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Dan Harkins'" , Sankar Ramamoorthi Cc: "'ipsec@lists.tislabs.com'" Subject: RE: parallel vpns Date: Fri, 9 Jul 1999 15:28:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Dan Harkins [dharkins@Network-Alchemy.COM] >Sent: Friday, July 09, 1999 10:27 AM >To: Sankar Ramamoorthi >Cc: 'ipsec@lists.tislabs.com' >Subject: Re: parallel vpns > >On Wed, 07 Jul 1999 09:48:48 PDT you wrote >> >> Hi, >> >> An IPSec Architecture question. >> In the following network >> >> >> S1----- -----D1 >> | | >> SG1 SG2 >> | | >> S2_---- -----D2 >> >> I have a setup where a pair of gateways SG1, SG2 are protecting >> hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns >> VPN1, VPN1 where >> >> S1,D1 belong to VPN1 >> >> S2,D2 belong to VPN2 >> >> Does IPsec architecture allows for such policy defnitions? >> ie: multiple VPNs managed by a pair of gateways. >> >> If so >> Can the main mode characterstics for VPN1 and VPN2 be different? >> Are there any constraints on how they can be different? >> >> For example: >> >> VPN1 (main mode characterstics) >> DES, MD5, preshared authentication with secret1 >> >> VPN2 (main mode characterstics) >> DES, MD5, preshared authentication wih secret2 >> >> VPN1 and VPN2 are different only in the preshared secret used >> for authentication purposes. > >The answer is no since there's nothing like a "cert req" payload for >pre-shared keys. That's like saying you have two identical token cards and >how does your radius server know which one you're using? But the next Correct me if I am wrong. Isn't the identity always sent as part of first message to Radius server which then could be used by the Radius Server to pick the right token card? If I have two different token cards, I would probably use two different identities. >question is why do you want to do this? The IKE SA is just used to protect >IKE traffic. You can use the same IKE SA to generate IPSec SAs for S1->D1 >and S2->D2. Do Quick Mode with PFS if you're worried about the keys being >related. > > Dan. I was hoping to allow differnt policy definitions (vpns) including IKE parameters (crypto algorithms, rekeying time, authentication method, authentication parameters..) thereby allowing different security definitions for different peer groups. -- sankar -- From owner-ipsec@lists.tislabs.com Fri Jul 9 18:49:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16488; Fri, 9 Jul 1999 18:49:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21681 Fri, 9 Jul 1999 20:23:37 -0400 (EDT) Message-Id: <199907100023.RAA23269@potassium.network-alchemy.com> To: Sankar Ramamoorthi cc: "'ipsec@lists.tislabs.com'" Subject: Re: parallel vpns In-reply-to: Your message of "Fri, 09 Jul 1999 15:28:22 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23266.931566219.1@network-alchemy.com> Date: Fri, 09 Jul 1999 17:23:40 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 09 Jul 1999 15:28:22 PDT you wrote > > Correct me if I am wrong. > Isn't the identity always sent as part of first message to Radius server > which then could be used by the Radius Server to pick the right token card? > If I have two different token cards, I would probably use two > different identities. Use two different identities with IKE then. ID_KEY_ID can be used for this purpose if you have to use pre-shared keys. If you don't then it doesn't matter as the public key used in authentication can be identified with other valid phase 1 IDs. > >question is why do you want to do this? The IKE SA is just used to protect > >IKE traffic. You can use the same IKE SA to generate IPSec SAs for S1->D1 > >and S2->D2. Do Quick Mode with PFS if you're worried about the keys being > >related. > > > > Dan. > > I was hoping to allow differnt policy definitions (vpns) > including IKE parameters (crypto algorithms, rekeying time, > authentication method, authentication parameters..) > thereby allowing different security definitions for > different peer groups. Why? Aren't the "security definitions" of "peer groups" done with IPSec policy? How do different IKE crypto algorithms or IKE authentication methods change that? If you want to do Blowfish and HMAC-RIPEMD to protect traffic from S1 to D1 then it doesn't matter whether the IKE SA was authenticated with El-Gamal or encrypts its messages with CAST. Dan. From owner-ipsec@lists.tislabs.com Sat Jul 10 07:30:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18202; Sat, 10 Jul 1999 07:30:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22503 Sat, 10 Jul 1999 08:56:51 -0400 (EDT) Message-ID: <3787513F.A4265A70@checkpoint.com> Date: Sat, 10 Jul 1999 15:57:19 +0200 From: Tamir Zegman X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Sankar Ramamoorthi CC: "'ipsec@lists.tislabs.com'" Subject: Re: parallel vpns References: <199907100023.RAA23269@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If using different Phase1 ID's does not solve your problem you can consider using different UDP ports to negotiate different IKE SAs. From owner-ipsec@lists.tislabs.com Mon Jul 12 00:33:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA05687; Mon, 12 Jul 1999 00:33:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25705 Mon, 12 Jul 1999 01:34:23 -0400 (EDT) Message-Id: <199907120534.WAA00913@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: Re: Taking AH to Draft Standard MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <910.931757671.1@network-alchemy.com> Date: Sun, 11 Jul 1999 22:34:31 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The protocol is VRRP-- RFC2338. Dan. On Fri, 09 Jul 1999 10:35:30 PDT I wrote > There has been a request to take a protocol dependent on AH to Draft > Standard and therefore there's a desire advance AH to that level as well. > What is needed to do this is statements from various implementors who've > been to the bakeoffs and sucessfully interoperated with other people > using AH. From owner-ipsec@lists.tislabs.com Mon Jul 12 15:36:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA23239; Mon, 12 Jul 1999 15:36:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28742 Mon, 12 Jul 1999 16:21:38 -0400 (EDT) From: Jackie Wilson Message-Id: <199907122021.PAA34122@jhwilson.austin.ibm.com> Subject: Calculation of HASH_I and HASH_R To: ipsec@lists.tislabs.com Date: Mon, 12 Jul 1999 15:21:39 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was wondering what the outcome of the discussions of the possible errors in calculating HASH_I and HASH_R both based on SAi_b several weeks back. Is this going to be discussed at the IETF meeting? If this were changed, I think it would require a version change, since current implementations would not be compatable. Hugo Krawczck also make some other suggestions to prevent reflection attacks, and I was wondering if these were going to be discussed as well. Jackie -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec@lists.tislabs.com Mon Jul 12 18:05:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA26513; Mon, 12 Jul 1999 18:05:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29341 Mon, 12 Jul 1999 18:45:31 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Dan Harkins'" , Sankar Ramamoorthi Cc: "'ipsec@lists.tislabs.com'" Subject: RE: parallel vpns Date: Mon, 12 Jul 1999 15:45:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >On Fri, 09 Jul 1999 15:28:22 PDT you wrote >> >> Correct me if I am wrong. >> Isn't the identity always sent as part of first message to Radius server >> which then could be used by the Radius Server to pick the right token card? >> If I have two different token cards, I would probably use two >> different identities. > >Use two different identities with IKE then. ID_KEY_ID can be used for this >purpose if you have to use pre-shared keys. If you don't then it doesn't >matter as the public key used in authentication can be identified with other >valid phase 1 IDs. > >> >question is why do you want to do this? The IKE SA is just used to protect >> >IKE traffic. You can use the same IKE SA to generate IPSec SAs for S1->D1 >> >and S2->D2. Do Quick Mode with PFS if you're worried about the keys being >> >related. >> > >> > Dan. >> >> I was hoping to allow differnt policy definitions (vpns) >> including IKE parameters (crypto algorithms, rekeying time, >> authentication method, authentication parameters..) >> thereby allowing different security definitions for >> different peer groups. > >Why? Aren't the "security definitions" of "peer groups" done with IPSec >policy? How do different IKE crypto algorithms or IKE authentication methods >change that? If you want to do Blowfish and HMAC-RIPEMD to protect traffic >from S1 to D1 then it doesn't matter whether the IKE SA was authenticated >with El-Gamal or encrypts its messages with CAST. > > Dan. > I guess it depends on how you want to view 'policy definition' of peer groups. In my case I wanted to include both the IPSec policy and IKE policy. The recommendations are to use multiple ID_KEY_ID type phase1 id's (from you and Scott) or use different udp ports for different IKE SAs (from tamir). -- sankar -- From owner-ipsec@lists.tislabs.com Tue Jul 13 14:58:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA24712; Tue, 13 Jul 1999 14:58:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02599 Tue, 13 Jul 1999 15:59:02 -0400 (EDT) Message-Id: <3.0.6.32.19990713132446.00805420@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 13 Jul 1999 13:24:46 +0200 To: ipsec@lists.tislabs.com From: Rodney Thayer Subject: new second mandatory IPsec cipher Cc: rodney@ssh.fi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We've been talking about declaring a second mandatory to implement cipher, or in some way declaring a new second cipher for IPsec. This would be to change from DES and 3DES to 3DES and . It seems this needs to be discussed on the list. So, here goes. I think we need to have a second cipher to use, in the event 3DES is found to be unsafe. This is not a reflection on the quality of 3DES. In my opinion there are genuine legitimate concerns about the use of DES, and there are definitely people out there in the commercial world who wish to phase out it's use. What should we use instead? Well, there are apparently three choices: -- DESX -- BLOWFISH -- CAST-128 All of these have their advocates. DESX (or DES-XEX, or whatever it's called) has some detractors. It is hoped that anyone who reads this message and attends Crypto '99 would look up the discussions that are expected there. BLOWFISH has some detractors. The negative views appear to be of the form "it wasn't constructed in a formal manner", or something like that. CAST-128 has some detractors. The negative views appear to be of the form "it's too young". Now I'm not a cryptographer, and I don't play one on the internet, but I want to get those of you that are cryptographers (or play one on the Internet) to comment on this. Of course, for us vendors of software implementations, the programmer's lazy answer is to implement all three of these and let someone else decide. This doesn't work for hardware vendors, and for users who want some level of coherent valid advice on what to use. Comments? In particular, if someone has something bad to say about any of these ciphers, please try to be specific. From owner-ipsec@lists.tislabs.com Tue Jul 13 15:43:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA25311; Tue, 13 Jul 1999 15:43:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02747 Tue, 13 Jul 1999 16:49:42 -0400 (EDT) From: David Wagner Message-Id: <199907132041.NAA31539@blowfish.isaac.cs.berkeley.edu> Subject: Re: new second mandatory IPsec cipher To: ipsec@lists.tislabs.com Date: Tue, 13 Jul 1999 20:41:43 +0000 () X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In article <3.0.6.32.19990713132446.00805420@127.0.0.1>, Rodney Thayer wrote: > I think we need to have a second cipher to use, in the event 3DES is > found to be unsafe. If this is the indeed the only goal, then I suggest that DESX is not the right answer. It's not different enough to provide the needed diversity. I find it difficult to imagine a scenario where 3DES gets broken yet DESX somehow remains untarnished. Don't get me wrong---I think DESX is a nice cipher, and it gives wonderful performance for the provided assurance and security level---but if the sole criterion is to provide a secure backup cipher in case 3DES fails, DESX seems like the wrong choice. On the remaining choices (Blowfish or CAST-128), I offer no opinions. From owner-ipsec@lists.tislabs.com Tue Jul 13 16:40:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26585; Tue, 13 Jul 1999 16:40:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03026 Tue, 13 Jul 1999 17:59:47 -0400 (EDT) Date: Tue, 13 Jul 1999 17:59:11 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: new second mandatory IPsec cipher In-Reply-To: <3.0.6.32.19990713132446.00805420@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 13 Jul 1999, Rodney Thayer wrote: > We've been talking about declaring a second mandatory to implement cipher... > -- DESX > -- BLOWFISH > -- CAST-128 > Comments? In particular, if someone has something bad to say about any of > these ciphers, please try to be specific. It seems to me that DESX is best thought of as a sort of faster variant of 3DES. It's for people who are basically happy with DES, but want a longer key length without 3DES's performance hit. Worries about 3DES seem to fall into two main categories. One is the fear that it is equivalent to some other transformation with a shorter key, which would make it vulnerable to brute-force search (it's known that 3DES is not equivalent to 1DES, but that does not exhaust the possibilities). The other is the fear that there are hidden structural weaknesses in DES which are preserved in 3DES... a fear accentuated by the fact that parts of DES's origin are still shrouded in secrecy. DESX pretty much deals with the first fear, but does little for the second. A cipher chosen as a hedge against the possible failure of 3DES should not use DES at all, and especially should not *be* DES in a thin aluminum-foil wrapper. I'd strike DESX from the list. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Tue Jul 13 16:40:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26604; Tue, 13 Jul 1999 16:40:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03060 Tue, 13 Jul 1999 18:06:41 -0400 (EDT) Message-ID: <378B7F3F.9200CC2D@sympatico.ca> Date: Tue, 13 Jul 1999 18:02:39 +0000 From: Sandy Harris X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher References: <3.0.6.32.19990713132446.00805420@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rodney Thayer wrote: > > We've been talking about declaring a second mandatory to implement cipher, > or in some way declaring a new second cipher for IPsec. . . . Good idea (no pun intended :-). I'm not certain if a second cipher would be a MUST or a SHOULD in the RFC, though. [snip] > What should we use instead? Well, there are apparently three choices: > > -- DESX > -- BLOWFISH > -- CAST-128 > > All of these have their advocates. > > DESX (or DES-XEX, or whatever it's called) has some detractors. > It is hoped that anyone who reads this message and attends Crypto '99 > would look up the discussions that are expected there. > > BLOWFISH has some detractors. The negative views appear to be of the > form "it wasn't constructed in a formal manner", or something like that. > > CAST-128 has some detractors. The negative views appear to be of the > form "it's too young". > > Now I'm not a cryptographer, and I don't play one on the internet, but I > want to get those of you that are cryptographers (or play one on the Internet) > to comment on this. Playtime? Wheee ! Methinks you can eliminate DES-X as a mandatory cipher. It is a clever design and apparently strong enough, but if there's some catastorphic failure in DES (either a remarkable new breakthrough attack or a relevation that the NSA or KGB or whoever broke it long ago), then 3DES and DES-X both fall too. We cannot afford that risk in a widespread standardised infrastructure. A secondary cipher should differ greatly from 3DES. Also, DES and therefore DES-X tend to be slow in software. Keeping it as an optional cipher, e.g. for devices with limited resources but some hardware acceleration for DES, is sensible. That leaves CAST-128 and Blowfish. These are very similar ciphers. CAST-128 has a rotation in the round function, and there are plausible arguments that this adds strength. See RFC 2144 or references in it. Blowfish takes keys up to 448 bits. It isn't clear that this is a real advantage over 128. Other than that, the main difference is in the s-boxes. CAST-128 builds carefully optimised ones in advance. They are published and must be presumed known to the attacker. Blowfish builds random s-boxes at runtime, measurably weaker than the CAST ones but unknown to the attacker. There are arguments both ways on that, but none that knock holes in either approach. Likely both ciphers are strong enough. Both have had quite a bit of analysis with no great weaknesses found. So for many applications, which to use would be purely a question of taste. I don't think it is for IPSEC, though. Blowfish needs extra setup time on every key change to generate the random s-boxes. Schneier himself says (p 336 AC II): Blowfish is optimised for applications where the key does not change often ... not suitable for applications, such as packet switching, with frequent key changes... I think that eliminates it as a required cipher for IPSEC. Also, since the s-boxes are different for every key, an IPSEC box using Blowfish has to store 4K bytes of s-box material per connection. this would be problematic for some. Conclusion: CAST-128 is the obvious choice. From owner-ipsec@lists.tislabs.com Tue Jul 13 17:09:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27470; Tue, 13 Jul 1999 17:09:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03106 Tue, 13 Jul 1999 18:19:10 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 13 Jul 1999 16:18:34 -0600 From: "Tolga Acar" To: Cc: Subject: Re: new second mandatory IPsec cipher 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 SAA03103 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure about the "apparently" part of the three choices, although each one of these choices is well worth discussion. One may propose his favorite cipher for one reason or another, preferably because of its "strength", even though there isn't a proof to prove that a cipher is stong other that doing a set of analyses and heuristics - such as saying that "it's too young", or "it's not formal" for some definition of age and formality; or claiming that "it's resistant to xxx class of attacks" probably supported by a set of analyses results. But, that's all we've got after all. Hence, One approach would be to pick one of the AES candidates, or wait until that selection process is over and pick the selected AES. There may be time/deadline constraints here. Or, start up another algorithm selection process, expect the cryptographers to analyze/attack the algorithms in that list, and do a natural selection type of process - similar to what AES does. Or, ... any other suggestions as Rodney says? In any case, one would (i guess) rather have a set of algorithms analyzed/attacked by a "sufficiently large" set of cryptographers rather than giving a preselected set of algorithms chosen by some criteria (no pun intended) with a feeling that they are "OK" to use. I'm not advocating this or that algorithm, but simply saying that an algorithm selection should be taken seriously. - Tolga >>> Rodney Thayer 7/13/99 5:24:46 >>> We've been talking about declaring a second mandatory to implement cipher, or in some way declaring a new second cipher for IPsec. This would be to change from DES and 3DES to 3DES and . It seems this needs to be discussed on the list. So, here goes. I think we need to have a second cipher to use, in the event 3DES is found to be unsafe. This is not a reflection on the quality of 3DES. In my opinion there are genuine legitimate concerns about the use of DES, and there are definitely people out there in the commercial world who wish to phase out it's use. What should we use instead? Well, there are apparently three choices: -- DESX -- BLOWFISH -- CAST-128 All of these have their advocates. DESX (or DES-XEX, or whatever it's called) has some detractors. It is hoped that anyone who reads this message and attends Crypto '99 would look up the discussions that are expected there. BLOWFISH has some detractors. The negative views appear to be of the form "it wasn't constructed in a formal manner", or something like that. CAST-128 has some detractors. The negative views appear to be of the form "it's too young". Now I'm not a cryptographer, and I don't play one on the internet, but I want to get those of you that are cryptographers (or play one on the Internet) to comment on this. Of course, for us vendors of software implementations, the programmer's lazy answer is to implement all three of these and let someone else decide. This doesn't work for hardware vendors, and for users who want some level of coherent valid advice on what to use. Comments? In particular, if someone has something bad to say about any of these ciphers, please try to be specific. From owner-ipsec@lists.tislabs.com Tue Jul 13 17:22:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27674; Tue, 13 Jul 1999 17:22:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03166 Tue, 13 Jul 1999 18:43:48 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: David Wagner Subject: Re: new second mandatory IPsec cipher Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 00:41:15 +0200 From: "Steven M. Bellovin" Message-Id: <19990713224121.083A6ACADC@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <199907132041.NAA31539@blowfish.isaac.cs.berkeley.edu>, David Wagner writes: >In article <3.0.6.32.19990713132446.00805420@127.0.0.1>, >Rodney Thayer wrote: >> I think we need to have a second cipher to use, in the event 3DES is >> found to be unsafe. > >If this is the indeed the only goal, then I suggest that DESX is not the >right answer. It's not different enough to provide the needed diversity. >I find it difficult to imagine a scenario where 3DES gets broken yet DESX >somehow remains untarnished. > >Don't get me wrong---I think DESX is a nice cipher, and it gives wonderful >performance for the provided assurance and security level---but if the sole >criterion is to provide a secure backup cipher in case 3DES fails, DESX >seems like the wrong choice. > >On the remaining choices (Blowfish or CAST-128), I offer no opinions. > I agree. DESX is intended to be a DES variant that's immune to brute-force attacks. It's not necessarily stronger against a cryptanalytic attack. The reason to have two new ciphers is precisely to defend against a sudden new successful attack on a single standard. Having the two so closely related would negate that advantage. My own personal choice is CAST. Blowfish has a big key schedule, and I'm not that fond of some of its construction. I'd really like AES, but of course that doesn't exist yet. I will be at CRYPTO next month, and this is indeed a question I was planning on discussing. From owner-ipsec@lists.tislabs.com Tue Jul 13 18:35:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA08249; Tue, 13 Jul 1999 18:35:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03386 Tue, 13 Jul 1999 20:00:56 -0400 (EDT) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Wed, 14 Jul 1999 03:00:09 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: Rodney Thayer cc: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher In-Reply-To: <3.0.6.32.19990713132446.00805420@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 13 Jul 1999, Rodney Thayer wrote: > We've been talking about declaring a second mandatory to implement cipher, > or in some way declaring a new second cipher for IPsec. This would be to > change from DES and 3DES to 3DES and . It seems this needs > to be discussed on the list. So, here goes. > > I think we need to have a second cipher to use, in the event 3DES is > found to be unsafe. This is not a reflection on the quality of 3DES. > In my opinion there are genuine legitimate concerns about the use of > DES, and there are definitely people out there in the commercial world > who wish to phase out it's use. > > What should we use instead? Well, there are apparently three choices: > > -- DESX > -- BLOWFISH > -- CAST-128 The best (IMHO) opinion would be to wait until December and then pick 1-2 leading AES candidates. As it was announced, 5 best candidates will be selected during this summer by NIST. 3-5 more months is a necessary time limit to avoid sudden brokages of the candidates. Surely nobody believes that DES gets broken in the next 5 months. I do not think your selection is algorithms is the best for IPSEC. If there were no patent problems, I'd select IDEA. I do not have a big confidence in the mentioned three algorithms. Moreover, IPSEC should embody in itself also a 128-bit _block_ cipher, and only the newest algorithms satisfy this criterion. New algorithms (Rijndael, RC6, Twofish, ...) are faster than Blowfish and presumably much more secure than Blowfish or Cast-128 (only by the block length!). Regards, Helger http://home.cyber.ee/helger From owner-ipsec@lists.tislabs.com Tue Jul 13 19:07:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA13707; Tue, 13 Jul 1999 19:07:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03433 Tue, 13 Jul 1999 20:23:49 -0400 (EDT) Date: Tue, 13 Jul 1999 20:23:13 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: new second mandatory IPsec cipher In-Reply-To: <378B7F3F.9200CC2D@sympatico.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 13 Jul 1999, Sandy Harris wrote: > I don't think it is for IPSEC, though. Blowfish needs extra > setup time on every key change to generate the random s-boxes... > Also, since the s-boxes are different for every key, an IPSEC > box using Blowfish has to store 4K bytes of s-box material > per connection. this would be problematic for some. There is a time-space tradeoff here: *either* you need extra setup time on every key change to recompute the S-boxes, *or* you need a chunk of memory for each active key to store them. You don't need both. If you decide to opt for the extra memory consumption -- a fairly easy decision for most users nowadays, since 4KB of memory costs almost nothing -- then the setup time must be paid only at rekeying time, when an old key is replaced by a new one. That's fairly infrequent for most users. > Schneier himself says (p 336 AC II): > Blowfish is optimised for applications where the key does > not change often ... not suitable for applications, such > as packet switching, with frequent key changes... He's assuming early-1990s memory prices, which (arguably) made it painful to store the S-boxes for each connection. That assumption is now invalid, so don't take the book as gospel. In fairness, CAST probably does have some practical advantage here; I just don't think it's as large as Sandy suggests. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Wed Jul 14 02:48:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16091; Wed, 14 Jul 1999 02:48:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04544 Wed, 14 Jul 1999 04:01:05 -0400 (EDT) Message-Id: <3.0.6.32.19990714095418.0089b520@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 14 Jul 1999 09:54:18 +0200 To: Helger Lipmaa , Rodney Thayer From: Rodney Thayer Subject: Re: new second mandatory IPsec cipher Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.6.32.19990713132446.00805420@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:00 AM 7/14/99 +0300, Helger Lipmaa wrote: >On Tue, 13 Jul 1999, Rodney Thayer wrote: > >> We've been talking about declaring a second mandatory to implement cipher, >> or in some way declaring a new second cipher for IPsec. > >The best (IMHO) opinion would be to wait until December and then pick 1-2 >leading AES candidates. This leads those of use in the spectator section of the "AES Horse Race" statium to conclude that the AES candidates are being more scrutinized than previous existing ciphers, specifically CAST. This is possibly true. On the other hand, it is quite disturbing since a lot of people are running around buying and selling technical opinions as to the safety of non-AES algorithms. Are we concluding that the AES candidates have been studied more than CAST, and therefore are safer? From owner-ipsec@lists.tislabs.com Wed Jul 14 02:48:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16090; Wed, 14 Jul 1999 02:48:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04550 Wed, 14 Jul 1999 04:01:13 -0400 (EDT) Message-Id: <3.0.6.32.19990714095740.00a095e0@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 14 Jul 1999 09:57:40 +0200 To: Rodney Thayer , ipsec@lists.tislabs.com From: Rodney Thayer Subject: Re: new second mandatory IPsec cipher - updated choice list Cc: rodney@ssh.fi In-Reply-To: <3.0.6.32.19990713132446.00805420@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >What should we use instead? Well, there are apparently three choices: > >-- DESX >-- BLOWFISH >-- CAST-128 Based on discussions so far, the choices list should be redrawn. I think this is the list... -- CAST-128 -- BLOWFISH -- IDEA -- TWOFISH -- MARS -- (other AES candidates, please feel free to contribute) Note there seems to be consensus that DESX is _NOT_ a choice, because if DES/3DES are going to fail, the same structural failure would probably apply to DESX. I assume the same logic applies to DES/SK. From owner-ipsec@lists.tislabs.com Wed Jul 14 02:50:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16135; Wed, 14 Jul 1999 02:50:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04595 Wed, 14 Jul 1999 04:09:13 -0400 (EDT) Message-Id: <199907140809.EAA04282@thunk.epilogue.com> From: Bill Sommerfeld To: Rodney Thayer cc: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher In-Reply-To: Message from Rodney Thayer of "Tue, 13 Jul 1999 13:24:46 +0200." <3.0.6.32.19990713132446.00805420@127.0.0.1> Date: Wed, 14 Jul 1999 04:09:09 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Of course, for us vendors of software implementations, the programmer's lazy > answer is to implement all three of these and let someone else decide. This > doesn't work for hardware vendors, and for users who want some level of > coherent valid advice on what to use. Those of us trying to build compact implementations in software (e.g., for the embedded market) also have issues with there being too many different mandatory algorithms. DESX has an extreme advantage here as it shares the same algorithm "core" with DES and 3DES. However, while I'm wearing my "cryptographic protocol engineer" hat, that in and of itself makes me nervous.. - Bill From owner-ipsec@lists.tislabs.com Wed Jul 14 02:55:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16222; Wed, 14 Jul 1999 02:55:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04613 Wed, 14 Jul 1999 04:17:18 -0400 (EDT) Message-ID: <378C4791.D633E1F6@mit.edu> Date: Wed, 14 Jul 1999 10:17:22 +0200 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer CC: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher - updated choice list References: <3.0.6.32.19990714095740.00a095e0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe that IDEA has some intellectual property rights issues... -Jeff Rodney Thayer wrote: > >What should we use instead? Well, there are apparently three choices: > > > >-- DESX > >-- BLOWFISH > >-- CAST-128 > > Based on discussions so far, the choices list should be redrawn. > > I think this is the list... > > -- CAST-128 > -- BLOWFISH > -- IDEA > -- TWOFISH > -- MARS > -- (other AES candidates, please feel free to contribute) > > Note there seems to be consensus that DESX is _NOT_ a choice, > because if DES/3DES are going to fail, the same structural failure > would probably apply to DESX. I assume the same logic applies to > DES/SK. From owner-ipsec@lists.tislabs.com Wed Jul 14 02:57:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16252; Wed, 14 Jul 1999 02:57:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04619 Wed, 14 Jul 1999 04:17:47 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Henry Spencer Subject: Re: new second mandatory IPsec cipher Cc: IP Security List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 09:41:20 +0200 From: "Steven M. Bellovin" Message-Id: <19990714075003.7C26CACAE8@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spen cer writes: >On Tue, 13 Jul 1999, Sandy Harris wrote: >> I don't think it is for IPSEC, though. Blowfish needs extra >> setup time on every key change to generate the random s-boxes... >> Also, since the s-boxes are different for every key, an IPSEC >> box using Blowfish has to store 4K bytes of s-box material >> per connection. this would be problematic for some. > >There is a time-space tradeoff here: *either* you need extra setup time >on every key change to recompute the S-boxes, *or* you need a chunk of >memory for each active key to store them. You don't need both. If you >decide to opt for the extra memory consumption -- a fairly easy decision >for most users nowadays, since 4KB of memory costs almost nothing -- then >the setup time must be paid only at rekeying time, when an old key is >replaced by a new one. That's fairly infrequent for most users. > >> Schneier himself says (p 336 AC II): >> Blowfish is optimised for applications where the key does >> not change often ... not suitable for applications, such >> as packet switching, with frequent key changes... > >He's assuming early-1990s memory prices, which (arguably) made it painful >to store the S-boxes for each connection. That assumption is now invalid, >so don't take the book as gospel. The real problem isn't on hosts but on dedicated gateways, especially those with hardware doing the encryption. Today, you can buy boxes that will handle thousands of IPsec security associations. Yes, the RAM to hold all the key schedules is cheap enough. But you can't store them all on-chip, and you can't move that much data from RAM onto the chip fast enough. Given typical packet sizes, you'd spend more chip bandwidth loading key schedules than you would reading and writing packets. From owner-ipsec@lists.tislabs.com Wed Jul 14 02:59:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16299; Wed, 14 Jul 1999 02:59:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04538 Wed, 14 Jul 1999 04:00:59 -0400 (EDT) Message-Id: <3.0.6.32.19990714094912.00897100@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 14 Jul 1999 09:49:12 +0200 To: Sandy Harris , ipsec@lists.tislabs.com From: Rodney Thayer Subject: Re: new second mandatory IPsec cipher In-Reply-To: <378B7F3F.9200CC2D@sympatico.ca> References: <3.0.6.32.19990713132446.00805420@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:02 PM 7/13/99 +0000, Sandy Harris wrote: >Rodney Thayer wrote: >> >> We've been talking about declaring a second mandatory to implement cipher, >> or in some way declaring a new second cipher for IPsec. . . . > >I don't think it is for IPSEC, though. Blowfish needs extra >setup time on every key change to generate the random s-boxes. >Schneier himself says (p 336 AC II): > > Blowfish is optimised for applications where the key does > not change often ... not suitable for applications, such > as packet switching, with frequent key changes... After you consider all the heavy lifting required for IPsec/IKE, I don't think Blowfish setup time is really an issue. I also don't buy the "it takes a lot of memory per context" argument, myself, but there are memory-challenged implementations where this is an issue. From owner-ipsec@lists.tislabs.com Wed Jul 14 07:15:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24593; Wed, 14 Jul 1999 07:15:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06192 Wed, 14 Jul 1999 08:49:04 -0400 (EDT) Message-ID: <01BECDF8.F46A8E40@ARMENH> From: "Armen M. Hayrapetyan" To: "'ipsec@lists.tislabs.com'" Subject: Re: new second mandatory IPsec cipher Date: Wed, 14 Jul 1999 13:01:12 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 13 Jul 1999, Rodney Thayer wrote: > We've been talking about declaring a second mandatory to implement cipher, > or in some way declaring a new second cipher for IPsec. This would be to > change from DES and 3DES to 3DES and . It seems this needs > to be discussed on the list. So, here goes. > > I think we need to have a second cipher to use, in the event 3DES is > found to be unsafe. This is not a reflection on the quality of 3DES. > In my opinion there are genuine legitimate concerns about the use of > DES, and there are definitely people out there in the commercial world > who wish to phase out it's use. > > What should we use instead? Well, there are apparently three choices: > > -- DESX > -- BLOWFISH > -- CAST-128 I think the list is too short (taking into account that DESX could be excluded at once for apparent reasons). The best solution would be to wait till the end of AES selection process, but unfortunately it could take too long; and we also have our share of concerned customers. So if the decision must be made immediately I would like to add several other algorithms to the list (maybe SAFER, IDEA). Or we can wait till the end of the year and then consider some of the AES candidates, and by that time IMHO it will be easy to guess which one has most chances to win. -Armen From owner-ipsec@lists.tislabs.com Wed Jul 14 07:17:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24678; Wed, 14 Jul 1999 07:17:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06057 Wed, 14 Jul 1999 08:43:13 -0400 (EDT) Message-Id: <199907141242.IAA07927@adk.gr> To: Rodney Thayer Cc: Sandy Harris , ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher In-reply-to: Your message of "Wed, 14 Jul 1999 09:49:12 +0200." <3.0.6.32.19990714094912.00897100@127.0.0.1> Date: Wed, 14 Jul 1999 08:42:53 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3.0.6.32.19990714094912.00897100@127.0.0.1>, Rodney Thayer writes: > >Blowfish setup time is really an issue. I also don't buy the "it takes a >lot of >memory per context" argument, myself, but there are memory-challenged >implementations where this is an issue. Depends how many SAs you are going to have; for example, we have done experiments with 20K SAs simultaneously active, and they take *a lot* of memory (in the order of 80M, when all's said and done). Some people are looking at about 100K SAs on a box for some operations, for a lot of boxes. Memory's cheap, but chances are they won't use blowfish as the default algorithm. -Angelos From owner-ipsec@lists.tislabs.com Wed Jul 14 07:21:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24901; Wed, 14 Jul 1999 07:21:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05393 Wed, 14 Jul 1999 07:28:32 -0400 (EDT) Message-Id: <199907141123.NAA07642@thunk.epilogue.com> From: Bill Sommerfeld To: Rodney Thayer cc: Sandy Harris , ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher In-Reply-To: Message from Rodney Thayer of "Wed, 14 Jul 1999 09:49:12 +0200." <3.0.6.32.19990714094912.00897100@127.0.0.1> Date: Wed, 14 Jul 1999 13:23:24 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > After you consider all the heavy lifting required for IPsec/IKE, I don't think > Blowfish setup time is really an issue. I also don't buy the "it takes a > lot of > memory per context" argument, myself, but there are memory-challenged > implementations where this is an issue. Yes, there are. By embedded systems standards, 3DES has fairly large space requirements for the key schedules (3-key requires ~384 bytes in the implementations I'm familiar with). I've seen optimized DES key schedule computation code which runs in about 1.5x the time of a single 64-bit block encryption (it's been a while since I last timed it); if you're pressed for space, it probably makes sense to not bother caching the expanded keys. It's worth noting that the DES key schedule computation involves very little "work", as each bit of the key schedule is a function of exactly one bit of the key. Can someone who knows the various algorithms give us some numbers on: - estimated time to construct expanded key.. i.e., A good metric here would be to compare it with the cost of encrypting a minimum-size IP packet. - estimated size of expanded key. Thanks.. - Bill From owner-ipsec@lists.tislabs.com Wed Jul 14 07:21:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24909; Wed, 14 Jul 1999 07:21:37 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06139 Wed, 14 Jul 1999 08:47:00 -0400 (EDT) Date: Wed, 14 Jul 1999 08:47:00 -0400 (EDT) Message-Id: <199907141247.IAA06139@lists.tislabs.com> MAA03861; Wed, 14 Jul 1999 12:01:10 +0300 (EET DST) Date: Wed, 14 Jul 1999 12:01:06 +0300 (EET DST) From: Markku-Juhani Saarinen To: Rodney Thayer cc: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher - updated choice list In-Reply-To: <3.0.6.32.19990714095740.00a095e0@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 14 Jul 1999, Rodney Thayer wrote: > I think this is the list... > > -- CAST-128 > -- BLOWFISH > -- IDEA > -- TWOFISH > -- MARS > -- (other AES candidates, please feel free to contribute) > > Note there seems to be consensus that DESX is _NOT_ a choice, > because if DES/3DES are going to fail, the same structural failure > would probably apply to DESX. I assume the same logic applies to > DES/SK. Please note that IDEA is patented, and there seems to be some patents covering parts of MARS, too. Also, the design of some AES candidates may change during the on-going the AES selection process. - mj Markku-Juhani Saarinen University of Jyväskylä, Finland From owner-ipsec@lists.tislabs.com Wed Jul 14 07:29:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25251; Wed, 14 Jul 1999 07:29:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05644 Wed, 14 Jul 1999 08:20:02 -0400 (EDT) Date: Tue, 13 Jul 1999 22:59:36 -0700 (PDT) From: Dennis Glatting To: ipsec@lists.tislabs.com Subject: Comment on xauth and hybrid In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I must first admit I had not read the xauth and hybrid drafts until after the IPsec meeting where concerns were raised about weakening IPsec by supporting legacy authentication systems. As a manager and advisor of several enterprises I certainly understand the "transitional" intent of these documents. In fact, I could easily be one calling for their existence and demanding their implementation. However, as that same manager and advisor I can confidently tell you legacy systems, no matter their function, remain in-place and key infrastructure components longer than they should. The PKI reality is there isn't one, so shared secrets, I expect, will be the IPsec authentication mechanism of choice until products mature and prices decline. The difference between simple shared secrets and xauth/hybrid is xauth/hybrid extends existing, seemingly easy to manage, managed shared secret technologies yielding, in my opinion, no motivation to improve the security of infrastructures (i.e., transition to PKI). Is this where we want to be after several years of work and some cantankerous meetings? Perhaps not using managed shared secret technologies but I look to the SSL/TLS web reality of today as a crystal ball of the future of a widely deployed xauth/hybrid IPsec. I do a fair amount of on-line purchasing. For some ten sites I have, to my dismay, several user identifiers and passwords housed in ten different databases managed by staffs with ten different philosophies on security and skill sets. Not once have I been prompted by my browsers for the password to decrypt my private key. Not once. If these sites supported client side certificates I would not have to create an identifier, divulge a password, or write these things down on a piece of paper and tuck it away in my wallet. Further, I remember reading about a survey by Netcraft where only 5% of the web sites they queried offering server side certificates offered valid certificates. My concern is xauth/hybrid effectively reduce IPsec to the SSL/TLS reality of today (i.e., we really haven't improved things). I offer the following suggestions. First, finish a combined xauth/hybrid draft and classify it as experimental. Second, the Security Considerations section of the draft be written not by the draft's proponents but by at least two of its detractors. Finally, set a deadline (perhaps three years) where the PS is committed to historic. From owner-ipsec@lists.tislabs.com Wed Jul 14 07:58:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25895; Wed, 14 Jul 1999 07:58:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06397 Wed, 14 Jul 1999 09:29:45 -0400 (EDT) Message-ID: <378C906A.C124E1AF@juggernautics.com> Date: Wed, 14 Jul 1999 09:28:10 -0400 From: Joel Odom Organization: Juggernautics, LLC X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer , ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher - updated choice list References: <3.0.6.32.19990714095740.00a095e0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Give the AES candidates some more time for scrutiny. Twofish seems to be fast, tight and secure. Since I'm not a cryptanalyst and won't play one, I'll leave the "secure" part to the academic community. There's a good book out on Twofish. Check the Counterpane home page. I've wanted to see Twofish in the standard. > I think this is the list... > > -- CAST-128 > -- BLOWFISH > -- IDEA > -- TWOFISH > -- MARS > -- (other AES candidates, please feel free to contribute) -- Juggernautics, LLC Computer, Electrical & Mechanical Engineering http://www.juggernautics.com From owner-ipsec@lists.tislabs.com Wed Jul 14 08:12:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26371; Wed, 14 Jul 1999 08:12:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06448 Wed, 14 Jul 1999 09:38:54 -0400 (EDT) Message-ID: <378C92C6.2CC164D7@thawte.com> Date: Wed, 14 Jul 1999 15:38:14 +0200 From: Mark Shuttleworth Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bill Sommerfeld CC: Rodney Thayer , ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher References: <199907140809.EAA04282@thunk.epilogue.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms59E61EBA81B8C82D4D40EC98" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms59E61EBA81B8C82D4D40EC98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all Is AES at the point where the "data structure" can be defined? In other words, is it possible at this stage to know what data structures you'll need to be able to represent an AES key or session? If so, why not simply shoot for that. Nobody loves the NSA, but most folk respect 'em ;-). I suspect AES will become as widely used as DES is today. -- Mark Shuttleworth Thawte --------------ms59E61EBA81B8C82D4D40EC98 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEgYJKoZIhvcNAQcCoIIIAzCCB/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTA3MTQxMzM4MTRaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFA3iFOdb/tk+7R9xwaT3gpvMO7zqMA0GCSqGSIb3 DQEBAQUABECllHHDu3KNhj0gnV3OfrwpF9jHjfWWn1S7MXf9Luw8ytvqj44oDcnfKa1/t170 XlpEelT8jBu0c0IyMVAMGN+N --------------ms59E61EBA81B8C82D4D40EC98-- From owner-ipsec@lists.tislabs.com Wed Jul 14 08:25:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26844; Wed, 14 Jul 1999 08:25:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06594 Wed, 14 Jul 1999 09:54:01 -0400 (EDT) Date: Wed, 14 Jul 1999 09:53:19 -0400 Message-Id: <199907141353.JAA02319@rsts-11.mit.edu> X-Authentication-Warning: rsts-11.mit.edu: tytso set sender to tytso@rsts-11.mit.edu using -f To: rodney@ssh.fi CC: rodney@ssh.fi, ipsec@lists.tislabs.com, rodney@ssh.fi In-reply-to: <3.0.6.32.19990714095740.00a095e0@127.0.0.1> (message from Rodney Thayer on Wed, 14 Jul 1999 09:57:40 +0200) Subject: Re: new second mandatory IPsec cipher - updated choice list From: tytso@MIT.EDU Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 References: <3.0.6.32.19990714095740.00a095e0@127.0.0.1> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Wed, 14 Jul 1999 09:57:40 +0200 From: Rodney Thayer Based on discussions so far, the choices list should be redrawn. I think this is the list... -- CAST-128 -- BLOWFISH -- IDEA -- TWOFISH -- MARS -- (other AES candidates, please feel free to contribute) Note that intellectual property is an issue; all other things being equal, an algorithm which does not require (both commercial and non-commercial) implementors to pay licensing fees. Two issues with the AES candidates is that first of all, while the eventual AES candidate will be free of licensing issues, this is not a NIST requirement of the AES candidates before one of them is chosen. Secondly, most of the AES candidates are "young"; while they are receiving some intense cryptographic review, they haven't had this attention for a long time, and so I am not sure it would be wise to select an AES candidate at this time. As a crypto protocol engineer (and not a cryptographer), this makes me a bit nervous! - Ted From owner-ipsec@lists.tislabs.com Wed Jul 14 08:26:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26881; Wed, 14 Jul 1999 08:26:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06545 Wed, 14 Jul 1999 09:49:46 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: marks@thawte.com Subject: Re: new second mandatory IPsec cipher Cc: Bill Sommerfeld , Rodney Thayer , ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 15:47:05 +0200 From: "Steven M. Bellovin" Message-Id: <19990714134712.292DEACADC@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <378C92C6.2CC164D7@thawte.com>, Mark Shuttleworth writes: >This is a cryptographically signed message in MIME format. > >--------------ms59E61EBA81B8C82D4D40EC98 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Hi all > >Is AES at the point where the "data structure" can be defined? In other >words, is it possible at this stage to know what data structures you'll >need to be able to represent an AES key or session? If so, why not >simply shoot for that. Nobody loves the NSA, but most folk respect 'em >;-). I suspect AES will become as widely used as DES is today. > It's quite certain that we'll want to mandate AES once it's blessed. It isn't, and won't be for a while yet. What we do know is that it will use 16-byte blocks -- and that change is likely to upset some implementations; vendors may want to start testing that now -- and variable-length keys starting at 128 bits. From owner-ipsec@lists.tislabs.com Wed Jul 14 08:30:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27105; Wed, 14 Jul 1999 08:30:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06550 Wed, 14 Jul 1999 09:49:53 -0400 (EDT) Date: Wed, 14 Jul 1999 09:49:26 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: new second mandatory IPsec cipher In-Reply-To: <19990714075003.7C26CACAE8@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 14 Jul 1999, Steven M. Bellovin wrote: > >...You don't need both. If you > >decide to opt for the extra memory consumption -- a fairly easy decision > >for most users nowadays, since 4KB of memory costs almost nothing... > > The real problem isn't on hosts but on dedicated gateways, especially those > with hardware doing the encryption... And little embedded boxes which are short on memory but still want to handle whole bunches of connections. This is why I said "*most* users". There are people who do still have problems with bulky per-connection state. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Wed Jul 14 08:42:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27445; Wed, 14 Jul 1999 08:42:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06650 Wed, 14 Jul 1999 10:04:33 -0400 (EDT) Date: Wed, 14 Jul 1999 10:03:34 -0400 (EDT) From: Henry Spencer To: Rodney Thayer cc: IP Security List Subject: Re: new second mandatory IPsec cipher - updated choice list In-Reply-To: <3.0.6.32.19990714095740.00a095e0@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 14 Jul 1999, Rodney Thayer wrote: > -- CAST-128 > -- BLOWFISH > -- IDEA > -- TWOFISH > -- MARS > -- (other AES candidates, please feel free to contribute) IDEA is patented, and is a poor choice for that reason. The AES candidates strike me as too new to inspire a lot of confidence; in a year or two they will have had a lot of attention paid to them and might be serious contenders, but not today. In the long run, the AES winner is a good bet, but the desire for at least an interim 3DES alternative is here today, and waiting for the AES process to grind on seems undesirable. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Wed Jul 14 08:48:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27626; Wed, 14 Jul 1999 08:48:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06667 Wed, 14 Jul 1999 10:06:48 -0400 (EDT) Date: Wed, 14 Jul 1999 10:06:23 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: new second mandatory IPsec cipher In-Reply-To: <3.0.6.32.19990714095418.0089b520@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 14 Jul 1999, Rodney Thayer wrote: > Are we concluding that the AES candidates have been studied more than CAST, > and therefore are safer? It's beyond question that this *will* be true in a year or two. While I haven't been keeping a close eye on the process, my impression is that it is not true yet. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Wed Jul 14 09:45:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29477; Wed, 14 Jul 1999 09:45:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06861 Wed, 14 Jul 1999 10:54:50 -0400 (EDT) X-Lotus-FromDomain: SHIVA CORPORATION From: "Jesse Walker" To: Rodney Thayer cc: ipsec@lists.tislabs.com Message-ID: <852567AE.004F6587.00@zule.shiva.com> Date: Wed, 14 Jul 1999 10:47:34 -0400 Subject: Re: new second mandatory IPsec cipher - updated choice list Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk MARS, RC6, Rijndael, Serpent, and Twofish seem to be the most serious AES candidates. If the goal is really to make IPSec more resistant to attack, we want the second mandatory algorithm to be as different from DES as possible. This line of reasoning argues in favor of RC5 among the algorithms already defined for use in IPSec, and RC6 and Rijndael as the best choices among the AES candidates. Rodney Thayer on 07/14/99 03:57:40 AM To: Rodney Thayer , ipsec@lists.tislabs.com cc: rodney@ssh.fi (bcc: Jesse Walker/Shiva Corporation) Subject: Re: new second mandatory IPsec cipher - updated choice list >What should we use instead? Well, there are apparently three choices: > >-- DESX >-- BLOWFISH >-- CAST-128 Based on discussions so far, the choices list should be redrawn. I think this is the list... -- CAST-128 -- BLOWFISH -- IDEA -- TWOFISH -- MARS -- (other AES candidates, please feel free to contribute) Note there seems to be consensus that DESX is _NOT_ a choice, because if DES/3DES are going to fail, the same structural failure would probably apply to DESX. I assume the same logic applies to DES/SK. From owner-ipsec@lists.tislabs.com Wed Jul 14 10:25:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00698; Wed, 14 Jul 1999 10:25:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07211 Wed, 14 Jul 1999 11:43:00 -0400 (EDT) From: CTrobridge@baltimore.com To: ipsec@lists.tislabs.com Subject: RE: new second mandatory IPsec cipher Date: Wed, 14 Jul 1999 16:39:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81CF736@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > The real problem isn't on hosts but on dedicated gateways, > especially those > > with hardware doing the encryption... > > And little embedded boxes which are short on memory but still want to > handle whole bunches of connections. This is why I said > "*most* users". > There are people who do still have problems with bulky per-connection > state. And don't forget those who need to decrypt their keys before using them. Chris Trobridge > Henry Spencer > > henry@spsystems.net > > (henry@zoo.toronto.edu) > From owner-ipsec@lists.tislabs.com Wed Jul 14 10:29:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00792; Wed, 14 Jul 1999 10:29:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07240 Wed, 14 Jul 1999 11:51:38 -0400 (EDT) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Wed, 14 Jul 1999 18:50:59 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher - updated choice list In-Reply-To: <199907141353.JAA02319@rsts-11.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 14 Jul 1999 tytso@MIT.EDU wrote: > Two issues with the AES candidates is that first of all, while the > eventual AES candidate will be free of licensing issues, this is not a > NIST requirement of the AES candidates before one of them is chosen. > Secondly, most of the AES candidates are "young"; True. Nevertheless, my gut feeling about (e.g.) Rijndael is better than about CAST-128 (note that Rijndael is also one of the leading AES candidates, while the successor of CAST-128, CAST-256, is most probably not going to make it to the second round of candidates). Why? * Rijndael is based on the design of Shark, and Square. Square has been known for 2.5 years and _no weaknesses_ in it have been found. * The theory behind Rijndael (or Square) seems to guarantee that completely new type of attacks should be invented to break them. * Rijndael is (most probably) much more secure than unbroken Square due to the added rounds. Moreover, Rijndael is the fastest AES candidate `in average' (cf http://home.cyber.ee/helger/aes/) and free of patents. Thus, I'd advocate strongly for including Rijndael at least to RFC 2451. But, I would personally oppose to any additional MUST algorithms atm (IDEA would be the only exception if there were no patents). David Wagner (or anyone else who scrutinizes block ciphers) could comment... Helger http://home.cyber.ee/helger From owner-ipsec@lists.tislabs.com Wed Jul 14 11:47:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03345; Wed, 14 Jul 1999 11:47:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07423 Wed, 14 Jul 1999 12:40:02 -0400 (EDT) Message-ID: <378CB0A4.C6AE4E06@redcreek.com> Date: Wed, 14 Jul 1999 15:45:40 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ".MailList, ipsec" Subject: Re: new second mandatory IPsec cipher References: <19990714134712.292DEACADC@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: >It's quite certain that we'll want to mandate AES once it's blessed. It > isn't, and won't be for a while yet. What we do know is that it will use > 16-byte blocks -- and that change is likely to upset some implementations; > vendors may want to start testing that now -- and variable-length keys > starting at 128 bits. Howdy () 16-byte blocks... ouch. Here's a little point to keep in mind: IP fragments come in 8byte blocks. As long as your crypto cypher chuncks though memory in 8 byte blocks, then your different fragments do not have to be lined up contigously in memory. But pick a 16byte block crypto tool and then you will have to get into memory copying fragments around. And I know that this is still a debate, but a good fraction of the community here believe that if you are and SGW using IPSec selectors which filter on ports, then you must do an 'intermediate reassemble' of the packet even if you are not the end destianation. That could add up to alot of traffic which a 16byte cypher would force you to mem-copy all about. Perhaps, given time, all us implementors could think up optimizations which mitigate this problem, but why go there? -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Wed Jul 14 12:32:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04856; Wed, 14 Jul 1999 12:32:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07653 Wed, 14 Jul 1999 13:54:26 -0400 (EDT) Message-Id: <199907141754.KAA07370@potassium.network-alchemy.com> To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher In-reply-to: Your message of "Wed, 14 Jul 1999 15:45:40 -0000." <378CB0A4.C6AE4E06@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7367.931974877.1@network-alchemy.com> Date: Wed, 14 Jul 1999 10:54:37 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 14 Jul 1999 15:45:40 -0000 you wrote > > 16-byte blocks... ouch. Here's a little point to keep in mind: IP > fragments come in 8byte blocks. As long as your crypto cypher chuncks > though memory in 8 byte blocks, then your different fragments do not > have to be lined up contigously in memory. But pick a 16byte block > crypto tool and then you will have to get into memory copying fragments > around. > And I know that this is still a debate, but a good fraction of the > community here believe that if you are and SGW using IPSec selectors > which filter on ports, then you must do an 'intermediate reassemble' of > the packet even if you are not the end destianation. That could add up > to alot of traffic which a 16byte cypher would force you to mem-copy all > about. I think you're misunderstanding the debate. The situation where reassembly in a SGW is necessary is IPSec encrypted fragments and they're all gonna be padded to the blocksize of the cipher anyway. What you have to do is reassemble enough of the cleartext fragment(s) to see whether this is an acceptable packet or not. In the case of an IPSec encrypted packet that gets fragmented you have to reconstruct the whole thing prior to decryption anyway and it too will be padded to the blocksize of the cipher. The blocksize of the cipher should not be a concern here. Dan. From owner-ipsec@lists.tislabs.com Wed Jul 14 13:41:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08165; Wed, 14 Jul 1999 13:41:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07896 Wed, 14 Jul 1999 15:06:07 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8AA@sothmxs06.entrust.com> From: Greg Carter To: "'ipsec@lists.tislabs.com'" Subject: XAUTH? Date: Wed, 14 Jul 1999 14:09:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Config Mode states: "A "Configuration Transaction" is defined as two configuration exchanges, the first being either a Set or a Request and the second being either an Acknowledge or a Reply, respectively. ... Transactions are completed once the Reply or Acknowledge code is received." To me this means that the message ID is unique for the transaction, either a Set-Ack or Request-Reply pair. However XAUTH states: All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID. And gives examples where a Request-Reply is followed by a Set-Ack and is referred to as a "transaction". Are the message ID's unique for the Request-Reply and Set-Ack in XAUTH or are they the same? From owner-ipsec@lists.tislabs.com Wed Jul 14 13:42:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08227; Wed, 14 Jul 1999 13:42:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07889 Wed, 14 Jul 1999 15:06:02 -0400 (EDT) From: Tze-Wei Sou Message-Id: <199907141906.MAA09429@eql-e.isi.edu> Subject: IPSec on NT? To: ipsec@lists.tislabs.com Date: Wed, 14 Jul 1999 12:06:02 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, all Is it possible to implement IPSec on NT (server 4) without the need of modifying kernel? Or does anyone know the third-party implementation? TKS Alex Sou From owner-ipsec@lists.tislabs.com Wed Jul 14 14:57:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10762; Wed, 14 Jul 1999 14:57:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08144 Wed, 14 Jul 1999 16:07:22 -0400 (EDT) Message-ID: <378CE134.8974FF6A@redcreek.com> Date: Wed, 14 Jul 1999 19:12:52 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ".MailList, ipsec" Subject: Re: new second mandatory IPsec cipher References: <199907141754.KAA07370@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > On Wed, 14 Jul 1999 15:45:40 -0000 you wrote > > > > 16-byte blocks... ouch. Here's a little point to keep in mind: IP > > fragments come in 8byte blocks. As long as your crypto cypher chuncks > > though memory in 8 byte blocks, then your different fragments do not > > have to be lined up contigously in memory. But pick a 16byte block > > crypto tool and then you will have to get into memory copying fragments > > around. > > And I know that this is still a debate, but a good fraction of the > > community here believe that if you are and SGW using IPSec selectors > > which filter on ports, then you must do an 'intermediate reassemble' of > > the packet even if you are not the end destianation. That could add up > > to alot of traffic which a 16byte cypher would force you to mem-copy all > > about. > > I think you're misunderstanding the debate. The situation where reassembly > in a SGW is necessary is IPSec encrypted fragments and they're all gonna > be padded to the blocksize of the cipher anyway. What you have to do > is reassemble enough of the cleartext fragment(s) to see whether this is > an acceptable packet or not. In the case of an IPSec encrypted packet that > gets fragmented you have to reconstruct the whole thing prior to decryption > anyway and it too will be padded to the blocksize of the cipher. > > The blocksize of the cipher should not be a concern here. > > Dan. -- Oops. You got me. As Dan says, "The situation where reassembly in a SGW is necessary is IPSec encrypted fragments and they're all gonna be padded to the blocksize of the cipher anyway." I withdraw my previous comment about wanting an 8 block cypher in order to be more 'fragment friendly'. #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### From owner-ipsec@lists.tislabs.com Wed Jul 14 15:25:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA11375; Wed, 14 Jul 1999 15:25:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08242 Wed, 14 Jul 1999 16:37:40 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC11B6D@exchange> From: Andrew Krywaniuk To: Greg Carter , "'ipsec@lists.tislabs.com'" Subject: RE: XAUTH? Date: Wed, 14 Jul 1999 16:39:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems that we have a keyword overloading problem here, as the word transaction is used in two different contexts: A "configuration transaction" is a pair of messages wherein a set of attributes is proposed (message 1) and then these attributes either accepted or rejected (message 2). An "XAuth transaction" is a series of ISAKMP-Config messages which leads to the user being accepted or rejected. Once you resolve the meaning of the word "transaction," I don't think it's implied that each configuration transaction has to have a different message id. The XAUTH draft is correct in stating (indirectly) that the message id has to remain the same across multiple configuration transactions. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Greg Carter [mailto:greg.carter@entrust.com] > Sent: Wednesday, July 14, 1999 2:09 PM > To: 'ipsec@lists.tislabs.com' > Subject: XAUTH? > > > Hi, > > Config Mode states: > > "A "Configuration Transaction" is defined as two configuration > exchanges, the first being either a Set or a Request and the second > being either an Acknowledge or a Reply, respectively. > > ... > Transactions are completed once the Reply or Acknowledge code is > received." > > To me this means that the message ID is unique for the > transaction, either a > Set-Ack or Request-Reply pair. > > However XAUTH states: > All ISAKMP-Config messages in an extended authentication > transaction MUST contain the same ISAKMP-Config message ID. > > And gives examples where a Request-Reply is followed by a > Set-Ack and is > referred to as a "transaction". > > Are the message ID's unique for the Request-Reply and Set-Ack > in XAUTH or > are they the same? > > > > > From owner-ipsec@lists.tislabs.com Wed Jul 14 18:14:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16209; Wed, 14 Jul 1999 18:14:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08550 Wed, 14 Jul 1999 19:32:22 -0400 (EDT) Message-ID: <378CE4D2.D64B1509@sympatico.ca> Date: Wed, 14 Jul 1999 19:28:18 +0000 From: Sandy Harris X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher - updated choice list References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Helger Lipmaa wrote: > (... Rijndael is also one of the leading AES > candidates, while the successor of CAST-128, CAST-256, is most probably > not going to make it to the second round of candidates). Judging by comments I'm seeing on assorted lists, you're likely right. > Why? I see no particularly good reasons. CAST-256 is one of my favorite candidates, largely because the design is conservative and based on much good research. On the other hand, I'm impressed with many of the others, especially Serpent. > * Rijndael is based on the design of Shark, and Square. Square has been > known for 2.5 years and _no weaknesses_ in it have been found. CAST-256 is based on CAST-128, which has been out longer, widely used commercially (Entrust, PGP,...), and has had lots of research and analysis papers published about it. No known weaknesses. > * The theory behind Rijndael (or Square) seems to guarantee > that completely new type of attacks should be invented to break them. Yes, but many of the AES candidates offer some (at least apparently) good theoretical ideas. > * Rijndael is (most probably) much more secure than unbroken Square > due to the added rounds. Yes, but Serpent presents a security analysis showing it is secure against all known attacks, then doubles the number of rounds, and CAST-256 increases rounds over unbroken CAST-128 and .... > Moreover, Rijndael is the fastest AES candidate `in average' (cf > http://home.cyber.ee/helger/aes/) and free of patents. Serious advantages, but several other AES candidates have been declared freely implementable by their proposers. > Thus, I'd advocate strongly for including Rijndael at least to RFC 2451. I'd say its too soon for any of the AES candiadtes as a MUST. On the other hand, I'd argue that as soon as NIST cuts the field to about five for round two (which is due to happen this summer), all five should become MAY implement items listed in the RFC, numbers should be assigned for all, and the working group should state its intent to make the winner a MUST. This would encourage implementers to be ready for the winner when it comes, by getting experience with the AES 128-bit block size. It might also contribute to AES via real world implementation and use experience. > But, I would personally oppose to any additional MUST algorithms atm (IDEA > would be the only exception if there were no patents). I'd like CAST-128 as a MUST or at least SHOULD now, AES later. From owner-ipsec@lists.tislabs.com Wed Jul 14 20:15:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA02443; Wed, 14 Jul 1999 20:15:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08780 Wed, 14 Jul 1999 21:41:24 -0400 (EDT) Message-Id: <3.0.6.32.19990715033329.00a20210@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 15 Jul 1999 03:33:29 +0200 To: "Jesse Walker" , Rodney Thayer From: Rodney Thayer Subject: Re: new second mandatory IPsec cipher - updated choice list Cc: ipsec@lists.tislabs.com In-Reply-To: <852567AE.004F6587.00@zule.shiva.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RC5 is proprietary now. MARS, RC6 are on the "not known to not be patented" AES list. I don't know about Rijndael and Serpent's patent status, but they suffer from youth as the other AES candidates do. Twofish is also AES and therefore young. If we're willing to consider AES then I think we need to look at the known-to-not-be-patented ones, meaning Twofish (and others?) At 10:47 AM 7/14/99 -0400, Jesse Walker wrote: >MARS, RC6, Rijndael, Serpent, and Twofish seem to be the most serious AES >candidates. At 10:47 AM 7/14/99 -0400, Jesse Walker wrote: >MARS, RC6, Rijndael, Serpent, and Twofish seem to be the most serious AES >candidates. > >If the goal is really to make IPSec more resistant to attack, we want the >second mandatory algorithm to be as different from DES as possible. This >line of reasoning argues in favor of RC5 among the algorithms already >defined for use in IPSec, and RC6 and Rijndael as the best choices among >the AES candidates. From owner-ipsec@lists.tislabs.com Wed Jul 14 21:37:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA08332; Wed, 14 Jul 1999 21:37:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09077 Wed, 14 Jul 1999 23:03:53 -0400 (EDT) Message-ID: <3C3175FCC945D211B65100805F1580890A486B62@RED-MSG-07> From: William Dixon To: "'ipsec@lists.tislabs.com'" Subject: Win2000 IPSec walkthrough pointer Date: Wed, 14 Jul 1999 20:02:08 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Had a number of requests, so wanted to let everyone know the link: http://www.microsoft.com/windows/server/Deploy/default.asp under Security It covers how to use certificates and enroll using the Internet Microsoft CAs available at http://sectestca1.rte.microsoft.com Expect the L2TP-IPSec walkthrough to be posted in 2-3 weeks. Please use the newsgroups mentioned in the walkthrough for questions on configuration. I can try to handle specific implementation questions offline via email. I would particularly like to hear from other OS vendors who have a GSS-API library, interested in supporting Kerberos v5 auth in IKE for transport SAs: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-02.txt To answer the most popular question, no, we don't have an API for this initial release, will be working on one for next release. I've been out for 2 weeks, so please don't be offended if I can't reply quickly. Wm IPSec Program Manager Microsoft 425-703-8729 From owner-ipsec@lists.tislabs.com Thu Jul 15 02:17:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18850; Thu, 15 Jul 1999 02:17:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA09604 Thu, 15 Jul 1999 03:25:50 -0400 (EDT) Message-Id: <3.0.5.32.19990715102558.00bea100@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Jul 1999 10:25:58 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: IPSec on NT? In-Reply-To: <199907141906.MAA09429@eql-e.isi.edu> 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 DAA09601 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:06 14.7.1999 -0700, you wrote: >Hi, all > >Is it possible to implement IPSec on NT (server 4) without the need >of modifying kernel? > >Or does anyone know the third-party implementation? > >TKS > >Alex Sou > > Yes. IPsec can be implemented as an NDIS intermediate driver for IP packet processing and an NT service for IKE. Various implementations are available today, including our own one. Jörn Sierwald From owner-ipsec@lists.tislabs.com Thu Jul 15 02:56:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19745; Thu, 15 Jul 1999 02:56:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA09745 Thu, 15 Jul 1999 04:25:21 -0400 (EDT) Message-Id: <3.0.5.32.19990715112530.00bdd100@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Jul 1999 11:25:30 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Timeout problems 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 EAA09741 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This might have been addresses in the ietf years ago, but I just stumbled into this one: I initiate cfg-mode. Remote host doesn't answer. After a couple of retransmissions, I give up. Two seconds later the remote hosts answers. I think it is a new cfg-mode exchange and calculate the IV incorrectly. Error "Invalid payload". Is there any way to prevent this? I found no way to abort a cfg-mode exchange cleanly, the delete payload does not work. Jörn Sierwald From owner-ipsec@lists.tislabs.com Thu Jul 15 03:22:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA21569; Thu, 15 Jul 1999 03:22:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA09803 Thu, 15 Jul 1999 04:45:30 -0400 (EDT) Message-ID: <378D9F5B.C3FA1495@checkpoint.com> Date: Thu, 15 Jul 1999 10:44:12 +0200 From: Tamir Zegman X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dennis Glatting , ipsec@lists.tislabs.com Subject: Re: Comment on xauth and hybrid References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dennis Glatting wrote: > I must first admit I had not read the xauth and hybrid drafts until > after the IPsec meeting where concerns were raised about weakening > IPsec by supporting legacy authentication systems. As a manager and > advisor of several enterprises I certainly understand the > "transitional" intent of these documents. In fact, I could easily be > one calling for their existence and demanding their implementation. > However, as that same manager and advisor I can confidently tell you > legacy systems, no matter their function, remain in-place and key > infrastructure components longer than they should. > > The PKI reality is there isn't one, so shared secrets, I expect, will > be the IPsec authentication mechanism of choice until products mature > and prices decline. The difference between simple shared secrets and > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > manage, managed shared secret technologies yielding, in my opinion, no > motivation to improve the security of infrastructures (i.e., > transition to PKI). Is this where we want to be after several years of > work and some cantankerous meetings? > There is another side for this coin. We have many customers that are deferring their migration to IPSec because they feel they are not ready to deploy a full scale PKI. Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment of PKI. Sometimes it's easier to jump over two small hurdles rather than over a big one. I'd like to point out another thing, Xauth/Hybrid is criticized on the grounds that it allows use of passwords. There is no doubt that passwords do not provide good security. However Xauth/Hybrid can be used with strong user authentication mechanisms such as - SecurID, DES Gold etc. I believe these methods offer better security than IKE pre-shared keys authentication. > > Perhaps not using managed shared secret technologies but I look to the > SSL/TLS web reality of today as a crystal ball of the future of a > widely deployed xauth/hybrid IPsec. I do a fair amount of on-line > purchasing. For some ten sites I have, to my dismay, several user > identifiers and passwords housed in ten different databases managed by > staffs with ten different philosophies on security and skill sets. Not > once have I been prompted by my browsers for the password to decrypt > my private key. Not once. If these sites supported client side > certificates I would not have to create an identifier, divulge a > password, or write these things down on a piece of paper and tuck it > away in my wallet. Further, I remember reading about a survey by > Netcraft where only 5% of the web sites they queried offering server > side certificates offered valid certificates. My concern is > xauth/hybrid effectively reduce IPsec to the SSL/TLS reality of today > (i.e., we really haven't improved things). I understand your concern, but these concerns should not be limited to the remote access scenario. Nothing prevents an IKE implementation from accepting an invalid certificate except for the IPSec RFCs. Xauth/Hybrid is not different. An IKE implementation that supports Xauth/Hybrid should still confirm to the standard IPSec RFCs and it is therefore not exempt from certification validation. > > I offer the following suggestions. First, finish a combined > xauth/hybrid draft and classify it as experimental. Second, the > Security Considerations section of the draft be written not by the > draft's proponents but by at least two of its detractors. Finally, set > a deadline (perhaps three years) where the PS is committed to > historic. I'll accept your offer with regard to the Security Consideration section. Any volunteers? I do not believe that the experimental is the right track for this. From owner-ipsec@lists.tislabs.com Thu Jul 15 03:23:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA21580; Thu, 15 Jul 1999 03:23:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA09779 Thu, 15 Jul 1999 04:35:49 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF1F5B48@exchange> From: Stephane Beaulieu To: Andrew Krywaniuk , Greg Carter , "'ipsec@lists.tislabs.com'" Subject: RE: XAUTH? Date: Thu, 15 Jul 1999 04:37:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Greg, I guess there is some ambiguity. The text in the next rev. will be clarified. in section 3, the following text All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID. Will be changed to An extended authentication transaction is defined as a series ISAKMP-Config messages. All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config Identifier as well as the same ISAKMP Message ID and continue to chain the IV for all messages in the transaction. Does this clarify things? Stephane. <-----Original Message----- -----Original Message----- <> From: Greg Carter [mailto:greg.carter@entrust.com] <> Sent: Wednesday, July 14, 1999 2:09 PM <> To: 'ipsec@lists.tislabs.com' <> Subject: XAUTH? <> <> <> Hi, <> <> Config Mode states: <> <> "A "Configuration Transaction" is defined as two configuration <> exchanges, the first being either a Set or a Request and being either an Acknowledge or a Reply, respectively. <> <> ... <> Transactions are completed once the Reply or Acknowledge code is <> received." <> <> To me this means that the message ID is unique for the <> transaction, either a <> Set-Ack or Request-Reply pair. <> <> However XAUTH states: <> All ISAKMP-Config messages in an extended authentication <> transaction MUST contain the same ISAKMP-Config message ID. <> <> And gives examples where a Request-Reply is followed by a <> Set-Ack and is <> referred to as a "transaction". <> <> Are the message ID's unique for the Request-Reply and Set-Ack <> in XAUTH or <> are they the same? <> <> <> <> <> < From owner-ipsec@lists.tislabs.com Thu Jul 15 04:08:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22731; Thu, 15 Jul 1999 04:08:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA09816 Thu, 15 Jul 1999 04:49:14 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF1F5B49@exchange> From: Stephane Beaulieu To: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: Timeout problems Date: Thu, 15 Jul 1999 04:51:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 EAA09813 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Joern, The symptom of receiving an "Invalid payload" after you've given up due to timeouts exists in most of the exchanges (all but info mode, I think). You can solve this problem by not giving up so soon. If you don't want to retry too often, use exponential backoff algorithms that will give you the ability of retrying at greater an greater intervals so that you don't bog down your box. Something like (1,2,4,8... seconds). The delete payload should work; assuming you really want to do this. If you tell the other guy that you've deleted your phase1 SA, then he should stop sending you ISAKMP messages for that SA. However, I believe that your best option is to increase you retry counts / times. Stephane. <-----Original Message----- From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: Policy management, COPS, and SCVP Date: Thu, 15 Jul 1999 10:44:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Is anyone thinking much about policy management for IPSEC VPN clients? I've been reading a bit about Common Open Policy Service (COPS) which seems to offer a solution with 'dynamic' policy decisions. One thought I had when reading it, is that the COPS server (The Policy Decision Point - PDP), could be passed the client certificate to start the policy look-up. This would then allow the COPS server to do the job of SCVP as well: 1) check the certificate 2) return the appropriate policy, or reject. Steve. From owner-ipsec@lists.tislabs.com Thu Jul 15 07:29:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA25419; Thu, 15 Jul 1999 07:29:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10824 Thu, 15 Jul 1999 08:53:04 -0400 (EDT) Message-Id: <4.1.19990715144712.00b5d760@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Jul 1999 14:55:49 +0200 To: ipsec@lists.tislabs.com From: Robert Moskowitz Subject: starting on asking THE QUESTION Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am sitting here in saag trying to capture Jeff's cypher question. Here is the pertinent part of 2406 5. Conformance Requirements Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] - NULL Authentication algorithm - NULL Encryption algorithm It seems that there is some level of concensus for: Drop DES Make 3DES as manditory There is a debate on the need or advisablity of a 2nd manditory SO PROPOSED QUESTION # 1 1a) Should a 2nd MUST cipher be added to 2406 1b) Shoud a SHOULD cipher be added to 2406 PROPOSED QUESTION # 2 Should we make the change to the standard (other than switch from DES to 3DES) 2a) This Year 2b) Next Year PROPOSED QUESTION #3 Should the 2nd cipher be: 3a) An existing non-DES cipher 3b) One of the 5 AES finalists We will discuss these questions before I call for straw votes to me and Ted. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Thu Jul 15 08:47:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27348; Thu, 15 Jul 1999 08:47:06 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11142 Thu, 15 Jul 1999 10:04:12 -0400 (EDT) Date: Thu, 15 Jul 1999 10:04:12 -0400 (EDT) Message-Id: <199907151404.KAA11142@lists.tislabs.com> with SMTP id IAA23642 for ; Thu, 15 Jul 1999 08:56:23 -0500 (CDT) Posted-Date: Thu, 15 Jul 1999 08:56:23 -0500 (CDT) Message-Id: <4.1.19990715084059.00a00290@mail.visi.com> X-Sender: schneier@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Jul 1999 08:50:44 -0500 To: ipsec@lists.tislabs.com From: Bruce Schneier Subject: CHoosing a second manditory cipher for IPSec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk People have forwarded some of this debate to me. I am not on the IPSec mailing list, so if you want me to respond to further emails please copy me. If you can afford to wait a year and a half before choosing a second manditory cipher, do so. The AES process is moving along at speed, and a final winner (or winner) should be chosen sometime in Summer 2000. Then you will have a second cipher that has some general consensus of security--and one that will become a standard--to add to IPSec. If you have to add a second cipher now, then the list I saw previously is a good place to start: -- CAST-128 -- BLOWFISH -- IDEA -- TWOFISH -- MARS -- (other AES candidates, please feel free to contribute) I contribute Rijndael. And someone else mentioned DES-X. This is a tough list. On the one hand, it is too early to choose any AES candidates as a manditory part of IPSec. If I had to pick one, I would pick Twofish or RIjndael. Those are the only two algorithms flexible enough to be efficient on the variety of platforms (hardware and software) that IPSec needs to run on. (Someone said that Rijndael is the fastest AES candidate on all platforms. I don't agree with that. Twofish is, and Rijndael is second. We have various tables in the Twofish AES submission document: http://www.counterpane.com/twofish-paper.html.) DES-X is philosophically the same as Triple-DES, so I see no reason to add it. IDEA is patented, and I don't know the current situation with the rights. Also, recent attacks are getting a bit too close to the full cipher for me. And it is very slow compared to other ciphers. Blowfish and CAST-128 are similar in philosophy. I prefer Blowfish, which has the advantage of more analysis and more use. There are over 100 products that use Blowfish: http://www.counterpane.com/products.html. Still, neither cipher has had as much analysis as DES and triple-DES. The question comes down to why IPSec needs a second cipher. Remember that any implementation of IPSec will probably be as secure as the weakest of the two cipher choices (under the assumption that an attacker can force a choice, or at least on the assumption that the users will have no idea which cipher to choose). I think giving users a choice is a bad idea, and that one strong cipher is better than two strong ciphers. Wait for the AES process; this is exactly the application that it was designed for. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com From owner-ipsec@lists.tislabs.com Thu Jul 15 09:44:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28194; Thu, 15 Jul 1999 09:44:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11378 Thu, 15 Jul 1999 10:57:56 -0400 (EDT) Date: Thu, 15 Jul 1999 10:57:24 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: starting on asking THE QUESTION In-Reply-To: <4.1.19990715144712.00b5d760@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Jul 1999, Robert Moskowitz wrote: > Should we make the change to the standard (other than switch from DES to 3DES) > 2a) This Year > 2b) Next Year I suggest narrowing the debate slightly: it seems to me that the question before this assembly :-) is whether to add a second cipher more or less immediately, i.e. this year. It is quite likely that the progress of AES will inspire a further addition somewhat later, and other developments could well have the same effect, but the question which needs to be decided *now* is whether to add another cipher *now*. The question of later additions can, and should, be postponed. > Should the 2nd cipher be: > 3a) An existing non-DES cipher > 3b) One of the 5 AES finalists If my proposed narrowing of debate is accepted, I think this question answers itself: the AES finalists are too new for there to be widespread confidence in them *now*. (The key word is "widespread".) The crucial question is whether an existing non-DES cipher should be added promptly, or whether changes other than DES->3DES should be deferred until at least next year. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Jul 15 10:15:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29283; Thu, 15 Jul 1999 10:15:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11462 Thu, 15 Jul 1999 11:21:16 -0400 (EDT) Date: Thu, 15 Jul 1999 18:21:24 +0300 (EET DST) Message-Id: <199907151521.SAA01183@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Stephane Beaulieu Cc: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: Timeout problems In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF1F5B49@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF1F5B49@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane Beaulieu writes: > The delete payload should work; assuming you really want to do this. If you > tell the other guy that you've deleted your phase1 SA, then he should stop > sending you ISAKMP messages for that SA. However, I believe that your best > option is to increase you retry counts / times. What is the spi and protocol of the configuration mode exchange? To fill in delete payload you need spi and protocol, and configuration mode does not have them. I think it is overkill to kill the whole ISAKMP SA in that case. From owner-ipsec@lists.tislabs.com Thu Jul 15 10:21:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29495; Thu, 15 Jul 1999 10:21:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11405 Thu, 15 Jul 1999 11:09:59 -0400 (EDT) Message-Id: <3.0.5.32.19990715181005.00c4c4e0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Jul 1999 18:10:05 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: starting on asking THE QUESTION 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 LAA11402 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:55 15.7.1999 +0200, Robert wrote: > > - DES in CBC mode [MD97] > - HMAC with MD5 [MG97a] > - HMAC with SHA-1 [MG97b] > - NULL Authentication algorithm > - NULL Encryption algorithm > Rodney wrote: > I think we need to have a second cipher to use, in the event 3DES is > found to be unsafe. This is not a reflection on the quality of 3DES. > In my opinion there are genuine legitimate concerns about the use of > DES, and there are definitely people out there in the commercial world > who wish to phase out it's use. There is no actual need to do anything. Everybody has implemented 3DES. We do have a second cipher to use, and even a third one, CAST-128 and blowfish. If people in the commercial world wish to use something else than DES, they can. If we add a "SHOULD implement CAST-128", does it matter? While we're at it, I'm very annoyed that there still are no values for using DESX in ISAKMP and IPsec. Could Mr. Tero "I have more ciphers than you have bits in your key" Kivinen please start the allocation of values to negotiate DESX, MARS, RC6, Rijndael, TwoFish and skipjack? Both Phase I and II. There are so many open slots, it wouldn't matter if we allocate numbers for all AES candidates. Jörn From owner-ipsec@lists.tislabs.com Thu Jul 15 10:26:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29660; Thu, 15 Jul 1999 10:26:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11536 Thu, 15 Jul 1999 11:39:56 -0400 (EDT) X-Lotus-FromDomain: SHIVA CORPORATION From: "Jesse Walker" To: Robert Moskowitz cc: ipsec@lists.tislabs.com Message-ID: <852567AF.0051B9EC.00@zule.shiva.com> Date: Thu, 15 Jul 1999 11:29:28 -0400 Subject: Re: starting on asking THE QUESTION Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bob: > SO PROPOSED QUESTION # 1 > > 1a) Should a 2nd MUST cipher be added to 2406 > 1b) Shoud a SHOULD cipher be added to 2406 1a - maybe 1b - no Adding another SHOULD to 2406 will do nothing to increase interoperability; we've tried the SHOULD route many times, with much grumbling and gnashing of teeth, as nearly every implementation seems to include its author's favorite subset of the collected SHOULDs scattered amongst 2401-2412. If a consensus for a second mandatory cipher emerges, we must make it a MUST. > PROPOSED QUESTION # 2 > > Should we make the change to the standard (other than switch from DES to 3DES) > > 2a) This Year > 2b) Next Year 2a - no 2b - maybe That will give the working group time to decide if there is a consensus for a second algorithm. It is not evident yet that a consensus exists, or that mandating two ciphers is an especialy good idea (it is not evident it is not a good idea, either). > PROPOSED QUESTION #3 > > Should the 2nd cipher be: > > 3a) An existing non-DES cipher > 3b) One of the 5 AES finalists 3a - no 3b - maybe Intellectual property claims prevent the working group from considering the only existing ciphers I would consider, so I can't support 3a. It is not self-evident that 3b is the right answer, either, since, if a consensus for two mandatory algorithms indeed emerges, we may instead want to vote for 3c) Two of the 5 AES finalists assuming we deprecate 3DES to historical status at the same time. I would vote for 3b if the working group decides to retain 3DES and mandate two ciphers. From owner-ipsec@lists.tislabs.com Thu Jul 15 11:00:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00733; Thu, 15 Jul 1999 11:00:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11607 Thu, 15 Jul 1999 12:04:11 -0400 (EDT) From: jerome@psti.com Message-ID: <19990715120554.A3699@jerome.psti.com> Date: Thu, 15 Jul 1999 12:05:54 -0400 To: ipsec@lists.tislabs.com Cc: Bruce Schneier Subject: Re: your mail Reply-To: jerome@psti.com References: <199907151404.KAA11142@lists.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: <199907151404.KAA11142@lists.tislabs.com>; from owner-ipsec@lists.tislabs.com on Thu, Jul 15, 1999 at 10:04:12AM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jul 15, 1999 at 10:04:12AM -0400, Bruce Schneier wrote: [snip] > I think giving users a choice is a bad idea, and > that one strong cipher is better than two strong ciphers. if ipsec is deployed with 2 ciphers A and B, and a major weakness is found out in A, you still have the choice to use B. if A was the only cypher, you have to upgrade all the software/hardware. [snip] From owner-ipsec@lists.tislabs.com Thu Jul 15 12:03:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA02473; Thu, 15 Jul 1999 12:03:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11836 Thu, 15 Jul 1999 13:03:52 -0400 (EDT) Message-Id: <199907151703.KAA19898@gallium.network-alchemy.com> To: jerome@psti.com cc: ipsec@lists.tislabs.com, Bruce Schneier Subject: Re: your mail In-reply-to: Your message of "Thu, 15 Jul 1999 12:05:54 EDT." <19990715120554.A3699@jerome.psti.com> Date: Thu, 15 Jul 1999 10:03:29 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All, > > I think giving users a choice is a bad idea, and > > that one strong cipher is better than two strong ciphers. > > if ipsec is deployed with 2 ciphers A and B, and a major weakness is found > out in A, you still have the choice to use B. > if A was the only cypher, you have to upgrade all the software/hardware. I agree that by requiring two MUST's, we ensure that there is a viable alternative in deployed implementations if one of the MUST ciphers should be compromised in the future. If there's only one, you're completed hosed. RE: 3DES to historic when AES is announced I would oppose this move at this time. Even when AES is announced, there's no way it's going to have had the same scrutiny that DES, hence 3DES, has had in fielded implementations. There will come a time when we want to deprecate 3DES, but that's not the day AES comes out. RE: AES, in general It seems a no-brainer to me that the AES choice be added to IPSEC as a MUST implement cipher once it's decided. Derrell From owner-ipsec@lists.tislabs.com Thu Jul 15 19:41:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA22918; Thu, 15 Jul 1999 19:41:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13357 Thu, 15 Jul 1999 21:01:40 -0400 (EDT) From: sakane@ydc.co.jp Date: Fri, 16 Jul 1999 10:00:58 +0900 (JST) Message-Id: <199907160100.KAA02438@ghost.wide.ydc.co.jp> To: ipsec@lists.tislabs.com Subject: IPsec SA proposal of IKE X-Mailer: Cue version 0.6 (990519-1347/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi folks, I'd like to make sense. A <------------------> B [IP][AH][ESP][ULP] When we want to use SA bundle of AH and ESP constructed like above, what should we do phase 2 of IKE ? 1) we MUST do one quick mode. 2) we SHOULD do one quick mode, and MAY do two quick mode. There may be the situation when I want to make AH-SA between node A and node B after ESP-SA was negotiated. Of course, we can do negotiate by using one quick mode with SA bundle after we delete old policy. So 2) seems good for interoperability. But there may be policy problem. 1) means, A B ----------- ----------- HDR*, ...SA(AH+ESP)... --> <-- HDR*, ...SA(AH+ESP)... 2) means, A B ----------- ----------- HDR*, ...SA(AH+ESP)... --> <-- HDR*, ...SA(AH+ESP)... or A B ----------- ----------- HDR*, ...SA(AH)... --> <-- HDR*, ...SA(AH)... HDR*, ...SA(ESP)... --> <-- HDR*, ...SA(ESP)... /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Thu Jul 15 22:11:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA03498; Thu, 15 Jul 1999 22:11:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13669 Thu, 15 Jul 1999 23:30:16 -0400 (EDT) Message-ID: <378EA7DD.346F1C77@intotoinc.com> Date: Fri, 16 Jul 1999 09:02:45 +0530 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Sankar Ramamoorthi CC: "'ipsec@lists.tislabs.com'" Subject: Re: parallel vpns References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sankar, This is similar to some discussion on ipsra mailing list while ago. It is possible to have different IKE policies between two SGs. And possible only with different IDs. If you want to use preshared key, then aggressive mode is only solution. In case of signatures, you still can use main mode. See VIPUL GUPTA draft which was posted in ipsra mailing list. Regards Srini Sankar Ramamoorthi wrote: > Hi, > > An IPSec Architecture question. > In the following network > > S1----- -----D1 > | | > SG1 SG2 > | | > S2_---- -----D2 > > I have a setup where a pair of gateways SG1, SG2 are protecting > hosts S1,S2 and D1,D2 respectively. I want to define 2 vpns > VPN1, VPN1 where > > S1,D1 belong to VPN1 > > S2,D2 belong to VPN2 > > Does IPsec architecture allows for such policy defnitions? > ie: multiple VPNs managed by a pair of gateways. > > If so > Can the main mode characterstics for VPN1 and VPN2 be different? > Are there any constraints on how they can be different? > > For example: > > VPN1 (main mode characterstics) > DES, MD5, preshared authentication with secret1 > > VPN2 (main mode characterstics) > DES, MD5, preshared authentication wih secret2 > > VPN1 and VPN2 are different only in the preshared secret used > for authentication purposes. > > SG1 initiates an IKE request to SG2. How can SG2 > determine to which VPN the request belongs looking the SA > request? > > If SG2 were to pick the wrong VPN, then authentication will > fail down the line and SG1 will not be able to complete > the IKE exchange. > > I thought about using non-ip identifiers and having different phase 1 > identifiers > for VPN1 and VPN2, but that leads to different set of problems. > > What am I missing? > > Thanks for any input. > > -- sankar -- From owner-ipsec@lists.tislabs.com Fri Jul 16 07:44:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18117; Fri, 16 Jul 1999 07:44:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15102 Fri, 16 Jul 1999 08:51:30 -0400 (EDT) Date: Thu, 15 Jul 1999 22:13:38 -0700 (PDT) From: Dennis Glatting To: Bruce Schneier cc: jerome@psti.com, ipsec@lists.tislabs.com Subject: Re: your mail In-Reply-To: <4.1.19990715161920.00a04930@mail.visi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Jul 1999, Bruce Schneier wrote: > This still makes no sense to me. There are so many things to > worry about wrt an IPSec implementation, so many things that can > compromise security if they are not done correctly, that making > sure there is a backup to triple-DES seems like a collossal waste > of time. It's like putting a mile-high stake in the ground and > hoping the enemy runs right into it, instead of trying to build a > wall. > I am having trouble believing 3DES is going to broken anytime soon, but then I am not a cryptographer and up on current events. Therefore, I believe that a back-up cipher will be caught in regular maintenance cycles and the whole thing a non-issue, but I've been wrong many times before. :) I ask what is going on here folks? This whole 3DES thing seems like FUD, which isn't typical IETF behaviour. What is it I don't know? From owner-ipsec@lists.tislabs.com Fri Jul 16 07:44:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18125; Fri, 16 Jul 1999 07:44:38 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15062 Fri, 16 Jul 1999 08:49:29 -0400 (EDT) Date: Fri, 16 Jul 1999 08:49:29 -0400 (EDT) Message-Id: <199907161249.IAA15062@lists.tislabs.com> with SMTP id MAA25564; Thu, 15 Jul 1999 12:59:01 -0500 (CDT) Posted-Date: Thu, 15 Jul 1999 12:59:01 -0500 (CDT) Message-Id: <4.1.19990715125053.00ab4530@mail.visi.com> X-Sender: schneier@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Jul 1999 12:51:54 -0500 To: jerome@psti.com, ipsec@lists.tislabs.com From: Bruce Schneier Subject: Re: your mail In-Reply-To: <19990715120554.A3699@jerome.psti.com> References: <199907151404.KAA11142@lists.tislabs.com> <199907151404.KAA11142@lists.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:05 PM 7/15/99 -0400, jerome@psti.com wrote: >On Thu, Jul 15, 1999 at 10:04:12AM -0400, Bruce Schneier wrote: >[snip] > >> I think giving users a choice is a bad idea, and >> that one strong cipher is better than two strong ciphers. > >if ipsec is deployed with 2 ciphers A and B, and a major weakness is found >out in A, you still have the choice to use B. >if A was the only cypher, you have to upgrade all the software/hardware. There's not going to be a major weakness found in triple-DES. That seems like a pretty far-fetched thing to worry about. I would spend my effort worrying about the implementation security of IPSec. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com From owner-ipsec@lists.tislabs.com Fri Jul 16 07:57:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18285; Fri, 16 Jul 1999 07:57:00 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15068 Fri, 16 Jul 1999 08:50:27 -0400 (EDT) Date: Fri, 16 Jul 1999 08:50:27 -0400 (EDT) Message-Id: <199907161250.IAA15068@lists.tislabs.com> with SMTP id QAA00201; Thu, 15 Jul 1999 16:26:27 -0500 (CDT) Posted-Date: Thu, 15 Jul 1999 16:26:27 -0500 (CDT) Message-Id: <4.1.19990715161920.00a04930@mail.visi.com> X-Sender: schneier@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Jul 1999 16:20:37 -0500 To: Dennis Glatting , jerome@psti.com From: Bruce Schneier Subject: Re: your mail Cc: ipsec@lists.tislabs.com In-Reply-To: References: <19990715120554.A3699@jerome.psti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:08 PM 7/15/99 -0700, Dennis Glatting wrote:>From an enterprise management perspective upgrading is a non-trivial >process, a costly process, and cannot happen in a timely manner >thereby leaving the enterprise vulnerable. > >In my cases, I have to first determine if the exploit has significant >impact for my users. I have to convince management teams it is >significant issue. I have to come up with a plan and budget to upgrade >devices. I have to locate and allocate sufficient expertise across my >distributed enterprises and coordinate their efforts. I have to wait >until my vendors revise their products. I have to cycle through my >remote users' equipment. And, if previous experience is an indication >of future events, upgrade devices themselves, such as revving the OS, >adding memory, and increase processor power. > >It would be much easier and cost effective simply to change my policy >engine (i.e., switch to cipher b). This still makes no sense to me. There are so many things to worry about wrt an IPSec implementation, so many things that can compromise security if they are not done correctly, that making sure there is a backup to triple-DES seems like a collossal waste of time. It's like putting a mile-high stake in the ground and hoping the enemy runs right into it, instead of trying to build a wall. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com From owner-ipsec@lists.tislabs.com Fri Jul 16 08:11:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18600; Fri, 16 Jul 1999 08:11:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15410 Fri, 16 Jul 1999 09:25:17 -0400 (EDT) Message-ID: <378F3261.D94EF4EE@juggernautics.com> Date: Fri, 16 Jul 1999 09:23:45 -0400 From: Joel Odom Organization: Juggernautics, LLC X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPsec Aware Packet Sniffer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there any packet sniffers out there that are IPsec aware in that they can identify and display ESP / AH header information and monitor IKE? It would be nice if manual keying could be used to even open and view ESP payload. -- Juggernautics, LLC Computer, Electrical & Mechanical Engineering http://www.juggernautics.com From owner-ipsec@lists.tislabs.com Fri Jul 16 08:28:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18740; Fri, 16 Jul 1999 08:28:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15061 Fri, 16 Jul 1999 08:49:28 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8AE@sothmxs06.entrust.com> From: Greg Carter To: "'Stephane Beaulieu'" , Andrew Krywaniuk , "'ipsec@lists.tislabs.com'" Subject: RE: XAUTH? Date: Thu, 15 Jul 1999 14:55:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Stephane, Yes it makes it clear, however it is broken. Config Mode is defined as a two packet exchange, then you can delete state. Now I have to determine is this is an XAUTH config mode? or is it just a regular config mode?, if it's xauth then wait for some more and save state. This isn't at all consistent with other IKE exchange types. All IKE exchanges types currently have a defined packet sequence, xauth changes that to "config is two but if this bit is set in an attribute payload then what I really want to do is something completely different with four." If you are going to make XAUTH a 4 sequence exchange then why not define a new exchange type, since it really has nothing to do with config? Especially since it breaks any generic config mode implementations would expect the 3rd sequence to be a new Config mode. Thanks Bye. -----Original Message----- From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] Sent: Thursday, July 15, 1999 4:38 AM To: Andrew Krywaniuk; Greg Carter; 'ipsec@lists.tislabs.com' Subject: RE: XAUTH? Hi Greg, I guess there is some ambiguity. The text in the next rev. will be clarified. in section 3, the following text All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID. Will be changed to An extended authentication transaction is defined as a series ISAKMP-Config messages. All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config Identifier as well as the same ISAKMP Message ID and continue to chain the IV for all messages in the transaction. Does this clarify things? Stephane. <-----Original Message----- -----Original Message----- <> From: Greg Carter [mailto:greg.carter@entrust.com] <> Sent: Wednesday, July 14, 1999 2:09 PM <> To: 'ipsec@lists.tislabs.com' <> Subject: XAUTH? <> <> <> Hi, <> <> Config Mode states: <> <> "A "Configuration Transaction" is defined as two configuration <> exchanges, the first being either a Set or a Request and being either an Acknowledge or a Reply, respectively. <> <> ... <> Transactions are completed once the Reply or Acknowledge code is <> received." <> <> To me this means that the message ID is unique for the <> transaction, either a <> Set-Ack or Request-Reply pair. <> <> However XAUTH states: <> All ISAKMP-Config messages in an extended authentication <> transaction MUST contain the same ISAKMP-Config message ID. <> <> And gives examples where a Request-Reply is followed by a <> Set-Ack and is <> referred to as a "transaction". <> <> Are the message ID's unique for the Request-Reply and Set-Ack <> in XAUTH or <> are they the same? <> <> <> <> <> < From owner-ipsec@lists.tislabs.com Fri Jul 16 08:34:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18801; Fri, 16 Jul 1999 08:34:29 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15099 Fri, 16 Jul 1999 08:51:29 -0400 (EDT) Date: Fri, 16 Jul 1999 08:51:29 -0400 (EDT) Message-Id: <199907161251.IAA15099@lists.tislabs.com> with SMTP id SAA12372; Thu, 15 Jul 1999 18:02:13 -0500 (CDT) Posted-Date: Thu, 15 Jul 1999 18:02:13 -0500 (CDT) Message-Id: <4.1.19990715175408.00ab7190@mail.visi.com> X-Sender: schneier@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Jul 1999 17:56:33 -0500 To: "Derrell D. Piper" , jerome@psti.com From: Bruce Schneier Subject: Re: your mail Cc: ipsec@lists.tislabs.com In-Reply-To: <199907151703.KAA19898@gallium.network-alchemy.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:03 AM 7/15/99 -0700, Derrell D. Piper wrote: >All, > >> > I think giving users a choice is a bad idea, and >> > that one strong cipher is better than two strong ciphers. >> >> if ipsec is deployed with 2 ciphers A and B, and a major weakness is found >> out in A, you still have the choice to use B. >> if A was the only cypher, you have to upgrade all the software/hardware. > >I agree that by requiring two MUST's, we ensure that there is a viable >alternative in deployed implementations if one of the MUST ciphers should be >compromised in the future. If there's only one, you're completed hosed. No. If there are two "MUST" ciphers, and one gets broken, then you must implement both a broken cipher and a strong cipher. And you had better make sure the selection mechanism is secure, of you are going to be hosed as well. This isn't a normal engineering paradigm of not putting all your eggs is one basket. In security engineering, the weakest egg defines the strength of the system. There are far more important things to worry about wrt IPSec that this matter is almost irrilevent. Use triple-DES. Wait a year or so for AES. Then add AES. In the menetime, solve all the other IPSec security problems. >RE: 3DES to historic when AES is announced No. That makes no sense, either. >I would oppose this move at this time. Even when AES is announced, there's no >way it's going to have had the same scrutiny that DES, hence 3DES, has had in >fielded implementations. There will come a time when we want to deprecate >3DES, but that's not the day AES comes out. Agreed. >RE: AES, in general > >It seems a no-brainer to me that the AES choice be added to IPSEC as a MUST >implement cipher once it's decided. Agreed. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com From owner-ipsec@lists.tislabs.com Fri Jul 16 08:36:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18821; Fri, 16 Jul 1999 08:36:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15077 Fri, 16 Jul 1999 08:50:32 -0400 (EDT) Date: Thu, 15 Jul 1999 12:08:48 -0700 (PDT) From: Dennis Glatting To: jerome@psti.com cc: ipsec@lists.tislabs.com, Bruce Schneier Subject: Re: your mail In-Reply-To: <19990715120554.A3699@jerome.psti.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Jul 1999 jerome@psti.com wrote: > On Thu, Jul 15, 1999 at 10:04:12AM -0400, Bruce Schneier wrote: > [snip] > > > I think giving users a choice is a bad idea, and > > that one strong cipher is better than two strong ciphers. > > if ipsec is deployed with 2 ciphers A and B, and a major weakness > is found out in A, you still have the choice to use B. if A was > the only cypher, you have to upgrade all the software/hardware. > >From an enterprise management perspective upgrading is a non-trivial process, a costly process, and cannot happen in a timely manner thereby leaving the enterprise vulnerable. In my cases, I have to first determine if the exploit has significant impact for my users. I have to convince management teams it is significant issue. I have to come up with a plan and budget to upgrade devices. I have to locate and allocate sufficient expertise across my distributed enterprises and coordinate their efforts. I have to wait until my vendors revise their products. I have to cycle through my remote users' equipment. And, if previous experience is an indication of future events, upgrade devices themselves, such as revving the OS, adding memory, and increase processor power. It would be much easier and cost effective simply to change my policy engine (i.e., switch to cipher b). From owner-ipsec@lists.tislabs.com Fri Jul 16 10:45:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21121; Fri, 16 Jul 1999 10:45:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15983 Fri, 16 Jul 1999 11:45:15 -0400 (EDT) Message-Id: <199907161544.IAA13062@potassium.network-alchemy.com> To: sakane@ydc.co.jp cc: ipsec@lists.tislabs.com Subject: Re: IPsec SA proposal of IKE In-reply-to: Your message of "Fri, 16 Jul 1999 10:00:58 +0900." <199907160100.KAA02438@ghost.wide.ydc.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13059.932139895.1@network-alchemy.com> Date: Fri, 16 Jul 1999 08:44:55 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's #1, you do one quick mode. Dan. On Fri, 16 Jul 1999 10:00:58 +0900 you wrote > Hi folks, I'd like to make sense. > > A <------------------> B > [IP][AH][ESP][ULP] > > When we want to use SA bundle of AH and ESP constructed like above, > what should we do phase 2 of IKE ? > > 1) we MUST do one quick mode. > 2) we SHOULD do one quick mode, and MAY do two quick mode. > > There may be the situation when I want to make AH-SA between node > A and node B after ESP-SA was negotiated. Of course, we can do > negotiate by using one quick mode with SA bundle after we delete > old policy. So 2) seems good for interoperability. > But there may be policy problem. > > 1) means, > A B > ----------- ----------- > HDR*, ...SA(AH+ESP)... --> > <-- HDR*, ...SA(AH+ESP)... > > 2) means, > A B > ----------- ----------- > HDR*, ...SA(AH+ESP)... --> > <-- HDR*, ...SA(AH+ESP)... > or > A B > ----------- ----------- > HDR*, ...SA(AH)... --> > <-- HDR*, ...SA(AH)... > > HDR*, ...SA(ESP)... --> > <-- HDR*, ...SA(ESP)... > > /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Fri Jul 16 10:57:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21415; Fri, 16 Jul 1999 10:57:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16061 Fri, 16 Jul 1999 12:11:17 -0400 (EDT) Date: Fri, 16 Jul 1999 09:11:17 +0000 (UCT) From: Brad Robel-Forrest To: Joel Odom cc: ipsec@lists.tislabs.com Subject: Re: IPsec Aware Packet Sniffer In-Reply-To: <378F3261.D94EF4EE@juggernautics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've added some preliminary support to Ethereal (http://ethereal.zing.org) for parsing IKE. It also has some very basic understanding of ESP and AH. -brad On Fri, 16 Jul 1999, Joel Odom wrote: > Are there any packet sniffers out there that are IPsec aware in that they can identify and display ESP / AH header information and monitor IKE? It would be nice if manual keying could be used to even open and view ESP payload. > > -- > Juggernautics, LLC > Computer, Electrical & Mechanical Engineering > http://www.juggernautics.com > From owner-ipsec@lists.tislabs.com Fri Jul 16 11:56:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22852; Fri, 16 Jul 1999 11:56:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16166 Fri, 16 Jul 1999 13:05:12 -0400 (EDT) From: eric.julien@wwgsolutions.com X-Lotus-FromDomain: GLOBAL To: ipsec@lists.tislabs.com Message-ID: <852567B0.005D9EC3.00@wg.com> Date: Fri, 16 Jul 1999 13:02:34 -0400 Subject: Re: IPsec Aware Packet Sniffer Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wandel & Goltermann will be coming out with IPSec protocol decodes in Examine 3.0, which should be released within the next couple of months. The protocols that I know of that will be part of that are ESP, AH, SPP, and ISAKMP (w/ IKE and Oakley information). Eric Joel Odom on 07/16/99 09:23:45 AM To: ipsec@lists.tislabs.com cc: (bcc: Eric Julien/RAL/Global) Subject: IPsec Aware Packet Sniffer Are there any packet sniffers out there that are IPsec aware in that they can identify and display ESP / AH header information and monitor IKE? It would be nice if manual keying could be used to even open and view ESP payload. -- Juggernautics, LLC Computer, Electrical & Mechanical Engineering http://www.juggernautics.com From owner-ipsec@lists.tislabs.com Fri Jul 16 12:20:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA23660; Fri, 16 Jul 1999 12:20:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16222 Fri, 16 Jul 1999 13:25:59 -0400 (EDT) Posted-Date: Fri, 16 Jul 1999 12:25:30 -0500 (CDT) Message-Id: <4.1.19990716101655.00a1a480@mail.visi.com> X-Sender: schneier@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 16 Jul 1999 10:23:41 -0500 To: Dennis Glatting , jerome@psti.com, ipsec@lists.tislabs.com From: Bruce Schneier Subject: More on a second IPSec algorithm In-Reply-To: References: <4.1.19990715161920.00a04930@mail.visi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:13 PM 7/15/99 -0700, Dennis Glatting wrote: >I am having trouble believing 3DES is going to broken anytime soon, >but then I am not a cryptographer and up on current events. Therefore, >I believe that a back-up cipher will be caught in regular maintenance >cycles and the whole thing a non-issue, but I've been wrong many times >before. :) Look at it this way. If triple-DES is broken--and by broken I don't mean an academic weakness that drops its keylength down to 100 bits with 100 terrabytes of known plaintext, but broken with a 2^64-ish complexity attack that requires immediat replacement--then there has been some kind of fundamental breakthrough in cryptanalysis. This breakthrough is likely to wreak havoc through all of our existing block ciphers, at least through those built on SP-networks and Feistel networks. I'm not convinced that we can reliably choose another algorithm to protect us against that eventually. On the more realistic hand, attacks nibble away at algorithms over the years. Look at the increasingly better attacks against DES, FEAL, IDEA, etc. Even when new attacks come out of the blue, they generally do a few rounds better than older attacks. We can't break single DES better than brute force (in situations with reasonable amounts of plaintext); an attack against triple-DES just isn't going to happen anytime soon. And for those who want a backup algorithm as a hot spare, just in case, I would feel much better if they would figure out how to recover from an overflow bug, or an implementation problem, or any of the more common and reasonable attacks that happen against Internet security protocols all the time. This is where the insecurities are going to happen, not in the trile-DES algorithm. The NSA does not build encryption equipment with a hot-spare algorithm in it. It makes no sense to do so. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com From owner-ipsec@lists.tislabs.com Fri Jul 16 14:27:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26340; Fri, 16 Jul 1999 14:27:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16715 Fri, 16 Jul 1999 15:29:26 -0400 (EDT) From: Otel Florian-Daniel Date: Fri, 16 Jul 1999 21:29:29 +0200 (MET DST) To: linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Subject: IP tunnel over a NAT (IP masq) possible ? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14223.33362.904306.427278@blomman18.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello everybody, I have the following problem: I have a machine behind a NAT performing one-to-many address translation (inside: Net 10. outside: only one IP addr). What i would like to do is to set a IP tunnel from one of the inside machines (the "client") to a remote machine (i.e. beyond NAT) (the "server"). Such that after the tunnel setup the inside machine appears to be virtually attached to the remote net. Requirements: -As it is implied, I don't have administrative control over the NAT (otherwise e.g. i could simply attach the client beyond it and use `oridnary` IP tunneling) -The tunnel is encrypted (overhead issues irrelevant for the time being) -The tunnel is set on-demand, in a client-server fashion (e.g. tunneling over a TCP connection). -The operating system: Linux Any ideas and suggestions are welcomed. Many thanks, Florian P.S: Maybe this were not the most appropriate forums were to ask. If that is the case, appologies in advance. Any hint in this respect will be appreciated. From owner-ipsec@lists.tislabs.com Fri Jul 16 14:46:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26493; Fri, 16 Jul 1999 14:46:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16773 Fri, 16 Jul 1999 16:02:12 -0400 (EDT) Message-ID: <378F9152.6C55E84E@raptor.com> Date: Fri, 16 Jul 1999 16:08:50 -0400 From: Ioannis Bonias Organization: Raptor Systems, Inc X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg Carter CC: "'Stephane Beaulieu'" , Andrew Krywaniuk , "'ipsec@lists.tislabs.com'" Subject: Re: XAUTH? References: <01E1D01C12D7D211AFC70090273D20B1B8F8AE@sothmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg, 1. Why do you want to distinguish a config mode exchange and XAUTH ? I think the problem starts with the absence of a clear definition of the 'Extended Authentication Method' (XAUTH) in the draft. If we define it as "a sequence of 1 or more config mode exchanges, initiated by an edge device to a host until the host is authenticated or rejected" then everything is fine. The 'responder' always expects a next config mode exchange until it receives the SET(STATUS=OK or NOT OK) message. The SET message is really the criterion that the responder uses to stop waiting for a message. When the responder sends the ACK then that is the end of the XAUTH session. 2. You don't want to limit the messages to 4, because i may want to do try a sequence of authentication types one after the other. So it is not necessarily negative that there is no limit the way it has been defined. yannis Greg Carter wrote: > Hi, Stephane, > Yes it makes it clear, however it is broken. > > Config Mode is defined as a two packet exchange, then you can delete state. > Now I have to determine is this is an XAUTH config mode? or is it just a > regular config mode?, if it's xauth then wait for some more and save state. > This isn't at all consistent with other IKE exchange types. All IKE > exchanges types currently have a defined packet sequence, xauth changes that > to "config is two but if this bit is set in an attribute payload then what I > really want to do is something completely different with four." > > If you are going to make XAUTH a 4 sequence exchange then why not define a > new exchange type, since it really has nothing to do with config? > Especially since it breaks any generic config mode implementations would > expect the 3rd sequence to be a new Config mode. > > Thanks > Bye. > > -----Original Message----- > From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] > Sent: Thursday, July 15, 1999 4:38 AM > To: Andrew Krywaniuk; Greg Carter; 'ipsec@lists.tislabs.com' > Subject: RE: XAUTH? > > Hi Greg, > > I guess there is some ambiguity. The text in the next rev. > will be clarified. > > in section 3, the following text > > All ISAKMP-Config messages in an extended authentication > transaction MUST contain the same ISAKMP-Config message ID. > > Will be changed to > > An extended authentication transaction is defined as a series > ISAKMP-Config messages. > > All ISAKMP-Config messages in an extended authentication transaction > MUST contain the same ISAKMP-Config Identifier as well as the same > ISAKMP Message ID and continue to chain the IV for all messages in > the transaction. > > Does this clarify things? > > Stephane. > <-----Original Message----- > < > < > < > < > < > < > <_______________________________________________ > < Beauty without truth is insubstantial. > < Truth without beauty is unbearable. > < > < > <> -----Original Message----- > <> From: Greg Carter [mailto:greg.carter@entrust.com] > <> Sent: Wednesday, July 14, 1999 2:09 PM > <> To: 'ipsec@lists.tislabs.com' > <> Subject: XAUTH? > <> > <> > <> Hi, > <> > <> Config Mode states: > <> > <> "A "Configuration Transaction" is defined as two configuration > <> exchanges, the first being either a Set or a Request and > <> being either an Acknowledge or a Reply, respectively. > <> > <> ... > <> Transactions are completed once the Reply or Acknowledge code is > <> received." > <> > <> To me this means that the message ID is unique for the > <> transaction, either a > <> Set-Ack or Request-Reply pair. > <> > <> However XAUTH states: > <> All ISAKMP-Config messages in an extended authentication > <> transaction MUST contain the same ISAKMP-Config message ID. > <> > <> And gives examples where a Request-Reply is followed by a > <> Set-Ack and is > <> referred to as a "transaction". > <> > <> Are the message ID's unique for the Request-Reply and Set-Ack > <> in XAUTH or > <> are they the same? > <> > <> > <> > <> > <> > < -- Ioannis Bonias, PhD Axent Technologies, INC. /Raptor Division email : ibonias@raptor.com phone : 781.530.2359 fax : 781.487.9372 From owner-ipsec@lists.tislabs.com Fri Jul 16 16:22:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27616; Fri, 16 Jul 1999 16:22:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16961 Fri, 16 Jul 1999 17:22:49 -0400 (EDT) Message-ID: From: Shih-Chin Yang To: "'otel@ce.chalmers.se'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: IP tunnel over a NAT (IP masq) possible ? Date: Fri, 16 Jul 1999 14:23:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BECFD1.690031CC" 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_01BECFD1.690031CC Content-Type: text/plain Hi! Florian: I am afraid that you would not be able setup a tunnel from a client behind a NAT device. The problem is the source address of the tunneled packet would be changed by the NAT device, but when client builds the authentication header, it takes the source address into account already. Thus, on the other end of the tunnel, the authentication would fail. One possiblity to solve your requirement is using a NAT device which would also originates a tunnel for you. So when it builds authentication header, it takes the mapped source address/port already. But even this approach might not work on every application that you might have. You could find out more in IETF NAT, IPSec working groups' home page. So far, I am in the context of IPsec tunnel. If you find something that would work for you, maybe another flavor of tunnel, please let me know. Regards, Shih-Chin > ---------- > From: Otel Florian-Daniel[SMTP:otel@ce.chalmers.se] > Reply To: otel@ce.chalmers.se > Sent: Friday, July 16, 1999 2:29 PM > To: linux-ipsec@clinet.fi; ipsec@lists.tislabs.com; > firewall-wizards@nfr.net > Subject: IP tunnel over a NAT (IP masq) possible ? > > > Hello everybody, > > > I have the following problem: I have a machine behind a NAT performing > one-to-many address translation (inside: Net 10. outside: only one IP > addr). What i would like to do is to set a IP tunnel from one of the > inside machines (the "client") to a remote machine (i.e. beyond NAT) > (the "server"). Such that after the tunnel setup the inside machine > appears to be virtually attached to the remote net. > > Requirements: > -As it is implied, I don't have administrative control over the NAT > (otherwise e.g. i could simply attach the client beyond it and use > `oridnary` IP tunneling) > -The tunnel is encrypted (overhead issues irrelevant for the time being) > -The tunnel is set on-demand, in a client-server fashion (e.g. tunneling > over a TCP connection). > -The operating system: Linux > > > Any ideas and suggestions are welcomed. > > Many thanks, > > Florian > > P.S: Maybe this were not the most appropriate forums were to ask. If > that is the case, appologies in advance. Any hint in this respect will > be appreciated. > ------_=_NextPart_001_01BECFD1.690031CC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IP tunnel over a NAT (IP masq) possible ?

Hi! Florian:

I am afraid that you = would not be able setup a tunnel from a client behind a NAT device. The = problem is the source address of the tunneled packet would be changed = by the NAT device, but when client builds the authentication header, it = takes the source address into account already. Thus, on the other end = of the tunnel, the authentication would fail.

One possiblity to = solve your requirement is using a NAT device which would also = originates a tunnel for you. So when it builds authentication header, = it takes the mapped source address/port already. But even this approach = might not work on every application that you might have. You could find = out more in IETF NAT, IPSec working groups' home page.

So far, I am in the = context of IPsec tunnel. If you find something that would work for you, = maybe another flavor of tunnel, please let me know.

Regards,
Shih-Chin

    ----------
    From:   = Otel = Florian-Daniel[SMTP:otel@ce.chalmers.se]
    Reply To: =       otel@ce.chalmers.se
    Sent:   = Friday, July 16, 1999 2:29 = PM
    To: =     linux-ipsec@clinet.fi; ipsec@lists.tislabs.com; = firewall-wizards@nfr.net
    Subject: =        IP tunnel over a NAT (IP masq) possible ?


    Hello everybody,


    I have the following problem: I have a = machine behind a NAT performing
    one-to-many address translation = (inside: Net 10. outside: only one IP
    addr). What i would like to do is to = set a IP tunnel from one of the
    inside machines (the = "client") to a remote machine (i.e. beyond NAT)
    (the "server"). Such that = after the tunnel setup the inside machine
    appears to be virtually attached to = the remote net.

    Requirements:
    -As it is implied, I don't have = administrative control over the NAT
    (otherwise e.g. i could simply attach = the client beyond it and use
    `oridnary` IP tunneling)
    -The tunnel is encrypted  = (overhead issues irrelevant for the time being)
    -The tunnel is set on-demand, in a = client-server fashion (e.g. tunneling
    over a TCP connection).
    -The operating system: Linux


    Any ideas and suggestions are = welcomed.

    Many thanks,

    Florian

    P.S: Maybe this were not the most appro= priate forums were to ask. If
    that is the case, appologies in = advance. Any hint in this respect will
    be appreciated.

------_=_NextPart_001_01BECFD1.690031CC-- From owner-ipsec@lists.tislabs.com Fri Jul 16 16:38:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27787; Fri, 16 Jul 1999 16:38:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17099 Fri, 16 Jul 1999 18:04:59 -0400 (EDT) Date: Fri, 16 Jul 1999 17:04:35 -0500 (CDT) From: David Borman Message-Id: <199907162204.RAA00653@frantic.bsdi.com> To: otel@ce.chalmers.se, syang@redcreek.com Subject: RE: IP tunnel over a NAT (IP masq) possible ? Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Shih-Chin Yang > Subject: RE: IP tunnel over a NAT (IP masq) possible ? > Date: Fri, 16 Jul 1999 14:23:04 -0700 > ... > I am afraid that you would not be able setup a tunnel from a client behind a > NAT device. The problem is the source address of the tunneled packet would > be changed by the NAT device, but when client builds the authentication > header, it takes the source address into account already. Thus, on the other > end of the tunnel, the authentication would fail. Or, at the other end of the tunnel, before processing the packet, you use "UNNAT" to put back the original source IP address, if that is possible... We're actually looking at doing this (using the IP filter capability in BSD/OS), where we have a network behind a NAT box (a Pipeline), and the encrypted tunnel endpoint is behind the NAT box. It won't be pretty, but sometimes you don't have much choice. Sigh. -David Borman, dab@bsdi.com From owner-ipsec@lists.tislabs.com Fri Jul 16 16:39:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27795; Fri, 16 Jul 1999 16:39:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17081 Fri, 16 Jul 1999 18:03:30 -0400 (EDT) X-Authentication-Warning: paladium.cary.cw.net: sbrown owned process doing -bs Date: Fri, 16 Jul 1999 18:03:06 -0400 (EDT) From: Steven Brown X-Sender: sbrown@paladium.cary.cw.net To: Otel Florian-Daniel cc: linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Subject: Re: IP tunnel over a NAT (IP masq) possible ? In-Reply-To: <14223.33362.904306.427278@blomman18.ce.chalmers.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Otel, Can't tell you about all products, but many will not work with (many to one NAT), they have problems after the IP headers are changed. Usually the key excahnge works, then the device (whatever it is) will not pass the following packets. (If anyone knows different, please add your comments, I'm working on that right now), and in the mix is an assorement of NAT, Proxy and hardware devices. I know checkPoint Secure Remote will not work, and I've heard many incompatibility stories using AOL as transport, since they write a modified TCP/IP stack. Someone made a mention though, if you use a public routable IP adress space, and have the NAT proxy doing IP forwarding, and using encryption, not encapsulation, that may work. Sincerely Steve On Fri, 16 Jul 1999, Otel Florian-Daniel wrote: > > Hello everybody, > > > I have the following problem: I have a machine behind a NAT performing > one-to-many address translation (inside: Net 10. outside: only one IP > addr). What i would like to do is to set a IP tunnel from one of the > inside machines (the "client") to a remote machine (i.e. beyond NAT) > (the "server"). Such that after the tunnel setup the inside machine > appears to be virtually attached to the remote net. > > Requirements: > -As it is implied, I don't have administrative control over the NAT > (otherwise e.g. i could simply attach the client beyond it and use > `oridnary` IP tunneling) > -The tunnel is encrypted (overhead issues irrelevant for the time being) > -The tunnel is set on-demand, in a client-server fashion (e.g. tunneling > over a TCP connection). > -The operating system: Linux > > > Any ideas and suggestions are welcomed. > > Many thanks, > > Florian > > P.S: Maybe this were not the most appropriate forums were to ask. If > that is the case, appologies in advance. Any hint in this respect will > be appreciated. > Steven A. Brown, MBA., CCSA, CCSE, VPN/Firewall & Internet Security Engineer Cable&Wireless, 6400 Weston Pkwy, 3rd. FL Research Triangle Park, NC, 27513 Author:Implementing Virtual Private Networks, McGraw-Hill CoAuthor:CheckPoint Firewall-1, McGraw-Hill sbrown@cw.net, Steven.Brown@cwusa.com From owner-ipsec@lists.tislabs.com Fri Jul 16 17:00:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27991; Fri, 16 Jul 1999 17:00:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17194 Fri, 16 Jul 1999 18:35:26 -0400 (EDT) Message-ID: From: Shih-Chin Yang To: "'David Borman'" , "'otel@ce.chalmers.se'" Cc: "'ipsec@lists.tislabs.com'" , Shih-Chin Yang Subject: RE: IP tunnel over a NAT (IP masq) possible ? Date: Fri, 16 Jul 1999 15:35:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BECFDB.931DB45C" 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_01BECFDB.931DB45C Content-Type: text/plain > ---------- > From: David Borman[SMTP:dab@BSDI.COM] > Sent: Friday, July 16, 1999 5:04 PM > To: otel@ce.chalmers.se; syang@redcreek.com > Cc: ipsec@lists.tislabs.com > Subject: RE: IP tunnel over a NAT (IP masq) possible ? > > > From: Shih-Chin Yang > > Subject: RE: IP tunnel over a NAT (IP masq) possible ? > > Date: Fri, 16 Jul 1999 14:23:04 -0700 > > ... > > I am afraid that you would not be able setup a tunnel from a client > behind a > > NAT device. The problem is the source address of the tunneled packet > would > > be changed by the NAT device, but when client builds the authentication > > header, it takes the source address into account already. Thus, on the > other > > end of the tunnel, the authentication would fail. > > Or, at the other end of the tunnel, before processing the packet, > you use "UNNAT" to put back the original source IP address, if that > is possible... We're actually looking at doing this (using the IP filter > capability in BSD/OS), where we have a network behind a NAT box (a > Pipeline), > and the encrypted tunnel endpoint is behind the NAT box. It won't be > pretty, but sometimes you don't have much choice. Sigh. > It seems to me this approach needs to assume the mapping between the address given by NAT and the real client address must be fixed, and known beforehands at the other tunnel endpoint. But it might work if you are the only client that is going to initiate tunnel behind that NAT device. ------_=_NextPart_001_01BECFDB.931DB45C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IP tunnel over a NAT (IP masq) possible ?

    ----------
    From:   = David = Borman[SMTP:dab@BSDI.COM]
    Sent:   = Friday, July 16, 1999 5:04 = PM
    To: =     otel@ce.chalmers.se; syang@redcreek.com
    Cc: =     ipsec@lists.tislabs.com
    Subject: =        RE: IP tunnel over a NAT (IP masq) possible ?

    > From: Shih-Chin Yang = <syang@redcreek.com>
    > Subject: RE: IP tunnel over a = NAT (IP masq) possible ?
    > Date: Fri, 16 Jul 1999 14:23:04 = -0700
    > ...
    > I am afraid that you would not = be able setup a tunnel from a client behind a
    > NAT device. The problem is the = source address of the tunneled packet would
    > be changed by the NAT device, = but when client builds the authentication
    > header, it takes the source = address into account already. Thus, on the other
    > end of the tunnel, the = authentication would fail.

    Or, at the other end of the tunnel, = before processing the packet,
    you use "UNNAT" to put back = the original source IP address, if that
    is possible...  We're actually = looking at doing this (using the IP filter
    capability in BSD/OS), where we have = a network behind a NAT box (a Pipeline),
    and the encrypted tunnel endpoint is = behind the NAT box.  It won't be
    pretty, but sometimes you don't have = much choice.  Sigh.

    It seems to me this = approach needs to assume the mapping between the address given by NAT = and the real client address must be fixed, and known beforehands at the = other tunnel endpoint. But it might work if you are the only client = that is going to initiate tunnel behind that NAT device.

------_=_NextPart_001_01BECFDB.931DB45C-- From owner-ipsec@lists.tislabs.com Fri Jul 16 17:21:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA28149; Fri, 16 Jul 1999 17:21:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17245 Fri, 16 Jul 1999 19:06:33 -0400 (EDT) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Joel Odom cc: ipsec@lists.tislabs.com Message-ID: <862567B0.007FB24E.00@mwgate02.mw.3com.com> Date: Fri, 16 Jul 1999 18:13:06 -0500 Subject: Re: IPsec Aware Packet Sniffer Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You can get ipgrab at http;//www.borella.net/mike I added ESP, AH and IKE in March but just updated them recently, so fruther testing and reports would be welcome. -Mike Joel Odom on 07/16/99 08:23:45 AM Sent by: Joel Odom To: ipsec@lists.tislabs.com cc: (Mike Borella/MW/US/3Com) Subject: IPsec Aware Packet Sniffer Are there any packet sniffers out there that are IPsec aware in that they can identify and display ESP / AH header information and monitor IKE? It would be nice if manual keying could be used to even open and view ESP payload. -- Juggernautics, LLC Computer, Electrical & Mechanical Engineering http://www.juggernautics.com From owner-ipsec@lists.tislabs.com Fri Jul 16 17:54:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA28384; Fri, 16 Jul 1999 17:54:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17330 Fri, 16 Jul 1999 19:36:51 -0400 (EDT) Message-ID: <008701becfe5$24bbcb20$0606000a@sonicsys.com> Reply-To: "Niranjan Koduri" From: "Niranjan Koduri" Cc: References: Subject: Re: IP tunnel over a NAT (IP masq) possible ? Date: Fri, 16 Jul 1999 16:44:27 -0700 Organization: Sonic Systems Inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01BECFAA.77E77500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0084_01BECFAA.77E77500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IP tunnel over a NAT (IP masq) possible ?Check http://www.wolfenet.com/~jhardin/ip_masq_vpn.html ----- Original Message -----=20 From: Shih-Chin Yang=20 To: 'David Borman' ; 'otel@ce.chalmers.se'=20 Cc: 'ipsec@lists.tislabs.com' ; Shih-Chin Yang=20 Sent: Friday, July 16, 1999 3:35 PM Subject: RE: IP tunnel over a NAT (IP masq) possible ? ----------=20 From: David Borman[SMTP:dab@BSDI.COM]=20 Sent: Friday, July 16, 1999 5:04 PM=20 To: otel@ce.chalmers.se; syang@redcreek.com=20 Cc: ipsec@lists.tislabs.com=20 Subject: RE: IP tunnel over a NAT (IP masq) possible ?=20 > From: Shih-Chin Yang =20 > Subject: RE: IP tunnel over a NAT (IP masq) possible ?=20 > Date: Fri, 16 Jul 1999 14:23:04 -0700=20 > ...=20 > I am afraid that you would not be able setup a tunnel from a = client behind a=20 > NAT device. The problem is the source address of the tunneled = packet would=20 > be changed by the NAT device, but when client builds the = authentication=20 > header, it takes the source address into account already. Thus, on = the other=20 > end of the tunnel, the authentication would fail.=20 Or, at the other end of the tunnel, before processing the packet,=20 you use "UNNAT" to put back the original source IP address, if that=20 is possible... We're actually looking at doing this (using the IP = filter=20 capability in BSD/OS), where we have a network behind a NAT box (a = Pipeline),=20 and the encrypted tunnel endpoint is behind the NAT box. It won't = be=20 pretty, but sometimes you don't have much choice. Sigh.=20 It seems to me this approach needs to assume the mapping between the = address given by NAT and the real client address must be fixed, and = known beforehands at the other tunnel endpoint. But it might work if you = are the only client that is going to initiate tunnel behind that NAT = device. ------=_NextPart_000_0084_01BECFAA.77E77500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IP tunnel over a NAT (IP masq) possible ?
Check
----- Original Message -----
From:=20 Shih-Chin=20 Yang
Cc: 'ipsec@lists.tislabs.com' ; Shih-Chin Yang=20
Sent: Friday, July 16, 1999 = 3:35 PM
Subject: RE: IP tunnel over a = NAT (IP=20 masq) possible ?



    ---------- =
    From:   David Borman[SMTP:dab@BSDI.COM] =
    Sent:   Friday, July 16, 1999 5:04 PM =
    To: =    =20 otel@ce.chalmers.se; syang@redcreek.com =
    Cc:     = ipsec@lists.tislabs.com=20
    Subject:=20        RE:=20 IP tunnel over a NAT (IP masq) possible ?

    > From: Shih-Chin Yang <syang@redcreek.com> =
    > Subject: RE: IP tunnel over a NAT (IP = masq) possible=20 ?
    > Date: Fri, 16 Jul 1999 = 14:23:04=20 -0700
    > ... =
    > I am afraid that you would not be able = setup a tunnel=20 from a client behind a
    > = NAT device.=20 The problem is the source address of the tunneled packet = would=20
    > be changed by the NAT device, = but when=20 client builds the authentication
    >=20 header, it takes the source address into account already. Thus, on = the=20 other
    > end of the tunnel, = the=20 authentication would fail.

    Or, at the other end of the tunnel, = before=20 processing the packet,
    you = use "UNNAT" to=20 put back the original source IP address, if that
    is possible...  We're actually looking at doing this = (using the=20 IP filter
    capability in = BSD/OS), where we=20 have a network behind a NAT box (a Pipeline),
    and the encrypted tunnel endpoint is behind the NAT = box.  It=20 won't be
    pretty, but = sometimes you don't=20 have much choice.  Sigh.

    It seems to me this = approach needs=20 to assume the mapping between the address given by NAT and the real = client=20 address must be fixed, and known beforehands at the other tunnel = endpoint.=20 But it might work if you are the only client that is going to = initiate=20 tunnel behind that NAT = device.

------=_NextPart_000_0084_01BECFAA.77E77500-- From owner-ipsec@lists.tislabs.com Sat Jul 17 02:18:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA01132; Sat, 17 Jul 1999 02:18:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18656 Sat, 17 Jul 1999 03:40:23 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8BA@sothmxs06.entrust.com> From: Greg Carter To: "'ipsec@lists.tislabs.com'" Subject: FW: XAUTH? Date: Fri, 16 Jul 1999 11:34:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I sent this yesterday, doesn't seem to have made it to the list. -----Original Message----- From: Greg Carter Sent: Thursday, July 15, 1999 2:55 PM To: 'Stephane Beaulieu'; Andrew Krywaniuk; 'ipsec@lists.tislabs.com' Subject: RE: XAUTH? Hi, Stephane, Yes it makes it clear, however it is broken. Config Mode is defined as a two packet exchange, then you can delete state. Now I have to determine is this is an XAUTH config mode? or is it just a regular config mode?, if it's xauth then wait for some more and save state. This isn't at all consistent with other IKE exchange types. All IKE exchanges types currently have a defined packet sequence, xauth changes that to "config is two but if this bit is set in an attribute payload then what I really want to do is something completely different with four." If you are going to make XAUTH a 4 sequence exchange then why not define a new exchange type, since it really has nothing to do with config? Especially since it breaks any generic config mode implementations would expect the 3rd sequence to be a new Config mode. Thanks Bye. -----Original Message----- From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] Sent: Thursday, July 15, 1999 4:38 AM To: Andrew Krywaniuk; Greg Carter; 'ipsec@lists.tislabs.com' Subject: RE: XAUTH? Hi Greg, I guess there is some ambiguity. The text in the next rev. will be clarified. in section 3, the following text All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID. Will be changed to An extended authentication transaction is defined as a series ISAKMP-Config messages. All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config Identifier as well as the same ISAKMP Message ID and continue to chain the IV for all messages in the transaction. Does this clarify things? Stephane. <-----Original Message----- -----Original Message----- <> From: Greg Carter [mailto:greg.carter@entrust.com] <> Sent: Wednesday, July 14, 1999 2:09 PM <> To: 'ipsec@lists.tislabs.com' <> Subject: XAUTH? <> <> <> Hi, <> <> Config Mode states: <> <> "A "Configuration Transaction" is defined as two configuration <> exchanges, the first being either a Set or a Request and being either an Acknowledge or a Reply, respectively. <> <> ... <> Transactions are completed once the Reply or Acknowledge code is <> received." <> <> To me this means that the message ID is unique for the <> transaction, either a <> Set-Ack or Request-Reply pair. <> <> However XAUTH states: <> All ISAKMP-Config messages in an extended authentication <> transaction MUST contain the same ISAKMP-Config message ID. <> <> And gives examples where a Request-Reply is followed by a <> Set-Ack and is <> referred to as a "transaction". <> <> Are the message ID's unique for the Request-Reply and Set-Ack <> in XAUTH or <> are they the same? <> <> <> <> <> < From owner-ipsec@lists.tislabs.com Sat Jul 17 12:12:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11784; Sat, 17 Jul 1999 12:12:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19247 Sat, 17 Jul 1999 13:36:39 -0400 (EDT) Message-ID: <3790BF1F.DFB1F382@greendragon.com> Date: Sat, 17 Jul 1999 13:36:48 -0400 From: William Allen Simpson X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher References: <3.0.6.32.19990713132446.00805420@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Although I'm no longer a regular reader of IPSec list, I've been directed over here, as this affects the proposed AS that's been pending for a year. Here are the mandatory to implement ciphers I recommended 2-3 years ago: 1) DESX to replace DES. Even before Deep Crack, we thought DES was weak, and recommended it not be for long term use. After Deep Crack, it is just foolhardy. DESX is very easy for vendors to retrofit into their boxen. Ease of implementation wins in my book. 2) 3DES for stronger (financial) cryptography. It has been selected by the banking community, and thus a good selling point. The core is DES, which means it is easy to implement in existing code. See above. 3) CAST5-128. Speed. Memory. Key setup. Free. Wins in every category that I'd hope for. I'd like to see a non-DES in the toolkit. I'm just not confident that it has "enough" analysis for the "strongest" cipher. Blowfish is OK, but I'm not sure vendors have enough room for it in the product line. And there are memory and key setup issues. I think having 3 mandatory to implement ciphers gives a nice range of functionality, promotes interoperability, and provides an escape when one proves too weak (as it did with DES). Someday, there will be an AES selection. But, until then, keep the number of MANDATORY to implement a very small number. Rodney Thayer wrote: > > We've been talking about declaring a second mandatory to implement cipher, > or in some way declaring a new second cipher for IPsec. .... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Sat Jul 17 14:00:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12571; Sat, 17 Jul 1999 14:00:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19352 Sat, 17 Jul 1999 15:20:49 -0400 (EDT) Message-ID: <3790D72C.F82930F9@greendragon.com> Date: Sat, 17 Jul 1999 15:19:45 -0400 From: William Allen Simpson X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Schneier CC: ipsec@lists.tislabs.com Subject: Re: More on a second IPSec algorithm References: <4.1.19990715161920.00a04930@mail.visi.com> <4.1.19990716101655.00a1a480@mail.visi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems I'm missing some of the messages in this thread, or the thread was renamed too many times, but while I agree that Bruce is correct on a theoretic basis, there are a few practical reasons why having more than one "mandatory to implement" cipher is good: A) Some vendors are resistant to mandating 3DES because of speed. Perry and Phil and I pushed 3DES pretty hard 4 years ago, but lost the battle on the speed issue. DESX is virtually the same speed as DES. We didn't push DESX 4 years ago, as it had no analysis. Now, I think DESX is the obvious choice for a quick update. Easiest to implement, with no speed changes that a user (or marketer) might notice. B) Mandating that both DESX and 3DES are in every product allows the customer to choose the speed, finessing the vendor complaint. The core code is the same, so it is still easy to implement. C) Having more than one algorithm tests the selection machinery on a regular basis. This implementation issue is very important. Even when a product works the first time around, later changes can break the implementation. Exercise the code paths. D) Having more than one algorithm tests the operational configuration machinery. Again, operational issues are very important. Of course, this same consideration encourages the number of choices to be small, probably only 2 or 3. But, as time goes on, there will be changes, and that means we have to be prepared to configure them. It is a lot easier to change a policy data file than have a deployment flag day. E) Having more than one cipher available inhibits analysis. The cipher in use can be hidden, requiring more effort for finding and tracking important data. Heterogeneity(?) may make it impractical. This was a design feature of Photuris, and is still optional in IKE/ISAKMP. F) Having more than one cipher simply instills confidence, for users, the naive press, and overblown marketing. This is another reason for adding a non-DES cipher. It may not fix anything in and of itself, but the mere presence says "we've covered all the bases". I wish that the working group had followed our advice in 1995, and allowed both DES and 3DES to be Proposed Standard. Then, we wouldn't be in the quandary we are in today. Bruce Schneier wrote: > The NSA does not build encryption equipment with a hot-spare algorithm > in it. It makes no sense to do so. > The NSA still has multiple fielded algorithms. They just have more control over which are in use and where. We don't have that luxury in the Internet. Whenever I work on protocol design, I think implementation and operation are incredibly important! All the best intentions in the world are worthless without deployment. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec@lists.tislabs.com Sun Jul 18 13:33:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25389; Sun, 18 Jul 1999 13:33:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21404 Sun, 18 Jul 1999 15:00:58 -0400 (EDT) Message-Id: <3.0.6.32.19990718115638.008118f0@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sun, 18 Jul 1999 11:56:38 -0700 To: Dennis Glatting From: Rodney Thayer Subject: Re: your mail Cc: ipsec@lists.tislabs.com In-Reply-To: References: <4.1.19990715161920.00a04930@mail.visi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are people worried that 3DES is vulnerable to attacks other than brute force. At 10:13 PM 7/15/99 -0700, Dennis Glatting wrote: > > >On Thu, 15 Jul 1999, Bruce Schneier wrote: > >> This still makes no sense to me. There are so many things to >> worry about wrt an IPSec implementation, so many things that can >> compromise security if they are not done correctly, that making >> sure there is a backup to triple-DES seems like a collossal waste >> of time. It's like putting a mile-high stake in the ground and >> hoping the enemy runs right into it, instead of trying to build a >> wall. >> > >I am having trouble believing 3DES is going to broken anytime soon, >but then I am not a cryptographer and up on current events. Therefore, >I believe that a back-up cipher will be caught in regular maintenance >cycles and the whole thing a non-issue, but I've been wrong many times >before. :) > >I ask what is going on here folks? This whole 3DES thing seems like >FUD, which isn't typical IETF behaviour. What is it I don't know? > > > > > > From owner-ipsec@lists.tislabs.com Sun Jul 18 13:33:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25390; Sun, 18 Jul 1999 13:33:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21398 Sun, 18 Jul 1999 15:00:50 -0400 (EDT) Message-Id: <3.0.6.32.19990718115357.0089cc30@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sun, 18 Jul 1999 11:53:57 -0700 To: Joern Sierwald From: Rodney Thayer Subject: Re: starting on asking THE QUESTION Cc: ipsec@lists.tislabs.com In-Reply-To: <3.0.5.32.19990715181005.00c4c4e0@smtp.datafellows.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA21395 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We'v volunteered to work with Jeff Schiller to come up with appropriate draftage on othe DOI values and related parameters. Just throwing DOI numbers over the wall is not productive. We're still all dealing with the initial whimsical set -- how many people implement HMAC-TIGER for example? At 06:10 PM 7/15/99 +0300, you wrote: >At 14:55 15.7.1999 +0200, Robert wrote: >> >> - DES in CBC mode [MD97] >> - HMAC with MD5 [MG97a] >> - HMAC with SHA-1 [MG97b] >> - NULL Authentication algorithm >> - NULL Encryption algorithm >> > >Rodney wrote: >> I think we need to have a second cipher to use, in the event 3DES is >> found to be unsafe. This is not a reflection on the quality of 3DES. >> In my opinion there are genuine legitimate concerns about the use of >> DES, and there are definitely people out there in the commercial world >> who wish to phase out it's use. > >There is no actual need to do anything. >Everybody has implemented 3DES. >We do have a second cipher to use, and even a third one, >CAST-128 and blowfish. If people in the commercial world wish >to use something else than DES, they can. > >If we add a "SHOULD implement CAST-128", does it matter? > >While we're at it, I'm very annoyed that there still are no >values for using DESX in ISAKMP and IPsec. Could >Mr. Tero "I have more ciphers than you have bits in your key" Kivinen >please start the allocation of values to negotiate DESX, MARS, >RC6, Rijndael, TwoFish and skipjack? Both Phase I and II. >There are so many open slots, it wouldn't matter if we allocate >numbers for all AES candidates. > >Jörn > > From owner-ipsec@lists.tislabs.com Sun Jul 18 13:40:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25465; Sun, 18 Jul 1999 13:40:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21381 Sun, 18 Jul 1999 14:55:08 -0400 (EDT) Date: Sun, 18 Jul 1999 14:54:49 -0400 Message-Id: <199907181854.OAA14649@brill.shiva.com> From: John Shriver To: wsimpson@greendragon.com CC: schneier@counterpane.com, ipsec@lists.tislabs.com In-reply-to: <3790D72C.F82930F9@greendragon.com> (message from William Allen Simpson on Sat, 17 Jul 1999 15:19:45 -0400) Subject: Re: More on a second IPSec algorithm Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill, your discussion is assuming people are doing cryptography in software. (Well, you're not alone in that attitude, for sure.) Lots of products do cryptography in hardware. Can the average chip that can do DES and 3DES in hardware also do DESX? (This is also the issue with mandating any of the AES candidates at this time. Are any available in hardware?) No question that all the IKE negotiation needs more exercising. The spec isn't all that explicit about such things, and the implementations often choose different responses. It's not a true negotiation like PPP, and even PPP can deadlock. From owner-ipsec@lists.tislabs.com Mon Jul 19 05:18:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA01356; Mon, 19 Jul 1999 05:18:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA23026 Mon, 19 Jul 1999 06:32:07 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCA8662F@new-exc1.ctron.com> From: "Waters, Stephen" To: Eric_Guerrino@LNOTES5.bankofny.com Cc: ietf-pkix@imc.org, ipsec@lists.tislabs.com, "Holland, Gary" , "Bassett, John Robert" Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt)) Date: Mon, 19 Jul 1999 11:31:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Eric, Some very useful comments here, thanks. From an IPSEC VPN point of view (my current concern), I would say that it looks like password/pin-protected certificates AND some secondary user-based authentication need to be implemented. Since it is easy to imagine a password-protected device/certificate being cracked off-line (i.e. in a dark room somewhere) before an attack is mounted on the VPN server, then secondary authentication becomes necessary/essential? Some examples: 1) My PC has a certificate loaded that is not password protected. The PC, if stolen, could be used to authenticate itself against a VPN server. This is clearly a problem that must be fixed without relying on notification of the theft to fix it. 2) My PC has a password-protected certificate. Each time I attempt to connect to the VPN server, the VPN application prompts the user for the password to unlock the certificate. My concern here is that, if the PC is stolen, then the password could be cracked by trial-and-error without any actual connection attempts (warnings) reaching the VPN server. 3) My PC uses a Smartcard with a pin-protected private-key/certificate. Again, if the Smartcard is stolen, how long would it take to crack the pin number off-line and use the authentication information on a different PC with a VPN client kit installed. This would require the attacker to know the address and security requirements of the VPN servers willing to accept the certificate. If the PC and Smartcard are stolen together, it is probably worse than case 2). 4) As for 3), but the Smartcard uses biometrics - thumb-print, signature, eye-scan. I guess this is much safer - provided you don't get gory! 5) My PC uses one of the approaches above, but once authentication via the certificate is complete, enforces a secondary authentication. This authentication is under the control of the server, and so can't be cracked off-line. If an attack is mounted, the VPN server will receive 'warnings' in the form of authentication failures (I hope). The authentication information provided in this secondary phase MUST NOT be part of the VPN client's automatic function. The advantages of 5) seem to be: 1) two-way authentication between the devices based on certificates. 2) secondary, independent authentication that can't be cracked 'off-line'. 3) an 'way out' for the non-repudiation legality. 4) continued use of existing remote access authentication methods. I have not covered the case where a stolen PC/certificate is used to spoof a VPN server. Mainly because I can't think of a solution! Steve. -----Original Message----- From: Eric_Guerrino@LNOTES5.bankofny.com [mailto:Eric_Guerrino@LNOTES5.bankofny.com] Sent: Friday, July 16, 1999 6:28 PM To: Stephen Kent Cc: 'ietf-pkix@imc.org' Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) There are legal issues to be resolved regarding limitations of liability and responsibilities of issuers, certificate authorities, subscribers, and relying parties. There are legal issues to be resolved regarding digital signatures. Last time I checked, about thirty states had enacted or were in the process of enacting digital signature laws. The federal government has a digital signature law pending. I was not basing my comment solely on legal issues regarding authentication of users. What is the limitation of liability of an issuer when a third party effects a transaction based on a certificate the issuer has issued, after the subscriber repudiates the transaction? What if all three parties are in three different states or, worse, countries? Whose law applies? What happens when a CA closes shop? Are the certificates valid or invalid? Who will relying parties consult if they need to verify that a certificate issued by the defunct CA was valid at a previous point in time for a disputed transaction? For how many years must a CA keep expired certificates? What responsibility does a CA have for providing for cessation of activities? I initially was led to believe PKI supported non-repudiation because this was one of the claims being made for it by its proponents. It was only after I started examining it more closely that I realized the claims were unsubstantiated. As long as one party can reasonably deny a fact, it is up to the other party to prove otherwise. If I receive a transaction and act on it, and the initiator subsequently denies the transaction, what do I have to authenticate the user and the data? I can't claim in court that I received and acted on a message because my server accepted it since it came with a valid certificate, and because the signature and the message digest were valid, based on the certificate. I need to to be able to produce the original message, the digest, the signature, and the certificate, and be able to show that the validity checks all passed. I also need to know what algoritms were used. I need logs and audit records to prove the transaction came in. And I need all this possibly months or years later. But, most of all, I need to be able to demonstrate that I based my decision on reasonable assurance that the originator was who they claimed to be. Which brings me to userids and passwords, and why I must use an application password even if I have issued a certificate. Passwords provide reasonable assurance to me that the originator is who they say they are; as long as the password is kept securely. Dynamic passwords (two-factor authentication) provide even stronger assurance that this is so. What do I, as a verifier, have when a certificate is used? I have no reasonable assurance about the originator because I have not done anything to authenticate them. I don't know how secure the originator's PC is. I don't know if they have told the browser to cache the private key password, nor the strength of it. I don't know if their PC will lock itself after a certain amount of inactivity. I don't know who has access to the PC. It is not difficult to copy certificate files from one system to another. If the password is not strong enough, it probably would not be too difficult to crack it. The certificate would be more reliable, for user authentication purposes, if I, as an issuer, could control usage of the private key and user authentication, or, minimally, if It is stored on some external device. At least this provides two-factor authentication. I can't control how software vendors utilize certificates in their browser products, but I am at their mercy if I allow my application to run from their browser. If risk assessment requires me to use password security anyway, I need to be able to show significant incremental value added by certificates, given that the certifcate process places a large administrative burden around all this. Granted, all this is less confusing if an originator is executing a transaction with the issuer of the cetificate, because the issuer could control the user authentication process. But it becomes more complex when the certificate is used to execute a transaction with a third party. How can a bank verify a certificate and, more importantly, vouch for a transaction, if it can't be reasonably assured the customer is who they claim to be? All it has is a request for validation from the third party (merchant) and a message. I am sure this will all be resolved over time, but at this point, I don't feel we are close enough. eric Stephen Kent on 07/16/99 03:04:48 AM To: Eric Guerrino cc: "'ietf-pkix@imc.org'" Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) Date: Fri, 16 Jul 1999 03:04:48 -0400 To: Eric_Guerrino@LNOTES5 From: Stephen Kent Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) Cc: "'ietf-pkix@imc.org'" Eric, >I couldn't agree with you more. However, regarding acceptance of PKI >technologies by large organizations, I believe there are many reasons >organizations are not adopting PKI readily besides ease-of-use issues. Nor >does it have anything to do with ASN.1 vs XML. This issue can't be resolved >with technology solutions because their lack of acceptance is not due >solely to technical problems. > >The problems with PKI are numerous, from a corporate perspective, and many >large organizations have not moved initial PKI efforts beyond the >pilot/evaluation stage. Problems include outstanding legal liability >issues, the lack of fraud protection laws, the need to address cessation of >activites of a CA and/or a registry, the inability to bind a certificate >distinctly to a user (software certificates identify systems, not users), >the inability of an issuer to associate a security policy with the >certificate (issuers need to be able to dictate when to allow caching of >passwords,as well as things like session timeout and password construction >rules), undefined procedures and products to support records management and >archiving, as well as that non-repudiation claims for current PKI products >may have no legal basis. Then there are all the technical problems. I agree that these are precieved problems that hinder PKI deployment, but I also think that many of these are red herrings. If I use certificates to authenticate users, in lieu of passwords, why are there any new legal issues? Part of the problem is that people have been led to believe that a PKI must support non-repudiation, which generates a large number of valid, legal concerns. However, use of a PKI to support SSL, IPsec, and S/MIME (at least on an intranet basis) does not raise such issues, yet promises to improve security and to make life easier for users. I disagree with your statement that a certificate in software binds a system, vs. a user. Yes, smart cards are preferable, but if the choice is between a password and a certificate (and private key) with software cryptography, I see no reason not to adopt the latter, and I certainly see no reason to declare that the latter is not a user (vs. system) authentication mechanism. Finally, why do you say that an issuer cann associate a security policy with a certificate? We have the syntactic means to do so as part of the standard. Do you mean that we don't have appplications that pay attention to the policy extension? Steve From owner-ipsec@lists.tislabs.com Mon Jul 19 05:42:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA01648; Mon, 19 Jul 1999 05:42:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23101 Mon, 19 Jul 1999 07:17:17 -0400 (EDT) From: "Pekka Turunen" To: , , , Subject: VS: IP tunnel over a NAT (IP masq) possible ? Date: Mon, 19 Jul 1999 14:18:55 +0300 Message-ID: <000a01bed1d8$7d31a820$390964c2@baudia.fi> 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <14223.33362.904306.427278@blomman18.ce.chalmers.se> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hello everybody, > > > I have the following problem: I have a machine behind a NAT performing > one-to-many address translation (inside: Net 10. outside: only one IP > addr). What i would like to do is to set a IP tunnel from one of the > inside machines (the "client") to a remote machine (i.e. beyond NAT) > (the "server"). Such that after the tunnel setup the inside machine > appears to be virtually attached to the remote net. > > Any ideas and suggestions are welcomed. > > Many thanks, > > Florian Hello Florian! We have studied the NAT -problem and developed a solution for it. We have applied a patent for this solution, which is called FireSeal. With FireSeal the firewall isn't required to decrypt the packets. Nevertheless the traffic can be fully controlled - dynamically. The FireSeal system consists of two main components. The Client component works as a part of the IPSec - or any other security application, inside the company network boundaries, whereas the server component is attached to the firewall. The process of controlling secured network traffic can be divided into three steps: 1. The client part of FireSeal sends parameters concerning the connection to the firewall (IP address, protocol used etc.). 2. The firewall decides if the connection is allowed (firewalls normal control mechanisms are used). If the connection is accepted then firewall sends to the client the needed parameters for the connection (i.e. the NAT transform parameters and a SPI number, which identifies the approved connection). 3. The client does the NAT transformation and sends the data. The data passes through the firewall if the SPI matches the ones in firewall. I.e. the firewall can use its normal policies to decide, whether or not to let the traffic pass through. In regard to applications needing secure communications, FireSeal is completely invisible. Yours sincerely, Pekka Turunen NetSeal Technologies - Complete Network Security Pekka Turunen pekka.turunen@netseal.com www.netseal.com phone +358-9-4375-428 From owner-ipsec@lists.tislabs.com Mon Jul 19 07:01:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03098; Mon, 19 Jul 1999 07:01:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23324 Mon, 19 Jul 1999 08:29:59 -0400 (EDT) Message-ID: <002f01becfc9$21620280$1400010a@seifried.org> Reply-To: "Kurt Seifried" From: "Kurt Seifried" To: , , , References: <14223.33362.904306.427278@blomman18.ce.chalmers.se> Subject: Re: linux-ipsec: IP tunnel over a NAT (IP masq) possible ? Date: Fri, 16 Jul 1999 14:23:56 -0600 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.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hello everybody, > > > I have the following problem: I have a machine behind a NAT performing [snipsnip] > -The operating system: Linux Use manual keying, should do the trick. To do auto keying the pluto's would need to talk to each other, you could forward port 500 in, but as you said you do not control the NAT box. As for automagically bringing the link up as needed (ala diald I guess you are thinking) no problem with leaving it up, no packets moving means no realy resource usage. At home I have a K5/100 running Email, Squid, IPMasq, IPSec, Samba, DNS, FTP, etc, no problems if you set it up right and tune the various things well. If you wanna be paranoid, setup a manually keyed tunnel from a to b, then using that you can setup an auto keyed tunnel (since they can talk to each other), although that would result in a LOT of overhead. > > Any ideas and suggestions are welcomed. > > Many thanks, > > Florian > > P.S: Maybe this were not the most appropriate forums were to ask. If > that is the case, appologies in advance. Any hint in this respect will > be appreciated. I think this is entirely the right forum since I;m sure other people have wondered this. - -Kurt Seifried, MCP+I, MCSE https://www.seifried.org/kurt/ Linux Administrator's Security Guide https://www.seifried.org/lasg/ -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.0.2 iQA/AwUBN4+U2Ib9cm7tpZo3EQJUrwCeKpDK6QkMHSOLYlbCPdp5F1qTwukAoPi7 7+plQZVuQuKz3sI7qyRCJFDR =3Prj -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jul 19 07:02:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03281; Mon, 19 Jul 1999 07:02:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23359 Mon, 19 Jul 1999 08:30:59 -0400 (EDT) To: "Mike Borella" cc: ipsec@lists.tislabs.com In-reply-to: Mike_Borella's message of Fri, 16 Jul 1999 18:13:06 EST. <862567B0.007FB24E.00@mwgate02.mw.3com.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPsec Aware Packet Sniffer From: itojun@iijlab.net Date: Sat, 17 Jul 1999 13:43:56 +0900 Message-ID: <15761.932186636@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >You can get ipgrab at http;//www.borella.net/mike >I added ESP, AH and IKE in March but just updated >them recently, so fruther testing and reports would >be welcome. KAME (ftp.kame.net) includes ESP/AH/IKE support in tcpdump, as well as ESP decoding in limited cases (you need to supply encryption key and algorithms on the command line) To what extent do you decode IKE? itojun From owner-ipsec@lists.tislabs.com Mon Jul 19 07:02:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03289; Mon, 19 Jul 1999 07:02:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23323 Mon, 19 Jul 1999 08:29:54 -0400 (EDT) Date: Fri, 16 Jul 1999 17:15:36 -0700 (PDT) From: "John D. Hardin" X-Sender: jhardin@gypsy.rubyriver.com To: Otel Florian-Daniel cc: linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Subject: Re: linux-ipsec: IP tunnel over a NAT (IP masq) possible ? In-Reply-To: <14223.33362.904306.427278@blomman18.ce.chalmers.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 16 Jul 1999, Otel Florian-Daniel wrote: > I have the following problem: I have a machine behind a NAT performing > one-to-many address translation (inside: Net 10. outside: only one IP > addr). What i would like to do is to set a IP tunnel from one of the > inside machines (the "client") to a remote machine (i.e. beyond NAT) > (the "server"). Such that after the tunnel setup the inside machine > appears to be virtually attached to the remote net. > > Requirements: > -As it is implied, I don't have administrative control over the NAT > (otherwise e.g. i could simply attach the client beyond it and use > `oridnary` IP tunneling) > -The tunnel is encrypted (overhead issues irrelevant for the time being) > -The tunnel is set on-demand, in a client-server fashion (e.g. tunneling > over a TCP connection). > -The operating system: Linux Take a look at ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html It may be what you want.. -- John Hardin KA7OHZ jhardin@wolfenet.com pgpk -a finger://gonzo.wolfenet.com/jhardin PGP key ID: 0x41EA94F5 PGP key fingerprint: A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76 ----------------------------------------------------------------------- Efficiency can magnify good, but it magnifies evil just as well. So, we should not be surprised to find that modern electronic communication magnifies stupidity as *efficiently* as it magnifies intelligence. -- Robert A. Matern ----------------------------------------------------------------------- 55 days until 9/9/99 From owner-ipsec@lists.tislabs.com Mon Jul 19 07:04:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03332; Mon, 19 Jul 1999 07:04:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23355 Mon, 19 Jul 1999 08:30:53 -0400 (EDT) To: "Aaron Griggs" cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com In-reply-to: agriggs's message of Fri, 02 Jul 1999 13:29:49 -0400. <035301bec4b0$7d2cd190$634cf526@east.isi.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Mon, 19 Jul 1999 20:31:12 +0900 Message-ID: <17191.932383872@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>Source address (whether it is ip6_src or home address option) >>is still very important. When you negotiate the key >>with the peer, IKE runs between (src, dst) pair. >Couldn't the source just be selected by the sender? For multiple address on >an interface, the best address is selected. My statements above handles >specifying a source for the SA. Since I am not implementing IKE, I might be >missing something. I may have replied this one, so ignore it if it is a duplicate. IKE must be run over src-dst pair which is to be used by IPsec. If IPsec needs a SA between (src home addr, dst), IKE must be run over (src home addr, dst) pair. This causes nasty bootstrap problem, like: - mobile node wishes to send tcp packet with (src home addr, dst) in the header - SA is looked up between (src home addr, dst) - since there's no SA, IKE daemon is invoked for new key - IKE daemon tries to send udp port 500 packet over (src home addr, dst) - infinite loop I've talked with Dave at Oslo IETF, about how mobile-ipv6 packet must be processed on inbound and outbound case, with regard to ipsec. He will be sending addition to the draft onto the list. itojun From owner-ipsec@lists.tislabs.com Mon Jul 19 07:11:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03467; Mon, 19 Jul 1999 07:11:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23440 Mon, 19 Jul 1999 08:48:44 -0400 (EDT) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: "Pekka Turunen" cc: otel@ce.chalmers.se, linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Message-ID: <862567B3.0047117C.00@mwgate02.mw.3com.com> Date: Mon, 19 Jul 1999 07:54:31 -0500 Subject: Re: VS: IP tunnel over a NAT (IP masq) possible ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is sounding an awful lot like RSIP (realm specific IP). Take a look at the following internet drafts: draft-ietf-nat-rsip-framework-01.txt draft-ietf-nat-rsip-protocol-01.txt draft-ietf-nat-rsip-ipsec-00.txt -Mike "Pekka Turunen" on 07/19/99 06:18:55 AM Sent by: "Pekka Turunen" To: otel@ce.chalmers.se, linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net cc: (Mike Borella/MW/US/3Com) Subject: VS: IP tunnel over a NAT (IP masq) possible ? > Hello everybody, > > > I have the following problem: I have a machine behind a NAT performing > one-to-many address translation (inside: Net 10. outside: only one IP > addr). What i would like to do is to set a IP tunnel from one of the > inside machines (the "client") to a remote machine (i.e. beyond NAT) > (the "server"). Such that after the tunnel setup the inside machine > appears to be virtually attached to the remote net. > > Any ideas and suggestions are welcomed. > > Many thanks, > > Florian Hello Florian! We have studied the NAT -problem and developed a solution for it. We have applied a patent for this solution, which is called FireSeal. With FireSeal the firewall isn't required to decrypt the packets. Nevertheless the traffic can be fully controlled - dynamically. The FireSeal system consists of two main components. The Client component works as a part of the IPSec - or any other security application, inside the company network boundaries, whereas the server component is attached to the firewall. The process of controlling secured network traffic can be divided into three steps: 1. The client part of FireSeal sends parameters concerning the connection to the firewall (IP address, protocol used etc.). 2. The firewall decides if the connection is allowed (firewalls normal control mechanisms are used). If the connection is accepted then firewall sends to the client the needed parameters for the connection (i.e. the NAT transform parameters and a SPI number, which identifies the approved connection). 3. The client does the NAT transformation and sends the data. The data passes through the firewall if the SPI matches the ones in firewall. I.e. the firewall can use its normal policies to decide, whether or not to let the traffic pass through. In regard to applications needing secure communications, FireSeal is completely invisible. Yours sincerely, Pekka Turunen NetSeal Technologies - Complete Network Security Pekka Turunen pekka.turunen@netseal.com www.netseal.com phone +358-9-4375-428 From owner-ipsec@lists.tislabs.com Mon Jul 19 07:57:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04687; Mon, 19 Jul 1999 07:57:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23635 Mon, 19 Jul 1999 09:24:48 -0400 (EDT) From: Otel Florian-Daniel Date: Mon, 19 Jul 1999 15:25:01 +0200 (MET DST) To: "Pekka Turunen" Cc: , Subject: Re: VS: IP tunnel over a NAT (IP masq) possible ? In-Reply-To: <000a01bed1d8$7d31a820$390964c2@baudia.fi> References: <14223.33362.904306.427278@blomman18.ce.chalmers.se> <000a01bed1d8$7d31a820$390964c2@baudia.fi> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14227.9500.546784.23745@blomman18.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hello Florian! > We have studied the NAT -problem and developed a solution for it. We have > applied a patent for this solution, which is called FireSeal. With FireSeal > the firewall isn't required to decrypt the packets. Nevertheless the > traffic can be fully controlled - dynamically. > The FireSeal system consists of two main components. The Client component > works as a part of the IPSec - or any other security application, inside the > company network boundaries, whereas the server component is attached to the > firewall. The process of controlling secured network traffic can be divided > into three steps: [.....] This sounds great but has one fatal flaw: As you read my initial posting i do _not_ have any control over the NAT (firewall). For my purposes it's just a black box that does IP masq. Nothing more. So everything sounds great, but it just doesn't work for my case. > Yours sincerely, Pekka Turunen Thanks anyway, Florian P.S: Right now I'm trying to get PPP over SSH running even though I don't particullary enjoy the idea: Imagine i do it on a laptop, i move somewhere when I use PPP for dialup. I will end up with something like SSH (for logging in the servers) over PPP (IP route) over SSH (the tunnel) over PPP (the local dialup). No comment here. Sick as it sounds, as soon as I will manage PPP over SSH I will look into IPsec realated mechanisms to do that and cut some overhead. Thanks to all how sent the VPN-minihowto URL. From owner-ipsec@lists.tislabs.com Mon Jul 19 09:31:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06095; Mon, 19 Jul 1999 09:31:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23984 Mon, 19 Jul 1999 10:48:00 -0400 (EDT) Date: Mon, 19 Jul 1999 10:48:07 -0400 Message-Id: <199907191448.KAA17551@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rodney@ssh.fi Cc: ipsec@lists.tislabs.com Subject: Re: new second mandatory IPsec cipher References: <3.0.6.32.19990713132446.00805420@127.0.0.1> <378B7F3F.9200CC2D@sympatico.ca> <3.0.6.32.19990714094912.00897100@127.0.0.1> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Rodney" == Rodney Thayer writes: Rodney> At 06:02 PM 7/13/99 +0000, Sandy Harris wrote: Rodney> After you consider all the heavy lifting required for Rodney> IPsec/IKE, I don't think Blowfish setup time is really an Rodney> issue. I also don't buy the "it takes a lot of memory per Rodney> context" argument, myself, but there are memory-challenged Rodney> implementations where this is an issue. Expanding on what Steve Bellovin already said: if you take a system with a crypto accelerator, as opposed to one that does the whole job in software, the argument "memory is cheap" is no longer valid. The issue isn't so much the price of the memory -- though that's often SRAM which is neither as cheap nor nearly as dense as DRAM. The bigger issue is that accelerator ASICs have severe limits on the amount of keying material they will keep on-board. For example, the chip I'm currently using keeps keying material in a "context" which is identified by an 11 bit number. It takes two per IPsec connection. So if you have more than 1000 SA sets, you have to treat the on-board context as a cache and page the keying material in from host memory on a miss. In the case of Blowfish, the cost of such a miss would be vastly LARGER than the cost of encrypting a typical packet, so the throughput penalty would be significant. In the case of the AES algorithms, agility was an explicit requirement. Similarly, the other alternatives that were mentioned seem to do a reasonable job, either with low key setup time or with modest expanded key schedule sizes. So I would rule out Blowfish. I'd also rule out IDEA because of patent issues. An AES finalist would be a good choice, provided it's one of the ones that are unconditionally free of intellectual property issues. (Contrast MARS, which will apparently be restricted unless it wins the AES competition.) paul From owner-ipsec@lists.tislabs.com Mon Jul 19 09:56:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06504; Mon, 19 Jul 1999 09:56:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24133 Mon, 19 Jul 1999 11:14:22 -0400 (EDT) Date: Mon, 19 Jul 1999 11:14:34 -0400 Message-Id: <199907191514.LAA17567@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jas@shiva.com Cc: wsimpson@greendragon.com, ipsec@lists.tislabs.com Subject: Re: More on a second IPSec algorithm References: <3790D72C.F82930F9@greendragon.com> <199907181854.OAA14649@brill.shiva.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "John" == John Shriver writes: John> Bill, your discussion is assuming people are doing cryptography John> in software. (Well, you're not alone in that attitude, for John> sure.) Lots of products do cryptography in hardware. Can the John> average chip that can do DES and 3DES in hardware also do DESX? No, but if you want to move away from the status quo there's not much you can do about this. Chips I've seen support either just DES, or DES and 3DES, or DES, 3DES, RC4. RC4 hasn't been mentioned in this entire discussion; the fact that it's a stream cipher certainly explains that, and there may be intellectual property issues as well. So it seems that any required support for a block cipher other than DES or 3DES means new hardware would be needed. As a somewhat mitigating factor, most other ciphers are cheaper in software, so the pain of doing without hardware assist is not quite as extreme. That's not to say I'm happy about it, admittedly. paul From owner-ipsec@lists.tislabs.com Mon Jul 19 10:19:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06934; Mon, 19 Jul 1999 10:19:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24196 Mon, 19 Jul 1999 11:31:11 -0400 (EDT) Date: Mon, 19 Jul 1999 11:30:51 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: starting on asking THE QUESTION In-Reply-To: <3.0.5.32.19990715181005.00c4c4e0@smtp.datafellows.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lists.tislabs.com id LAA24193 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Yes, slightly old mail -- I've been out of town.) On Thu, 15 Jul 1999, Joern Sierwald wrote: > There is no actual need to do anything. > Everybody has implemented 3DES. > We do have a second cipher to use, and even a third one, > CAST-128 and blowfish. If people in the commercial world wish > to use something else than DES, they can. > If we add a "SHOULD implement CAST-128", does it matter? "SHOULD", probably not. "MUST", yes, it could matter. *Not* everybody has implemented 3DES, at least not in readily-available forms. We still get occasional complaints about FreeS/WAN not supporting 1DES, from people who are trying to make FreeS/WAN talk to existing commercial boxes which don't speak anything else. Sometimes there are 3DES upgrades for said boxes, but only at higher cost or with availability problems. Sometimes not. Which points out that the issue is interoperability. Why have standards at all, if people are free to use whatever they wish? The answer is, they aren't. The reason to add another "MUST" algorithm would be to (help) ensure that *everybody* implements it, so you can *depend* on being able to use it. Some users have control over all the equipment they use, and so can choose systems that support the algorithms they want (provided that such systems exist!). Many are not so fortunate. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Mon Jul 19 12:23:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09228; Mon, 19 Jul 1999 12:23:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24761 Mon, 19 Jul 1999 13:49:14 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC124DE@exchange> From: Stephane Beaulieu To: Tero Kivinen , Stephane Beaulieu Cc: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: Timeout problems Date: Mon, 19 Jul 1999 13:51:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is no spi / protocol to be used in a delete. You can't send a delete for the Config-Mode exchange itself. My impression was the Joern was sending a delete for the ISAKMP SA if Ike-Cfg was timing out. What I was trying to get accross was that if an Ike-Cfg transaction is taking a long time (perhaps your gw is going to a DHCP server), then you should increase your timeouts accordingly. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Thursday, July 15, 1999 11:21 AM > To: Stephane Beaulieu > Cc: 'Joern Sierwald'; ipsec@lists.tislabs.com > Subject: RE: Timeout problems > > > Stephane Beaulieu writes: > > The delete payload should work; assuming you really want to > do this. If you > > tell the other guy that you've deleted your phase1 SA, then > he should stop > > sending you ISAKMP messages for that SA. However, I > believe that your best > > option is to increase you retry counts / times. > > What is the spi and protocol of the configuration mode exchange? To > fill in delete payload you need spi and protocol, and configuration > mode does not have them. I think it is overkill to kill the whole > ISAKMP SA in that case. > From owner-ipsec@lists.tislabs.com Mon Jul 19 12:23:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09237; Mon, 19 Jul 1999 12:23:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24679 Mon, 19 Jul 1999 13:25:09 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: "Pekka Turunen" Cc: otel@ce.chalmers.se, linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Subject: Re: VS: IP tunnel over a NAT (IP masq) possible ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jul 1999 13:25:11 -0400 From: "Steven M. Bellovin" Message-Id: <19990719172516.64BA941F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <000a01bed1d8$7d31a820$390964c2@baudia.fi>, "Pekka Turunen" writes: > > We have studied the NAT -problem and developed a solution for it. We have > applied a patent for this solution, which is called FireSeal. With FireSeal > the firewall isn't required to decrypt the packets. Nevertheless the > traffic can be fully controlled - dynamically. > > The FireSeal system consists of two main components. The Client component > works as a part of the IPSec - or any other security application, inside the > company network boundaries, whereas the server component is attached to the > firewall. The process of controlling secured network traffic can be divided > into three steps: > > 1. The client part of FireSeal sends parameters concerning the connection to > the firewall (IP address, protocol used etc.). > > 2. The firewall decides if the connection is allowed (firewalls normal > control mechanisms are used). If the connection is accepted then firewall > sends to the client the needed parameters for the connection (i.e. the NAT > transform parameters and a SPI number, which identifies the approved > connection). > > 3. The client does the NAT transformation and sends the data. The data > passes through the firewall if the SPI matches the ones in firewall. > > I.e. the firewall can use its normal policies to decide, whether or not to > let the traffic pass through. In regard to applications needing secure > communications, FireSeal is completely invisible. Except, of course, that the firewall can't see into the packet to see if the client is really abiding by the policy. For that matter, it can't see if the remote host is really responding to client requests, or if it's probing other ports on that host, all under the cover of that SPI. From owner-ipsec@lists.tislabs.com Mon Jul 19 15:41:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14298; Mon, 19 Jul 1999 15:41:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25571 Mon, 19 Jul 1999 17:03:35 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DCA8662F@new-exc1.ctron.com> Date: Mon, 19 Jul 1999 17:02:23 -0400 To: "Waters, Stephen" From: Stephen Kent Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt)) Cc: Eric_Guerrino@LNOTES5.bankofny.com, ietf-pkix@imc.org, ipsec@lists.tislabs.com, "Holland, Gary" , "Bassett, John Robert" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, >Some very useful comments here, thanks. From an IPSEC VPN point of view (my >current concern), I would say that it looks like password/pin-protected >certificates AND some secondary user-based authentication need to be >implemented. > >Since it is easy to imagine a password-protected device/certificate being >cracked off-line (i.e. in a dark room somewhere) before an attack is mounted >on the VPN server, then secondary authentication becomes >necessary/essential? > >Some examples: > >1) My PC has a certificate loaded that is not password protected. The PC, if >stolen, could be used to authenticate itself against a VPN server. This is >clearly a problem that must be fixed without relying on notification of the >theft to fix it. Presumably you mean the private key is not password protected, not that the certificate is not. This would be a poor design, so I'm not sure it's relevant to the discussion. >2) My PC has a password-protected certificate. Each time I attempt to >connect to the VPN server, the VPN application prompts the user for the >password to unlock the certificate. My concern here is that, if the PC is >stolen, then the password could be cracked by trial-and-error without any >actual connection attempts (warnings) reaching the VPN server. True, unless one uses the Arcot approach to protecting private keys. (See their paper in the 1999 IEEE Security and Privacy Symposium proceedings. I don't necessarily endorse the technique by mentioning it here, but point it out for completeness.) >3) My PC uses a Smartcard with a pin-protected private-key/certificate. >Again, if the Smartcard is stolen, how long would it take to crack the pin >number off-line and use the authentication information on a different PC >with a VPN client kit installed. This would require the attacker to know the >address and security requirements of the VPN servers willing to accept the >certificate. If the PC and Smartcard are stolen together, it is probably >worse than case 2). I think that one should assume that whoever steals the smart card has collateral intelligence about where to use it, unless it just happens to be in your wallet and the goal of the theft is the credit cards and cash. In that latter case, the theft of the smart card is probably not a security problem so much as it is an inconvenience for the user. >4) As for 3), but the Smartcard uses biometrics - thumb-print, signature, >eye-scan. I guess this is much safer - provided you don't get gory! As noted in another message, if one admits the ability to open up the card, then the biometric protection is probably not very interesting. Note that the average college physical lab has all one needs to successfully open up almost all of these cards and extract private keys, these days, and the info on how to do this is being published, removing that barries as well. >5) My PC uses one of the approaches above, but once authentication via the >certificate is complete, enforces a secondary authentication. This >authentication is under the control of the server, and so can't be cracked >off-line. If an attack is mounted, the VPN server will receive 'warnings' in >the form of authentication failures (I hope). The authentication >information provided in this secondary phase MUST NOT be part of the VPN >client's automatic function. What exaclty is an example fo the second phase authentication here? If one assumes use of a SecurID card, for example, why not postulate that it was tolen at the same time as the smart card? If a password is used, then we have all the usual password-related problems that make guessing possible. >The advantages of 5) seem to be: >1) two-way authentication between the devices based on certificates. >2) secondary, independent authentication that can't be cracked 'off-line'. >3) an 'way out' for the non-repudiation legality. >4) continued use of existing remote access authentication methods. > >I have not covered the case where a stolen PC/certificate is used to spoof a >VPN server. Mainly because I can't think of a solution! I don't think that #3 is a real issue here, but the rest of the points are well taken. However, one is making the user do through more hoops, and the result also may still vulnerable to Trojan Horse attacks. What you didn't mention explicity here is that your analysis focuses on the threat posed by physical theft of the PC and/or authentication token. That's not a bad model, but it's not the only one to consider, and today many folks would rate it much lower than software-based attacks against the server or the client. Steve From owner-ipsec@lists.tislabs.com Mon Jul 19 16:34:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15431; Mon, 19 Jul 1999 16:34:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25721 Mon, 19 Jul 1999 18:12:18 -0400 (EDT) Date: Mon, 19 Jul 1999 15:12:19 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt)) To: Stephen Kent Cc: "Waters, Stephen" , Eric_Guerrino@LNOTES5.bankofny.com, ietf-pkix@imc.org, ipsec@lists.tislabs.com, "Holland, Gary" , "Bassett, John Robert" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >4) As for 3), but the Smartcard uses biometrics - thumb-print, signature, > >eye-scan. I guess this is much safer - provided you don't get gory! > > As noted in another message, if one admits the ability to open up the card, > then the biometric protection is probably not very interesting. Note that > the average college physical lab has all one needs to successfully open up > almost all of these cards and extract private keys, these days, and the > info on how to do this is being published, removing that barries as well. > Furthermore, one has to implicitely trust the biometric reader. biometric authentication only really works if the reader is owned by the user. Otherwise, the authentication is subject to replay. PatC From owner-ipsec@lists.tislabs.com Mon Jul 19 16:53:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15721; Mon, 19 Jul 1999 16:53:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25735 Mon, 19 Jul 1999 18:17:33 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE42@new-exc1.ctron.com> From: "Waters, Stephen" To: Stephen Kent Cc: ietf-pkix@imc.org, ipsec@lists.tislabs.com Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt)) Date: Mon, 19 Jul 1999 23:17:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>5) My PC uses one of the approaches above, but once authentication via the >>certificate is complete, enforces a secondary authentication. This >>authentication is under the control of the server, and so can't be cracked >>off-line. If an attack is mounted, the VPN server will receive 'warnings' in >>the form of authentication failures (I hope). The authentication >>information provided in this secondary phase MUST NOT be part of the VPN >>client's automatic function. >What exaclty is an example fo the second phase authentication here? If one >assumes use of a SecurID card, for example, why not postulate that it was >tolen at the same time as the smart card? If a password is used, then we >have all the usual password-related problems that make guessing possible. I like 'guessing possible', provided that the guessing can only be done on-line. If I am using a SecureID card, for example, the card itself can not help you know when you have the right pin number, only the server in the head office knows which pin number goes with which card. To crack-in using IKE XAUTH, I need to go on-line and interface directly with the server. If the server get suspicious that I'm guessing, it can take action. I agree that badly chosen passwords/pin-numbers will be a problem, but apart from that, it does give the server a way of keeping a secret that is not (should not) be recorded in any place other than the users head, and the server's database. If 'normal' smartcards can be dismantled and interrogated as you suggest, then that is a worry that secondary authentication seems to help with. Maybe 'normal' Smartcards are not enough? We need super, FIP-140 level-4 type devices that can defend themselves against all manor of creepy crawlies? Fortezza? On a related point, since IKE XAUTH is typically one-way (server authenticating client), secondary authentication does leave the problem of the server being spoofed with a compromised key! Steve. From owner-ipsec@lists.tislabs.com Mon Jul 19 17:50:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16352; Mon, 19 Jul 1999 17:50:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25916 Mon, 19 Jul 1999 19:24:01 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DC4BBE42@new-exc1.ctron.com> Date: Mon, 19 Jul 1999 19:25:44 -0400 To: "Waters, Stephen" From: Stephen Kent Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt)) Cc: ietf-pkix@imc.org, ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, >>>5) My PC uses one of the approaches above, but once authentication via the >>>certificate is complete, enforces a secondary authentication. This >>>authentication is under the control of the server, and so can't be cracked >>>off-line. If an attack is mounted, the VPN server will receive 'warnings' >in >>>the form of authentication failures (I hope). The authentication >>>information provided in this secondary phase MUST NOT be part of the VPN >>>client's automatic function. > >>What exaclty is an example fo the second phase authentication here? If one >>assumes use of a SecurID card, for example, why not postulate that it was >>tolen at the same time as the smart card? If a password is used, then we >>have all the usual password-related problems that make guessing possible. > >I like 'guessing possible', provided that the guessing can only be done >on-line. If I am using a SecureID card, for example, the card itself can not >help you know when you have the right pin number, only the server in the >head office knows which pin number goes with which card. To crack-in using >IKE XAUTH, I need to go on-line and interface directly with the server. If >the server get suspicious that I'm guessing, it can take action. I agree >that badly chosen passwords/pin-numbers will be a problem, but apart from >that, it does give the server a way of keeping a secret that is not (should >not) be recorded in any place other than the users head, and the server's >database. Depends on what form of SecurID card you are talking about. Most of these cards do not require a PIN to actuve them; the PIN is just used as a static password to help counter the threat posed by theft of a card. Under that model there are various ways I may have acquired the PIN, especially if I can spoof the server (which would not happen if one authenticated the server prior to transmitting the PIN). In more traditional SecurID usage, the passive wiretapper has access to valid challenge/response pairs and would be able to search the PIN space even when the PIN is entered into the card as part of activation. So, under the best circumstances, yes, the use of a card like SecuID and a full fledged 2-way authenticated IPsec SA is an improvement, as you noted. >If 'normal' smartcards can be dismantled and interrogated as you suggest, >then that is a worry that secondary authentication seems to help with. >Maybe 'normal' Smartcards are not enough? We need super, FIP-140 level-4 >type devices that can defend themselves against all manor of creepy >crawlies? Fortezza? Fortezza is not evaluated vs. 140-1, but it would not meet level 4, or probably even level 3 criteria, for a variety of reasons, some of which are orthogonal to the discussion here. >On a related point, since IKE XAUTH is typically one-way (server >authenticating client), secondary authentication does leave the problem of >the server being spoofed with a compromised key! I thought it was one way the other way, i.e., server is authenticated to client via a cert, but client uses only "legacy" auth to server. If it were the other way around it would be awful, as it would open a variety of attacks against the legacy systems which could diminish their effectiveness. For example, S/Key is very vulnerable to active server spoofing attacks. Steve From owner-ipsec@lists.tislabs.com Mon Jul 19 18:44:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA24336; Mon, 19 Jul 1999 18:44:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26078 Mon, 19 Jul 1999 20:19:54 -0400 (EDT) Message-Id: <199907182047.QAA04447@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com CC: Bruce Schneier Subject: CHoosing a second manditory cipher for IPSec In-reply-to: Your message of "Thu, 15 Jul 1999 10:04:12 EDT." <199907151404.KAA11142@lists.tislabs.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Sun, 18 Jul 1999 16:47:04 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bruce" == owner-ipsec writes: Bruce> Version 4.1 Date: Thu, 15 Jul 1999 08:50:44 -0500 To: Bruce> ipsec@lists.tislabs.com From: Bruce Schneier Bruce> Subject: CHoosing a second manditory ... Bruce> The question comes down to why IPSec needs a second cipher. Bruce> Remember that any implementation of IPSec will probably be as Bruce> secure as the weakest of the two cipher choices (under the Bruce> assumption that an attacker can force a choice, or at least on the Bruce> assumption that the users will have no idea which cipher to Bruce> choose). I think giving users a choice is a bad idea, and that Bruce> one strong cipher is better than two strong ciphers. This is true. The reason to pick two is to guarantee that it will be widely available, and thus when the user *does* decide to make a choice for the stronger one (probably based upon new attacks) that he can get both ends to cooperate without going through a patch release cycle, etc. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Jul 20 03:21:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA14106; Tue, 20 Jul 1999 03:21:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27069 Tue, 20 Jul 1999 04:36:38 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE46@new-exc1.ctron.com> From: "Waters, Stephen" To: Stephen Kent Cc: ietf-pkix@imc.org, ipsec@lists.tislabs.com Subject: RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt)) Date: Tue, 20 Jul 1999 09:36:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>On a related point, since IKE XAUTH is typically one-way (server >>authenticating client), secondary authentication does leave the problem of >>the server being spoofed with a compromised key! >I thought it was one way the other way, i.e., server is authenticated to >client via a cert, but client uses only "legacy" auth to server. If it >were the other way around it would be awful, as it would open a variety of >attacks against the legacy systems which could diminish their >effectiveness. For example, S/Key is very vulnerable to active server >spoofing attacks. I think there has been a proposal along those lines (asymmetric authentication), but the XAUTH draft does not cover that (I don't think). A normal symmetric Phase-1 authentication (pre-shared,signature,encrypted-nonce) is followed by a one-way secondary authentication via XAUTH. Cheers, Steve. From owner-ipsec@lists.tislabs.com Tue Jul 20 08:12:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00609; Tue, 20 Jul 1999 08:12:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27699 Tue, 20 Jul 1999 08:25:12 -0400 (EDT) From: O.Schnapauff@tu-bs.de Date: Tue, 20 Jul 1999 09:49:49 +0200 To: Pekka Turunen Cc: otel@ce.chalmers.se, linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Subject: Re: linux-ipsec: VS: IP tunnel over a NAT (IP masq) possible ? Message-ID: <19990720094949.B3631@alpha.utopia> Reply-To: O.Schnapauff@tu-bs.de References: <14223.33362.904306.427278@blomman18.ce.chalmers.se> <000a01bed1d8$7d31a820$390964c2@baudia.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <000a01bed1d8$7d31a820$390964c2@baudia.fi>; from Pekka Turunen on Mon, Jul 19, 1999 at 02:18:55PM +0300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On stardate Mon, Jul 19, 1999 at 02:18:55PM +0300, Pekka Turunen wrote: [snip] > The FireSeal system consists of two main components. The Client component > works as a part of the IPSec - or any other security application, inside the > company network boundaries, whereas the server component is attached to the > firewall. The process of controlling secured network traffic can be divided > into three steps: > > 1. The client part of FireSeal sends parameters concerning the connection to > the firewall (IP address, protocol used etc.). > > 2. The firewall decides if the connection is allowed (firewalls normal > control mechanisms are used). If the connection is accepted then firewall > sends to the client the needed parameters for the connection (i.e. the NAT > transform parameters and a SPI number, which identifies the approved > connection). > > 3. The client does the NAT transformation and sends the data. The data > passes through the firewall if the SPI matches the ones in firewall. > > I.e. the firewall can use its normal policies to decide, whether or not to > let the traffic pass through. In regard to applications needing secure > communications, FireSeal is completely invisible. Well, if I understand this right you do not add security at all, stricly speaking. You do trust the client part of fireseal, and the client. If the client claims to send traffic type A and the firewall allows that, and the client lied and sends soemthing else in encrypted packets the firewall has no chance to control that. Also you delegate NAT transformations etc to the client. If I make a firewall I dont trust anything else, esp. not "inside" users, local machines. Most security problems (80-90%) come from within the "trusted" local network. As John already pointed out he is working on NAT for IPSec traffic, but if you look up the thread from about 7 weeks ago there are severe limitations on the use. If you are interested I can send you an excerpt of my thesis where the problem is analysed, but Johns Howto also mentions the problems, as well as the thread on this mailinglist where we discussed it in length. Olaf -- "The number of Unix installations Olaf Schnapauff, has grown to 10, with more expected." O.Schnapauff@tu-bs.de - The Unix Programmer's Manual,1972 http://www.tu-bs.de/~c0033014/ See Web page and keyservers for pgp public key From owner-ipsec@lists.tislabs.com Tue Jul 20 08:22:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01906; Tue, 20 Jul 1999 08:22:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27841 Tue, 20 Jul 1999 09:14:09 -0400 (EDT) Date: Tue, 20 Jul 1999 06:13:14 -0700 (PDT) From: Dennis Glatting To: Rodney Thayer cc: Dennis Glatting , ipsec@lists.tislabs.com Subject: Re: your mail In-Reply-To: <3.0.6.32.19990718115638.008118f0@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 18 Jul 1999, Rodney Thayer wrote: > There are people worried that 3DES is vulnerable to attacks other > than brute force. > Let's play devil's advocate. What about DH? RSA? Is 3DES more susceptible to cryptanalytic attack than those? What's the probability of cracking 3DES before DH or RSA? I understand there have been significant advances in algorithms to attack them (last read in cryptogram). Should we add back-ups in the event of their demise, too? > At 10:13 PM 7/15/99 -0700, Dennis Glatting wrote: > > > > > >On Thu, 15 Jul 1999, Bruce Schneier wrote: > > > >> This still makes no sense to me. There are so many things to > >> worry about wrt an IPSec implementation, so many things that can > >> compromise security if they are not done correctly, that making > >> sure there is a backup to triple-DES seems like a collossal waste > >> of time. It's like putting a mile-high stake in the ground and > >> hoping the enemy runs right into it, instead of trying to build a > >> wall. > >> > > > >I am having trouble believing 3DES is going to broken anytime soon, > >but then I am not a cryptographer and up on current events. Therefore, > >I believe that a back-up cipher will be caught in regular maintenance > >cycles and the whole thing a non-issue, but I've been wrong many times > >before. :) > > > >I ask what is going on here folks? This whole 3DES thing seems like > >FUD, which isn't typical IETF behaviour. What is it I don't know? > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Jul 20 10:41:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09442; Tue, 20 Jul 1999 10:41:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28319 Tue, 20 Jul 1999 11:34:41 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: "John D. Hardin" Cc: O.Schnapauff@tu-bs.de, Pekka Turunen , otel@ce.chalmers.se, linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Subject: Re: linux-ipsec: VS: IP tunnel over a NAT (IP masq) possible ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jul 1999 11:34:48 -0400 From: "Steven M. Bellovin" Message-Id: <19990720153454.63D2441F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Joh n D. Hardin" writes: > On Tue, 20 Jul 1999 O.Schnapauff@tu-bs.de wrote: > > > As John already pointed out he is working on NAT for IPSec traffic > > NB- I think I've taken IPSec masquerade about as far as it can be > taken without attempting to communicate with the endpoint gateways or > act as an intelligent proxy and participate in any of the encryption. For a different approach to firewalls and IPsec, see http://www.research.att.com/~smb/papers/distfw.ps or http://www.research.att.com/~smb/papers/distfw.pdf. From owner-ipsec@lists.tislabs.com Tue Jul 20 10:54:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09721; Tue, 20 Jul 1999 10:54:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28394 Tue, 20 Jul 1999 11:58:43 -0400 (EDT) Message-Id: <4.1.19990720114557.00b62160@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 20 Jul 1999 11:56:27 -0400 To: ipsec@lists.tislabs.com, Bruce Schneier From: Robert Moskowitz Subject: Re: More on a second IPSec algorithm In-Reply-To: <3790D72C.F82930F9@greendragon.com> References: <4.1.19990715161920.00a04930@mail.visi.com> <4.1.19990716101655.00a1a480@mail.visi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:19 PM 7/17/99 -0400, William Allen Simpson wrote: Sorry I was gone for a few days... >It seems I'm missing some of the messages in this thread, or the thread was >renamed too many times, but while I agree that Bruce is correct on a theoretic >basis, there are a few practical reasons why having more than one "mandatory >to implement" cipher is good: > > A) Some vendors are resistant to mandating 3DES because of speed. Perry > and Phil and I pushed 3DES pretty hard 4 years ago, but lost the battle > on the speed issue. DESX is virtually the same speed as DES. We didn't > push DESX 4 years ago, as it had no analysis. Now, I think DESX is the > obvious choice for a quick update. Easiest to implement, with no speed > changes that a user (or marketer) might notice. Speed is the paramount item. DES was slow enough. 3DES is so much slower. If we want serious penetration, we MUST pay attention to speed. I am not so concerned for those big gateway boxes with OCn interfaces. In the end they lose anyway. Rather small end systens. cell phones and PDAs. Hubs (At chrysler we use to shut off ports where we suspected a user had stolen someone elses IP address. we were only wrong twice, but this is a great DOS), assembly robots, etc. When you drop DES you make a bad situation much worse. > B) Mandating that both DESX and 3DES are in every product allows the > customer to choose the speed, finessing the vendor complaint. The core > code is the same, so it is still easy to implement. true > C) Having more than one algorithm tests the selection machinery on a > regular basis. This implementation issue is very important. Even > when a product works the first time around, later changes can break > the implementation. Exercise the code paths. we still see this problem in the lab. > D) Having more than one algorithm tests the operational configuration > machinery. Again, operational issues are very important. Of course, > this same consideration encourages the number of choices to be small, > probably only 2 or 3. But, as time goes on, there will be changes, > and that means we have to be prepared to configure them. It is a lot > easier to change a policy data file than have a deployment flag day. again you see things like this in the lab. pity the deployer. > F) Having more than one cipher simply instills confidence, for users, > the naive press, and overblown marketing. This is another reason > for adding a non-DES cipher. It may not fix anything in and of itself, > but the mere presence says "we've covered all the bases". All too aware of this 'reality'. >I wish that the working group had followed our advice in 1995, and allowed >both DES and 3DES to be Proposed Standard. Then, we wouldn't be in the >quandary we are in today. Yes we would, as we are advocating dropping DES. 3DES is not an equivalent replacement that addresses the weakness of DES (ie brute strength attack). Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Jul 20 11:27:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10478; Tue, 20 Jul 1999 11:27:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28516 Tue, 20 Jul 1999 12:28:50 -0400 (EDT) Message-Id: <4.1.19990720115931.00b6f8e0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 20 Jul 1999 12:28:27 -0400 To: ipsec@lists.tislabs.com From: Robert Moskowitz Subject: TCP checksum recalculation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I looked over Kai's MIKE proposal, I got to thinking about transport mode. The more I thought about transport mode, the more I looked for what we do for maintaining the TCP checksum. It seems to me that transport mode breaks the checksum and requires its recomputation on deencapsulating. I could not find any discussion of this in the RFCs. Either I missed it in my search (and thus others will). Or else I missed something in the checksum handling in the IP kernel that makes this not an issue. The way I see it, each router decrements the TTL, but will not recompute the checksum, as the next protocol is NOT TCP. Then the end system gets the packet, decapsulates and blindly sends the packet upwards to TCP with a bad checksum. ERGO either it is in the docs and I missed it, I have this all wrong, I have it right and everyone knows about it and is building their code properly, I have this right and no one is testing their transport mode through routers (seems unlikely). So where is this documented :) Oh with MIKE, consider that at each IKE SA boundary, the addresses are altered at each point (shades of RSIP), so then TCP checksum would really be broken and partial recalculation would be different (not just TTL, but whole IP). Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Jul 20 11:30:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10542; Tue, 20 Jul 1999 11:30:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28269 Tue, 20 Jul 1999 11:27:10 -0400 (EDT) Date: Tue, 20 Jul 1999 08:01:58 -0700 (PDT) From: "John D. Hardin" X-Sender: jhardin@gypsy.rubyriver.com To: O.Schnapauff@tu-bs.de cc: Pekka Turunen , otel@ce.chalmers.se, linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, firewall-wizards@nfr.net Subject: Re: linux-ipsec: VS: IP tunnel over a NAT (IP masq) possible ? In-Reply-To: <19990720094949.B3631@alpha.utopia> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Jul 1999 O.Schnapauff@tu-bs.de wrote: > As John already pointed out he is working on NAT for IPSec traffic NB- I think I've taken IPSec masquerade about as far as it can be taken without attempting to communicate with the endpoint gateways or act as an intelligent proxy and participate in any of the encryption. -- John Hardin KA7OHZ jhardin@wolfenet.com pgpk -a finger://gonzo.wolfenet.com/jhardin PGP key ID: 0x41EA94F5 PGP key fingerprint: A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76 ----------------------------------------------------------------------- Efficiency can magnify good, but it magnifies evil just as well. So, we should not be surprised to find that modern electronic communication magnifies stupidity as *efficiently* as it magnifies intelligence. -- Robert A. Matern ----------------------------------------------------------------------- 51 days until 9/9/99 From owner-ipsec@lists.tislabs.com Tue Jul 20 12:45:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA12330; Tue, 20 Jul 1999 12:45:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28833 Tue, 20 Jul 1999 13:42:49 -0400 (EDT) Date: Tue, 20 Jul 1999 13:42:22 -0400 (EDT) From: Henry Spencer To: Robert Moskowitz cc: ipsec@lists.tislabs.com Subject: Re: TCP checksum recalculation In-Reply-To: <4.1.19990720115931.00b6f8e0@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Jul 1999, Robert Moskowitz wrote: > The way I see it, each router decrements the TTL, but will not recompute > the checksum, as the next protocol is NOT TCP. The TCP checksum doesn't cover the TTL. It does cover some fields of the IP header, but only selected ones, and the TTL is not among them. The IP checksum, which covers the whole IP header, does need to be updated when the TTL changes. (And people have devised assorted clever ways of doing that without full recomputation.) The TCP checksum doesn't; it is deliberately an end-to-end check, not something updated at each hop. > Oh with MIKE, consider that at each IKE SA boundary, the addresses are > altered at each point (shades of RSIP), so then TCP checksum would really > be broken and partial recalculation would be different (not just TTL, but > whole IP). Yes, messing with the *addresses* is a much stickier problem. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Tue Jul 20 13:41:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13631; Tue, 20 Jul 1999 13:41:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29119 Tue, 20 Jul 1999 14:55:49 -0400 (EDT) Message-ID: <3794C636.82B100C8@redcreek.com> Date: Tue, 20 Jul 1999 11:55:50 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tamir Zegman CC: Dennis Glatting , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <378D9F5B.C3FA1495@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tamir Zegman wrote: > > Dennis Glatting wrote: > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > be the IPsec authentication mechanism of choice until products mature > > and prices decline. The difference between simple shared secrets and > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > manage, managed shared secret technologies yielding, in my opinion, no > > motivation to improve the security of infrastructures (i.e., > > transition to PKI). Is this where we want to be after several years of > > work and some cantankerous meetings? > > > > There is another side for this coin. > We have many customers that are deferring their migration to IPSec because > they feel they are not ready to deploy a full scale PKI. > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > of PKI. > Sometimes it's easier to jump over two small hurdles rather than over a > big one. I agree with Tamir on this point, but think that if we are indeed viewing this (xauth, hybrid) as an intermediate step, then we should make this exceedingly clear, and the transition path should be clearly stated ("clearly" being a relative term at this point in the game). > > > > I offer the following suggestions. First, finish a combined > > xauth/hybrid draft and classify it as experimental. Second, the > > Security Considerations section of the draft be written not by the > > draft's proponents but by at least two of its detractors. Finally, set > > a deadline (perhaps three years) where the PS is committed to > > historic. > > I'll accept your offer with regard to the Security Consideration section. > Any volunteers? > I do not believe that the experimental is the right track for this. I'd be willing to contribute to the security considerations text. I'm not sure if the experimental track is right or not, though I do think that somehow limiting the lifetime of password-based approaches has a certain appeal. We must grease the skids for PKI deployment, and not simply provide an excuse for maintaining the status quo, but this is a complex issue. That is why I think we need a working group to iron it out. Scott From owner-ipsec@lists.tislabs.com Tue Jul 20 13:56:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13963; Tue, 20 Jul 1999 13:56:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29179 Tue, 20 Jul 1999 15:08:46 -0400 (EDT) Message-ID: <3794C928.D2B4AD06@mitel.com> Date: Tue, 20 Jul 1999 15:08:24 -0400 From: Dave Perks Organization: Mitel Corporation X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IP Security List Subject: Re: TCP checksum recalculation References: <4.1.19990720115931.00b6f8e0@homebase.htt-consult.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Robert Moskowitz wrote: > > As I looked over Kai's MIKE proposal, I got to thinking about transport > mode. The more I thought about transport mode, the more I looked for what > we do for maintaining the TCP checksum. > > It seems to me that transport mode breaks the checksum and requires its > recomputation on deencapsulating. I could not find any discussion of this > in the RFCs. TCP checksum does not include TTL from IP header, only the IP addresses. -- The opinions expressed in this message are my personal opinion and in no way reflect the views of my employer. Søren Kierkegaard says "Life can only be understood backwards; but it must be lived forwards." From owner-ipsec@lists.tislabs.com Tue Jul 20 14:22:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14598; Tue, 20 Jul 1999 14:22:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29310 Tue, 20 Jul 1999 15:40:15 -0400 (EDT) Date: Tue, 20 Jul 1999 10:48:48 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else) To: kent@bbn.com, Stephen.Waters@cabletron.com Cc: ietf-pkix@imc.org, ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NdTMbAmTW4dHZWpKUJA3jQ== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>On a related point, since IKE XAUTH is typically one-way (server > >>authenticating client), secondary authentication does leave the problem of > >>the server being spoofed with a compromised key! > > >I thought it was one way the other way, i.e., server is authenticated to > >client via a cert, but client uses only "legacy" auth to server. If it > >were the other way around it would be awful, as it would open a variety of > >attacks against the legacy systems which could diminish their > >effectiveness. For example, S/Key is very vulnerable to active server > >spoofing attacks. > > I think there has been a proposal along those lines (asymmetric > authentication), but the XAUTH draft does not cover that (I don't think). A > normal symmetric Phase-1 authentication > (pre-shared,signature,encrypted-nonce) is followed by a one-way secondary > authentication via XAUTH. > > Cheers, Steve. The "Hybrid Authentication" draft: draft-ietf-ipsec-isakmp-hybrid-auth-02.txt discusses asymmetric authentication (server is authenticated via a digital signature and the client uses OTP/token card etc). The hybrid authentication draft uses a slight modification of Main/Aggressive mode in which only the responder (server) is authenticated -- the initiator sends only a hash rather than a signature. This is immediately followed by an XAUTH exchange in which the client authenticates to the server using a "legacy" mechanism. This approach is very similar to how web-based banking works -- the bank's server is authenticated via a signature during SSL negotiation and the user is authenticated via a password sent over HTTPS. I don't quite see the motivation behind XAUTH if it is used in conjunction with regular Main/Aggressive mode since each of those modes provides mutual authentication. If the client has already been authenticated in Main/Aggressive mode, what is the additional functionality provided by XAUTH? Or is it that the pre-shared key used in Main/Aggressive mode common to *all* clients (e.g. all corporate employees) and XAUTH is used to identify a particular client? thanks, vipul From owner-ipsec@lists.tislabs.com Tue Jul 20 15:40:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16448; Tue, 20 Jul 1999 15:40:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29712 Tue, 20 Jul 1999 16:58:11 -0400 (EDT) Message-Id: <199907202058.NAA11319@potassium.network-alchemy.com> To: Vipul Gupta cc: kent@bbn.com, Stephen.Waters@cabletron.com, ietf-pkix@imc.org, ipsec@lists.tislabs.com Subject: Re: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else) In-reply-to: Your message of "Tue, 20 Jul 1999 10:48:48 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11316.932504284.1@network-alchemy.com> Date: Tue, 20 Jul 1999 13:58:04 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Jul 1999 10:48:48 PDT Vipul Gupta wrote > > I don't quite see the motivation behind XAUTH if it is used in > conjunction with regular Main/Aggressive mode since each of those > modes provides mutual authentication. If the client has already > been authenticated in Main/Aggressive mode, what is the additional > functionality provided by XAUTH? Or is it that the pre-shared key > used in Main/Aggressive mode common to *all* clients (e.g. all > corporate employees) and XAUTH is used to identify a particular > client? Exactly! I brought this point up back in May. If the IKE SA has been authenticated properly then XAUTH doesn't buy you anything. You have the double burden of supporting a PKI and some legacy database and the user gets yet another dialog box asking for yet another passphrase. I find it very hard to believe that this is what people are doing when I hear that "customers want XAUTH". For XAUTH to provide anything the IKE SA is authenticated with some shared key and then the "client" authenticates himself to the "server" with the legacy method. The problem with this is that the IKE SA and all the SKEYID state is not authenticated. Therefore all the keys in the IPSec SAs are not authenticated. Depending on the legacy method this can be open to a man-in-the-middle attack too. draft-ietf-ipsec-internet-key-00.txt is an April Fool's draft but the security considerations is right on in this respect. Dan. From owner-ipsec@lists.tislabs.com Tue Jul 20 16:38:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17649; Tue, 20 Jul 1999 16:38:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29878 Tue, 20 Jul 1999 18:07:27 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.1.19990720115931.00b6f8e0@homebase.htt-consult.com> Date: Tue, 20 Jul 1999 18:04:04 -0400 To: Robert Moskowitz From: Stephen Kent Subject: Re: TCP checksum recalculation Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bob, I'm confused by your comments. The TCP checksum does not cover all of the IP header. It includes only the source and dest IP addresses. So, transport mode is unaffected by TTL value changes enroute. Only the IP header checksum is affected by such changes, and it is the responsibility of a router to modify that checksum whenever it modifies any IP header field, irrespective of what the next protocol is. Steve From owner-ipsec@lists.tislabs.com Tue Jul 20 23:25:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA21671; Tue, 20 Jul 1999 23:25:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00703 Wed, 21 Jul 1999 00:43:00 -0400 (EDT) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Wed, 21 Jul 1999 07:42:21 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@lists.tislabs.com Subject: Re: More on a second IPSec algorithm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk DES is ``not very secure'' and ``not very fast''. 3DES is ``secure'' but ``extremely slow''. Most of the other candidates are ruled out since they are ``too new''. May be we should select the most conservative AES candidate: Serpent. It is DES-like, but has larger blocks (128), larger keys (up to 256 bits), more secure S-boxes, more rounds (32!), and very conservative design. Although Serpent has been critisised for slow troughput (the current best (known) implementation on Pentium II (in C!) takes ~990 cycles per 128-bit block, as opposed to ~340 cycles per OpenSSL implementations of DES (in assembler)), it is still almost twice as fast than 3DES and most probably also more secure. Note that the authors of Serpent (Ross Anderson, Eli Biham and Lars Knudsen) had no attacks for 16-round Serpent but still decided to double the number of rounds. Serpent is patent-resistant. And faster implementations probably follow. Helger From owner-ipsec@lists.tislabs.com Wed Jul 21 06:58:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA12306; Wed, 21 Jul 1999 06:58:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01884 Wed, 21 Jul 1999 08:20:28 -0400 (EDT) Message-Id: <3.0.6.32.19990721105717.02ac1d70@stmail01.cubis.de> X-Sender: martius@stmail01.cubis.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 21 Jul 1999 10:57:17 +0200 To: Robert Moskowitz , ipsec@lists.tislabs.com From: Kai Martius Subject: Re: TCP checksum recalculation In-Reply-To: <4.1.19990720115931.00b6f8e0@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, At 12:28 20.07.99 -0400, Robert Moskowitz wrote: >Oh with MIKE, consider that at each IKE SA boundary, the addresses are >altered at each point (shades of RSIP), so then TCP checksum would really >be broken and partial recalculation would be different (not just TTL, but >whole IP). MIKE is a kind of "application-level gateway", and from the transport view the messages are exchanged in unsecured UDP packets between MIKE instances in the same IP realm (if these instances are at the border of a realm; otherwise - NAT between two MIKE daemons - raises the same (minor) issues like IKE over NAT). Hmm, I didn't really watch the RSIP developments, but there could be other advantages for RSIP servers to know about the relation of {dst, SPI, ESP} <-> {src, dst, s-port, d-port}.... In draft-ietf-nat-rsip-ipsec-00.txt, RSIP servers utilize SPIs to demultiplex incoming traffic, but they need to *negotiate* a SPI with the client, which it finally uses end-2-end. This MIKE doesn't provide (yet?). Kai From owner-ipsec@lists.tislabs.com Wed Jul 21 08:13:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14640; Wed, 21 Jul 1999 08:13:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02326 Wed, 21 Jul 1999 09:21:50 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE56@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com, ietf-pkix@imc.org Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else) Date: Wed, 21 Jul 1999 14:21:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, This is a bag of 'if buts and maybes', but XAUTH may have some value if... I agree that using XAUTH should be avoided if possible, and if I could eliminate all possible uses, I'd be very happy not to add more state to our already-busy IKE state machine. At the moment, I think I'm interested in using XAUTH as a way of forcing contact with the VPN server. If may laptop is stolen with a individual pre-shared secret or certificate loaded, there is a good chance that the security protecting that secret can be cracked 'off-line' with no 'warning' given to the VPN server that that is taking place. I would be relying on timely notification of the theft to plug this hole. Cases: 1) Thief does a runner with a device with no intention of returning it. If I force VPN client to engage in a secondary authentication phase, then that can not be cracked off-line: the hacker needs to attempt to break-in with exchanges to the VPN server. The VPN server can then log repeated failures, and take action. 2) Thief borrows the device in order to steal the primary authentication secret, then returns the device. In the case, where the primary authentication method is a pre-shared secret, and the stolen/borrowed device is returned without being missed/suspected, then the attacker can then listen-in. They can also see the XAUTH phase, and if it is weak, they can then impersonate the client. If the XAUTH phase is secure (challenge-based), then it should be possible to prevent the impersonation, but the listening-in.... I'm assuming listening-in is infeasible in the case of certificates, unless I crack their server as well. As you say, if the Phase1 authentication is based on a poorly kept shared (group) key, anything can happen without the need to acquire a device. I don't see that a well chosen, unique, well secured pre-shared secret is much worse than a certificate though. So, it seems that XAUTH may offer some protection from impersonation if the secondary authentication method reasonably robust. If pre-shared secrets are used, make sure they are treated as unique secrets per individual, and protect them with a password-derived key, and definitely use a robust XAUTH mechanism. Smartcards seem to offer some hope, but there seems to be room for debate on just secure they are. They are probably more secure than most software key stores, but until we get cards that can guarantee tamper resistance, there would seem to be a job for XAUTH. Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] Sent: Tuesday, July 20, 1999 9:58 PM To: Vipul Gupta Cc: kent@bbn.com; Stephen.Waters@cabletron.com; ietf-pkix@imc.org; ipsec@lists.tislabs.com Subject: Re: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else) On Tue, 20 Jul 1999 10:48:48 PDT Vipul Gupta wrote > > I don't quite see the motivation behind XAUTH if it is used in > conjunction with regular Main/Aggressive mode since each of those > modes provides mutual authentication. If the client has already > been authenticated in Main/Aggressive mode, what is the additional > functionality provided by XAUTH? Or is it that the pre-shared key > used in Main/Aggressive mode common to *all* clients (e.g. all > corporate employees) and XAUTH is used to identify a particular > client? Exactly! I brought this point up back in May. If the IKE SA has been authenticated properly then XAUTH doesn't buy you anything. You have the double burden of supporting a PKI and some legacy database and the user gets yet another dialog box asking for yet another passphrase. I find it very hard to believe that this is what people are doing when I hear that "customers want XAUTH". For XAUTH to provide anything the IKE SA is authenticated with some shared key and then the "client" authenticates himself to the "server" with the legacy method. The problem with this is that the IKE SA and all the SKEYID state is not authenticated. Therefore all the keys in the IPSec SAs are not authenticated. Depending on the legacy method this can be open to a man-in-the-middle attack too. draft-ietf-ipsec-internet-key-00.txt is an April Fool's draft but the security considerations is right on in this respect. Dan. From owner-ipsec@lists.tislabs.com Wed Jul 21 12:01:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21559; Wed, 21 Jul 1999 12:01:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02972 Wed, 21 Jul 1999 13:24:47 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8D8@sothmxs06.entrust.com> From: Greg Carter To: "'Ioannis Bonias'" Cc: "'Stephane Beaulieu'" , Andrew Krywaniuk , "'ipsec@lists.tislabs.com'" Subject: RE: XAUTH? Date: Wed, 21 Jul 1999 13:23:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Ioannis Bonias [mailto:ibonias@raptor.com] Sent: Friday, July 16, 1999 4:09 PM To: Greg Carter Cc: 'Stephane Beaulieu'; Andrew Krywaniuk; 'ipsec@lists.tislabs.com' Subject: Re: XAUTH? Greg, 1. Why do you want to distinguish a config mode exchange and XAUTH ? I don't, that is the problem. I want a clear way to know that the exchange has ended and I can clear state. Right now I have to check and see if the XAUTH attribute is set, if it is then allow the exchange to continue. If Config mode is to be used in this way then config mode should provide a simple way to manage state. With XAUTH there are now two places to check for state (type field and XAUTH attribute), and nothing has been said about what to do when multiple attribute payloads are included in an XAUTH exchange, is it even allowed?, does it make sense?, what if their multiple state indicators contradict those in the another attribute payload? can the exchange be more than 4 sequences? Bye. From owner-ipsec@lists.tislabs.com Wed Jul 21 12:01:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21575; Wed, 21 Jul 1999 12:01:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02915 Wed, 21 Jul 1999 13:09:29 -0400 (EDT) Message-ID: <3795FF73.9FC060FF@checkpoint.com> Date: Wed, 21 Jul 1999 20:12:19 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <378D9F5B.C3FA1495@checkpoint.com> <3794C636.82B100C8@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" wrote: > Tamir Zegman wrote: > > > > Dennis Glatting wrote: > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > be the IPsec authentication mechanism of choice until products mature > > > and prices decline. The difference between simple shared secrets and > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > manage, managed shared secret technologies yielding, in my opinion, no > > > motivation to improve the security of infrastructures (i.e., > > > transition to PKI). Is this where we want to be after several years of > > > work and some cantankerous meetings? > > > > > > > There is another side for this coin. > > We have many customers that are deferring their migration to IPSec because > > they feel they are not ready to deploy a full scale PKI. > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > of PKI. > > Sometimes it's easier to jump over two small hurdles rather than over a > > big one. > > I agree with Tamir on this point, but think that if we are indeed > viewing this (xauth, hybrid) as an intermediate step, then we should > make this exceedingly clear, and the transition path should be clearly > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > I offer the following suggestions. First, finish a combined > > > xauth/hybrid draft and classify it as experimental. Second, the > > > Security Considerations section of the draft be written not by the > > > draft's proponents but by at least two of its detractors. Finally, set > > > a deadline (perhaps three years) where the PS is committed to > > > historic. > > > > I'll accept your offer with regard to the Security Consideration section. > > Any volunteers? > > I do not believe that the experimental is the right track for this. > > I'd be willing to contribute to the security considerations text. > > I'm not sure if the experimental track is right or not, though I do > think that somehow limiting the lifetime of password-based approaches > has a certain appeal. We must grease the skids for PKI deployment, and > not simply provide an excuse for maintaining the status quo, but this is > a complex issue. That is why I think we need a working group to iron it > out. > > Scott Hi Scott, I think that there is a consensus that static passwords are BAD. XAUTH/Hybrid are not there to support static passwords but to support stronger authentication schemes. In some cases PKI with "soft" tokens are even less secure than legacy authentication schemes such as SecurID tokens. In the absence of PKI, IKE users will fall back to use pre-shared keys. Do we want that? In some aspects IKE pre-shared secrets are even less secure than XAUTH/Hybrid with fixed passwords since they are susceptible to off-line dictionary attacks. Why not ban pre-shared secrets? Tamir. From owner-ipsec@lists.tislabs.com Wed Jul 21 13:15:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23841; Wed, 21 Jul 1999 13:15:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03232 Wed, 21 Jul 1999 14:30:56 -0400 (EDT) Date: Wed, 21 Jul 1999 11:30:13 -0700 (PDT) From: Dennis Glatting To: Tamir Zegman cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid In-Reply-To: <3795FF73.9FC060FF@checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 21 Jul 1999, Tamir Zegman wrote: > > > > "Scott G. Kelly" wrote: > > > Tamir Zegman wrote: > > > > > > Dennis Glatting wrote: > > > > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > > be the IPsec authentication mechanism of choice until products mature > > > > and prices decline. The difference between simple shared secrets and > > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > > manage, managed shared secret technologies yielding, in my opinion, no > > > > motivation to improve the security of infrastructures (i.e., > > > > transition to PKI). Is this where we want to be after several years of > > > > work and some cantankerous meetings? > > > > > > > > > > There is another side for this coin. > > > We have many customers that are deferring their migration to IPSec because > > > they feel they are not ready to deploy a full scale PKI. > > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > > of PKI. > > > Sometimes it's easier to jump over two small hurdles rather than over a > > > big one. > > > > I agree with Tamir on this point, but think that if we are indeed > > viewing this (xauth, hybrid) as an intermediate step, then we should > > make this exceedingly clear, and the transition path should be clearly > > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > > > > > > I offer the following suggestions. First, finish a combined > > > > xauth/hybrid draft and classify it as experimental. Second, the > > > > Security Considerations section of the draft be written not by the > > > > draft's proponents but by at least two of its detractors. Finally, set > > > > a deadline (perhaps three years) where the PS is committed to > > > > historic. > > > > > > I'll accept your offer with regard to the Security Consideration section. > > > Any volunteers? > > > I do not believe that the experimental is the right track for this. > > > > I'd be willing to contribute to the security considerations text. > > > > I'm not sure if the experimental track is right or not, though I do > > think that somehow limiting the lifetime of password-based approaches > > has a certain appeal. We must grease the skids for PKI deployment, and > > not simply provide an excuse for maintaining the status quo, but this is > > a complex issue. That is why I think we need a working group to iron it > > out. > > > > Scott > > Hi Scott, > > I think that there is a consensus that static passwords are BAD. > XAUTH/Hybrid are not there to support static passwords but to > support stronger authentication schemes. In some cases PKI with > "soft" tokens are even less secure than legacy authentication > schemes such as SecurID tokens. In the absence of PKI, IKE users > will fall back to use pre-shared keys. Do we want that? In some > aspects IKE pre-shared secrets are even less secure than > XAUTH/Hybrid with fixed passwords since they are susceptible to > off-line dictionary attacks. Why not ban pre-shared secrets? > One of the key differences is XAUTH/hybrid provides no incentive to move to PKI whereas pre-shared secrets by virtue of being unmanageable does. However, just to throw a little personal experience for perspective in favor of shared secrets, whether XAUTH/hybrid provided or pre-shared secrets, I offer the following story. One of my clients has an IKE capable firewall. I decided to purchase the vendor's certificate based solution because I believe a certificate based solution offers better security, it inexpensively introduces my client to certificate based thinking, and it was a slam-dunk -- I didn't have to think about it. :) I purchased the recently released software in May of 1999 and discovered, after five weeks, I had to downgrade my NT server to a non-y2k patch level and the software itself wasn't y2k. I returned the software and went the pre-shared secret route. Even with PKI there is still a password problem: the user's password used to encrypt their private key. People do stupid things including choosing stupid passwords. Many users still write their passwords on pieces of paper and attach them to their terminals, or write them down on mouse pads, or write them down on a sheet just inside their top desk drawer, sometimes labeled "password." In one case a women could not remember her ID and password to save her life. Eventually I changed her password to her husband's name without any character substitutions. She could not remember that one, too. So, whether you are using certificates, smart cards, or anything else that is password related, the question is: what's the difference between having xauth/hybrid and not having it? Strictly looking at passwords, a central service can impose good password selection mechanisms as can client software; However, a central service is in a better position to perform an off-line dictionary attack to assure good choice. When I think about the problems xauth/hybrid address I think of Bart Simpson's immortal words (stolen from somewhere else, I bet) "you're damned if you do and you're damned if you don't." I believe XAUTH/hybrid offers something valuable but should not be encouraged. -dpg From owner-ipsec@lists.tislabs.com Wed Jul 21 13:21:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24246; Wed, 21 Jul 1999 13:21:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03287 Wed, 21 Jul 1999 14:56:40 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8DB@sothmxs06.entrust.com> From: Greg Carter To: "'Tamir Zegman'" , "Scott G. Kelly" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Wed, 21 Jul 1999 14:55:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, How are PKI 'soft' tokens (by that I guess you mean private keys stored on disk, password protected) less secure? How is a one way proprietary authentication scheme more secure than mutual authentication? with shared secrets or PKI? Its been awhile since I looked at the internals of the ACE server but I believe it too uses DES shared secrets between the server and the NAS, Most of the other DES based token cards rely on RADIUS to act as their authentication server, so now we are down to MD5 hiding. One way authentication is pointless, IMHO. Oh, what about soft tokens, most of the DES based challenge/response token vendors offer software based tokens, I believe SecurID does as well. So how does your SGW know if the user is using a true hardware token or a soft token, it doesn't. A soft token will be susceptible to the same attacks as your shared key file, yet offers only one way authentication. Bye. -----Original Message----- From: Tamir Zegman [mailto:zegman@checkpoint.com] Sent: Wednesday, July 21, 1999 1:12 PM To: Scott G. Kelly Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid I think that there is a consensus that static passwords are BAD. XAUTH/Hybrid are not there to support static passwords but to support stronger authentication schemes. In some cases PKI with "soft" tokens are even less secure than legacy authentication schemes such as SecurID tokens. In the absence of PKI, IKE users will fall back to use pre-shared keys. Do we want that? In some aspects IKE pre-shared secrets are even less secure than XAUTH/Hybrid with fixed passwords since they are susceptible to off-line dictionary attacks. Why not ban pre-shared secrets? Tamir. From owner-ipsec@lists.tislabs.com Wed Jul 21 14:52:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27937; Wed, 21 Jul 1999 14:52:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06036 Wed, 21 Jul 1999 16:12:05 -0400 (EDT) Date: Wed, 21 Jul 1999 16:11:35 -0400 (EDT) From: "Y. John Jiang" Subject: Re: Comment on xauth and hybrid In-reply-to: To: Dennis Glatting Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Certificate authentication is prone to key board monitoring attack. If one leaves the hard token in the PCMCIA slot, it is as weak as a soft token. Y. John Jiang, Internet Engineer, Internet Security, Cable and Wireless 703-715-7480, 2100 Reston Parkway, Reston, VA 20191 On Wed, 21 Jul 1999, Dennis Glatting wrote: > > > On Wed, 21 Jul 1999, Tamir Zegman wrote: > > > > > > > > > "Scott G. Kelly" wrote: > > > > > Tamir Zegman wrote: > > > > > > > > Dennis Glatting wrote: > > > > > > > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > > > be the IPsec authentication mechanism of choice until products mature > > > > > and prices decline. The difference between simple shared secrets and > > > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > > > manage, managed shared secret technologies yielding, in my opinion, no > > > > > motivation to improve the security of infrastructures (i.e., > > > > > transition to PKI). Is this where we want to be after several years of > > > > > work and some cantankerous meetings? > > > > > > > > > > > > > There is another side for this coin. > > > > We have many customers that are deferring their migration to IPSec because > > > > they feel they are not ready to deploy a full scale PKI. > > > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > > > of PKI. > > > > Sometimes it's easier to jump over two small hurdles rather than over a > > > > big one. > > > > > > I agree with Tamir on this point, but think that if we are indeed > > > viewing this (xauth, hybrid) as an intermediate step, then we should > > > make this exceedingly clear, and the transition path should be clearly > > > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > > > > > > > > > > > I offer the following suggestions. First, finish a combined > > > > > xauth/hybrid draft and classify it as experimental. Second, the > > > > > Security Considerations section of the draft be written not by the > > > > > draft's proponents but by at least two of its detractors. Finally, set > > > > > a deadline (perhaps three years) where the PS is committed to > > > > > historic. > > > > > > > > I'll accept your offer with regard to the Security Consideration section. > > > > Any volunteers? > > > > I do not believe that the experimental is the right track for this. > > > > > > I'd be willing to contribute to the security considerations text. > > > > > > I'm not sure if the experimental track is right or not, though I do > > > think that somehow limiting the lifetime of password-based approaches > > > has a certain appeal. We must grease the skids for PKI deployment, and > > > not simply provide an excuse for maintaining the status quo, but this is > > > a complex issue. That is why I think we need a working group to iron it > > > out. > > > > > > Scott > > > > Hi Scott, > > > > I think that there is a consensus that static passwords are BAD. > > XAUTH/Hybrid are not there to support static passwords but to > > support stronger authentication schemes. In some cases PKI with > > "soft" tokens are even less secure than legacy authentication > > schemes such as SecurID tokens. In the absence of PKI, IKE users > > will fall back to use pre-shared keys. Do we want that? In some > > aspects IKE pre-shared secrets are even less secure than > > XAUTH/Hybrid with fixed passwords since they are susceptible to > > off-line dictionary attacks. Why not ban pre-shared secrets? > > > > One of the key differences is XAUTH/hybrid provides no incentive to > move to PKI whereas pre-shared secrets by virtue of being unmanageable > does. However, just to throw a little personal experience for > perspective in favor of shared secrets, whether XAUTH/hybrid provided > or pre-shared secrets, I offer the following story. > > One of my clients has an IKE capable firewall. I decided to purchase > the vendor's certificate based solution because I believe a > certificate based solution offers better security, it inexpensively > introduces my client to certificate based thinking, and it was a > slam-dunk -- I didn't have to think about it. :) I purchased the > recently released software in May of 1999 and discovered, after five > weeks, I had to downgrade my NT server to a non-y2k patch level and > the software itself wasn't y2k. I returned the software and went the > pre-shared secret route. > > Even with PKI there is still a password problem: the user's password > used to encrypt their private key. People do stupid things including > choosing stupid passwords. Many users still write their passwords on > pieces of paper and attach them to their terminals, or write them down > on mouse pads, or write them down on a sheet just inside their top > desk drawer, sometimes labeled "password." In one case a women could > not remember her ID and password to save her life. Eventually I > changed her password to her husband's name without any character > substitutions. She could not remember that one, too. So, whether you > are using certificates, smart cards, or anything else that is password > related, the question is: what's the difference between having > xauth/hybrid and not having it? Strictly looking at passwords, a > central service can impose good password selection mechanisms as can > client software; However, a central service is in a better position to > perform an off-line dictionary attack to assure good choice. > > > When I think about the problems xauth/hybrid address I think of Bart > Simpson's immortal words (stolen from somewhere else, I bet) "you're > damned if you do and you're damned if you don't." I believe > XAUTH/hybrid offers something valuable but should not be encouraged. > > > -dpg > > > > From owner-ipsec@lists.tislabs.com Wed Jul 21 14:52:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27954; Wed, 21 Jul 1999 14:52:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06630 Wed, 21 Jul 1999 16:26:09 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 21 Jul 1999 16:22:47 -0400 To: "Y. John Jiang" From: Stephen Kent Subject: Re: Comment on xauth and hybrid Cc: Dennis Glatting , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:11 PM -0400 7/21/99, Y. John Jiang wrote: >Certificate authentication is prone to key board monitoring attack. >If one leaves the hard token in the PCMCIA slot, it is as weak as >a soft token. No well-engineered hardware device should be capable of having it's private key(s) extracted via a software attack effected through a PC to which it is connected. Depending on the engineering of the device one might carry out various forms of close-in attacks, if the device is enabled and physically available to an attacker. Certainly one could initiate new SAs that the user might not really want to authorize (but that's a problem in any case). What eacctly did you have in mind when you made the above statement/ Steve From owner-ipsec@lists.tislabs.com Wed Jul 21 18:53:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA08876; Wed, 21 Jul 1999 18:53:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12746 Wed, 21 Jul 1999 19:11:39 -0400 (EDT) Date: Wed, 21 Jul 1999 19:11:19 -0400 (EDT) From: "Y. John Jiang" Subject: Re: Comment on xauth and hybrid In-reply-to: To: Stephen Kent Cc: Dennis Glatting , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I did not mean the hacker needed to extract the key. The scenario is like this: 1. A trojan is installed on a user's PC (btw, this has become very popular). 2. The pass phrase is captured by monitoring the user's keystrokes. 3. The hacker logs into the PC and then logs into the user's bank account which requires certificate authentication. True, a well-engineered hardware device does not allow the capture of the pass phrase. Adding a small keyboard on the hard token would help. However, the popular hard tokens on the market all rely on the PC keyboard for pass phrase input. John On Wed, 21 Jul 1999, Stephen Kent wrote: > At 4:11 PM -0400 7/21/99, Y. John Jiang wrote: > > >Certificate authentication is prone to key board monitoring attack. > >If one leaves the hard token in the PCMCIA slot, it is as weak as > >a soft token. > > No well-engineered hardware device should be capable of having it's private > key(s) extracted via a software attack effected through a PC to which it is > connected. Depending on the engineering of the device one might carry out > various forms of close-in attacks, if the device is enabled and physically > available to an attacker. Certainly one could initiate new SAs that the > user might not really want to authorize (but that's a problem in any case). > What eacctly did you have in mind when you made the above statement/ > > Steve > From owner-ipsec@lists.tislabs.com Wed Jul 21 19:18:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA12231; Wed, 21 Jul 1999 19:18:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17316 Wed, 21 Jul 1999 21:05:29 -0400 (EDT) Message-Id: <3.0.5.32.19990721180703.0104c8c0@10.1.10.20> X-Sender: fletcher@10.1.10.20 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jul 1999 18:07:03 -0500 To: ipsec@lists.tislabs.com From: fletcher@cylink.com (Fergus Fletcher) Subject: Checking incoming traffic against SPD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question concerning inbound IPsec processing. RFC-2401 describes how incoming traffic should be handled, (section 5.2 Processing Inbound IP Traffic): "1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. . . . 2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. . . . Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. . . . 3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD. 4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3). NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. " Question: How can the first inbound policy found not be -------- the correct policy, except when security gateways are inconsistently configured ? Thanks, Fergus -- Tel. : (408) 328-5445 E-mail: fletcher@cylink.com -- Fax. : (408) 735-6645 -- Cylink Corporation, -- 910 Hermosa Court , Sunnyvale, CA 94086 From owner-ipsec@lists.tislabs.com Wed Jul 21 23:34:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA22354; Wed, 21 Jul 1999 23:34:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25440 Thu, 22 Jul 1999 01:05:19 -0400 (EDT) Message-Id: <3.0.6.32.19990722103026.0134f100@hydmail> X-Sender: rohit@hydmail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 22 Jul 1999 10:30:26 To: fletcher@cylink.com (Fergus Fletcher) From: Rohit Aradhya Subject: Re: Checking incoming traffic against SPD Cc: ipsec@lists.tislabs.com In-Reply-To: <3.0.5.32.19990721180703.0104c8c0@10.1.10.20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Fergus, This problem arises only when you are sharing an SA with diffrent SPD Entries, resulting in a SA having backlinks to more than one SPD entries.. In this scenerio there is a possibility of mismatch in "kind and order" of SAs of Inbound Policy. -Regards Rohit At 06:07 PM 7/21/99 -0500, you wrote: >I have a question concerning inbound IPsec processing. > >RFC-2401 describes how incoming traffic should be handled, >(section 5.2 Processing Inbound IP Traffic): > >"1. Use the packet's destination address (outer IP header), > IPsec protocol, and SPI to look up the SA in the SAD. > . . . > > 2. Use the SA found in (1) to do the IPsec processing, e.g., > authenticate and decrypt. This step includes matching the > packet's (Inner Header if tunneled) selectors to the > selectors in the SA. > . . . > Do (1) and (2) for every IPsec header until a Transport > Protocol Header or an IP header that is NOT for this > system is encountered. > . . . > 3. Find an incoming policy in the SPD that matches the > packet. This could be done, for example, by use of > backpointers from the SAs to the SPD or by matching the > packet's selectors (Inner Header if tunneled) against > those of the policy entries in the SPD. > > 4. Check whether the required IPsec processing has been > applied, i.e., verify that the SA's found in (1) and (2) > match the kind and order of SAs required by the policy > found in (3). > > NOTE: The correct "matching" policy will not necessarily > be the first inbound policy found. If the check in (4) > fails, steps (3) and (4) are repeated until all policy > entries have been checked or until the check succeeds. " > > >Question: How can the first inbound policy found not be >-------- the correct policy, except when security > gateways are inconsistently configured ? > > >Thanks, Fergus > > > >-- Tel. : (408) 328-5445 E-mail: fletcher@cylink.com >-- Fax. : (408) 735-6645 >-- Cylink Corporation, >-- 910 Hermosa Court , Sunnyvale, CA 94086 > From owner-ipsec@lists.tislabs.com Thu Jul 22 03:11:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA27725; Thu, 22 Jul 1999 03:11:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04213 Thu, 22 Jul 1999 04:27:17 -0400 (EDT) Message-Id: <3.0.5.32.19990722112723.00a20100@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 11:27:23 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: XAUTH is broken 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 EAA04209 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk About XAUTH: Doing multiple cfg-exchanges with the same message-id is just not possible. There are a several ways out of the mess: 1) Do two or three cfg-exchanges. message-id changes. The exchanges have the same ISAKMP cookies, thus the state information can be kept with the phase-1 data. 2) Invent a new exchange. xauth would not use cfg-mode. 3) Cut down XAUTH. Only one cfg-exchange is done: IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> And that's it. If the password is wrong, the phase-1 is killed with an informational exchange carrying a notify payload AUTHENTICATION_FAILED. I'd vote for 1). Jörn Sierwald From owner-ipsec@lists.tislabs.com Thu Jul 22 04:37:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00297; Thu, 22 Jul 1999 04:37:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08814 Thu, 22 Jul 1999 06:08:23 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCA86819@new-exc1.ctron.com> From: "Waters, Stephen" To: "David P. Kemp" Cc: ipsec@lists.tislabs.com Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication Date: Thu, 22 Jul 1999 11:07:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This started, I think, as a debate about certificates v passwords, but does seem to be going in the IKE direction :) In your mail, are you suggesting that the client device is only loaded with part of the private key, and that the remainder is entered when the client device connects? If so, I think this can still be cracked off-line. If we are using certificates, the client's public certificate (with public key) is very much available. It may take some time (I've no idea how long!), but couldn't I still work on the portion of the private key (the majority of which is stored on the client device somehow) until I had reconstructed the private key to match the public key? Cheers, Steve. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Wednesday, July 21, 1999 4:49 PM To: ietf-pkix@imc.org Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication That sounds like an interesting approach when a user's public key is public. But I assume from the IKE/XAUTH discussion that: 1) the VPN server authenticates itself to the client and establishes confidentiality for a secondary authentication of the client to the server. 2) the VPN server has some unique secret knowledge about the user, established by some enrollment process, that allows it to determine if the user has typed the correct password/pin. Otherwise, the thief could set up his own VPN server from public information, configure the stolen client to authenticate the bogus server, and start guessing passwords. My suggestion is that if the VPN server must have some secret knowledge of the user, then that secret might as well be the larger component of a keypair generated during enrollment. The client would get the smaller component, a private key which can not be determined by offline trial decryption. This eliminates the need for a secondary XAUTH protocol, since the normal IKE handshake provides the benefit claimed for XAUTH. KISS. Dave Kemp (Why are we discussing IKE on the PKIX list?) > From: Stephen Kent > > Stephen and David, > > There is another approach here, that I first heard suggested by Jeff > Schiller a number of years ago. One could remember a pass phrase and use it > as the seed for a PRNG, which then feeds into a key pair selection > algorithm, thus recreating one's private key, rather than storing it. It > occurs to me that some additonal entropy could be provided by a second seed > value, saved in encrypted form and decrypted with the pass phrase. because > this second value would be random (preferavly from a non-deterministic > source) attempts to decrypt it do not yield quick confirmation of gusses. > Instead, one has to try to use the pair of values (the pass phrase guess > and the decrypted second seed), to genreate a key pair, and then check to > see if the result yields the public key for the user. This approach is > clearly much, much slower that just decrypting a stored key, but it allows > a greater degree of security vs. a stored private key encrypted with a > password, and makes offline guessing attacks more costly. Also, because > one hash complete freedom in choosing the pass phrase, it should be easier > to remember than a string of words formed from the bit pattern of a private > key. > > Just a thought, > > Steve From owner-ipsec@lists.tislabs.com Thu Jul 22 05:33:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA00885; Thu, 22 Jul 1999 05:33:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11497 Thu, 22 Jul 1999 07:09:00 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCA86824@new-exc1.ctron.com> From: "Waters, Stephen" To: Dennis Glatting Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 12:07:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Fair comment Dennis - passwords are a mess, wherever they are used. A shame really - a well chosen, well kept password does provide a hard nut to crack off-line, but the users can't be trusted to keep them safe. So what are we left with? If the end-user can't remember a simple pin number for a Token card/Smartcard without writing it down, what is left? That sort of blows all legacy mechanisms. Maybe if we write down the ideal requirements, something will pop-up (humm): 1) no passwords needed, since passwords get written down! 2) client authentication that can not be cracked off-line 3) a single, strong authentication mechanism that can be used without the need of XAUTH Without passwords/pin-numbers, we need some other way of validating that the user of the authentication information is the owner - like have a photo on a driving license. For VPNs, the best hope at the moment seems to be biometric cards. There have been some doubts expressed about the physical security of these cards on this list, so they need to be fixed somehow. The boimetric reader needs to be tightly coupled with the private-key access logic such that if any tampering occurs, the private key is history. In the meantime, it looks like we can't get away from some form of password/pin number. And if that is the case, I intend to use XAUTH to prevent off-line cracking. If the password is given-up easily (written down, or spoken loudly), then all bets are off. If it is treated with reverence, then XAUTH helps. Steve. -----Original Message----- From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] Sent: Wednesday, July 21, 1999 7:30 PM To: Tamir Zegman Cc: Scott G. Kelly; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid On Wed, 21 Jul 1999, Tamir Zegman wrote: > > > > "Scott G. Kelly" wrote: > > > Tamir Zegman wrote: > > > > > > Dennis Glatting wrote: > > > > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > > be the IPsec authentication mechanism of choice until products mature > > > > and prices decline. The difference between simple shared secrets and > > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > > manage, managed shared secret technologies yielding, in my opinion, no > > > > motivation to improve the security of infrastructures (i.e., > > > > transition to PKI). Is this where we want to be after several years of > > > > work and some cantankerous meetings? > > > > > > > > > > There is another side for this coin. > > > We have many customers that are deferring their migration to IPSec because > > > they feel they are not ready to deploy a full scale PKI. > > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > > of PKI. > > > Sometimes it's easier to jump over two small hurdles rather than over a > > > big one. > > > > I agree with Tamir on this point, but think that if we are indeed > > viewing this (xauth, hybrid) as an intermediate step, then we should > > make this exceedingly clear, and the transition path should be clearly > > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > > > > > > I offer the following suggestions. First, finish a combined > > > > xauth/hybrid draft and classify it as experimental. Second, the > > > > Security Considerations section of the draft be written not by the > > > > draft's proponents but by at least two of its detractors. Finally, set > > > > a deadline (perhaps three years) where the PS is committed to > > > > historic. > > > > > > I'll accept your offer with regard to the Security Consideration section. > > > Any volunteers? > > > I do not believe that the experimental is the right track for this. > > > > I'd be willing to contribute to the security considerations text. > > > > I'm not sure if the experimental track is right or not, though I do > > think that somehow limiting the lifetime of password-based approaches > > has a certain appeal. We must grease the skids for PKI deployment, and > > not simply provide an excuse for maintaining the status quo, but this is > > a complex issue. That is why I think we need a working group to iron it > > out. > > > > Scott > > Hi Scott, > > I think that there is a consensus that static passwords are BAD. > XAUTH/Hybrid are not there to support static passwords but to > support stronger authentication schemes. In some cases PKI with > "soft" tokens are even less secure than legacy authentication > schemes such as SecurID tokens. In the absence of PKI, IKE users > will fall back to use pre-shared keys. Do we want that? In some > aspects IKE pre-shared secrets are even less secure than > XAUTH/Hybrid with fixed passwords since they are susceptible to > off-line dictionary attacks. Why not ban pre-shared secrets? > One of the key differences is XAUTH/hybrid provides no incentive to move to PKI whereas pre-shared secrets by virtue of being unmanageable does. However, just to throw a little personal experience for perspective in favor of shared secrets, whether XAUTH/hybrid provided or pre-shared secrets, I offer the following story. One of my clients has an IKE capable firewall. I decided to purchase the vendor's certificate based solution because I believe a certificate based solution offers better security, it inexpensively introduces my client to certificate based thinking, and it was a slam-dunk -- I didn't have to think about it. :) I purchased the recently released software in May of 1999 and discovered, after five weeks, I had to downgrade my NT server to a non-y2k patch level and the software itself wasn't y2k. I returned the software and went the pre-shared secret route. Even with PKI there is still a password problem: the user's password used to encrypt their private key. People do stupid things including choosing stupid passwords. Many users still write their passwords on pieces of paper and attach them to their terminals, or write them down on mouse pads, or write them down on a sheet just inside their top desk drawer, sometimes labeled "password." In one case a women could not remember her ID and password to save her life. Eventually I changed her password to her husband's name without any character substitutions. She could not remember that one, too. So, whether you are using certificates, smart cards, or anything else that is password related, the question is: what's the difference between having xauth/hybrid and not having it? Strictly looking at passwords, a central service can impose good password selection mechanisms as can client software; However, a central service is in a better position to perform an off-line dictionary attack to assure good choice. When I think about the problems xauth/hybrid address I think of Bart Simpson's immortal words (stolen from somewhere else, I bet) "you're damned if you do and you're damned if you don't." I believe XAUTH/hybrid offers something valuable but should not be encouraged. -dpg From owner-ipsec@lists.tislabs.com Thu Jul 22 06:46:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA01792; Thu, 22 Jul 1999 06:46:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA13631 Thu, 22 Jul 1999 07:56:50 -0400 (EDT) Message-ID: <379707AC.B93B29E1@checkpoint.com> Date: Thu, 22 Jul 1999 14:59:40 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg Carter CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <01E1D01C12D7D211AFC70090273D20B1B8F8DB@sothmxs06.entrust.com> Content-Type: multipart/alternative; boundary="------------D6755A718FA47231388316A3" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------D6755A718FA47231388316A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Greg, Let me try to answer the questions you have posed: Greg Carter wrote: > Hi, > How are PKI 'soft' tokens (by that I guess you mean private keys stored on > disk, password protected) less secure? > > How is a one way proprietary authentication scheme more secure than mutual > authentication? with shared secrets or PKI? Its been awhile since I looked > at the internals of the ACE server but I believe it too uses DES shared > secrets between the server and the NAS, Most of the other DES based token > cards rely on RADIUS to act as their authentication server, so now we are > down to MD5 hiding. > > One way authentication is pointless, IMHO. > I agree - One way authentication is indeed pointless. But that's not what Hybrid is all about. In Hybrid you first authenticate the Gateway using signatures. Only then you authenticate the client using "legacy" authentication schemes. Authentication is mutual but different methods are employed to authenticate the client and the Gateway, hence the term Hybrid. > > Oh, what about soft tokens, most of the DES based challenge/response token > vendors offer software based tokens, I believe SecurID does as well. So how > does your SGW know if the user is using a true hardware token or a soft > token, it doesn't. A soft token will be susceptible to the same attacks as > your shared key file, yet offers only one way authentication. > Again I agree. It might be that I was misunderstood. I argue that in some cases hardware based legacy authentication schemes (e.g. SecurID cards) have advantages over PKI software tokens. One can copy your software token without you even noticing it and then mount on it an offline dictionary attack. I agree that XAUTH/Hybrid can be abused by employing weak authentication methods. I don't endorse static passwords or other weak authentication methods and I believe they should not be used. I do believe that there are strong legacy authentication methods. They are widely used today and should be supported. Regards, Tamir. --------------D6755A718FA47231388316A3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Greg,
Let me try to answer the questions you have posed:

Greg Carter wrote:

Hi,
How are PKI 'soft' tokens (by that I guess you mean private keys stored on
disk, password protected) less secure?

How is a one way proprietary authentication scheme more secure than mutual
authentication? with shared secrets or PKI?  Its been awhile since I looked
at the internals of the ACE server but I believe it too uses DES shared
secrets between the server and the NAS, Most of the other DES based token
cards rely on RADIUS to act as their authentication server, so now we are
down to MD5 hiding.

One way authentication is pointless, IMHO.
 

I agree - One way authentication is indeed pointless. But that's not what Hybrid is all about.
In Hybrid you first authenticate the Gateway using signatures. Only then you authenticate the client using "legacy" authentication schemes.
Authentication is mutual but different methods are employed to authenticate the client and the Gateway, hence the term Hybrid.
 
Oh, what about soft tokens, most of the DES based challenge/response token
vendors offer software based tokens, I believe SecurID does as well.  So how
does your SGW know if the user is using a true hardware token or a soft
token, it doesn't.  A soft token will be susceptible to the same attacks as
your shared key file, yet offers only one way authentication.
 
Again I agree.
It might be that I was misunderstood.
I argue that in some cases hardware based legacy authentication schemes (e.g. SecurID cards) have advantages over PKI software tokens.
One can copy your software token without you even noticing it and then mount on it an offline dictionary attack.

I agree that XAUTH/Hybrid can be abused by employing weak authentication methods.
I don't endorse static passwords or other weak authentication methods and I believe they should not be used.
I do believe that there are strong legacy authentication methods. They are widely used today and should be supported.

Regards,
Tamir.
  --------------D6755A718FA47231388316A3-- From owner-ipsec@lists.tislabs.com Thu Jul 22 07:36:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02342; Thu, 22 Jul 1999 07:36:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16081 Thu, 22 Jul 1999 08:51:03 -0400 (EDT) Message-ID: <005a01bed442$4bc27dc0$634cf526@east.isi.edu> From: "Aaron Griggs" To: , "Fergus Fletcher" References: <3.0.5.32.19990721180703.0104c8c0@10.1.10.20> Subject: Re: Checking incoming traffic against SPD Date: Thu, 22 Jul 1999 09:01:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3. Find an incoming policy in the SPD that matches the > packet. This could be done, for example, by use of > backpointers from the SAs to the SPD or by matching the > packet's selectors (Inner Header if tunneled) against > those of the policy entries in the SPD. > > 4. Check whether the required IPsec processing has been > applied, i.e., verify that the SA's found in (1) and (2) > match the kind and order of SAs required by the policy > found in (3). > > NOTE: The correct "matching" policy will not necessarily > be the first inbound policy found. If the check in (4) > fails, steps (3) and (4) are repeated until all policy > entries have been checked or until the check succeeds. " > > > Question: How can the first inbound policy found not be > -------- the correct policy, except when security > gateways are inconsistently configured ? > > This can occur because the inbound security policies (SP) are not required to be in order. So if you do the inbound verification by matching the selectors to the inbound SP list, you could hit a policy that matches but the SA does not. You must keep checking to find the correct SP. An alternative is to use the SA found during the inbound packet processing and do a check of the SP (if the SA has a back pointer to the SP). However in the case of bypass or drop, no SA is found and you still need to search the inbound SPs. A previous email mentioned this occurs due to the sharing of SAs. Can you even share SAs since they are really instantiations of the SP entry (many SAs to one SP)? Aaron From owner-ipsec@lists.tislabs.com Thu Jul 22 07:37:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02352; Thu, 22 Jul 1999 07:37:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15542 Thu, 22 Jul 1999 08:39:05 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC40BF0@exchange> From: Tim Jenkins To: Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Thu, 22 Jul 1999 08:41:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can you explain why you say that doing multiple config-exchanges with the same message-id is not possible? Is it because of the current definition of config-exchange? (BTW, we do what you say cannot be done...) --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] Sent: July 22, 1999 4:27 AM To: ipsec@lists.tislabs.com Subject: XAUTH is broken About XAUTH: Doing multiple cfg-exchanges with the same message-id is just not possible. From owner-ipsec@lists.tislabs.com Thu Jul 22 08:49:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03138; Thu, 22 Jul 1999 08:49:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18736 Thu, 22 Jul 1999 09:49:02 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8E5@sothmxs06.entrust.com> From: Greg Carter To: "'Tim Jenkins'" , Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Thu, 22 Jul 1999 09:48:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tim, Yes you do it, however you are are not compatible with Config mode. It is broken because Config mode states quite clearly that the Message ID is for ONE config exchange (one sequence of Request-Reply or one of Set-Ack). Then you can clear state, if I wrote a Config implementation, then you sent me an XAUTH exchange I would toss your SET message because I would have no idea how to decrypt it. To be compatible with XAUTH my generic Config implementation has to keep indefinitely around state just in case you want to send me the second Set-Ack transaction which needs the IV, Key etc... from the first. Please see my other posts. Bye. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, July 22, 1999 8:41 AM To: Joern Sierwald; ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Can you explain why you say that doing multiple config-exchanges with the same message-id is not possible? Is it because of the current definition of config-exchange? (BTW, we do what you say cannot be done...) --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] Sent: July 22, 1999 4:27 AM To: ipsec@lists.tislabs.com Subject: XAUTH is broken About XAUTH: Doing multiple cfg-exchanges with the same message-id is just not possible. From owner-ipsec@lists.tislabs.com Thu Jul 22 08:49:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03149; Thu, 22 Jul 1999 08:49:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18854 Thu, 22 Jul 1999 09:51:08 -0400 (EDT) Message-Id: <3.0.6.32.19990722191652.013619a0@hydmail> X-Sender: rohit@hydmail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 22 Jul 1999 19:16:52 To: "Aaron Griggs" , , "Fergus Fletcher" From: Rohit Aradhya Subject: Re: Checking incoming traffic against SPD Cc: In-Reply-To: <005a01bed442$4bc27dc0$634cf526@east.isi.edu> References: <3.0.5.32.19990721180703.0104c8c0@10.1.10.20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Sorry it seems i am not in sync with latest IPSec RFC, I think Sharing of SAs was present in some earlier IPSec drafts.. later it was removed. If SAs are instantiation of a single SPD entry then first matching Inbound Policy will definetly have "the kind and order of SAs" required, *iff* you have backpointer from SAs to the SPD entry. -Regards Rohit At 09:01 AM 7/22/99 -0400, Aaron Griggs wrote: >> 3. Find an incoming policy in the SPD that matches the >> packet. This could be done, for example, by use of >> backpointers from the SAs to the SPD or by matching the >> packet's selectors (Inner Header if tunneled) against >> those of the policy entries in the SPD. >> >> 4. Check whether the required IPsec processing has been >> applied, i.e., verify that the SA's found in (1) and (2) >> match the kind and order of SAs required by the policy >> found in (3). >> >> NOTE: The correct "matching" policy will not necessarily >> be the first inbound policy found. If the check in (4) >> fails, steps (3) and (4) are repeated until all policy >> entries have been checked or until the check succeeds. " >> >> >> Question: How can the first inbound policy found not be >> -------- the correct policy, except when security >> gateways are inconsistently configured ? >> >> > >This can occur because the inbound security policies (SP) are not required >to be in order. So if you do the inbound verification by matching the >selectors to the inbound SP list, you could hit a policy that matches but >the SA does not. You must keep checking to find the correct SP. An >alternative is to use the SA found during the inbound packet processing and >do a check of the SP (if the SA has a back pointer to the SP). However in >the case of bypass or drop, no SA is found and you still need to search the >inbound SPs. > >A previous email mentioned this occurs due to the sharing of SAs. Can you >even share SAs since they are really instantiations of the SP entry (many >SAs to one SP)? > >Aaron > From owner-ipsec@lists.tislabs.com Thu Jul 22 08:49:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03158; Thu, 22 Jul 1999 08:49:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19840 Thu, 22 Jul 1999 10:11:22 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8E6@sothmxs06.entrust.com> From: Greg Carter To: "'Waters, Stephen'" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 10:10:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Stephen, Not to be flippant but fortunately the first two are outside the scope of IPSec, the last already exists in IKE. We can not engineer IKE to the point of requiring Tempest shielded workstations... If an attacker can install a keyboard monitoring app, then why can't they install a shim to monitor IP traffic, which would make all the authentication in the world useless since they can just grab the plain text. If your software allows trivial passwords, or stores private keys/shared keys in the clear, or any of the other arguments I have heard for one-way auth... then its less than adequate to say the least. I actually have no problems in allowing vendors to do XAUTH, I have no doubts that any implementation that requires the user to enter two passwords, a challenge and a response and only provide one way authentication will never win in the market. I have problems with such a protocol being developed (and market) under the notion that it is some how more secure than the current IKE authentication mechanisms. Bye. -----Original Message----- From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] Sent: Thursday, July 22, 1999 7:08 AM To: Dennis Glatting Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Maybe if we write down the ideal requirements, something will pop-up (humm): 1) no passwords needed, since passwords get written down! 2) client authentication that can not be cracked off-line 3) a single, strong authentication mechanism that can be used without the need of XAUTH From owner-ipsec@lists.tislabs.com Thu Jul 22 08:52:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03191; Thu, 22 Jul 1999 08:52:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18292 Thu, 22 Jul 1999 09:40:15 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 22 Jul 1999 09:34:49 -0400 To: "Y. John Jiang" From: Stephen Kent Subject: Re: Comment on xauth and hybrid Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:11 PM -0400 7/21/99, Y. John Jiang wrote: >I did not mean the hacker needed to extract the key. The scenario >is like this: >1. A trojan is installed on a user's PC (btw, this has become very >popular). >2. The pass phrase is captured by monitoring the user's keystrokes. >3. The hacker logs into the PC and then logs into the user's bank account >which requires certificate authentication. > >True, a well-engineered hardware device does not allow the capture of >the pass phrase. Adding a small keyboard on the hard token would help. >However, the popular hard tokens on the market all rely on the PC >keyboard for pass phrase input. I agree that this sort of TH attack would be successful, but this is only slightly different from having a TH take advantage of an already-enabled token of any sort, irrespectove of keystroke capture. Users are not likely to be willing to have to re-enter a PIN/passphrase every time they wat to enable a token. Once per "session" is about it. So, having a key[ad on a token help a bit, but also is not a complete solution. Steve From owner-ipsec@lists.tislabs.com Thu Jul 22 08:53:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03204; Thu, 22 Jul 1999 08:53:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19510 Thu, 22 Jul 1999 10:04:16 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC40C6A@exchange> From: Tim Jenkins To: Greg Carter , Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Thu, 22 Jul 1999 10:06:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 KAA19506 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg,   >From Stephane's reply to your other posts, I got the impression that he was re-defining XAUTH to state that it used config-exchange message formats, and that it was over-riding the 2 message limitation of that exchange.   However, it might make more sense that XAUTH be given a new exchange value since it is open ended. This would also help with IKE state handling, since it would make looking for the result of authentication a little easier. This is as Joern's number 2 suggestion (copied below), and would be my preferred route.   Another suggestion not mentioned is to remove the config-exchange restriction from being only 2 messages.   >From Joern's earlier post:   1) Do two or three cfg-exchanges. message-id changes. The exchanges have the same ISAKMP cookies, thus the state information can be kept with the phase-1 data. 2) Invent a new exchange. xauth would not use cfg-mode. 3) Cut down XAUTH. Only one cfg-exchange is done:    IPSec Host                                              Edge Device    --------------                                    -----------------                           <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> 4) Change config-exchange to be open ended. Opinions? --- Tim Jenkins                       TimeStep Corporation tjenkins@timestep.com          http://www.timestep.com (613) 599-3610 x4304               Fax: (613) 599-3617   -----Original Message----- From: Greg Carter [mailto:greg.carter@entrust.com] Sent: July 22, 1999 9:48 AM To: 'Tim Jenkins'; Joern Sierwald; ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Hi Tim, Yes you do it, however you are are not compatible with Config mode.  It is broken because Config mode states quite clearly that the Message ID is for ONE config exchange (one sequence of Request-Reply or one of Set-Ack).  Then you can clear state, if I wrote a Config implementation, then you sent me an XAUTH exchange I would toss your SET message because I would have no idea how to decrypt it. To be compatible with XAUTH my generic Config implementation has to keep indefinitely around state just in case you want to send me the second Set-Ack transaction which needs the IV, Key etc... from the first. Please see my other posts. Bye. -----Original Message----- From: Tim Jenkins [ mailto:tjenkins@TimeStep.com ] Sent: Thursday, July 22, 1999 8:41 AM To: Joern Sierwald; ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Can you explain why you say that doing multiple config-exchanges with the same message-id is not possible? Is it because of the current definition of config-exchange? (BTW, we do what you say cannot be done...) --- Tim Jenkins                       TimeStep Corporation tjenkins@timestep.com          http://www.timestep.com (613) 599-3610 x4304               Fax: (613) 599-3617 -----Original Message----- From: Joern Sierwald [ mailto:joern.sierwald@datafellows.com ] Sent: July 22, 1999 4:27 AM To: ipsec@lists.tislabs.com Subject: XAUTH is broken About XAUTH: Doing multiple cfg-exchanges with the same message-id is just not possible. From owner-ipsec@lists.tislabs.com Thu Jul 22 10:36:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA05344; Thu, 22 Jul 1999 10:36:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22822 Thu, 22 Jul 1999 11:20:44 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8E8@sothmxs06.entrust.com> From: Greg Carter To: "'Tamir Zegman'" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 11:17:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Tamir Zegman [mailto:zegman@checkpoint.com] Sent: Thursday, July 22, 1999 8:00 AM To: Greg Carter Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid Hi Greg, In Hybrid you first authenticate the Gateway using signatures. Only then you authenticate the client using "legacy" authentication schemes. Authentication is mutual but different methods are employed to authenticate the client and the Gateway, hence the term Hybrid. [Greg Carter] Dan has already stated that these methods do not allow for proper authentication of the IKE SA keying material. Also it introduces another DOS attack, where the gateway is forced to do many phase 1 negotiations without ever authenticating the client. [Greg Carter] Given that the client has the code to read and verify certificates why can't it manage its own (or its own shared keys)? If an organization can run an ACE server and manage 10's thousands of hardware cards, why can they run a directory and issue certificates? I argue that in some cases hardware based legacy authentication schemes (e.g. SecurID cards) have advantages over PKI software tokens. One can copy your software token without you even noticing it and then mount on it an offline dictionary attack. [Greg Carter] I meant 'soft' challenge/response tokens: http://www.securitydynamics.com/products/datasheets/securidst-ds.html http://www.axent.com/product/dsbu/def2.htm#secure , which you as a SGW have no way of knowing the user is using. So you can not guarantee that the user is using a 'hard' token, so the arguments that challenge/response tokens are more "secure" than public key are not valid. Bye. From owner-ipsec@lists.tislabs.com Thu Jul 22 10:55:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA05891; Thu, 22 Jul 1999 10:55:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24904 Thu, 22 Jul 1999 12:06:33 -0400 (EDT) Message-ID: <3797438A.98D131E2@raptor.com> Date: Thu, 22 Jul 1999 12:15:06 -0400 From: Ioannis Bonias Organization: Raptor Systems, Inc X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg Carter CC: "'Tim Jenkins'" , Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: XAUTH is broken References: <01E1D01C12D7D211AFC70090273D20B1B8F8E5@sothmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is it broken or not? I think we have to come to an agreement very soon if we want people to implement xauth and get some interoperability testing in the coming bakeoffs. In previous messages Greg carter has brought up some good points regarding the isakmp header message id. Stephane Beaulieu, in a previous message, proposed a change in the draft that fixes the problem. (section 3: All ISAKMP_Config messages in an extended auth transaction will contain same message id...). The main point that Greg raised was how someone determines at any given time of a config mode exchange if should wait for another message or clear state. Before we answer this question i suggest that we clearly state in the draft in section 2, 1st paragraph, that an xauth session MUST always end with a SET/ACKconfig mode exchange. Then the answer to the question becomes trivial: if the FIRST attribute in an ISAKMP_CFG_REQUEST has value in closed interval [13,21] then you know this is an xauth exchange. Therefore the responder knows that the exchange is over when sending an ACK and the initiator knows it is over when receiving the ACK. Note that any other config mode exchange where the FIRST attribute value is not in [13,21] must be treated as a single config mode request/reply or set/ack exchange and therefore the responder/initiator clear state after sent/received reply. yannis Greg Carter wrote: > Hi Tim, > Yes you do it, however you are are not compatible with Config mode. It is > broken because Config mode states quite clearly that the Message ID is for > ONE config exchange (one sequence of Request-Reply or one of Set-Ack). Then > you can clear state, if I wrote a Config implementation, then you sent me an > XAUTH exchange I would toss your SET message because I would have no idea > how to decrypt it. > > To be compatible with XAUTH my generic Config implementation has to keep > indefinitely around state just in case you want to send me the second > Set-Ack transaction which needs the IV, Key etc... from the first. > > Please see my other posts. > Bye. > > -----Original Message----- > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > Sent: Thursday, July 22, 1999 8:41 AM > To: Joern Sierwald; ipsec@lists.tislabs.com > Subject: RE: XAUTH is broken > > Can you explain why you say that doing multiple config-exchanges with the > same message-id is not possible? > > Is it because of the current definition of config-exchange? > > (BTW, we do what you say cannot be done...) > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > -----Original Message----- > From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] > Sent: July 22, 1999 4:27 AM > To: ipsec@lists.tislabs.com > Subject: XAUTH is broken > > About XAUTH: > Doing multiple cfg-exchanges with the same message-id is just > not possible. -- Ioannis Bonias, PhD Axent Technologies, INC. /Raptor Division email : ibonias@raptor.com phone : 781.530.2359 fax : 781.487.9372 From owner-ipsec@lists.tislabs.com Thu Jul 22 11:04:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06145; Thu, 22 Jul 1999 11:04:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25170 Thu, 22 Jul 1999 12:16:42 -0400 (EDT) Message-ID: <37974497.C682DC06@checkpoint.com> Date: Thu, 22 Jul 1999 19:19:35 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg Carter CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <01E1D01C12D7D211AFC70090273D20B1B8F8E8@sothmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg Carter wrote: > -----Original Message----- > From: Tamir Zegman [mailto:zegman@checkpoint.com] > Sent: Thursday, July 22, 1999 8:00 AM > To: Greg Carter > Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org > Subject: Re: Comment on xauth and hybrid > > Hi Greg, > In Hybrid you first authenticate the Gateway using signatures. Only then you > authenticate the client using "legacy" authentication schemes. > Authentication is mutual but different methods are employed to authenticate > the client and the Gateway, hence the term Hybrid. > > [Greg Carter] Dan has already stated that these methods do not allow for > proper authentication of the IKE SA keying material. Also it introduces > another DOS attack, where the gateway is forced to do many phase 1 > negotiations without ever authenticating the client. > I think that Dan was talking about the use of a global pre-shared key in Phase1. This is not Hybrid. Could you refer me to that above mentioned thread? With regard to DoS attacks this weakness is inherent to IKE as it is today: I assume you are not talking about Aggressive mode which opens you to very vicious DoS attacks no matter what authentication you are using but on MainMode. There are three cases we need to consider: 1. The client is spoofing its address - in which case the cookie mechanism protects the server and no DoS is possible (unless the client is in between the server and the spoofed address, see 2.). 2. The client is using his own address but does not do any DH exponentiations - In which case the server will be forced to do 2 DH exponentiations no matter what authentication method is used. 3. The client is using his own address and is doing the DH computations (well actually it can use 2^1 as a public key and thus save on the DH computations): In Hybrid authentication the server will need to do 2 DH computations + 1 DSA/RSA signature operation while the client will need to do 2 DH computations. In Signature authentication the server will need to do 2 DH computations + 1 DSA/RSA verification operation while the client will need to do 2 DH computations. I don't see much difference since DH has a bigger computational overhead. Oh, one more thing, if you use DSA, then verification is actually more expensive than signature. So Hybrid is even better in that respect. > > [Greg Carter] Given that the client has the code to read and verify > certificates why can't it manage its own (or its own shared keys)? If an > organization can run an ACE server and manage 10's thousands of hardware > cards, why can they run a directory and issue certificates? > > Well they can but they already have the ACE server infrastructure and are hesitant on having a fast transition to PKI. > I argue that in some cases hardware based legacy authentication schemes > (e.g. SecurID cards) have advantages over PKI software tokens. > One can copy your software token without you even noticing it and then mount > on it an offline dictionary attack. > > [Greg Carter] I meant 'soft' challenge/response tokens: > > http://www.securitydynamics.com/products/datasheets/securidst-ds.html > > > http://www.axent.com/product/dsbu/def2.htm#secure > > > , which you as a SGW have no way of knowing the user is using. So you can > not guarantee that the user is using a 'hard' token, so the arguments that > challenge/response tokens are more "secure" than public key are not valid. > I think we agree. I was talking about hardware legacy tokens while you are discussing software. I was not trying to say that Hybrid is better than signatures but that in some situations it is not much worse. Tamir & Moshe. From owner-ipsec@lists.tislabs.com Thu Jul 22 11:23:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06611; Thu, 22 Jul 1999 11:23:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25620 Thu, 22 Jul 1999 12:26:34 -0400 (EDT) Message-Id: <3.0.5.32.19990722092759.0102fb00@10.1.10.20> X-Sender: fletcher@10.1.10.20 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 09:27:59 -0500 To: , rohit@mihy.mot.com From: fletcher@cylink.com (Fergus Fletcher) Subject: Re: Checking incoming traffic against SPD Cc: ipsec@lists.tislabs.com In-Reply-To: <005a01bed442$4bc27dc0$634cf526@east.isi.edu> References: <3.0.5.32.19990721180703.0104c8c0@10.1.10.20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:01 AM 7/22/99 -0400, you wrote: >> 3. Find an incoming policy in the SPD that matches the >> packet. This could be done, for example, by use of >> backpointers from the SAs to the SPD or by matching the >> packet's selectors (Inner Header if tunneled) against >> those of the policy entries in the SPD. >> >> 4. Check whether the required IPsec processing has been >> applied, i.e., verify that the SA's found in (1) and (2) >> match the kind and order of SAs required by the policy >> found in (3). >> >> NOTE: The correct "matching" policy will not necessarily >> be the first inbound policy found. If the check in (4) >> fails, steps (3) and (4) are repeated until all policy >> entries have been checked or until the check succeeds. " >> >> >> Question: How can the first inbound policy found not be >> -------- the correct policy, except when security >> gateways are inconsistently configured ? >> >> > >This can occur because the inbound security policies (SP) are not required >to be in order. So if you do the inbound verification by matching the >selectors to the inbound SP list, you could hit a policy that matches but >the SA does not. You must keep checking to find the correct SP. An >alternative is to use the SA found during the inbound packet processing and >do a check of the SP (if the SA has a back pointer to the SP). However in >the case of bypass or drop, no SA is found and you still need to search the >inbound SPs. > >A previous email mentioned this occurs due to the sharing of SAs. Can you >even share SAs since they are really instantiations of the SP entry (many >SAs to one SP)? > >Aaron > > Aaron, Rohit: I understood that Inbound SPD entries are ordered. I guess another way of formulating the question would be as follows: Assume the following configuration: SA-1 +----------------+ SGW1 SGW2 +----------------+ SA-2 * SA-1 matches TCP traffic on port 300 * SA-2 matches all TCP traffic SGW1 Inbound SPD: SGW2 Outbound SPD: 1. SA-1 1. SA-2 2. SA-2 2. SA-1 Both SGWs have the same SPD definitions, except that the order of the SAs are reversed. Assume SGW2 tunnels a packet (TCP,port=300) to SGW-1 using SA-2 (per its SPD). At SGW1 the packet will: (1) match the selectors of the SA in which it was sent (2) match an entry in the SPD however it was sent on the wrong SA. Should SGW1 accept it ? -- Tel. : (408) 328-5445 E-mail: fletcher@cylink.com -- Fax. : (408) 735-6645 -- Cylink Corporation, -- 910 Hermosa Court , Sunnyvale, CA 94086 From owner-ipsec@lists.tislabs.com Thu Jul 22 11:55:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07592; Thu, 22 Jul 1999 11:55:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27538 Thu, 22 Jul 1999 13:09:48 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.5.32.19990722092759.0102fb00@10.1.10.20> References: <005a01bed442$4bc27dc0$634cf526@east.isi.edu> <3.0.5.32.19990721180703.0104c8c0@10.1.10.20> Date: Thu, 22 Jul 1999 13:06:42 -0400 To: fletcher@cylink.com (Fergus Fletcher) From: Stephen Kent Subject: Re: Checking incoming traffic against SPD Cc: ipsec@lists.tislabs.com, clynn@bbn.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Fergus, All SPDs are ordered. SAs may be part of SA bundles. This means that the SAD entry for a given SA does not tell what other processing might have to be performed on the packet, consistent with the SPD entry. That is what motivates looking into the SPD to check and see that everything that should be done has been done, after doing everything required by lookups into the SAD based on SPIs and AH/ESP headers encountered during inbound processing. Because SAs might be shared by more than one SA bundle (a complex feature allowed by the architecture in response to concerns voice by implementors and users who were concerned about creating largely duplicative SAs under some circumstances), there may be a need to look at multiple (inbound) SPD entries to ensure that the completed processing is consistent with at least one of these entries. However, I defer to Charlie Lynn, who is responsible for that particular piece of text. he may be able to provide a better rationale. The example you gave, re checking inbound traffic, omits the SAD check, which is where on detects that a received packet does not match the selectors for the SA in question, prior to looking at the SPD. The SPD check is made after the SAD check, to ensure that all the processing expected has been performed. For example, if an SA bundle was established that called for tunnel mode AH followed by transport mode ESP (looking at an end-to-end vs. SGW case). An attacker could strip off AH and forward the packet to the destination. The ESP header would find an appropriate match in the SAD, and the selectors would match just fine. However, this would not be consistent with the processing mandated when these SAs were negotiated, and so the SPD check should discover that and reject the traffic. Steve From owner-ipsec@lists.tislabs.com Thu Jul 22 12:05:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07716; Thu, 22 Jul 1999 12:05:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28250 Thu, 22 Jul 1999 13:41:36 -0400 (EDT) Message-ID: <00af01bed46a$e30db1e0$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Fergus Fletcher" Cc: References: <3.0.5.32.19990721180703.0104c8c0@10.1.10.20> <3.0.5.32.19990722092759.0102fb00@10.1.10.20> Subject: Re: Checking incoming traffic against SPD Date: Thu, 22 Jul 1999 13:51:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Fergus, > I understood that Inbound SPD entries are ordered. I guess > another way of formulating the question would be as follows: > I think it should be and my implementation does require it to be ordered. Maybe later, I'll do a sorting algorithm to order them for the user. Also, most policies are bidirectional so if the outbound is ordered then inbound is ordered. > Assume the following configuration: > > SA-1 > +----------------+ > SGW1 SGW2 > +----------------+ > SA-2 > > * SA-1 matches TCP traffic on port 300 > * SA-2 matches all TCP traffic > > SGW1 Inbound SPD: SGW2 Outbound SPD: > 1. SA-1 1. SA-2 > 2. SA-2 2. SA-1 > > Both SGWs have the same SPD definitions, except that > the order of the SAs are reversed. > > Assume SGW2 tunnels a packet (TCP,port=300) to SGW-1 > using SA-2 (per its SPD). At SGW1 the packet will: > > (1) match the selectors of the SA in which it was sent > (2) match an entry in the SPD > > however it was sent on the wrong SA. > Should SGW1 accept it ? > I'd say no that SGW1 should drop the traffic. Maybe TCP port 300 needs to be more secure so letting traffic in with a different SA is bad. This case is one of the security gateways being "misconfigured." The best way to prevent it from working is to deny the traffic. Aaron From owner-ipsec@lists.tislabs.com Thu Jul 22 12:09:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07742; Thu, 22 Jul 1999 12:09:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28274 Thu, 22 Jul 1999 13:47:38 -0400 (EDT) Message-Id: <3.0.5.32.19990722204714.00bbab90@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jul 1999 20:47:14 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: XAUTH is broken In-Reply-To: <3797438A.98D131E2@raptor.com> References: <01E1D01C12D7D211AFC70090273D20B1B8F8E5@sothmxs06.entrust.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA28271 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:15 22.7.1999 -0400, you wrote: >Is it broken or not? >I think we have to come to an agreement very soon if we want people to >implement xauth and get some interoperability testing in the coming >bakeoffs. > >In previous messages Greg carter has brought up some good points regarding >the isakmp header message id. Stephane Beaulieu, in a previous message, >proposed a change in the draft that fixes the problem. >(section 3: All ISAKMP_Config messages in an extended auth transaction > will contain same message id...). > Stephane did not propose a change, he simply clarified the section. Again, here is the problem. draft-ietf-ipsec-isakmp-mode-cfg-04.txt, chapter 3.1.1: As noted, the message ID in the ISAKMP header-- as used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another exchange. And "this exchange" is a config-exchange, which has two packets. Always. As Grep has pointed out, the cfg-mode draft and the xauth draft contradict each other. IMHO the cfg-mode draft is fine. The xauth draft is wrong, it wants the same message id for several cfg-mode exchanges. Whats the problem with each cfg-mode having a different id? tephane and Tim try to change the specs (the cfg-mode) so that they don't have to change their implementation, but I think we should simply delete the "All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID." part from the xauth draft. --- Jörn Sierwald From owner-ipsec@lists.tislabs.com Thu Jul 22 12:18:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07829; Thu, 22 Jul 1999 12:18:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28330 Thu, 22 Jul 1999 13:53:40 -0400 (EDT) Message-Id: <199907221753.KAA19245@potassium.network-alchemy.com> To: fletcher@cylink.com (Fergus Fletcher) cc: agriggs@east.isi.edu, rohit@mihy.mot.com, ipsec@lists.tislabs.com Subject: Re: Checking incoming traffic against SPD In-reply-to: Your message of "Thu, 22 Jul 1999 09:27:59 CDT." <3.0.5.32.19990722092759.0102fb00@10.1.10.20> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19242.932666006.1@network-alchemy.com> Date: Thu, 22 Jul 1999 10:53:27 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In a case like this I think it's prudent to follow the example of routing and take the longest match regardless of the "ordering" of the SAs. Dan. On Thu, 22 Jul 1999 09:27:59 CDT you wrote > > I understood that Inbound SPD entries are ordered. I guess > another way of formulating the question would be as follows: > > Assume the following configuration: > > SA-1 > +----------------+ > SGW1 SGW2 > +----------------+ > SA-2 > > * SA-1 matches TCP traffic on port 300 > * SA-2 matches all TCP traffic > > SGW1 Inbound SPD: SGW2 Outbound SPD: > 1. SA-1 1. SA-2 > 2. SA-2 2. SA-1 > > Both SGWs have the same SPD definitions, except that > the order of the SAs are reversed. > > Assume SGW2 tunnels a packet (TCP,port=300) to SGW-1 > using SA-2 (per its SPD). At SGW1 the packet will: > > (1) match the selectors of the SA in which it was sent > (2) match an entry in the SPD > > however it was sent on the wrong SA. > Should SGW1 accept it ? From owner-ipsec@lists.tislabs.com Thu Jul 22 12:27:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07957; Thu, 22 Jul 1999 12:27:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28399 Thu, 22 Jul 1999 13:59:14 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8EA@sothmxs06.entrust.com> From: Greg Carter To: "'Tamir Zegman'" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 13:53:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tamir, I think that Dan was talking about the use of a global pre-shared key in Phase1. This is not Hybrid. Could you refer me to that above mentioned thread? Hybrid expects the Secure GW to use keying material it hasn't authenticated yet, to me this is similar to the global shared key case. With regard to DoS attacks this weakness is inherent to IKE as it is today: I assume you are not talking about Aggressive mode which opens you to very vicious DoS attacks no matter what authentication you are using but on MainMode. Except with regular IKE at the end of phase 1 you have authenticated the client, so if it fails you can through away state. Hybrid you must keep the phase 1 state around and do an XAUTH to authenticate the client. Given that most of the XAUTH methods (token cards) are rather lengthy operations I think this is worse, especially given that you'll have to allow for mistyped responses and have to 'retry' the AXUTH a number of times before failing. Or do you force a new phase 1 for each XAUTH attempt? > [Greg Carter] I meant 'soft' challenge/response tokens: > > http://www.securitydynamics.com/products/datasheets/securidst-ds.html > > > http://www.axent.com/product/dsbu/def2.htm#secure > > > , which you as a SGW have no way of knowing the user is using. So you can > not guarantee that the user is using a 'hard' token, so the arguments that > challenge/response tokens are more "secure" than public key are not valid. > I think we agree. I was talking about hardware legacy tokens while you are discussing software. I was not trying to say that Hybrid is better than signatures but that in some situations it is not much worse. I know your were talking about hardware tokens, I was pointing out that it is impossible for your gateway to distinguish a SecurID hardware token user from a SecurID software token user. So how can you make claims that using hardware tokens is better if there is no cryptographic way to prove the client is using them? Again I don't care if others want to do this, just don't claim it is better, or equivalent to existing IKE. Bye. From owner-ipsec@lists.tislabs.com Thu Jul 22 13:13:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08336; Thu, 22 Jul 1999 13:13:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28990 Thu, 22 Jul 1999 14:27:56 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> From: "Waters, Stephen" To: "David P. Kemp" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Secret public keys Date: Thu, 22 Jul 1999 19:26:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, I believe your suggestion (copied below) would fix the off-line cracking problem, and is supported in IKE today. BUT, it has problems in that, to a large extent, it will through VPN role into confusion! The model would be:- Client is loaded with: a) private key (password protected still, just for laughs) b) certificate of VPN server c) certificate of VPN server signer (CA certificate) I can deliver all this information to the client in a PKCS#12 file. As you say, the private key can now be impossible (very hard) to crack, because the client's public key is not accessible (hopefully). The client now 'connects' to the VPN server to engage in a signature authentication passing some id. The problem I have now is mapping that id to the client's public key or certificate in a manageable way. I hope we can agree that managing public-key to id mapping can only be handled by using the CA/certificate approach. For me to be able to find the appropriate certificate, I would need most of the information typically passed (by the client) in a certificate. To back-track a bit. My previous model was to have the VPN client send their certificate as part of the IKE exchange. This allows me greater flexibility. If the client did not send their certificate, a simple id (DN, IP, DNS..) may not be sufficient to resolve the correct certificate. I think (just made it up, so this is probably tosh but..) what is needed to fix this is a new type of certificate, a certificate with no public key in it! When I enrol, the CA would now generate two sister certificates: one 'public' one, and one 'private' one. The 'public' one would contain now public key, but would allow the 'private' certificate to be found using the contain DN/Signer/Serial number. The VPN client is then loaded with the 'public' certificate, and presents this to the VPN server. The VPN server uses this certificate (once tested for trustworthiness) to retrieve the 'private' certificate that does have the public key. Even if this makes sense, is it too late? Steve. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Thursday, July 22, 1999 2:39 PM To: Stephen.Waters@cabletron.com Cc: dpkemp@missi.ncsc.mil; kent@bbn.com Subject: Secret public keys It's not relevant to PKIX anymore, and since I'm not currently subscribed to IPSEC, I won't start a thread there. I was suggesting that the client be loaded with the entire private key, transformed (encrypted) using the password as the encryption key. Assuming private keys are uniformly distributed, there is no way to tell offline when the right password is guessed. And I was suggesting that the "public key" corresponding to the client's private key not be placed in a certificate or be made public - it is kept secret as part of the VPN server's user database. This is precisely Lynn Wheeler's "certificateless account" idea. The server can authenticate the client using the stored public key without ever sending it in a cert over the wire. The user may actually have a certificate and private key which he could use once to sign up for VPN service, but after that initial enrollment, the enrollment-generated keypair would be used in the IKE handshake. The user's certified keypair wouldn't need to be retained on the laptop at all for VPN purposes, and keeping it there for other purposes would not compromise the VPN authentication. Jeff Schiller's procedure mentioned by Steve Kent may increase the cracking effort by 1000x or 10,000x, but it is only a constant (O(1)) increase. I tend to view subexponential processes with caution, and an O(1) process as a band-aid. Increasing the length of the password gives an exponential (O(2^n)) increase in effort, so forcing the user to remember a longer password has big payoffs, but has even bigger pushback from users and marketers. Keeping the VPN public key secret completely precludes offline cracking even with user-friendly short passwords and without any artificial performance degraders. Regards, Dave > From: "Waters, Stephen" > > This started, I think, as a debate about certificates v passwords, but does > seem to be going in the IKE direction :) > > In your mail, are you suggesting that the client device is only loaded with > part of the private key, and that the remainder is entered when the client > device connects? > > If so, I think this can still be cracked off-line. If we are using > certificates, the client's public certificate (with public key) is very much > available. It may take some time (I've no idea how long!), but couldn't I > still work on the portion of the private key (the majority of which is > stored on the client device somehow) until I had reconstructed the private > key to match the public key? > > Cheers, Steve. From owner-ipsec@lists.tislabs.com Thu Jul 22 13:14:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08355; Thu, 22 Jul 1999 13:14:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28909 Thu, 22 Jul 1999 14:23:01 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8EC@sothmxs06.entrust.com> From: Greg Carter To: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Thu, 22 Jul 1999 14:21:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.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 OAA28906 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes I prefer this, if XAUTH wants to use more than one Config exchange than create a new attribute called XAUTH_STATE Set by the initiator and used by both initiator and responder to identify XAUTH exchanges which span multiple Config exchanges. The 4 exchange XAUTH is not ideal either, (above attribute would help fix). If any one has actually used a token card they'll know that it is rather easy to type in the wrong response, forcing another challenge. This would force a new phase 1 (at least how I read the draft) if the first XAUTH failed, but all you want to do is prompt them again... Bye. -----Original Message----- From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] Sent: Thursday, July 22, 1999 1:47 PM To: ipsec@lists.tislabs.com Subject: Re: XAUTH is broken At 12:15 22.7.1999 -0400, you wrote: >Is it broken or not? >I think we have to come to an agreement very soon if we want people to >implement xauth and get some interoperability testing in the coming >bakeoffs. > >In previous messages Greg carter has brought up some good points regarding >the isakmp header message id. Stephane Beaulieu, in a previous message, >proposed a change in the draft that fixes the problem. >(section 3: All ISAKMP_Config messages in an extended auth transaction > will contain same message id...). > Stephane did not propose a change, he simply clarified the section. Again, here is the problem. draft-ietf-ipsec-isakmp-mode-cfg-04.txt, chapter 3.1.1: As noted, the message ID in the ISAKMP header-- as used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another exchange. And "this exchange" is a config-exchange, which has two packets. Always. As Grep has pointed out, the cfg-mode draft and the xauth draft contradict each other. IMHO the cfg-mode draft is fine. The xauth draft is wrong, it wants the same message id for several cfg-mode exchanges. Whats the problem with each cfg-mode having a different id? tephane and Tim try to change the specs (the cfg-mode) so that they don't have to change their implementation, but I think we should simply delete the "All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID." part from the xauth draft. --- Jörn Sierwald From owner-ipsec@lists.tislabs.com Thu Jul 22 14:20:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09252; Thu, 22 Jul 1999 14:20:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29793 Thu, 22 Jul 1999 15:07:12 -0400 (EDT) Message-ID: <37977A43.E7844AC1@checkpoint.com> Date: Thu, 22 Jul 1999 22:08:35 +0200 From: Tamir Zegman X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Greg Carter CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <01E1D01C12D7D211AFC70090273D20B1B8F8EA@sothmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg Carter wrote: > Hi Tamir, > > > Hybrid expects the Secure GW to use keying material it hasn't authenticated > yet, to me this is similar to the global shared key case. I believe there is a difference. When you use a global shared key the client does not really authenticate the server whereas if you use Hybrid the server is authenticated using signatures. The Secure GW does use as you say the keying material before authenticating the client. However this keying material is used only for the following XAUTH exchange. It MUST NOT be used for anything else, specifically it MUST NOT be used for quick mode until XAUTH is successfully completed. < trimmed> > > > With regard to DoS attacks this weakness is inherent to IKE as it is > today: > I assume you are not talking about Aggressive mode which opens you > to very > vicious DoS attacks no matter what authentication you are using but > on MainMode. > > Except with regular IKE at the end of phase 1 you have authenticated the > client, so if it fails you can through away state. Hybrid you must keep the > phase 1 state around and do an XAUTH to authenticate the client. Given that > most of the XAUTH methods (token cards) are rather lengthy operations I > think this is worse, especially given that you'll have to allow for mistyped > responses and have to 'retry' the AXUTH a number of times before failing. > Or do you force a new phase 1 for each XAUTH attempt? > > Yes, I agree. This means that you need to keep state around for a while until the XAUTH is finished. I think that the best practice is to through away the Phase1 SA if XAUTH fails: "If the User fails to authenticate the IKE SA MUST be discarded." < trimmed> > > [Greg Carter] I meant 'soft' challenge/response tokens: > > > > http://www.securitydynamics.com/products/datasheets/securidst-ds.html > > > > > > http://www.axent.com/product/dsbu/def2.htm#secure > > > > > > , which you as a SGW have no way of knowing the user is using. So you can > > not guarantee that the user is using a 'hard' token, so the arguments that > > challenge/response tokens are more "secure" than public key are not valid. > > > > I think we agree. I was talking about hardware legacy tokens while > you are > discussing software. > I was not trying to say that Hybrid is better than signatures but > that in some > situations it is not much worse. > > I know your were talking about hardware tokens, I was pointing out that it > is impossible for your gateway to distinguish a SecurID hardware token user > from a SecurID software token user. So how can you make claims that using > hardware tokens is better if there is no cryptographic way to prove the > client is using them? > > Again I don't care if others want to do this, just don't claim it is better, > or equivalent to existing IKE. > Bye. Yes I agree. But if you issue your workers only hardware tokens then you have no problem with that. Regards, Tamir. From owner-ipsec@lists.tislabs.com Thu Jul 22 14:21:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09261; Thu, 22 Jul 1999 14:21:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00570 Thu, 22 Jul 1999 15:48:21 -0400 (EDT) Message-ID: <00dd01bed47c$8bb7bbe0$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Stephen Kent" Cc: References: <005a01bed442$4bc27dc0$634cf526@east.isi.edu><3.0.5.32.19990721180703.0104c8c0@10.1.10.20> Subject: Re: Checking incoming traffic against SPD Date: Thu, 22 Jul 1999 15:58:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > All SPDs are ordered. I thought there was a statement in the draft before it became RFC2406 stating that the inbound SPD is not required to be ordered, which never made sense to me. Although looking at the RFC, I couldn't find the statement. > Because SAs might be shared by more than one SA bundle (a complex feature > allowed by the architecture in response to concerns voice by implementors > and users who were concerned about creating largely duplicative SAs under > some circumstances), there may be a need to look at multiple (inbound) SPD > entries to ensure that the completed processing is consistent with at > least one of these entries. However, I defer to Charlie Lynn, who is > responsible for that particular piece of text. he may be able to provide a > better rationale. Can someone demonstrate sharing an SA between SA Bundles and the subsequent processing Steve is mentioning? Here is what I consider sharing an SA, which is essentially sharing an SP in my implementation. A ------ SG ---------- ----------- C B---| A and B are hosts protected by security gateway SG. Note my ordering is most specific at the higher numbers. C has the following entries in its SPD: Policy Dst Proto Mode SABundle Direction Action 10 B AH Trans 4 bidirectional IPSec 9 A ESP Trans 4 bidirectional IPSec 4 SG AH Tunnel None bidirectional IPSec 1 * * * None bidirectional Drop This is just the way I do things. Traffic from C to A: IP(C->SG)_AH_IP(C->A)_ESP_Data Traffic from C to B: IP(C->SG)_AH_IP(C->B)_AH_Data I consider policy 4 and hence the SA instantiation shared by the two different SA Bundles. If C just sends traffic to SG, policy 4 is used unless I install a policy above 4. In the case of inbound SP verification for traffic from A to C, policy number 9 is found and it states that there should be an SA Bundle. If there isn't, I drop the packet. If the SA pointed to by SP 4 is wrong, I drop the packet. I don't see (at least in my implementation) this as requiring multiple inbound SP lookups to verify everything was done. Because, you need to know an SA Bundle is required in the first place. You wouldn't want to keep searching the inbound SPD until you found the correct selectors and the right SA would you? It could be that other implementers did something completely different for SA Bundles. Thanks, Aaron From owner-ipsec@lists.tislabs.com Thu Jul 22 14:21:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09277; Thu, 22 Jul 1999 14:21:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00687 Thu, 22 Jul 1999 15:51:41 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC40E3E@exchange> From: Tim Jenkins To: Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Thu, 22 Jul 1999 15:53:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 PAA00683 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] > Sent: July 22, 1999 1:47 PM > To: ipsec@lists.tislabs.com > Subject: Re: XAUTH is broken > > > IMHO the cfg-mode draft is fine. The xauth draft is wrong, > it wants the same message id for several cfg-mode exchanges. > Whats the problem with each cfg-mode having a different id? Because it makes state tracking more difficult. It also doesn't seem to make alot of sense. > > tephane and Tim try to change the specs (the cfg-mode) > so that they don't have to change their implementation, This is a rather unfair and unreasonable accusation. If it turns out that the best solution is to use a new exchange type, we would still have to change our code, and it also one of the suggestions that I already said I prefer. > but I think we should simply delete the > "All ISAKMP-Config messages in an extended authentication > transaction MUST contain the same ISAKMP-Config message ID." > part from the xauth draft. I don't think this is best. Again, tracking authentication over multiple separate exchanges for the sole purpose of meeting another specification doesn't seem to justify the cost in implementation. > > --- > Jörn Sierwald > > From owner-ipsec@lists.tislabs.com Thu Jul 22 14:41:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09578; Thu, 22 Jul 1999 14:41:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01109 Thu, 22 Jul 1999 16:11:05 -0400 (EDT) Posted-Date: Thu, 22 Jul 1999 15:11:16 -0500 (CDT) Message-Id: <4.1.19990722120635.00a08690@mail.visi.com> Message-Id: <4.1.19990722120635.00a08690@mail.visi.com> X-Sender: schneier@mail.visi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 22 Jul 1999 12:07:13 -0500 To: William Allen Simpson From: Bruce Schneier Subject: Re: More on a second IPSec algorithm Cc: ipsec@lists.tislabs.com In-Reply-To: <3790D72C.F82930F9@greendragon.com> References: <4.1.19990715161920.00a04930@mail.visi.com> <4.1.19990716101655.00a1a480@mail.visi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:19 PM 7/17/99 -0400, William Allen Simpson wrote: >It seems I'm missing some of the messages in this thread, or the thread was >renamed too many times, but while I agree that Bruce is correct on a theoretic >basis, there are a few practical reasons why having more than one "mandatory >to implement" cipher is good: > > A) Some vendors are resistant to mandating 3DES because of speed. Perry > and Phil and I pushed 3DES pretty hard 4 years ago, but lost the battle > on the speed issue. DESX is virtually the same speed as DES. We didn't > push DESX 4 years ago, as it had no analysis. Now, I think DESX is the > obvious choice for a quick update. Easiest to implement, with no speed > changes that a user (or marketer) might notice. DES-X is a good choice. > B) Mandating that both DESX and 3DES are in every product allows the > customer to choose the speed, finessing the vendor complaint. The core > code is the same, so it is still easy to implement. > > C) Having more than one algorithm tests the selection machinery on a > regular basis. This implementation issue is very important. Even > when a product works the first time around, later changes can break > the implementation. Exercise the code paths. > > D) Having more than one algorithm tests the operational configuration > machinery. Again, operational issues are very important. Of course, > this same consideration encourages the number of choices to be small, > probably only 2 or 3. But, as time goes on, there will be changes, > and that means we have to be prepared to configure them. It is a lot > easier to change a policy data file than have a deployment flag day. > > E) Having more than one cipher available inhibits analysis. The cipher > in use can be hidden, requiring more effort for finding and tracking > important data. Heterogeneity(?) may make it impractical. This was > a design feature of Photuris, and is still optional in IKE/ISAKMP. Triple-DES and DES-X are pretty much the same WRT analysis. > F) Having more than one cipher simply instills confidence, for users, > the naive press, and overblown marketing. This is another reason > for adding a non-DES cipher. It may not fix anything in and of itself, > but the mere presence says "we've covered all the bases". > >I wish that the working group had followed our advice in 1995, and allowed >both DES and 3DES to be Proposed Standard. Then, we wouldn't be in the >quandary we are in today. > > >Bruce Schneier wrote: >> The NSA does not build encryption equipment with a hot-spare algorithm >> in it. It makes no sense to do so. >> >The NSA still has multiple fielded algorithms. They just have more control >over which are in use and where. We don't have that luxury in the Internet. > >Whenever I work on protocol design, I think implementation and operation >are incredibly important! All the best intentions in the world are >worthless without deployment. > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com From owner-ipsec@lists.tislabs.com Thu Jul 22 14:44:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA09627; Thu, 22 Jul 1999 14:44:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01136 Thu, 22 Jul 1999 16:18:44 -0400 (EDT) Message-Id: <199907221940.PAA12864@ara.missi.ncsc.mil> Date: Thu, 22 Jul 1999 15:40:31 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Secret public keys To: dpkemp@missi.ncsc.mil, Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: b/06FOgafknU3EAhW9jNQQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: "Waters, Stephen" > > The problem I have now is mapping that id to the client's public key or > certificate in a manageable way. I hope we can agree that managing > public-key to id mapping can only be handled by using the CA/certificate > approach. It seems to me that the client must pass some sort of ID to the server, and that the server must have some sort of client-specific data that is *not* contained in a public certificate to enable XAUTH to work. You mentioned a large shared-secret value which could be unlocked on the client by use of a short password; how is that shared-secret made known to the server, in a manageable way? If shared-secrets are manageable, then a certificateless secret public key is just as manageable, using the identical procedures. Please describe exactly the steps you proposed for enabling a secondary authentication exchange (XAUTH). What data is stored on the client, what is stored on the server, and what flows between them during the IKE and XAUTH exchanges? The question that began this thread was "does IKE+XAUTH have any value-added over IKE alone?" It's obvious that managing secrets is more difficult than managing public data. But I believe that regardless of whether you choose to use secret information on the server to eliminate the possibility of offline password guessing attacks on the client, a secondary authentication exchange is superfluous. Whatever the requirements are, they can be satisfied within IKE. From owner-ipsec@lists.tislabs.com Thu Jul 22 15:41:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA11285; Thu, 22 Jul 1999 15:41:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01393 Thu, 22 Jul 1999 17:17:54 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE64@new-exc1.ctron.com> From: "Waters, Stephen" To: "David P. Kemp" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, "Bussiere, Dick" , "Bassett, John Robert" , "Holland, Gary" Subject: RE: Secret public keys Date: Thu, 22 Jul 1999 22:17:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, (your note copied below) I am trying to avoid using XAUTH, if possible. If I can get offline cracking protection using an IKE Phase mechanism, that's what I want. We have plans to allow RADIUS servers to provide per-user pre-shared secrets for IKE Phase-1 authentication, if that is what the customer wants. If the customer wants legacy, they are probably not going to like PKI in the picture, so our recommendation will be to use per-user pre-shared phase-1 and XAUTH for the legacy. If the customer will tolerate PKI, I would like to be able to offer it in a way that was comparable to the strongest legacy authentication they may be using today. The proposal to not load the VPN client with the public key (just private) COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to collect the appropriate public key, but the security manager would need some handy way to 'copy' the users' public key from the certificate (or key generation point) to the RADIUS management tool. Not impossible I guess. O.K., so here's a 'from ground up' Private Key Infrastructure: 1) Go to RADIUS tool. Add client stephen.waters@ctron.com 2) Push 'generate key pair' and public key is stored in association with new client 3) Push 'build client file' and a file is generated with the private-key (password protected), appropriate VPN server public key and ID (also password protected), and client id to present when connecting (stephen.waters@ctron.com), VPN server address, other stuff on policy/proposals maybe. Client device is now loaded with the file. Connects to VPN server, presents id and engages in a signature exchange. VPN server calls to RADIUS using provided id to collect public key to complete Phase1. Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. I think I like it :) No off-line cracking, no CRL problems, no new protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password problem, no CA. Something must be wrong! At the very least, a lot of people are going to be miffed it this works :) Sorry, I'm not being flippant, it's just late here and I've started to giggle at the apparent relief this offers. I know it won't last long. Steve. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Thursday, July 22, 1999 8:41 PM To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: RE: Secret public keys > From: "Waters, Stephen" > > The problem I have now is mapping that id to the client's public key or > certificate in a manageable way. I hope we can agree that managing > public-key to id mapping can only be handled by using the CA/certificate > approach. It seems to me that the client must pass some sort of ID to the server, and that the server must have some sort of client-specific data that is *not* contained in a public certificate to enable XAUTH to work. You mentioned a large shared-secret value which could be unlocked on the client by use of a short password; how is that shared-secret made known to the server, in a manageable way? If shared-secrets are manageable, then a certificateless secret public key is just as manageable, using the identical procedures. Please describe exactly the steps you proposed for enabling a secondary authentication exchange (XAUTH). What data is stored on the client, what is stored on the server, and what flows between them during the IKE and XAUTH exchanges? The question that began this thread was "does IKE+XAUTH have any value-added over IKE alone?" It's obvious that managing secrets is more difficult than managing public data. But I believe that regardless of whether you choose to use secret information on the server to eliminate the possibility of offline password guessing attacks on the client, a secondary authentication exchange is superfluous. Whatever the requirements are, they can be satisfied within IKE. From owner-ipsec@lists.tislabs.com Thu Jul 22 16:37:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12132; Thu, 22 Jul 1999 16:37:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01482 Thu, 22 Jul 1999 18:11:41 -0400 (EDT) Message-ID: <37979748.A21D606D@redcreek.com> Date: Thu, 22 Jul 1999 15:12:24 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Requirements driving xauth [was Re: Secret public keys, Re: comment on xauth and hybrid] References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The various xauth threads have been most interesting, but I think Vipul and Dan asked a question which has never been explicitly answered: why do we need this? Stephen assessed the various threats pretty well: "Waters, Stephen" wrote: > Cases: > 1) Thief does a runner with a device with no intention of returning it. > > > 2) Thief borrows the device in order to steal the primary authentication > secret, then returns the device. > That is, there seems to be an argument for use of xauth as the second factor in a two-factor authentication scheme, where the threat motivating the use of this mechanism pertains to an attacker's ability to impersonate the user by simply swiping their laptop (or hardware token, or both), either temporarily or permanently, or otherwise gain access to their private key, preshared key, or whatever they are using. Note that the term "two-factor authentication", as used here, assumes that the endpoints of the IKE SA have been mutually authenticated in a reliable way prior to the xauth exchange. The xauth/hybrid scheme seems to indicate that there is a need for xauth as a primary single factor authentication mechanism (with respect to the user). This approach would seem to obviate the need for a second factor, since the first factor ostensibly may not be spoofed or otherwise compromised. Now, the point has been raised that xauth would not be necessary at all if we had a PKI in place, but that customers are not willing to make this leap at this time. However, it appears that even if the PKI were in place, we would still be faced with the threats Stephen mentioned. This leads me to think that the questions are these: 1) If we rely only upon the current built-in authentication methods for IKE, do we perceive a need for a two-factor mechanism like xauth, or for a single-factor hybrid mechanism using passphrases? If the answer to (1) is no, we are finished. On the other hand, if the answer to (1) is yes (or maybe), we must ask the following: 2) Why do we perceive this need? That is, could we remove the threat by somehow modifying the authentication mechanisms in IKE, or by better protecting the material IKE uses for authentication? 3) In the end, if we cannot insure the integrity of our stored authentication material, can we be sure of the integrity of the system into which we are typing our passphrase? That is, can we be sure we're running a "secure" ipsec implementation that's not diverting or otherwise storing our passphrase for later use, if we cannot be sure someone hasn't tampered with our system? What a can of worms... but what I think I may have convinced myself of is this: the need for xauth is dubious if you have PKI plus some measure of physical security for the private keys in the client. These may be locally protected on the client's system in a number of ways, ranging from hardware tokens to software obfuscation a la arcotsign. The point is, if you want to use a passphrase, biometric, or other such authentication mechanism, then it seems to make more sense from a security perspective to use it to unlock the private key on the client's system, and then use *that* to authenticate within IKE using the existing public key mechanisms. Scott From owner-ipsec@lists.tislabs.com Fri Jul 23 02:09:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA20614; Fri, 23 Jul 1999 02:09:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02557 Fri, 23 Jul 1999 03:39:53 -0400 (EDT) Message-Id: <3.0.5.32.19990723104018.00c08bf0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 23 Jul 1999 10:40:18 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: RE: XAUTH is broken In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFC40E3E@exchange> 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 DAA02554 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:53 22.7.1999 -0400, you wrote: >This is a rather unfair and unreasonable accusation. Yes it is. It was meant to be a bit teasing, but it looks just mean if it read it today. Sorry. >If it turns >out that the best solution is to use a new exchange type, we would >still have to change our code, and it also one of the suggestions >that I already said I prefer. > OK, let's go this way. I would like to suggest that we define _two_ new exchanges, one for 4 packets and one for 6 packets. Jörn From owner-ipsec@lists.tislabs.com Fri Jul 23 04:29:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA24654; Fri, 23 Jul 1999 04:29:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA02854 Fri, 23 Jul 1999 05:57:09 -0400 (EDT) Message-Id: <199907230957.NAA09576@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com, Joern Sierwald Date: Fri, 23 Jul 1999 13:56:43 +4 MIME-Version: 1.0 Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 8BIT Comments: Sender has elected to use 8-bit data in this message. If problems arise, refer to postmaster at sender's site. Subject: RE: XAUTH is broken In-reply-to: <3.0.5.32.19990723104018.00c08bf0@smtp.datafellows.com> References: <319A1C5F94C8D11192DE00805FBBADDFC40E3E@exchange> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 23 Jul 99 at 10:40, Joern Sierwald wrote: > At 15:53 22.7.1999 -0400, you wrote: > > >This is a rather unfair and unreasonable accusation. > Yes it is. It was meant to be a bit teasing, but it looks just mean > if it read it today. Sorry. > > >If it turns > >out that the best solution is to use a new exchange type, we would > >still have to change our code, and it also one of the suggestions > >that I already said I prefer. > > > OK, let's go this way. I would like to suggest that we define _two_ > new exchanges, one for 4 packets and one for 6 packets. Number of packets depends on type of authentication. Who can guarantee that tomorrow another type of authentication will require, say, 8 packets? Shall we define new exchange again then? And so on? Would'n be better to define XAUTH exchange as open ended? BTW, question to Tim Jenkins. Attribute payload contains "Identifier" field. Why not use it (by requiring it to be the same in all attribute payloads during one XAUTH exchange) for state tracking and let M-ID be different (e.g. perform XAUTH as series of ordinary ISAKMP-CFG)? > Jörn Regards, Valery. From owner-ipsec@lists.tislabs.com Fri Jul 23 06:40:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26186; Fri, 23 Jul 1999 06:40:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03169 Fri, 23 Jul 1999 08:12:47 -0400 (EDT) Message-Id: <3.0.5.32.19990723081453.007c1530@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 23 Jul 1999 08:14:53 -0400 To: "Waters, Stephen" From: David Jablon Subject: RE: Secret public keys Cc: "David P. Kemp" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, "Bussiere, Dick" , "Bassett, John Robert" , "Holland, Gary" In-Reply-To: <29752A74B6C5D211A4920090273CA3DC4BBE64@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk XAUTH notwithstanding, the value of shared secret passwords and "secret public keys" is that they allow strong one-to-one agreements between a user and a service provider that is easy to set up with existing tools, with a large base of pre-existing relationships. Of course, shared-secrets alone, without a complementary PKI, don't scale to solve the world's e-commerce problems with establishing mutual trust between strangers. But this just isn't everyone's goal. Passwords and secret-public-keys are immensely practical and useful for securing user-to-provider relationships, especially when the number of highly-secure provider relationships needed by the typical user is small. Think about protecting the one most important site in your "single-sign-on" solutiuon. I believe IKE should be extended to permit strong mutual authentication based on low-entropy shared secrets. Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem to do it either. At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote: >David [Kemp], (your note copied below) > >I am trying to avoid using XAUTH, if possible. If I can get offline >cracking protection using an IKE Phase mechanism, that's what I want. > >We have plans to allow RADIUS servers to provide per-user pre-shared secrets >for IKE Phase-1 authentication, if that is what the customer wants. If the >customer wants legacy, they are probably not going to like PKI in the >picture, so our recommendation will be to use per-user pre-shared phase-1 >and XAUTH for the legacy. > >If the customer will tolerate PKI, I would like to be able to offer it in a >way that was comparable to the strongest legacy authentication they may be >using today. > >The proposal to not load the VPN client with the public key (just private) >COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to >collect the appropriate public key, but the security manager would need some >handy way to 'copy' the users' public key from the certificate (or key >generation point) to the RADIUS management tool. Not impossible I guess. > >O.K., so here's a 'from ground up' Private Key Infrastructure: > >1) Go to RADIUS tool. Add client stephen.waters@ctron.com >2) Push 'generate key pair' and public key is stored in association with new >client >3) Push 'build client file' and a file is generated with the private-key >(password protected), appropriate VPN server public key and ID (also >password protected), and client id to present when connecting >(stephen.waters@ctron.com), VPN server address, other stuff on >policy/proposals maybe. > >Client device is now loaded with the file. Connects to VPN server, presents >id and engages in a signature exchange. VPN server calls to RADIUS using >provided id to collect public key to complete Phase1. > >Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. > >I think I like it :) No off-line cracking, no CRL problems, no new >protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password >problem, no CA. Here's one problem: Password-encrypted local data may be inadequate protection for the safety of locally stored credentials. David Kemp wrote: >From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] >Sent: Thursday, July 22, 1999 8:41 PM >To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com >Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org >Subject: RE: Secret public keys > [...] >The question that began this thread was "does IKE+XAUTH have any >value-added over IKE alone?" It's obvious that managing secrets >is more difficult than managing public data. But I believe that >regardless of whether you choose to use secret information on the >server to eliminate the possibility of offline password guessing >attacks on the client, a secondary authentication exchange is >superfluous. Whatever the requirements are, they can be satisfied >within IKE. Even if we ignore obvious out-of-scope issues that IKE was never designed to solve, I think the last statement goes too far. IKE can certainly be further extended or improved to better use and protect low-entropy shared secrets. I have no opinion on whether IKE+XAUTH has value over IKE as-is. I do know that XAUTH doesn't address the mutual authentication issue in using low-entropy shared-secrets to strengthen the key exchange. IKE could be extended to use "legacy" credentials in a stronger way, with a password-authenticated key exchange. This would provide another factor for mutual authentication, and at the same time prevent yet another potential path for disclosure of these secrets. I think these are worthy goals. -- dpj --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ipsec@lists.tislabs.com Fri Jul 23 06:49:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26257; Fri, 23 Jul 1999 06:49:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03183 Fri, 23 Jul 1999 08:14:52 -0400 (EDT) Message-Id: <3.0.5.32.19990723081649.00799300@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 23 Jul 1999 08:16:49 -0400 To: "Scott G. Kelly" From: David Jablon Subject: Re: Requirements driving xauth [was Re: Secret public keys, Re: comment on xauth and hybrid] Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org In-Reply-To: <37979748.A21D606D@redcreek.com> References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The XAUTH threads have raised some good questions, but so far, not quite as many good answers, about the role of "legacy" authentication systems based on passwords, tokens, etc. I present some reasons to refocus the discussion on the issue of local vs. remote storage of credentials below. At 03:12 PM 7/22/99 -0700, Scott G. Kelly wrote: >The various xauth threads have been most interesting, but I think Vipul >and Dan asked a question which has never been explicitly answered: why >do we need this? Stephen assessed the various threats pretty well: > >"Waters, Stephen" wrote: >> Cases: >> 1) Thief does a runner with a device with no intention of returning it. > >> >> 2) Thief borrows the device in order to steal the primary authentication >> secret, then returns the device. We can also add: 3) Thief steals a backup media, which is never noticed as missing. >That is, there seems to be an argument for use of xauth as the second >factor in a two-factor authentication scheme, where the threat >motivating the use of this mechanism pertains to an attacker's ability >to impersonate the user by simply swiping their laptop (or hardware >token, or both), either temporarily or permanently, or otherwise gain >access to their private key, preshared key, or whatever they are using. > [...] >2) Why do we perceive this need? That is, could we remove the threat by >somehow modifying the authentication mechanisms in IKE, or by better >protecting the material IKE uses for authentication? Good questions. There is a need to better deal with credentials that can be kept in the user's head, and not on the local disk, without requiring cards and tokens. To fully deal with the low-entropy problem requires both extensions to IKE auth mechanisms *and* providing as much protection as possible for the use of the credentials in the local and remote systems. My main point is that there is no one perfect approach to this for all situations, and secure remote password verifiers are at least as important as local ones. >3) In the end, if we cannot insure the integrity of our stored >authentication material, can we be sure of the integrity of the system >into which we are typing our passphrase? That is, can we be sure we're >running a "secure" ipsec implementation that's not diverting or >otherwise storing our passphrase for later use, if we cannot be sure >someone hasn't tampered with our system? Your analysis is too simple. Local integrity and local privacy are distinct issues. The vulnerability of password-derived or password-encrypted local credentials is a separate serious issue. For example, one might be reasonably sure that a system doesn't have a keyboard sniffer installed right now, while at the same time be suspicious that a backup copy of the local disk has fallen into the wrong hands. >What a can of worms... but what I think I may have convinced myself of >is this: the need for xauth is dubious if you have PKI plus some measure >of physical security for the private keys in the client. These may be >locally protected on the client's system in a number of ways, ranging >from hardware tokens to software obfuscation a la arcotsign. The point >is, if you want to use a passphrase, biometric, or other such >authentication mechanism, then it seems to make more sense from a >security perspective to use it to unlock the private key on the client's >system, and then use *that* to authenticate within IKE using the >existing public key mechanisms. I'm not convinced. Perhaps the need for XAUTH is dubious, but to leap to the conclusion that local physical security is the sole answer is wrong. In many cases it makes more sense to keep sensitive user credentials in a secure remote location, and use strong remote password-based authentication (in-part) to securely retrieve this data. Entrust's SPEKE-enabled roaming feature is yet another approach to a so-called "virtual smart card" system, providing optimal use and protection for the low-entropy key, without limiting the scope of use of the user's private key. While XAUTH doesn't meet these goals, the need for strong mutual authentication that can safely use low-entropy secrets is real, and having a variety of solutions is valuable. I strongly disagree with some opinions expressed in earlier posts that supporting password methods will somehow slow deployment of PKI. Strong password methods do not pose a threat to those seriously committed to the evolution of robust PKI-based systems. -- dpj --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ipsec@lists.tislabs.com Fri Jul 23 07:06:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26401; Fri, 23 Jul 1999 07:06:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03247 Fri, 23 Jul 1999 08:33:20 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC40F33@exchange> From: Tim Jenkins To: Valery Smyslov , ipsec@lists.tislabs.com, Joern Sierwald Subject: RE: XAUTH is broken Date: Fri, 23 Jul 1999 08:36:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA03244 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk š -----Original Message----- From: Valery Smyslov [mailto:svan@trustworks.com] Sent: July 23, 1999 9:57 AM To: ipsec@lists.tislabs.com; Joern Sierwald Subject: RE: XAUTH is broken On 23 Jul 99 at 10:40, Joern Sierwald wrote: > At 15:53 22.7.1999 -0400, you wrote: > > >This is a rather unfair and unreasonable accusation. > Yes it is. It was meant to be a bit teasing, but it looks just mean > if it read it today. Sorry. > > >If it turns > >out that the best solution is to use a new exchange type, we would > >still have to change our code, and it also one of the suggestions > >that I already said I prefer. > > > OK, let's go this way. I would like to suggest that we define _two_ > new exchanges, one for 4 packets and one for 6 packets. Number of packets depends on type of authentication. Who can guarantee that tomorrow another type of authentication will require, say, 8 packets? Shall we define new exchange again then? And so on? Would'n be better to define XAUTH exchange as open ended? BTW, question to Tim Jenkins. Attribute payload contains "Identifier" field. Why not use it (by requiring it to be the same in all attribute payloads during one XAUTH exchange) for state tracking and let M-ID be different (e.g. perform XAUTH as series of ordinary ISAKMP-CFG)? > Jörn Regards, Valery. From owner-ipsec@lists.tislabs.com Fri Jul 23 07:31:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26736; Fri, 23 Jul 1999 07:31:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03506 Fri, 23 Jul 1999 09:01:07 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC40F5C@exchange> From: Tim Jenkins To: Valery Smyslov , ipsec@lists.tislabs.com, Joern Sierwald Subject: RE: XAUTH is broken Date: Fri, 23 Jul 1999 09:04:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA03503 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Damn mailer dropped my response...) This is in response to questions about my objection to using multiple different configuration exchange exchanges for extended authentications that require more than two packets. When extended authentication is required, an overall state machine that controls the phase 1 SA has to know what the result of the extended authentication session is. It would be advantageous to minimize how much that state machine needs to know about the exchange. If it is done over a configuration exchange using the attribute payload identifier (or some other value common to the whole exchange), the state machine has to do the following: 1) know that extended authentication is required 2) check that the first packet sent is the correct exchange type (configuration exchange) 3) check that the attributes in the exchange are valid (right now there are 9 defined; it needs to know about all of them in order to know that this an XAUTH exchange) 4) save the message ID from the exchange 5) save the identifier out of the attribute payload Then, for the next packet that goes through: 1) check the packet is the correct exchange type (configuration exchange) 2) check that the message ID matches the previous exchange 3) look for the XAUTH_STATUS attribute If the XAUTH_STATUS attribute is found, the state machine can take action accordingly. If it's not found, the state machine has to do the next set of actions until it is found: 1) check that the next packet sent is the correct exchange type (configuration exchange) 2) check that the identifier out of the attribute payload matches the saved one 3) check that the attributes in the exchange are valid (right now there are 9 defined; it needs to know about all of them) 4) save the message ID from the exchange 5) check that the next packet is the correct exchange type (configuration exchange) 6) check that the message ID matches the previous exchange 7) look for the XAUTH_STATUS attribute Compare that work to the case where the extended authentication is done in its own open-ended exchange type: 1) know that extended authentication is required 2) check that the first packet sent is the correct exchange type (XAUTH exchange) 3) save the message ID from the exchange Then, for the remainder of the packets that go through: 1) check the packet is the correct exchange type (XAUTH exchange) 2) check that the message ID matches the previous exchange 3) look for the XAUTH_STATUS attribute (if an even numbered message of the exchange) If the XAUTH_STATUS attribute is found, the state machine take action accordingly. If it's not found, the state machine has to the next pair of actions until it is found: It's simpler, requires less knowledge of the exchange and attribute by the state machine. Both can be done; it seems that the separate exchange type is architecturally purer. Tim > -----Original Message----- > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > Sent: July 23, 1999 8:36 AM > To: Valery Smyslov; ipsec@lists.tislabs.com; Joern Sierwald > Subject: RE: XAUTH is broken > > > š > > -----Original Message----- > From: Valery Smyslov [mailto:svan@trustworks.com] > Sent: July 23, 1999 9:57 AM > To: ipsec@lists.tislabs.com; Joern Sierwald > Subject: RE: XAUTH is broken > > > > On 23 Jul 99 at 10:40, Joern Sierwald wrote: > > > At 15:53 22.7.1999 -0400, you wrote: > > > > >This is a rather unfair and unreasonable accusation. > > Yes it is. It was meant to be a bit teasing, but it looks just mean > > if it read it today. Sorry. > > > > >If it turns > > >out that the best solution is to use a new exchange type, we would > > >still have to change our code, and it also one of the suggestions > > >that I already said I prefer. > > > > > OK, let's go this way. I would like to suggest that we define _two_ > > new exchanges, one for 4 packets and one for 6 packets. > > Number of packets depends on type of authentication. Who can > guarantee that tomorrow another type of authentication will require, > say, 8 packets? Shall we define new exchange again then? And so on? > Would'n be better to define XAUTH exchange as open ended? > > BTW, question to Tim Jenkins. Attribute payload contains "Identifier" > field. Why not use it (by requiring it to be the same in all > attribute payloads during one XAUTH exchange) for state tracking and > let M-ID be different (e.g. perform XAUTH as series of ordinary > ISAKMP-CFG)? > > > Jörn > > Regards, > Valery. > From owner-ipsec@lists.tislabs.com Fri Jul 23 07:49:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26929; Fri, 23 Jul 1999 07:49:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03550 Fri, 23 Jul 1999 09:09:13 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> From: "Waters, Stephen" To: David Jablon Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Secret public keys Date: Fri, 23 Jul 1999 14:08:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can you explain this bit "Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem to do it either." IKE supports (today) the concept of "secret public keys". It's just a signature exchange. You are right that password protecting the private information is still the weak point, but if the private information is stored in such a way that it is not obvious when you have cracked it, the attacker won't know when he has the right password. This is an improvement on what we had before with all the tools (public key /cracked-private key) available, but it still relies on the sensible use of passwords. Whatever can be used to improve this weakness would be welcome. Any comments from Smartcard folk on the prospect of bomb-proof biometric cards? Cheers, Steve. -----Original Message----- From: David Jablon [mailto:dpj@world.std.com] Sent: Friday, July 23, 1999 1:15 PM To: Waters, Stephen Cc: David P. Kemp; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Bussiere, Dick; Bassett, John Robert; Holland, Gary Subject: RE: Secret public keys XAUTH notwithstanding, the value of shared secret passwords and "secret public keys" is that they allow strong one-to-one agreements between a user and a service provider that is easy to set up with existing tools, with a large base of pre-existing relationships. Of course, shared-secrets alone, without a complementary PKI, don't scale to solve the world's e-commerce problems with establishing mutual trust between strangers. But this just isn't everyone's goal. Passwords and secret-public-keys are immensely practical and useful for securing user-to-provider relationships, especially when the number of highly-secure provider relationships needed by the typical user is small. Think about protecting the one most important site in your "single-sign-on" solutiuon. I believe IKE should be extended to permit strong mutual authentication based on low-entropy shared secrets. Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem to do it either. At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote: >David [Kemp], (your note copied below) > >I am trying to avoid using XAUTH, if possible. If I can get offline >cracking protection using an IKE Phase mechanism, that's what I want. > >We have plans to allow RADIUS servers to provide per-user pre-shared secrets >for IKE Phase-1 authentication, if that is what the customer wants. If the >customer wants legacy, they are probably not going to like PKI in the >picture, so our recommendation will be to use per-user pre-shared phase-1 >and XAUTH for the legacy. > >If the customer will tolerate PKI, I would like to be able to offer it in a >way that was comparable to the strongest legacy authentication they may be >using today. > >The proposal to not load the VPN client with the public key (just private) >COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to >collect the appropriate public key, but the security manager would need some >handy way to 'copy' the users' public key from the certificate (or key >generation point) to the RADIUS management tool. Not impossible I guess. > >O.K., so here's a 'from ground up' Private Key Infrastructure: > >1) Go to RADIUS tool. Add client stephen.waters@ctron.com >2) Push 'generate key pair' and public key is stored in association with new >client >3) Push 'build client file' and a file is generated with the private-key >(password protected), appropriate VPN server public key and ID (also >password protected), and client id to present when connecting >(stephen.waters@ctron.com), VPN server address, other stuff on >policy/proposals maybe. > >Client device is now loaded with the file. Connects to VPN server, presents >id and engages in a signature exchange. VPN server calls to RADIUS using >provided id to collect public key to complete Phase1. > >Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. > >I think I like it :) No off-line cracking, no CRL problems, no new >protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password >problem, no CA. Here's one problem: Password-encrypted local data may be inadequate protection for the safety of locally stored credentials. David Kemp wrote: >From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] >Sent: Thursday, July 22, 1999 8:41 PM >To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com >Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org >Subject: RE: Secret public keys > [...] >The question that began this thread was "does IKE+XAUTH have any >value-added over IKE alone?" It's obvious that managing secrets >is more difficult than managing public data. But I believe that >regardless of whether you choose to use secret information on the >server to eliminate the possibility of offline password guessing >attacks on the client, a secondary authentication exchange is >superfluous. Whatever the requirements are, they can be satisfied >within IKE. Even if we ignore obvious out-of-scope issues that IKE was never designed to solve, I think the last statement goes too far. IKE can certainly be further extended or improved to better use and protect low-entropy shared secrets. I have no opinion on whether IKE+XAUTH has value over IKE as-is. I do know that XAUTH doesn't address the mutual authentication issue in using low-entropy shared-secrets to strengthen the key exchange. IKE could be extended to use "legacy" credentials in a stronger way, with a password-authenticated key exchange. This would provide another factor for mutual authentication, and at the same time prevent yet another potential path for disclosure of these secrets. I think these are worthy goals. -- dpj --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ipsec@lists.tislabs.com Fri Jul 23 07:55:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA26993; Fri, 23 Jul 1999 07:55:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03614 Fri, 23 Jul 1999 09:30:22 -0400 (EDT) Message-Id: <3.0.5.32.19990723163036.00c60ae0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 23 Jul 1999 16:30:36 +0300 To: ipsec@lists.tislabs.com, tjenkins@TimeStep.com From: Joern Sierwald Subject: RE: XAUTH is broken 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 JAA03611 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Conclusion: Best way is a new exchange. It will work exactly as specified in the xauth draft, except the exchange number in the ISAKMP headers will be a new XAUTH number instead of cfg-mode. A clarification: XAUTH ends with a SET and an ACK type packet. SET and ACK are used only at the end of the exchange. This way, the XAUTH exchange is not "open-ended", it is just "variable length". As I am ignorant of the procedures... Who picks the number? Jörn From owner-ipsec@lists.tislabs.com Fri Jul 23 08:01:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27061; Fri, 23 Jul 1999 08:01:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03636 Fri, 23 Jul 1999 09:39:09 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC041113@new-exc1.ctron.com> From: "Bassett, John Robert" To: "'Valery Smyslov'" , Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Fri, 23 Jul 1999 14:37:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA03633 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FWIW my vote goes for just two exchange types - one for a 2 packet Config exchange (as already defined) - one for an open ended XAUTH exchange terminated with ACK(STATUS). All packets in an exchange get the same msgid, running IV etc as for any other IKE exchange. Regards, John B. -----Original Message----- From: Valery Smyslov [mailto:svan@trustworks.com] Sent: Friday, July 23, 1999 2:57 PM To: ipsec@lists.tislabs.com; Joern Sierwald Subject: RE: XAUTH is broken On 23 Jul 99 at 10:40, Joern Sierwald wrote: > At 15:53 22.7.1999 -0400, you wrote: > > >This is a rather unfair and unreasonable accusation. > Yes it is. It was meant to be a bit teasing, but it looks just mean > if it read it today. Sorry. > > >If it turns > >out that the best solution is to use a new exchange type, we would > >still have to change our code, and it also one of the suggestions > >that I already said I prefer. > > > OK, let's go this way. I would like to suggest that we define _two_ > new exchanges, one for 4 packets and one for 6 packets. Number of packets depends on type of authentication. Who can guarantee that tomorrow another type of authentication will require, say, 8 packets? Shall we define new exchange again then? And so on? Would'n be better to define XAUTH exchange as open ended? BTW, question to Tim Jenkins. Attribute payload contains "Identifier" field. Why not use it (by requiring it to be the same in all attribute payloads during one XAUTH exchange) for state tracking and let M-ID be different (e.g. perform XAUTH as series of ordinary ISAKMP-CFG)? > Jörn Regards, Valery. From owner-ipsec@lists.tislabs.com Fri Jul 23 08:30:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27358; Fri, 23 Jul 1999 08:30:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03685 Fri, 23 Jul 1999 09:48:41 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC40FAB@exchange> From: Stephane Beaulieu To: Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Fri, 23 Jul 1999 09:51:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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 JAA03682 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think this is definitely the best way to proceed. It should have minimum impact on those already having implemented / deployed XAUTH, and results in a cleaner state machine for those who are just implementing it now. Before we make any changes to the doc. though I want to make sure that everyone is in agreement. Are there are any objections? > -----Original Message----- > From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] > Sent: Friday, July 23, 1999 9:31 AM > To: ipsec@lists.tislabs.com; tjenkins@TimeStep.com > Subject: RE: XAUTH is broken > > > Conclusion: > > Best way is a new exchange. It will work exactly as specified in > the xauth draft, except the exchange number in the ISAKMP headers will > be a new XAUTH number instead of cfg-mode. > > A clarification: XAUTH ends with a SET and an ACK type packet. > SET and ACK are used only at the end of the exchange. > This way, the XAUTH exchange is not "open-ended", > it is just "variable length". > > As I am ignorant of the procedures... Who picks the number? > > Jörn > > > From owner-ipsec@lists.tislabs.com Fri Jul 23 12:15:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00285; Fri, 23 Jul 1999 12:15:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04463 Fri, 23 Jul 1999 13:26:08 -0400 (EDT) Message-ID: <3798A5E7.67156CFC@redcreek.com> Date: Fri, 23 Jul 1999 10:27:03 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Jablon CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Requirements driving xauth [was Re: Secret public keys,Re: comment on xauth and hybrid] References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi David, David Jablon wrote: > > > >"Waters, Stephen" wrote: > >> Cases: > >> 1) Thief does a runner with a device with no intention of returning it. > > > >> > >> 2) Thief borrows the device in order to steal the primary authentication > >> secret, then returns the device. > > We can also add: > 3) Thief steals a backup media, which is never noticed as missing. I think that the implications of (3) are covered by (2). > >2) Why do we perceive this need? That is, could we remove the threat by > >somehow modifying the authentication mechanisms in IKE, or by better > >protecting the material IKE uses for authentication? > > Good questions. There is a need to better deal with > credentials that can be kept in the user's head, and not on > the local disk, without requiring cards and tokens. > To fully deal with the low-entropy problem requires both > extensions to IKE auth mechanisms *and* providing as much > protection as possible for the use of the credentials > in the local and remote systems. I don't understand what you mean by "the low-entropy problem", and don't understand why you think IKE auth mechanisms need extending for this. >From your previous posts, I assume you mean that IKE should support passphrases, but it already does support preshared keys, which are passphrases, so I'm confused. > My main point is that there is no one perfect approach to > this for all situations, and secure remote password verifiers are > at least as important as local ones. I agree with the first part of this point, but would qualify that by saying that we are not trying to cover all situations. The focus here is on remote access to a company network. > >3) In the end, if we cannot insure the integrity of our stored > >authentication material, can we be sure of the integrity of the system > >into which we are typing our passphrase? That is, can we be sure we're > >running a "secure" ipsec implementation that's not diverting or > >otherwise storing our passphrase for later use, if we cannot be sure > >someone hasn't tampered with our system? > > Your analysis is too simple. Local integrity and local privacy > are distinct issues. The vulnerability of password-derived or > password-encrypted local credentials is a separate serious issue. It was not meant to be an analysis; rather, it is a rhetorical question, meant to illustrate some of the intracacies of this debate. Sorry I didn't make that more clear. I had hoped that my subsequent comment ("What a can of worms...") would have made it clear that I recognize the complexity here. > >What a can of worms... but what I think I may have convinced myself of > >is this: the need for xauth is dubious if you have PKI plus some measure > >of physical security for the private keys in the client. These may be > >locally protected on the client's system in a number of ways, ranging > >from hardware tokens to software obfuscation a la arcotsign. The point > >is, if you want to use a passphrase, biometric, or other such > >authentication mechanism, then it seems to make more sense from a > >security perspective to use it to unlock the private key on the client's > >system, and then use *that* to authenticate within IKE using the > >existing public key mechanisms. > > I'm not convinced. Perhaps the need for XAUTH is dubious, but to > leap to the conclusion that local physical security is the sole > answer is wrong. In many cases it makes more sense to keep > sensitive user credentials in a secure remote location, and use > strong remote password-based authentication (in-part) to securely > retrieve this data. Entrust's SPEKE-enabled roaming feature is > yet another approach to a so-called "virtual smart card" system, > providing optimal use and protection for the low-entropy key, > without limiting the scope of use of the user's private key. I think I understand your point, but maybe not. The term "physical security" does not quite do justice to what I was trying to communicate, and I could have added some more text, but then that probably wouldn't have done it either. This is very complex stuff, and there are no simple answers. This is why I think we need to focus on the requirements before we run off and try to design one-size-fits-all solutions. > I strongly disagree with some opinions expressed in earlier > posts that supporting password methods will somehow slow > deployment of PKI. Strong password methods do not pose > a threat to those seriously committed to the evolution of > robust PKI-based systems. > I'm one who has expressed such opinions, so let me try to clarify my reasoning. I think the concern has to do largely with complacency. It's not so much the thought that supporting *password* methods will slow PKI deployment, it's more that supporting arbitrary *legacy* mechanisms will slow deployment. Security is hard to understand, and also hard to deploy. Administrators will tend to take the path of least resistance, which in many cases may be attempting to continue using deployed technology. For remote access, this technology usually consists of radius, but there are others. The people who worked on radius will tell you unequivocally that is has major flaws with respect to security. As a security working group, the best thing we could possibly do is steer people clear of this. Granted, it may have been the only game in town 18 months ago, and this would give some justification for an interim hack. Even my company's products support radius at present, albeit not with xauth. However, doing it in practice as an interim hack is *way* different from standardizing it, and that is what we are discussing here. Scott From owner-ipsec@lists.tislabs.com Fri Jul 23 12:36:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA00641; Fri, 23 Jul 1999 12:36:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04503 Fri, 23 Jul 1999 13:44:38 -0400 (EDT) Message-Id: <3.0.5.32.19990723134652.00812070@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 23 Jul 1999 13:46:52 -0400 To: "Waters, Stephen" From: David Jablon Subject: RE: Secret public keys Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org In-Reply-To: <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:08 PM 7/23/99 +0100, Stephen Waters wrote: >Can you explain this bit "Maybe XAUTH doesn't get us there. But IKE as-is >doesn't seem >to do it either." > >IKE supports (today) the concept of "secret public keys". It's just a >signature exchange. Simple. IKE doesn't yet use secret public keys in a way that protects low-entropy private keys. More specifically, IKE does not support a zero-knowledge password proof, which prevents network disclosure of a small password and at the same time authenticate the key exchange with the password. It can be done in several ways, and I thought that the philosophy motivating XAUTH and the technology of IKE fit particularly well with EKE-style techniques. >You are right that password protecting the private information is still the >weak point, but if the private information is stored in such a way that it >is not obvious when you have cracked it, the attacker won't know when he has >the right password. That's a big IF. Storing the information in a "non obvious" way still sounds weak to me. Better to not store it locally at all. I can do this today with well-built password systems, and I'd rather not be encouraged to take a step backwards to use IPSEC. To be conservative, one should presume that if software can find even an obscured locally stored private key, then then an attacker can too. One should also presume that if it's a user-chosen key, then it's crackable. >This is an improvement on what we had before with all the tools (public key >/cracked-private key) available, but it still relies on the sensible use of >passwords. Whatever can be used to improve this weakness would be welcome. What you suggest is not an improvement over all systems. And your implied meaning of "sensible use" misses the point. The entire concept of "sensible use of passwords" is relative to the system in which they're used. Take an ATM machine. A four-digit password seems to work fine there with appropriate revocation rules. With better password systems, it becomes much easier to enforce sensible use rules, which makes it possible for more users to operate securely. Deploying a new crypto system that relies on cryptographically-long passwords for security is a step in the wrong direction, and introduces unnecessary risk for users in many situations. >-----Original Message----- >From: David Jablon [mailto:dpj@world.std.com] >Sent: Friday, July 23, 1999 1:15 PM >To: Waters, Stephen >Cc: David P. Kemp; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; >Bussiere, Dick; Bassett, John Robert; Holland, Gary >Subject: RE: Secret public keys > > >XAUTH notwithstanding, the value of shared secret passwords >and "secret public keys" is that they allow strong one-to-one >agreements between a user and a service provider that is >easy to set up with existing tools, with a large base >of pre-existing relationships. > >Of course, shared-secrets alone, without a complementary PKI, >don't scale to solve the world's e-commerce problems with >establishing mutual trust between strangers. But this just >isn't everyone's goal. Passwords and secret-public-keys are >immensely practical and useful for securing user-to-provider >relationships, especially when the number of highly-secure >provider relationships needed by the typical user is small. >Think about protecting the one most important site in your >"single-sign-on" solutiuon. > >I believe IKE should be extended to permit strong mutual >authentication based on low-entropy shared secrets. > >Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem >to do it either. > >At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote: >>David [Kemp], (your note copied below) >> >>I am trying to avoid using XAUTH, if possible. If I can get offline >>cracking protection using an IKE Phase mechanism, that's what I want. >> >>We have plans to allow RADIUS servers to provide per-user pre-shared >secrets >>for IKE Phase-1 authentication, if that is what the customer wants. If the >>customer wants legacy, they are probably not going to like PKI in the >>picture, so our recommendation will be to use per-user pre-shared phase-1 >>and XAUTH for the legacy. >> >>If the customer will tolerate PKI, I would like to be able to offer it in a >>way that was comparable to the strongest legacy authentication they may be >>using today. >> >>The proposal to not load the VPN client with the public key (just private) >>COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to >>collect the appropriate public key, but the security manager would need >some >>handy way to 'copy' the users' public key from the certificate (or key >>generation point) to the RADIUS management tool. Not impossible I guess. >> >>O.K., so here's a 'from ground up' Private Key Infrastructure: >> >>1) Go to RADIUS tool. Add client stephen.waters@ctron.com >>2) Push 'generate key pair' and public key is stored in association with >new >>client >>3) Push 'build client file' and a file is generated with the private-key >>(password protected), appropriate VPN server public key and ID (also >>password protected), and client id to present when connecting >>(stephen.waters@ctron.com), VPN server address, other stuff on >>policy/proposals maybe. >> >>Client device is now loaded with the file. Connects to VPN server, >presents >>id and engages in a signature exchange. VPN server calls to RADIUS using >>provided id to collect public key to complete Phase1. >> >>Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. >> >>I think I like it :) No off-line cracking, no CRL problems, no new >>protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password >>problem, no CA. > >Here's one problem: Password-encrypted local data may be inadequate >protection for the safety of locally stored credentials. > >David Kemp wrote: >>From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] >>Sent: Thursday, July 22, 1999 8:41 PM >>To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com >>Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org >>Subject: RE: Secret public keys >> [...] >>The question that began this thread was "does IKE+XAUTH have any >>value-added over IKE alone?" It's obvious that managing secrets >>is more difficult than managing public data. But I believe that >>regardless of whether you choose to use secret information on the >>server to eliminate the possibility of offline password guessing >>attacks on the client, a secondary authentication exchange is >>superfluous. Whatever the requirements are, they can be satisfied >>within IKE. > >Even if we ignore obvious out-of-scope issues that IKE was >never designed to solve, I think the last statement goes too far. >IKE can certainly be further extended or improved to better use >and protect low-entropy shared secrets. > >I have no opinion on whether IKE+XAUTH has value over IKE as-is. >I do know that XAUTH doesn't address the mutual authentication >issue in using low-entropy shared-secrets to strengthen the >key exchange. IKE could be extended to use "legacy" credentials >in a stronger way, with a password-authenticated key exchange. >This would provide another factor for mutual authentication, >and at the same time prevent yet another potential path >for disclosure of these secrets. > >I think these are worthy goals. > >-- dpj > >--------------------------------------------------- >David P. Jablon dpj@IntegritySciences.com >President +1 508 898 9024 >Integrity Sciences, Inc. www.IntegritySciences.com From owner-ipsec@lists.tislabs.com Fri Jul 23 13:14:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01138; Fri, 23 Jul 1999 13:14:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04587 Fri, 23 Jul 1999 14:28:36 -0400 (EDT) Message-ID: <3770797500008EFC@mcfeeley.indusriver.com> (added by mcfeeley.indusriver.com) X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 23 Jul 1999 14:34:12 -0400 To: Stephen.Waters@cabletron.com, dpj@IntegritySciences.com From: David Chen Subject: RE: Secret public keys Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org In-Reply-To: <3.0.5.32.19990723134652.00812070@world.std.com> References: <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I thought we like the public key as "public" as possible. (so that to prevent attack) How can someone want a "secret" for "public" key ? If it is secret, then it is private. Don't you agree? --- David From owner-ipsec@lists.tislabs.com Fri Jul 23 13:22:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01235; Fri, 23 Jul 1999 13:22:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04686 Fri, 23 Jul 1999 14:50:54 -0400 (EDT) Message-ID: <51C0AF25889FD211AC3F00A0C984090DC0BCB4@orsmsx50.jf.intel.com> From: "Saint-Hilaire, Ylian" To: ipsec@lists.tislabs.com Subject: Aggressive mode fallback to main mode Date: Fri, 23 Jul 1999 11:51:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Questions to the group: - Is it normal IKE behavior by vendors that don't support aggressive mode to process the first message as a main mode message? or MUST you respond to a aggressive mode with a "INVALID-EXCHANCE-TYPE". Can an implementation initiate in aggressive mode and see if the response is main or aggressive and process the rest of the exchange in that mode? (Of course, this limits all transforms to having the same DH group, your aggressive mode must be correct) - If I initiate in aggressive mode and time out, can I assume that the other machine does not support IKE? Thanks, Ylian Saint-Hilaire Intel (CAL) Communication Architecture Labs From owner-ipsec@lists.tislabs.com Fri Jul 23 13:27:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01300; Fri, 23 Jul 1999 13:27:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04752 Fri, 23 Jul 1999 15:01:51 -0400 (EDT) Message-Id: <199907231902.MAA23592@potassium.network-alchemy.com> To: Stephane Beaulieu cc: Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: XAUTH is broken In-reply-to: Your message of "Fri, 23 Jul 1999 09:51:41 EDT." <319A1C5F94C8D11192DE00805FBBADDFC40FAB@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <23589.932756536.1@network-alchemy.com> Date: Fri, 23 Jul 1999 12:02:17 -0700 From: Dan Harkins Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA04748 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't have any objection to a new exchange but I have a request. Please don't just grab the next number in the _reserved_ _to_ _IANA_ space. Config-mode did this and I think it's a bad precedent. We've already seen magic number conflicts (DH-less IKE and the Certicom EC draft) from this sort of thing. Pick a private use number and define some blob for a vendor ID which says, "I do XAUTH++". When you receive a properly formatted "I do XAUTH++" vendor ID payload you can know that each side has mutually agreed to use the private use number and you can proceed to XAUTH++. Then you can test this thing properly at the bakeoff and if, and when, it advances it can be assigned a number in the proper manner. Just grabbing numbers will result in chaos when IANA does assign the next number in its space and people say, "whoa, you can't do that! The Frobnitz draft is already using that number." thank you, Dan. On Fri, 23 Jul 1999 09:51:41 EDT you wrote > I think this is definitely the best way to proceed. It should have minimum > impact on those already having implemented / deployed XAUTH, and results in > a cleaner state machine for those who are just implementing it now. > > Before we make any changes to the doc. though I want to make sure that > everyone is in agreement. > > Are there are any objections? > > > -----Original Message----- > > From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] > > Sent: Friday, July 23, 1999 9:31 AM > > To: ipsec@lists.tislabs.com; tjenkins@TimeStep.com > > Subject: RE: XAUTH is broken > > > > > > Conclusion: > > > > Best way is a new exchange. It will work exactly as specified in > > the xauth draft, except the exchange number in the ISAKMP headers will > > be a new XAUTH number instead of cfg-mode. > > > > A clarification: XAUTH ends with a SET and an ACK type packet. > > SET and ACK are used only at the end of the exchange. > > This way, the XAUTH exchange is not "open-ended", > > it is just "variable length". > > > > As I am ignorant of the procedures... Who picks the number? > > > > Jörn > > > > > > From owner-ipsec@lists.tislabs.com Fri Jul 23 16:58:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03876; Fri, 23 Jul 1999 16:58:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05153 Fri, 23 Jul 1999 18:40:47 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3770797500008EFC@mcfeeley.indusriver.com> (added by mcfeeley.indusriver.com) References: <3.0.5.32.19990723134652.00812070@world.std.com> <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Date: Fri, 23 Jul 1999 18:36:18 -0400 To: David Chen From: Stephen Kent Subject: RE: Secret public keys Cc: Stephen.Waters@cabletron.com, dpj@IntegritySciences.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Sender: owner-ipsec@lists.tislabs.com Precedence: bulk , Chen wrote: >I thought we like the public key as "public" as possible. (so that to >prevent attack) >How can someone want a "secret" for "public" key ? >If it is secret, then it is private. >Don't you agree? No. Making a public key public does nothing to improve its security. We're not talking about algorithms here. Public keys are public to facilitate verification of signatures, encryption, etc. However, one can choose to not disclose a public key to everyone, but rather to disclose it only to a selected set of peers if the application context supports that. Authentication in a closed system is an example of such a context. Steve From owner-ipsec@lists.tislabs.com Fri Jul 23 23:40:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA12372; Fri, 23 Jul 1999 23:40:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA05648 Sat, 24 Jul 1999 00:59:52 -0400 (EDT) Message-ID: <002b01bed591$88dfdfe0$3f323ac3@elvis.ru> From: "Valery Smyslov" To: "Saint-Hilaire, Ylian" , References: <51C0AF25889FD211AC3F00A0C984090DC0BCB4@orsmsx50.jf.intel.com> Subject: Re: Aggressive mode fallback to main mode Date: Sat, 24 Jul 1999 09:01:00 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: Saint-Hilaire, Ylian To: Sent: Friday, July 23, 1999 10:51 PM Subject: Aggressive mode fallback to main mode > > Questions to the group: > > - Is it normal IKE behavior by vendors that don't support aggressive mode to > process the first message as a main mode message? or MUST you respond to a > aggressive mode with a "INVALID-EXCHANCE-TYPE". Can an implementation > initiate in aggressive mode and see if the response is main or aggressive > and process the rest of the exchange in that mode? (Of course, this limits > all transforms to having the same DH group, your aggressive mode must be > correct) No, IKE doesn't allow you to switch exchange type in the middle of exchange. If you start with aggressive mode you must continue with it, or abort negotiation and restart with main mode. > - If I initiate in aggressive mode and time out, can I assume that the other > machine does not support IKE? Or that the other machine doesn't support error notifications (or for whatever reason, i.e. shortage of resources, doesn't want to send them). > Thanks, Ylian Saint-Hilaire > Intel (CAL) Communication Architecture Labs Regards, Valery. From owner-ipsec@lists.tislabs.com Sat Jul 24 01:51:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA05601; Sat, 24 Jul 1999 01:51:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05823 Sat, 24 Jul 1999 03:14:23 -0400 (EDT) Message-ID: <000e01bed5a4$517c3540$db253ac3@elvis.ru> From: "Valery Smyslov" To: "Tim Jenkins" , , "Joern Sierwald" References: <319A1C5F94C8D11192DE00805FBBADDFC40F5C@exchange> Subject: Re: XAUTH is broken Date: Sat, 24 Jul 1999 11:15:23 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, you don't pay any attention to attribute payload Identifier field in your processing with the same M-ID, do you? If so, then next problem arises: currently XAUTH draft doesn't prohibit multiple attribute payloads in one message (and ISAKMP-CFG explicitly allows it). If you ignore Identifier, you cannot link REQUEST with REPLY and SET with ACK unless the only attribute payload is present in every message. This restriction (only one attribute payload in every message) seems to make sense for XAUTH, so I'd prefer it to be mentioned explicitly in the draft. Even in this case we have a problem: what to do if Identifiers in consequent messages don't match - ignore, abort, consider as another XAUTH exchange? Is it ever possible to have multiple concurrent XAUTH exchanges? Regards, Valery. ----- Original Message ----- From: Tim Jenkins To: Valery Smyslov ; ; Joern Sierwald Sent: Friday, July 23, 1999 5:04 PM Subject: RE: XAUTH is broken (Damn mailer dropped my response...) This is in response to questions about my objection to using multiple different configuration exchange exchanges for extended authentications that require more than two packets. When extended authentication is required, an overall state machine that controls the phase 1 SA has to know what the result of the extended authentication session is. It would be advantageous to minimize how much that state machine needs to know about the exchange. If it is done over a configuration exchange using the attribute payload identifier (or some other value common to the whole exchange), the state machine has to do the following: 1) know that extended authentication is required 2) check that the first packet sent is the correct exchange type (configuration exchange) 3) check that the attributes in the exchange are valid (right now there are 9 defined; it needs to know about all of them in order to know that this an XAUTH exchange) 4) save the message ID from the exchange 5) save the identifier out of the attribute payload Then, for the next packet that goes through: 1) check the packet is the correct exchange type (configuration exchange) 2) check that the message ID matches the previous exchange 3) look for the XAUTH_STATUS attribute If the XAUTH_STATUS attribute is found, the state machine can take action accordingly. If it's not found, the state machine has to do the next set of actions until it is found: 1) check that the next packet sent is the correct exchange type (configuration exchange) 2) check that the identifier out of the attribute payload matches the saved one 3) check that the attributes in the exchange are valid (right now there are 9 defined; it needs to know about all of them) 4) save the message ID from the exchange 5) check that the next packet is the correct exchange type (configuration exchange) 6) check that the message ID matches the previous exchange 7) look for the XAUTH_STATUS attribute Compare that work to the case where the extended authentication is done in its own open-ended exchange type: 1) know that extended authentication is required 2) check that the first packet sent is the correct exchange type (XAUTH exchange) 3) save the message ID from the exchange Then, for the remainder of the packets that go through: 1) check the packet is the correct exchange type (XAUTH exchange) 2) check that the message ID matches the previous exchange 3) look for the XAUTH_STATUS attribute (if an even numbered message of the exchange) If the XAUTH_STATUS attribute is found, the state machine take action accordingly. If it's not found, the state machine has to the next pair of actions until it is found: It's simpler, requires less knowledge of the exchange and attribute by the state machine. Both can be done; it seems that the separate exchange type is architecturally purer. Tim > -----Original Message----- > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > Sent: July 23, 1999 8:36 AM > To: Valery Smyslov; ipsec@lists.tislabs.com; Joern Sierwald > Subject: RE: XAUTH is broken > > > > > -----Original Message----- > From: Valery Smyslov [mailto:svan@trustworks.com] > Sent: July 23, 1999 9:57 AM > To: ipsec@lists.tislabs.com; Joern Sierwald > Subject: RE: XAUTH is broken > > > > On 23 Jul 99 at 10:40, Joern Sierwald wrote: > > > At 15:53 22.7.1999 -0400, you wrote: > > > > >This is a rather unfair and unreasonable accusation. > > Yes it is. It was meant to be a bit teasing, but it looks just mean > > if it read it today. Sorry. > > > > >If it turns > > >out that the best solution is to use a new exchange type, we would > > >still have to change our code, and it also one of the suggestions > > >that I already said I prefer. > > > > > OK, let's go this way. I would like to suggest that we define _two_ > > new exchanges, one for 4 packets and one for 6 packets. > > Number of packets depends on type of authentication. Who can > guarantee that tomorrow another type of authentication will require, > say, 8 packets? Shall we define new exchange again then? And so on? > Would'n be better to define XAUTH exchange as open ended? > > BTW, question to Tim Jenkins. Attribute payload contains "Identifier" > field. Why not use it (by requiring it to be the same in all > attribute payloads during one XAUTH exchange) for state tracking and > let M-ID be different (e.g. perform XAUTH as series of ordinary > ISAKMP-CFG)? > > > Jörn > > Regards, > Valery. > From owner-ipsec@lists.tislabs.com Sat Jul 24 01:57:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA02906; Sat, 24 Jul 1999 01:57:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05853 Sat, 24 Jul 1999 03:26:52 -0400 (EDT) Message-ID: <001401bed5a6$144b01e0$db253ac3@elvis.ru> From: "Valery Smyslov" To: "Stephane Beaulieu" , "Dan Harkins" Cc: "Joern Sierwald" , References: <199907231902.MAA23592@potassium.network-alchemy.com> Subject: Re: XAUTH is broken Date: Sat, 24 Jul 1999 11:27:57 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, although I agree with you in this particular case, I think that in case of ISAKMP-CFG it wasn't possible to pick a number from private space. According to the draft, ISAKMP-CFG may take place _before_ phase 1, when Vendor ID payloads are not yet exchanged and even DOI is not yet determined. In general, I think that any exchange that may take place before phase 1 or instead of it (new exchange for phase 1) must get its number from range 0..32. Regards, Valery. ----- Original Message ----- From: Dan Harkins To: Stephane Beaulieu Cc: Joern Sierwald ; Sent: Friday, July 23, 1999 11:02 PM Subject: Re: XAUTH is broken I don't have any objection to a new exchange but I have a request. Please don't just grab the next number in the _reserved_ _to_ _IANA_ space. Config-mode did this and I think it's a bad precedent. We've already seen magic number conflicts (DH-less IKE and the Certicom EC draft) from this sort of thing. Pick a private use number and define some blob for a vendor ID which says, "I do XAUTH++". When you receive a properly formatted "I do XAUTH++" vendor ID payload you can know that each side has mutually agreed to use the private use number and you can proceed to XAUTH++. Then you can test this thing properly at the bakeoff and if, and when, it advances it can be assigned a number in the proper manner. Just grabbing numbers will result in chaos when IANA does assign the next number in its space and people say, "whoa, you can't do that! The Frobnitz draft is already using that number." thank you, Dan. On Fri, 23 Jul 1999 09:51:41 EDT you wrote > I think this is definitely the best way to proceed. It should have minimum > impact on those already having implemented / deployed XAUTH, and results in > a cleaner state machine for those who are just implementing it now. > > Before we make any changes to the doc. though I want to make sure that > everyone is in agreement. > > Are there are any objections? > > > -----Original Message----- > > From: Joern Sierwald [mailto:joern.sierwald@datafellows.com] > > Sent: Friday, July 23, 1999 9:31 AM > > To: ipsec@lists.tislabs.com; tjenkins@TimeStep.com > > Subject: RE: XAUTH is broken > > > > > > Conclusion: > > > > Best way is a new exchange. It will work exactly as specified in > > the xauth draft, except the exchange number in the ISAKMP headers will > > be a new XAUTH number instead of cfg-mode. > > > > A clarification: XAUTH ends with a SET and an ACK type packet. > > SET and ACK are used only at the end of the exchange. > > This way, the XAUTH exchange is not "open-ended", > > it is just "variable length". > > > > As I am ignorant of the procedures... Who picks the number? > > > > Jörn > > > > > > From owner-ipsec@lists.tislabs.com Sat Jul 24 09:11:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29904; Sat, 24 Jul 1999 09:11:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06376 Sat, 24 Jul 1999 10:43:02 -0400 (EDT) Message-Id: <3.0.5.32.19990724174326.00c0f100@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 24 Jul 1999 17:43:26 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: XAUTH is broken In-Reply-To: <199907231902.MAA23592@potassium.network-alchemy.com> References: 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 KAA06373 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:02 23.7.1999 -0700, Dan wrote: > I don't have any objection to a new exchange but I have a request. >Please don't just grab the next number in the _reserved_ _to_ _IANA_ >space. Config-mode did this and I think it's a bad precedent. We've >already seen magic number conflicts (DH-less IKE and the Certicom >EC draft) from this sort of thing. > > Pick a private use number and define some blob for a vendor ID which >says, "I do XAUTH++". When you receive a properly formatted "I do XAUTH++" >vendor ID payload you can know that each side has mutually agreed to >use the private use number and you can proceed to XAUTH++. Then you can >test this thing properly at the bakeoff and if, and when, it advances it >can be assigned a number in the proper manner. > > Just grabbing numbers will result in chaos when IANA does assign the >next number in its space and people say, "whoa, you can't do that! The >Frobnitz draft is already using that number." > > thank you, > > Dan. > I have the feeling that vendors in the mailing list want to ship really soon. If we choose private numbers now they will end up in shipping products. Not that I would mind. I guess there will be a new version of the xauth draft, I therefore suggest VID=md5("draft-ietf-ipsec-isakmp-xauth-05"). And please don't take the _first_ of the private numbers. BTW: What happened to DH group "5"? Has anybody asked IANA for a number? Jörn Sierwald From owner-ipsec@lists.tislabs.com Sat Jul 24 11:34:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03625; Sat, 24 Jul 1999 11:34:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06603 Sat, 24 Jul 1999 13:06:38 -0400 (EDT) Message-Id: <199907241707.KAA29531@potassium.network-alchemy.com> To: Joern Sierwald cc: ipsec@lists.tislabs.com Subject: Re: XAUTH is broken In-reply-to: Your message of "Sat, 24 Jul 1999 17:43:26 +0300." <3.0.5.32.19990724174326.00c0f100@smtp.datafellows.com> MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <29528.932836040.1@network-alchemy.com> Date: Sat, 24 Jul 1999 10:07:20 -0700 From: Dan Harkins Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA06600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jörn, "Group 5", the 1536 bit MODP group, is in the new IKE draft. Since that draft intends to depricate RFC2409 it seems appropriate for it to "steal" numbers from RFC2409's space. This draft is not an independent companion/ extension draft but a wholesale replacement. I don't see the possibility for conflict in this case. According to the IANA Considerations section of RFC2409 new group descriptions must accompany a standards-track or informational RFC. So a 1536 bit MODP group could be assigned a number by coming up with an RFC that describes the 1536 bit MODP group only or the description of the group can be part of the IKE draft which will, hopefully, be advanced as a standards-track replacement to RFC2409-- in effect, piggybacking the group into definition. Since it didn't appear that the former was going to happen I decided to choose the latter route. Dan. On Sat, 24 Jul 1999 17:43:26 +0300 you wrote > > BTW: What happened to DH group "5"? Has anybody asked IANA for a number? > From owner-ipsec@lists.tislabs.com Sun Jul 25 08:42:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18062; Sun, 25 Jul 1999 08:42:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08188 Sun, 25 Jul 1999 09:49:28 -0400 (EDT) Message-Id: <3.0.5.32.19990725094831.007e2c70@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 25 Jul 1999 09:48:31 -0400 To: David Chen From: David Jablon Subject: RE: Secret public keys Cc: Stephen.Waters@cabletron.com, dpj@IntegritySciences.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, dpkemp@missi.ncsc.mil In-Reply-To: <3770797500008EFC@mcfeeley.indusriver.com> (added by mcfeeley.indusriver.com) References: <3.0.5.32.19990723134652.00812070@world.std.com> <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:34 PM 7/23/99 -0400, David Chen wrote: >I thought we like the public key as "public" as possible. (so that to >prevent attack) >How can someone want a "secret" for "public" key ? >If it is secret, then it is private. >Don't you agree? To see the definition of "secret public keys" in this thread, read David Kemp's original message as forwarded by Stephen Waters. "Secret public keys" can be used in several ways, typically to protect a private key that may be otherwise vulnerable to a brute-force attack. For example, a private key may be encrypted under a weak encryption key derived from a password. When the encryption key can be brute-forced, there's a risk that someone who obtains the encrypted private key and the public key can crack the private key. The principle of a *persistent* secret public key is to distribute the public key on a "need-to-know" basis. This greatly reduces the exposure to such attack. A related concept is *ephemeral* secret public keys. These form the basis for many strong password protocols. The general idea is to choose a one-time public/private key pair, integrate them with a password in a special way, and perform a key exchange with another party. The public/private keys are then discarded. The result is that only parties with the same password will be able to negotiate a large session key, without exposing the small password to brute-force attack. For examples, you can see slides from a presentation on protocols that use both of these concepts: --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ipsec@lists.tislabs.com Mon Jul 26 08:40:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA28316; Mon, 26 Jul 1999 08:40:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11015 Mon, 26 Jul 1999 09:39:35 -0400 (EDT) Date: Mon, 26 Jul 1999 09:39:55 -0400 Message-Id: <199907261339.JAA20187@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: joern.sierwald@datafellows.com Cc: ipsec@lists.tislabs.com Subject: Re: XAUTH is broken References: <199907231902.MAA23592@potassium.network-alchemy.com> <3.0.5.32.19990724174326.00c0f100@smtp.datafellows.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Joern" == Joern Sierwald writes: Joern> At 12:02 23.7.1999 -0700, Dan wrote: >> I don't have any objection to a new exchange but I have a request. >> Please don't just grab the next number in the _reserved_ _to_ >> _IANA_ space. Config-mode did this and I think it's a bad >> precedent. We've already seen magic number conflicts (DH-less IKE >> and the Certicom EC draft) from this sort of thing. >> >> Pick a private use number and define some blob for a vendor ID >> which says, "I do XAUTH++". When you receive a properly formatted >> "I do XAUTH++" vendor ID payload you can know that each side has >> mutually agreed to use the private use number and you can proceed >> to XAUTH++. Then you can test this thing properly at the bakeoff >> and if, and when, it advances it can be assigned a number in the >> proper manner. >> >> Just grabbing numbers will result in chaos when IANA does assign >> the next number in its space and people say, "whoa, you can't do >> that! The Frobnitz draft is already using that number." >> >> thank you, >> >> Dan. >> Joern> I have the feeling that vendors in the mailing list want to Joern> ship really soon. If we choose private numbers now they will Joern> end up in shipping products. Not that I would mind. Joern> I guess there will be a new version of the xauth draft, I Joern> therefore suggest Joern> VID=md5("draft-ietf-ipsec-isakmp-xauth-05"). And please don't Joern> take the _first_ of the private numbers. I don't understand the rationnale for using private numbers for working group efforts. The notion of "private" implies that it's for purposes that aren't being standardized. Is the problem that it's taking a really long time for IANA to assign the number? If the numbers could be assigned efficiently, it would be perfectly straightforward to give a number to a draft as soon as the draft is prepared. If a draft ends up not being approved, or changes in such a fashion that the number is no longer needed, it can either be marked obsolete, or recycled. paul From owner-ipsec@lists.tislabs.com Mon Jul 26 10:14:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA29347; Mon, 26 Jul 1999 10:14:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11411 Mon, 26 Jul 1999 11:19:49 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC41344@exchange> From: Stephane Beaulieu To: Valery Smyslov , ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken Date: Mon, 26 Jul 1999 11:22:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="koi8-r" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery, You raise a good point regarding multiple attribute payloads in the same Isakmp-Cfg message. I agree that this should be disallowed for XAUTH. This type of extensibility would probably hurt interoperability and provide no significant gain. Even though the Message ID / XAUTH id pair would be the same for transaction, I would recommend that you still keep state on the XAUTH id and not solely rely on Message ID. These two identifiers serve different purposes. As for your question about concurrent XAUTHs. The answer is no. There's only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) message. If you were to have multiple XAUTH transactions, how could you tell when it's "really" done. There are mechanisms that allow you to send 2 REQUESTs within 1 XAUTH transaction. Thanks for your input, Stephane. Valery Smyslov wrote: > So, you don't pay any attention to attribute payload Identifier field > in your processing with the same M-ID, do you? If so, then > next problem arises: > currently XAUTH draft doesn't prohibit multiple attribute > payloads in one > message (and ISAKMP-CFG explicitly allows it). If you ignore > Identifier, you > cannot link REQUEST with REPLY and SET with ACK unless the > only attribute > payload is present in every message. This restriction (only > one attribute payload > in every message) seems to make sense for XAUTH, so I'd > prefer it to be mentioned > explicitly in the draft. Even in this case we have a problem: > what to do if Identifiers in > consequent messages don't match - ignore, abort, consider as > another XAUTH > exchange? Is it ever possible to have multiple concurrent > XAUTH exchanges? > > Regards, > Valery. > > > ----- Original Message ----- > From: Tim Jenkins > To: Valery Smyslov ; > ; Joern Sierwald > > Sent: Friday, July 23, 1999 5:04 PM > Subject: RE: XAUTH is broken > > > (Damn mailer dropped my response...) > > This is in response to questions about my objection to using multiple > different configuration exchange exchanges for extended > authentications that > require more than two packets. > > When extended authentication is required, an overall state > machine that > controls the phase 1 SA has to know what the result of the extended > authentication session is. It would be advantageous to > minimize how much > that state machine needs to know about the exchange. > > If it is done over a configuration exchange using the > attribute payload > identifier (or some other value common to the whole > exchange), the state > machine has to do the following: > > 1) know that extended authentication is required > 2) check that the first packet sent is the correct exchange type > (configuration exchange) > 3) check that the attributes in the exchange are valid (right > now there are > 9 defined; it needs to know about all of them in order to > know that this an > XAUTH exchange) > 4) save the message ID from the exchange > 5) save the identifier out of the attribute payload > > Then, for the next packet that goes through: > > 1) check the packet is the correct exchange type > (configuration exchange) > 2) check that the message ID matches the previous exchange > 3) look for the XAUTH_STATUS attribute > > If the XAUTH_STATUS attribute is found, the state machine can > take action > accordingly. > > If it's not found, the state machine has to do the next set > of actions until > it is found: > > 1) check that the next packet sent is the correct exchange type > (configuration exchange) > 2) check that the identifier out of the attribute payload > matches the saved > one > 3) check that the attributes in the exchange are valid (right > now there are > 9 defined; it needs to know about all of them) > 4) save the message ID from the exchange > 5) check that the next packet is the correct exchange type > (configuration > exchange) > 6) check that the message ID matches the previous exchange > 7) look for the XAUTH_STATUS attribute > > > Compare that work to the case where the extended > authentication is done in > its own open-ended exchange type: > > 1) know that extended authentication is required > 2) check that the first packet sent is the correct exchange > type (XAUTH > exchange) > 3) save the message ID from the exchange > > Then, for the remainder of the packets that go through: > > 1) check the packet is the correct exchange type (XAUTH exchange) > 2) check that the message ID matches the previous exchange > 3) look for the XAUTH_STATUS attribute (if an even numbered > message of the > exchange) > > If the XAUTH_STATUS attribute is found, the state machine take action > accordingly. > > If it's not found, the state machine has to the next pair of > actions until > it is found: > > It's simpler, requires less knowledge of the exchange and > attribute by the > state machine. > > Both can be done; it seems that the separate exchange type is > architecturally purer. > > Tim > > > > -----Original Message----- > > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > > Sent: July 23, 1999 8:36 AM > > To: Valery Smyslov; ipsec@lists.tislabs.com; Joern Sierwald > > Subject: RE: XAUTH is broken > > > > > > > > > > -----Original Message----- > > From: Valery Smyslov [mailto:svan@trustworks.com] > > Sent: July 23, 1999 9:57 AM > > To: ipsec@lists.tislabs.com; Joern Sierwald > > Subject: RE: XAUTH is broken > > > > > > > > On 23 Jul 99 at 10:40, Joern Sierwald wrote: > > > > > At 15:53 22.7.1999 -0400, you wrote: > > > > > > >This is a rather unfair and unreasonable accusation. > > > Yes it is. It was meant to be a bit teasing, but it looks > just mean > > > if it read it today. Sorry. > > > > > > >If it turns > > > >out that the best solution is to use a new exchange > type, we would > > > >still have to change our code, and it also one of the suggestions > > > >that I already said I prefer. > > > > > > > OK, let's go this way. I would like to suggest that we > define _two_ > > > new exchanges, one for 4 packets and one for 6 packets. > > > > Number of packets depends on type of authentication. Who can > > guarantee that tomorrow another type of authentication will require, > > say, 8 packets? Shall we define new exchange again then? And so on? > > Would'n be better to define XAUTH exchange as open ended? > > > > BTW, question to Tim Jenkins. Attribute payload contains > "Identifier" > > field. Why not use it (by requiring it to be the same in all > > attribute payloads during one XAUTH exchange) for state tracking and > > let M-ID be different (e.g. perform XAUTH as series of ordinary > > ISAKMP-CFG)? > > > > > Jörn > > > > Regards, > > Valery. > > > > From owner-ipsec@lists.tislabs.com Mon Jul 26 11:11:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29904; Mon, 26 Jul 1999 11:11:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11591 Mon, 26 Jul 1999 12:09:46 -0400 (EDT) Message-ID: <379C8808.CB2A3B@redcreek.com> Date: Mon, 26 Jul 1999 09:08:40 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: joern.sierwald@datafellows.com, ipsec@lists.tislabs.com Subject: Re: XAUTH is broken References: <199907231902.MAA23592@potassium.network-alchemy.com> <3.0.5.32.19990724174326.00c0f100@smtp.datafellows.com> <199907261339.JAA20187@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > I don't understand the rationnale for using private numbers for > working group efforts. The notion of "private" implies that it's for > purposes that aren't being standardized. > > Is the problem that it's taking a really long time for IANA to assign > the number? If the numbers could be assigned efficiently, it would be > perfectly straightforward to give a number to a draft as soon as the > draft is prepared. If a draft ends up not being approved, or changes > in such a fashion that the number is no longer needed, it can either > be marked obsolete, or recycled. > > paul The problem is that it's not clear that this will be standardized, and there is currently a healthy debate on as to whether this approach (xauth) is necessary or prudent. Assigning a number before the wg has actually committed to putting this on the standards track seems inappropriate. Scott From owner-ipsec@lists.tislabs.com Mon Jul 26 13:31:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA02574; Mon, 26 Jul 1999 13:31:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11979 Mon, 26 Jul 1999 14:37:15 -0400 (EDT) Message-Id: <199907261837.LAA04417@potassium.network-alchemy.com> To: "Scott G. Kelly" cc: Paul Koning , joern.sierwald@datafellows.com, ipsec@lists.tislabs.com Subject: Re: XAUTH is broken In-reply-to: Your message of "Mon, 26 Jul 1999 09:08:40 PDT." <379C8808.CB2A3B@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4414.933014258.1@network-alchemy.com> Date: Mon, 26 Jul 1999 11:37:38 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It also prevents conflicts. The first rev of the GSS-API draft used the value 13 to represent the GSS-API Token Payload since that was the next value in the payload value range from ISAKMP. Of course that was before the Vendor ID payload got defined as, you guessed it, value 13. There was a large OS vendor who implemented GSS-API with the value 13 and they serious problems when given a Vendor ID payload. There have also been conflicts with another IKE exchange draft and another D-H group draft when the authors just take the next value in the space that is reserved to IANA. Take a look at the GSS-API draft now. It uses private use payloads and attribute values and mentions that people have to agree on a Vendor ID payload to pass and expect before using the private use values. The Hybrid Mode draft does too. This is the way it's supposed to be done. IANA thinks the next ISAKMP payload is 14 and RFC2408 specifically says under its IANA Considerations section: "ISAKMP is designed to provide security association negotiation and key management for many security protocols. Requests for identifiers for additional security protocols must be accompanied by a standards-track RFC which describes the security protocol and its relationship to ISAKMP." So the next standards-track RFC which comes down the pike is going to be given 14. If that isn't Config-Mode then everyone who implememented Config-Mode in shipping product is SOL. It's not a problem with IANA being inefficient it's that the procedure we've defined for the allocation of numbers (our own procedure) is not being followed. That and people shipping code based on I-Ds which have not gone through the proper vetting process and then using that as a sort of fait accompli. The "private" doesn't denote that its not for standardization. It's a way of trying out extensions and experimenting with new things. Something like XAUTH is _exactly_ what it's for. Dan. On Mon, 26 Jul 1999 09:08:40 PDT you wrote > Paul Koning wrote: > > > > > I don't understand the rationnale for using private numbers for > > working group efforts. The notion of "private" implies that it's for > > purposes that aren't being standardized. > > > > Is the problem that it's taking a really long time for IANA to assign > > the number? If the numbers could be assigned efficiently, it would be > > perfectly straightforward to give a number to a draft as soon as the > > draft is prepared. If a draft ends up not being approved, or changes > > in such a fashion that the number is no longer needed, it can either > > be marked obsolete, or recycled. > > > > paul > > The problem is that it's not clear that this will be standardized, and > there is currently a healthy debate on as to whether this approach > (xauth) is necessary or prudent. Assigning a number before the wg has > actually committed to putting this on the standards track seems > inappropriate. > > Scott From owner-ipsec@lists.tislabs.com Mon Jul 26 16:40:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA04721; Mon, 26 Jul 1999 16:40:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12576 Mon, 26 Jul 1999 17:59:16 -0400 (EDT) Message-ID: From: "Heyman, Michael" To: ipsec@lists.tislabs.com Subject: Processing multiple phase 2 SA payloads Date: Mon, 26 Jul 1999 14:57:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Processing multiple phase 2 SA payloads Let me preface this by stating that I have an IKE implementation that negotiates multiple SA payloads with different transforms in a single phase 2 negotiation. This seems to be allowed according to (although I believe the original intent may have been for multiple SA payloads with the same transform such that the SAs could be cached to be used sequentially without re-negotiation). Even so, in building our implementation, I have found that either the multiple SA payload option does not seem to be sufficiently specified or I am missing some distinguishing characteristic. The document does not specify that the SA payloads returning to the initiator are in the same order as the SA payloads transmitted (they are not the same payloads because they have different SPIs and may have less underlying proposal payloads and transform payloads, but one can think of response SA payloads being derived from initiator SA payloads). If the responder must send the SA payload responses back in the same order that the SA payloads they were derived from were received, does that mean that the negotiation must proceed all or nothing? That is, if one out of 15 payloads is not acceptable, should no SA payload response be sent? It seems to be the case that the initiator may not be able to determine which one of the 15 SA payloads it sent was the unacceptable one. If the responders SA payloads can be in a different order then the initiators SA payloads they were derived from, how can they be distinguished? The following is a contrived example to illustrate the point: Initiator sends out: SAi1 proposal1/transform1 a proposal2/transform1 b proposal3/transform1 c SAi2 proposal1/transform1 x proposal2/transform1 b proposal3/transform1 c SAi3 proposal1/transform1 a proposal2/transform1 b proposal3/transform1 x Responder replies with: SAr1 proposal2/transform1 b SAr2 proposal3/transform1 c SAr3 proposal1/transform1 a So, which responder SA goes with which initiator SA? If they are in the same order this is easy. But, what if SAr2 was not acceptable and did not get returned to the initiator? There is no way for the initiator to know if SAr1 goes with SAi1 or SAi2 because they both contain "proposal3/transform1 c". If they are not in the same order, I believe the initiator cannot know which of the SA payloads the responder sent derives from which of the SA payloads the initiator sent. To make things even harder, the proposal and transform numbers can change between initiator and responder - they only "SHOULD" stay the same (RFC 2408 section 4.2). Back to our implementation: Our implementation currently does "first match", where the initiator checks every returned SA payload in order against every sent one in the order that the payloads were sent. The first one to match is assumed to be the proper one and no sent payload is ever matched twice. This allows any order responder SA payloads but does a somewhat better job of matching payloads that come back with the same ordering as the sent payloads they were derived from. Our implementation should not send out payloads with repeated transforms so this algorithm is reasonable. But, I do not wish to write the machinery to enforce transform distinguishing rules, especially when no where does the specification state that all transforms must be either different or the same (if multiple SAs are to be use sequentially). Just to throw out a possible solution: A new attribute could be defined with the sole purpose of distinguishing otherwise identical transforms (this attribute must have a different value every time it is used). - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1b23 iQA/AwUBN5zZ4bXbkJfuXzRQEQIuNwCgp5kq32aG/dq3y4lN0OaH7fGxs9MAoNod O3F9hmoJjVG8bWoskJXIMbSi =ntHq -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jul 26 20:23:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA26882; Mon, 26 Jul 1999 20:23:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13207 Mon, 26 Jul 1999 21:59:20 -0400 (EDT) Message-Id: <4.2.0.58.19990726185415.009d5840@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 26 Jul 1999 18:59:38 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: XAUTH is broken In-Reply-To: <199907261837.LAA04417@potassium.network-alchemy.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan's exactly right here. As a veteran of the IANA registration battles in the mail arena, I can assure you that the Right Thing To Do is to use a single private identifier in the draft. When (well, if) the draft becomes an RFC, remind IANA to give you a number. This works both for people who implement too early (as in, during the draft stage) and people who wait for the RFC. The early people use the private value and then add in the standard number after the RFC is issued. As soon as the number is issued, they start to emit the number, not the private ID, but they continue to accept the private ID, probably forever. The end result of this is that there are two identifiers for a few years, but the private one falls from grace after a while. The only other logical alternative is to *always* use private identifiers, which is worse (in my mind) unless those are what get registered with IANA. The latter method is how algorithms are identified in things like PKIX and S/MIME, and it leads to massive lack of interoperability as people use their own OIDs or have multiple, similar meanings for the same OID. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jul 27 01:03:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA12744; Tue, 27 Jul 1999 01:03:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA13847 Tue, 27 Jul 1999 02:35:25 -0400 (EDT) Message-Id: <199907270635.KAA07497@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: Stephane Beaulieu Date: Tue, 27 Jul 1999 10:34:47 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: XAUTH is broken CC: ipsec@lists.tislabs.com, ipsra In-reply-to: <319A1C5F94C8D11192DE00805FBBADDFC41344@exchange> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 26 Jul 99 at 11:22, Stephane Beaulieu wrote: Hi, Stephane > Valery, > > You raise a good point regarding multiple attribute payloads in the same > Isakmp-Cfg message. I agree that this should be disallowed for XAUTH. This > type of extensibility would probably hurt interoperability and provide no > significant gain. > > Even though the Message ID / XAUTH id pair would be the same for > transaction, I would recommend that you still keep state on the XAUTH id and > not solely rely on Message ID. These two identifiers serve different > purposes. I agree. I asked this question because Tim's algorithm seems to ignore Attribute payload id. But the usage of Attribute payload id in XAUTH is still unclear. Should it be the same for all attribute payloads within one XAUTH exchange or should it be changed with every REQUEST/REPLY SET/ACK pair (as ISAKMP-CFG requires)? The former seems to simplify processing a bit while the latter more strictly follows ISAKMP-CFG draft (is it really needed if we define XAUTH as new exchange?). > As for your question about concurrent XAUTHs. The answer is no. There's > only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) > message. If you were to have multiple XAUTH transactions, how could you > tell when it's "really" done. There are mechanisms that allow you to send 2 > REQUESTs within 1 XAUTH transaction. You may initiate several XAUTH exchanges (with different M-ID, of course) simultaneously. In this case each transaction will be identified by M-ID and will be ended when SET(STATUS) will appear in corresponding XAUTH exchange. So, it seems that the reason you mentioned is not a real problem here. Have I missed something? > Thanks for your input, > Stephane. Regards, Valery. From owner-ipsec@lists.tislabs.com Tue Jul 27 08:02:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA26649; Tue, 27 Jul 1999 08:02:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15079 Tue, 27 Jul 1999 09:22:49 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6E7D7@exchange> From: Stephane Beaulieu To: Valery Smyslov , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken Date: Tue, 27 Jul 1999 09:25:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov wrote: > But the usage of Attribute payload id in XAUTH is still unclear. > Should it be the same for all attribute payloads within one XAUTH > exchange or should it be changed with every REQUEST/REPLY SET/ACK > pair (as ISAKMP-CFG requires)? The former seems to simplify > processing a bit while the latter more strictly follows ISAKMP-CFG > draft (is it really needed if we define XAUTH as new exchange?). The Attribute payload id should be identical for all messages in the XAUTH exchange. > > > As for your question about concurrent XAUTHs. The answer > is no. There's > > only one way end an XAUTH for a user and that's to send an > SET(STATUS(OK)) > > message. If you were to have multiple XAUTH transactions, > how could you > > tell when it's "really" done. There are mechanisms that > allow you to send 2 > > REQUESTs within 1 XAUTH transaction. > > You may initiate several XAUTH exchanges (with different M-ID, of > course) simultaneously. In this case each transaction will be > identified by M-ID and will be ended when SET(STATUS) will appear > in corresponding XAUTH exchange. > > So, it seems that the reason you mentioned is not a real problem > here. Have I missed something? I don't understand why you would need multiple XAUTH exchanges for 1 User. Is this a requirement for anyone? If so, why? If this is a requirement, then when would the Remote Client be allowed to initiate Quick Modes? after the first successful XAUTH, or only once they're all complete? I would really like to limit the number of XAUTH transactions to 1. You can still do two different authentication schemes in 1 transaction. Remote Edge ------- ----- <-- REQUEST(RADIUS) REPLY (RADIUS) --> <-- REQUEST(OTP) REPLY(OTP) --> <-- SET(OK) ACK --> QUICK MODE --> It make the state machine simpler. As soon as you receive STATUS=OK, start doing your QMs. From owner-ipsec@lists.tislabs.com Tue Jul 27 08:02:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA26658; Tue, 27 Jul 1999 08:02:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15066 Tue, 27 Jul 1999 09:19:51 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6E7D0@exchange> From: Tim Jenkins To: Valery Smyslov , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken Date: Tue, 27 Jul 1999 09:22:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > -----Original Message----- > From: Valery Smyslov [mailto:svan@trustworks.com] > Sent: July 27, 1999 6:35 AM > To: Stephane Beaulieu > Cc: ipsec@lists.tislabs.com; ipsra > Subject: RE: XAUTH is broken > > > On 26 Jul 99 at 11:22, Stephane Beaulieu wrote: > Hi, Stephane > > Valery, > > > > You raise a good point regarding multiple attribute payloads in the same > > Isakmp-Cfg message. I agree that this should be disallowed for XAUTH. This > > type of extensibility would probably hurt interoperability and provide no > > significant gain. > > > > Even though the Message ID / XAUTH id pair would be the same for > > transaction, I would recommend that you still keep state on the XAUTH id and > > not solely rely on Message ID. These two identifiers serve different > > purposes. > I agree. I asked this question because Tim's algorithm seems to > ignore Attribute payload id. My "algorithm" was a quick-and-dirty illustration of the differences required between the two. It is not and should not be treated as gospel. What I illustrated was potentially the minimum you might need to do in order to show why I personally preferred the new exchange number route. > But the usage of Attribute payload id in XAUTH is still unclear. > Should it be the same for all attribute payloads within one XAUTH > exchange or should it be changed with every REQUEST/REPLY SET/ACK > pair (as ISAKMP-CFG requires)? The former seems to simplify > processing a bit while the latter more strictly follows ISAKMP-CFG > draft (is it really needed if we define XAUTH as new exchange?). If we use a new exchange type, then that can be defined independently of configuration exchange, while keeping the format of the attribute payload. I think your first suggestion (keep it across the entire exchange) is the correct one. > > As for your question about concurrent XAUTHs. The answer is no. There's > > only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) > > message. If you were to have multiple XAUTH transactions, how could you > > tell when it's "really" done. There are mechanisms that allow you to send 2 > > REQUESTs within 1 XAUTH transaction. > You may initiate several XAUTH exchanges (with different M-ID, of > course) simultaneously. In this case each transaction will be > identified by M-ID and will be ended when SET(STATUS) will appear > in corresponding XAUTH exchange. > So, it seems that the reason you mentioned is not a real problem > here. Have I missed something? Stephane's point was that you need a way to indicate to a higher level state machine that the phase 1 SA is fully authenticated and that it can be used for other things, such as quick modes. If you have multiple independent XAUTH exchanges, what does it mean with respect to fully authenticating the phase 1? Unless there's a really good reason to allow this, for the sake of interoperability, I would suggest we don't allow concurrent XAUTHS. (I suppose one could conceive of using dual bi-directional XAUTH, but I really don't think we want to go there right now.) Tim From owner-ipsec@lists.tislabs.com Tue Jul 27 09:57:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA28447; Tue, 27 Jul 1999 09:57:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15500 Tue, 27 Jul 1999 11:06:34 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F92A@sothmxs06.entrust.com> From: Greg Carter To: "'Dan Harkins'" Cc: ipsec@lists.tislabs.com Subject: RE: XAUTH is broken Date: Tue, 27 Jul 1999 11:06:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What about Config Mode and the Exchange Type? Shouldn't it specify a number in the private use range instead of '6' as selected by the draft? Bye. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Monday, July 26, 1999 2:38 PM To: Scott G. Kelly Cc: Paul Koning; joern.sierwald@datafellows.com; ipsec@lists.tislabs.com Subject: Re: XAUTH is broken It also prevents conflicts. The first rev of the GSS-API draft used the value 13 to represent the GSS-API Token Payload since that was From owner-ipsec@lists.tislabs.com Wed Jul 28 12:25:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18084; Wed, 28 Jul 1999 12:25:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19460 Wed, 28 Jul 1999 12:26:51 -0400 (EDT) Message-ID: <379F2F41.9CE2E65C@redcreek.com> Date: Wed, 28 Jul 1999 09:26:41 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, "Beaulieu, Stephane" , "Pereira, Roy" , Tamir Zegman Subject: xauth requirements: vulnerabilities References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry to keep hammering on this, but we need to make sure we've fully specified the requirements before we can reasonably discuss the efficacy of the proposed solution. I invite the various xauth and xauth/hybrid authors to contribute to this discussion, since you are the ones proposing solutions. So far, the following vulnerabilities have been identified in scenarios entailing using ipsec for remote access: (1) A system containing either a password (preshared key) or private key may be stolen, and the thief may now use the system to impersonate the owner, and access protected resources. (2) A system containing either a password (preshared key) or private key may be otherwise compromised in such a way as to give the attacker access to the password or private key, without the owners knowledge. This means that either a backup containing the information is stolen/copied, a copy of the system is somehow made without the owners knowledge, or the keys are somehow directly extracted. This information could be used to access protected resources directly, or to mount a man-in-the-middle attack on subsquent remote access sessions. (3) Rogue software may be installed on the system without the owners knowledge which monitors the user's typing and/or other aspects of any online session. Are there other vulnerabilities? Scott From owner-ipsec@lists.tislabs.com Wed Jul 28 12:28:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18222; Wed, 28 Jul 1999 12:28:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19746 Wed, 28 Jul 1999 13:27:18 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6ED60@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Stephane Beaulieu , Roy Pereira , Tamir Zegman Subject: RE: xauth requirements: vulnerabilities Date: Wed, 28 Jul 1999 13:30:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, XAUTH was never intended to solve the vulnerabilities which you have enumerated. I will attempt to clarify it's intent. The purpose of XAUTH is to give a migration path to those people who have huge infrastructures that rely on RADIUS and other authentication mechanisms to do their day-to-day business. These people would like to start using IPSec, but can't (and won't) substitute their entire RADIUS infrastructure overnight. Some will deploy a PKI and still use some of the RADIUS tools to do their accounting, logging, and even authentication. Some will simply use a shared secret along with XAUTH for authentication only. To these people we must say "Be extremely careful not to bypass IKE's security by choosing a weak shared secret". And I can assure you, this will be in our documentation probably in bold and underlined three times. So I would say that the requirements are not what you have listed below but rather: "Provide the customer with a mechanism which will allow the use of legacy authentication schemes in conjunction with IPSec, while not diminishing the security of IPSec itself." Some have argued that XAUTH does diminish the security of IPSec by giving security administrators a false sense of security, and allowing them to choose a weak shared secret (which they could do with or without XAUTH). To prevent this, an implementation could easily restrict the network admin from using a "global" shared secret. You could also force them to use "good" shared secrets with FIPS 112. You could even go as far as forcing them to change their shared secret every day... although I'm sure you'd hear about it. I don't want people to think that what we're trying to solve is what you've listed below, although they are problems which I'm sure is of interest to everyone on this list. Regards, Stephane. > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Wednesday, July 28, 1999 12:27 PM > To: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Beaulieu, Stephane; > Pereira, Roy; Tamir Zegman > Subject: xauth requirements: vulnerabilities > > > Sorry to keep hammering on this, but we need to make sure we've fully > specified the requirements before we can reasonably discuss > the efficacy > of the proposed solution. I invite the various xauth and xauth/hybrid > authors to contribute to this discussion, since you are the ones > proposing solutions. > > So far, the following vulnerabilities have been identified in > scenarios > entailing using ipsec for remote access: > > (1) A system containing either a password (preshared key) or > private key > may be stolen, and the thief may now use the system to impersonate the > owner, and access protected resources. > > (2) A system containing either a password (preshared key) or > private key > may be otherwise compromised in such a way as to give the attacker > access to the password or private key, without the owners knowledge. > This means that either a backup containing the information is > stolen/copied, a copy of the system is somehow made without the owners > knowledge, or the keys are somehow directly extracted. This > information > could be used to access protected resources directly, or to mount a > man-in-the-middle attack on subsquent remote access sessions. > > (3) Rogue software may be installed on the system without the owners > knowledge which monitors the user's typing and/or other aspects of any > online session. > > Are there other vulnerabilities? > > Scott > From owner-ipsec@lists.tislabs.com Wed Jul 28 13:47:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA21784; Wed, 28 Jul 1999 13:47:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20034 Wed, 28 Jul 1999 15:01:23 -0400 (EDT) Message-Id: <199907281902.MAA10726@potassium.network-alchemy.com> To: Stephane Beaulieu cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities In-reply-to: Your message of "Wed, 28 Jul 1999 13:30:18 EDT." <319A1C5F94C8D11192DE00805FBBADDFC6ED60@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10723.933188526.1@network-alchemy.com> Date: Wed, 28 Jul 1999 12:02:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane, Your description of XAUTH is very disingenous. Since the whole point of someone using XAUTH is because they do not want to deploy a PKI let's dismiss forever the notion that the IKE SA can be authenticated with a certificate and the two parties can proceed to XAUTH. You even admit this. It's for people who "can't (and won't) deploy a PKI". So that means you're stuck with pre-shared keys to authenticate the IKE SA. You can say in the largest font possible and underlined as much as you want, "Be extremely careful not to bypass IKE's security by choosing a weak shared secret" but the very use of this pre-shared key will make it weak! There is a fundamental limit in IKE that to use pre-shared keys (with Main Mode) means that the pre-shared key is bound to an IP address. Since you cannot know the IP address of these remote clients a priori you MUST use a shared group secret. That is by definition weak. FIPS 112 deals with passwords that are personal. You cannot use a FIPS 112 password in this environment. You also cannot go around changing the password every day because you'd orphan all the people out on the road (unless you somehow announced to all what the new "secret" was so they could update their laptops but the problem with that is, I hope, obvious). I don't know how you can say such things as "an implementation could easily restrict the network admin from using a 'global' shared secret" when you know that that is impossible. If a requirement of XAUTH is to provide legacy authentication without "diminishing the security of IPSec itself" please tell me how you intend to do this? The real problem I see with XAUTH is that it promotes and encourages and legitimizes an insecure use of IKE and IPSec. Dan. On Wed, 28 Jul 1999 13:30:18 EDT you wrote > Hi Scott, > > XAUTH was never intended to solve the vulnerabilities which you have > enumerated. I will attempt to clarify it's intent. > > The purpose of XAUTH is to give a migration path to those people who have > huge infrastructures that rely on RADIUS and other authentication mechanisms > to do their day-to-day business. These people would like to start using > IPSec, but can't (and won't) substitute their entire RADIUS infrastructure > overnight. Some will deploy a PKI and still use some of the RADIUS tools to > do their accounting, logging, and even authentication. Some will simply use > a shared secret along with XAUTH for authentication only. To these people > we must say "Be extremely careful not to bypass IKE's security by choosing a > weak shared secret". And I can assure you, this will be in our > documentation probably in bold and underlined three times. > > So I would say that the requirements are not what you have listed below but > rather: > "Provide the customer with a mechanism which will allow the use of legacy > authentication schemes in conjunction with IPSec, while not diminishing the > security of IPSec itself." > > Some have argued that XAUTH does diminish the security of IPSec by giving > security administrators a false sense of security, and allowing them to > choose a weak shared secret (which they could do with or without XAUTH). To > prevent this, an implementation could easily restrict the network admin from > using a "global" shared secret. You could also force them to use "good" > shared secrets with FIPS 112. You could even go as far as forcing them to > change their shared secret every day... although I'm sure you'd hear about > it. > > I don't want people to think that what we're trying to solve is what you've > listed below, although they are problems which I'm sure is of interest to > everyone on this list. From owner-ipsec@lists.tislabs.com Wed Jul 28 14:03:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA22384; Wed, 28 Jul 1999 14:03:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20164 Wed, 28 Jul 1999 15:29:06 -0400 (EDT) Date: Wed, 28 Jul 1999 15:29:03 -0400 Message-Id: <199907281929.PAA20474@brill.shiva.com> From: John Shriver To: ipsec@lists.tislabs.com Subject: weakness in IKE/DOI specs Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No range is specified for the SA Life Duration Attribute Type in the DOI (RFC 2407). Nor is this specified in the latest revised IKE Internet-Draft (draft-ieft-ipsec-ike-01.txt). The physical limit set by the coding of a Data Attribute in ISAKMP (RFC 2408, Section 3.3) is (2^(65536*8))-1 kilobytes or seconds. This is a perposterously large limit, one that nobody would ever want to implement. (Using bignums for byte counters?) This is a big enough number to measure the life of the universe in seconds, and then a lot more! Moreover, as a security feature, we know that you really don't want large lifetimes anyway. Too much ciphertext on too little key. I think it is perfectly appropriate to limit these to 32 bits, with the range being 0 to (2^32)-1. I don't think there is any sensible justification to allow 64 bit values, that's just too long a lifetime. Also, are there any restrictions on the value of an Attribute Length? Is 1 a legal? Or must you use the short form when Attribute Length would be less than 3? Also, is an attribute length of 3 legal for a lifetime? I could want a lifetime of 128 Kbytes, I could choose to code that as "00 02 00 03 01 00 00", rather than the far more sensible "00 02 00 04 00 01 00 00". Can ANYONE parse that 3 byte lifetime? I doubt it! Should we allow it? I don't think so! I think that the only allowable encodings for SA Duration should be: 80 02 xx xx (xxxx is lifetime < 65536) and 00 02 00 04 yy yy yy yy (yyyyyyyy is lifetime >= 65536 and < 4294967296) Interestingly, our own code sends any lifetime greater than 255 in the long format. Odd. It actively pukes if it receives a long format with a length other than 4. This issue partly comes up because we've coded these as Unsigned32 in the MIB, but there's nothing in the protocol definitions that assures us that Unsigned32 is sufficient. From owner-ipsec@lists.tislabs.com Wed Jul 28 15:19:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA25082; Wed, 28 Jul 1999 15:19:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20423 Wed, 28 Jul 1999 16:57:54 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Stephane Beaulieu Cc: Dan Harkins , "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jul 1999 16:58:14 -0400 From: "Steven M. Bellovin" Message-Id: <19990728205820.08AF341F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <319A1C5F94C8D11192DE00805FBBADDFC6EE7A@exchange>, Stephane Beaulieu writes: > > One of the problems lies in the fact that IPSec doesn't prohibit the use of > "weak" shared secrets. Certainly a less security-concious person may be > more inclined to use a "weak" shared secret when using XAUTH (despite my > bold and triple underlined warning), but nothing prevents a less > security-concious person from doing the exact same thing when XAUTH isn't > there. There are methods that one could use to ensure that the shared > secret be unique and strong, but IPSec doesn't mandate them. Or, as David Jablon has pointed out, there are strong protocols that permit downloading of strong shared secrets or private keys without exposure to offline attacks based on weak shared secrets. Yes, there are patent issues with some of them. There are also at least three different schemes proposed, which gives the IETF a fair amount of leverage. (Disclaimer: I'm the inventor of one of the encumbered schemes. But in the aftermath of the break-up of AT&T, the EKE patents went to Lucent, so I no longer have any connection with those patents. In particular, I don't benefit if they're used; on the other hand, I no longer have any influence on the licensing policies.) The Perlman and Kaufman paper in NDSS '99 shows several different ways to do what's needed here -- bootstrap from a password to a strong private key. And they use show how both EKE and SPEKE can be used. From owner-ipsec@lists.tislabs.com Wed Jul 28 15:21:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA25145; Wed, 28 Jul 1999 15:21:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20385 Wed, 28 Jul 1999 16:48:30 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6EE7A@exchange> From: Stephane Beaulieu To: Dan Harkins , Stephane Beaulieu Cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: RE: xauth requirements: vulnerabilities Date: Wed, 28 Jul 1999 16:51:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, > You can say in the largest font possible and underlined as > much as you > want, "Be extremely careful not to bypass IKE's security by choosing a > weak shared secret" but the very use of this pre-shared key will make > it weak! There is a fundamental limit in IKE that to use pre-shared > keys (with Main Mode) means that the pre-shared key is bound to an IP > address. Since you cannot know the IP address of these remote clients > a priori you MUST use a shared group secret. That is by > definition weak. The ID doesn't need to be bound to an IP Address in Aggressive Mode or Base Mode. It could be a known unique value for each remote user. > > FIPS 112 deals with passwords that are personal. You cannot > use a FIPS 112 > password in this environment. I believe that FIPS 112 has a set of rules that one may follow to choose a "good" password. Regardless, one could restrict the the admin from using a password that is less than 10 characters in length, at least one uppercase, one lower case, one numeric, etc... You also cannot go around > changing the password > every day because you'd orphan all the people out on the road > (unless you > somehow announced to all what the new "secret" was so they > could update > their laptops but the problem with that is, I hope, obvious). Yes, I wasn't really being serious by suggesting this. > I don't know > how you can say such things as "an implementation could > easily restrict the > network admin from using a 'global' shared secret" when you > know that that > is impossible. See above comments on using an ID with Base Mode or Aggressive Mode. > > If a requirement of XAUTH is to provide legacy > authentication without > "diminishing the security of IPSec itself" please tell me how > you intend > to do this? > > The real problem I see with XAUTH is that it promotes and encourages > and legitimizes an insecure use of IKE and IPSec. > One of the problems lies in the fact that IPSec doesn't prohibit the use of "weak" shared secrets. Certainly a less security-concious person may be more inclined to use a "weak" shared secret when using XAUTH (despite my bold and triple underlined warning), but nothing prevents a less security-concious person from doing the exact same thing when XAUTH isn't there. There are methods that one could use to ensure that the shared secret be unique and strong, but IPSec doesn't mandate them. Regards, Stephane. From owner-ipsec@lists.tislabs.com Wed Jul 28 15:22:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA25167; Wed, 28 Jul 1999 15:22:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20368 Wed, 28 Jul 1999 16:43:54 -0400 (EDT) Message-ID: <379F6B7B.8B015EDB@ennovatenetworks.com> Date: Wed, 28 Jul 1999 16:43:39 -0400 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu , "Scott G. Kelly" , ipsec@lists.tislabs.com CC: ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities References: <319A1C5F94C8D11192DE00805FBBADDFC6ED60@exchange> Content-Type: multipart/mixed; boundary="------------F0AD7ACCE4F8FF453B4D2EFE" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------F0AD7ACCE4F8FF453B4D2EFE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephane and the rest, Hello. I am an implementor trying to decide whether or not I need to support RADIUS Authentication in IKE via XAUTH. I have been reading this entire thread (and sub-threads, and ancillary threads) with great interest. Marketing tells me that I need to support XAUTH, particularly with SecureID, and so I might have to implement it anyway, but standardization should have higher bar. I personally don't see how supporting XAUTH/RADIUS provides an easy migration path when I still have to specify an entropy-filled shared secret for each user. How is this less work than just specifying that entropy-filled shared secret once? If, however, the argument is made that supporting XAUTH/RADIUS *and* the entropy-filled shared secret is more secure, then I can understand. And I think that's what Scott is trying to do. But as much as I'd like to, I just can't see the "migration path" argument, unless you use a global shared secret for phase 1. If we're migrating to PKI, and XAUTH is not more secure than pre-shared secrets, then the proper migration path is to use pre-shared secrets and gradually phase in PKI. Why add the extra infrastructure of XAUTH if it doesn't buy you anything? I think we need to really start a discussion on our requirements, and I think Scott has started us down that path. Stephane Beaulieu wrote: > Hi Scott, > > XAUTH was never intended to solve the vulnerabilities which you have > enumerated. I will attempt to clarify it's intent. > > The purpose of XAUTH is to give a migration path to those people who have > huge infrastructures that rely on RADIUS and other authentication mechanisms > to do their day-to-day business. These people would like to start using > IPSec, but can't (and won't) substitute their entire RADIUS infrastructure > overnight. Some will deploy a PKI and still use some of the RADIUS tools to > do their accounting, logging, and even authentication. Some will simply use > a shared secret along with XAUTH for authentication only. To these people > we must say "Be extremely careful not to bypass IKE's security by choosing a > weak shared secret". And I can assure you, this will be in our > documentation probably in bold and underlined three times. > > So I would say that the requirements are not what you have listed below but > rather: > "Provide the customer with a mechanism which will allow the use of legacy > authentication schemes in conjunction with IPSec, while not diminishing the > security of IPSec itself." > > Some have argued that XAUTH does diminish the security of IPSec by giving > security administrators a false sense of security, and allowing them to > choose a weak shared secret (which they could do with or without XAUTH). To > prevent this, an implementation could easily restrict the network admin from > using a "global" shared secret. You could also force them to use "good" > shared secrets with FIPS 112. You could even go as far as forcing them to > change their shared secret every day... although I'm sure you'd hear about > it. > > I don't want people to think that what we're trying to solve is what you've > listed below, although they are problems which I'm sure is of interest to > everyone on this list. > > Regards, > Stephane. > > > -----Original Message----- > > From: Scott G. Kelly [mailto:skelly@redcreek.com] > > Sent: Wednesday, July 28, 1999 12:27 PM > > To: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Beaulieu, Stephane; > > Pereira, Roy; Tamir Zegman > > Subject: xauth requirements: vulnerabilities > > > > > > Sorry to keep hammering on this, but we need to make sure we've fully > > specified the requirements before we can reasonably discuss > > the efficacy > > of the proposed solution. I invite the various xauth and xauth/hybrid > > authors to contribute to this discussion, since you are the ones > > proposing solutions. > > > > So far, the following vulnerabilities have been identified in > > scenarios > > entailing using ipsec for remote access: > > > > (1) A system containing either a password (preshared key) or > > private key > > may be stolen, and the thief may now use the system to impersonate the > > owner, and access protected resources. > > > > (2) A system containing either a password (preshared key) or > > private key > > may be otherwise compromised in such a way as to give the attacker > > access to the password or private key, without the owners knowledge. > > This means that either a backup containing the information is > > stolen/copied, a copy of the system is somehow made without the owners > > knowledge, or the keys are somehow directly extracted. This > > information > > could be used to access protected resources directly, or to mount a > > man-in-the-middle attack on subsquent remote access sessions. > > > > (3) Rogue software may be installed on the system without the owners > > knowledge which monitors the user's typing and/or other aspects of any > > online session. > > > > Are there other vulnerabilities? > > > > Scott > > --------------F0AD7ACCE4F8FF453B4D2EFE Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-263-2002 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;330 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------F0AD7ACCE4F8FF453B4D2EFE-- From owner-ipsec@lists.tislabs.com Wed Jul 28 15:50:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA25828; Wed, 28 Jul 1999 15:50:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20501 Wed, 28 Jul 1999 17:28:34 -0400 (EDT) Message-Id: <199907282129.OAA11040@potassium.network-alchemy.com> To: Stephane Beaulieu cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities In-reply-to: Your message of "Wed, 28 Jul 1999 16:51:22 EDT." <319A1C5F94C8D11192DE00805FBBADDFC6EE7A@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11037.933197367.1@network-alchemy.com> Date: Wed, 28 Jul 1999 14:29:27 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane, On Wed, 28 Jul 1999 16:51:22 EDT you wrote > Hi Dan, > > > You can say in the largest font possible and underlined as > > much as you > > want, "Be extremely careful not to bypass IKE's security by choosing a > > weak shared secret" but the very use of this pre-shared key will make > > it weak! There is a fundamental limit in IKE that to use pre-shared > > keys (with Main Mode) means that the pre-shared key is bound to an IP > > address. Since you cannot know the IP address of these remote clients > > a priori you MUST use a shared group secret. That is by > > definition weak. > > The ID doesn't need to be bound to an IP Address in Aggressive Mode or Base > Mode. It could be a known unique value for each remote user. Pre-shared keys don't scale. But I'll concede this point. You could somehow manage a large radius database _and_ some monster database of unique, per-user pre-shared keys. Fine, but then this gets back to my original point some months back. It's either insecure or superfluous. If the pre-shared key is unique for each remote user then what's the point of doing XAUTH? It doesn't buy you anything except to give you a warm fuzzy by "using" a card to "authenticate." Proof of knowledge of the unique, per-person, pre-shared key would unambiguously authenticate the user. You can spit accounting records out the back end when the user authenticates if this is the real goal. Two factors? Possession of the laptop and knowledge of the passphrase to unlock the pre-shared key. Authenticating with a unique pre-shared key also requires another dialog box (for the passphrase to unlock the pre-shared key) and runs counter to the other customer demand of single sign-on. Since "using" the card is paramount, that's the dialog box that's given. The pre-shared key is left unlocked and since pre-shared keys scale poorly that pre-shared key is just a shared group key. Yes, it's possible to use XAUTH securely but to do so is ridiculous. Why would someone go to double the trouble to authenticate? You're not going to sell alot of boxes by saying that customers have to manage two secret databases and have to go through two dialog boxes just to log in. Since the push behind XAUTH is supposed to be customer requirements which customer has this as a requirement? "I demand twice the trouble! I won't buy anything that let's me off with just a single sign-on!" > > The real problem I see with XAUTH is that it promotes and encourages > > and legitimizes an insecure use of IKE and IPSec. > > One of the problems lies in the fact that IPSec doesn't prohibit the use of > "weak" shared secrets. Certainly a less security-concious person may be > more inclined to use a "weak" shared secret when using XAUTH (despite my > bold and triple underlined warning), but nothing prevents a less > security-concious person from doing the exact same thing when XAUTH isn't > there. There are methods that one could use to ensure that the shared > secret be unique and strong, but IPSec doesn't mandate them. This is a red herring. The issue isn't whether the pre-shared key is "weak" or "strong". It's that XAUTH is either insecure or superfluous. Since it's doubtful that people will want to go through the trouble of superfluous "authentication" (with double the work) I believe that it's the former. Dan. From owner-ipsec@lists.tislabs.com Thu Jul 29 06:01:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA13903; Thu, 29 Jul 1999 06:01:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA25607 Thu, 29 Jul 1999 07:15:05 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBEA0@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: xauth requirements: vulnerabilities Date: Thu, 29 Jul 1999 12:14:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can use public-key cryptography in a closed system without deploying PKI. I can use public-key, or PKI AND XAUTH to suit certain requirements. I can use per-user pre-shared secrets without knowing the client IP address. I can use long, difficult pre-shared secrets without needed the client to remember them. XAUTH can be more secure than PKI. PKI can be more secure than XAUTH. I think XAUTH may be useful in the following ways: 1) per-user pre-shared secret, used with Aggressive mode, backed up by a secure legacy authentication, e.g. SecurID tokens. Main reason: Because the customer is happy with their investment in the legacy method and wants to use the same method for traditional RAS and VPN. The added benefit is that the token card can't be cracked off-line - it doesn't know what the secret, so it can't tell it to you. Now, this off-line exposure could be 'fixed' just with pre-shared, if the client software did the right thing, i.e. challenge for a passphrase to unlock the pre-shared, derive a key, unencrypt the pre-shared, and just use whatever it recovers, without having anyway to verify it (e.g. hash signature). This would mean that the client would not know when you had answered the question correctly and prevent off-line hacking. The problem is that this relies on the implementation. But, the file containing the pre-shared secret could be worked-on off-line, and I once I hit a string of ASCII, I have probably got the key. 2) per-user certificates, with XAUTH to reduce off-line cracking exposure. Main reason: Customers that are concerned about the possible off-line cracking exposure of software-loaded certificates or Smartcards. For the software-loaded case, I guess the client could provide the same 'dumb' attitude to the unlock passphrase, using whatever becomes of the private key once processed with the passphrase to attempt Phase1 authentication. The problem is that the files containing the private key could be worked-on directly, and I would know when I had the right answer because there is a reasonable chance I get access to the matching public key for verification, so the 'dumb' approach does not help for certificates either. For Smartcards that can defend themselves/self destruct, we may have a goer, but there have been concerns expressed on this list about the security of Smartcards. Basically, all the information to access the network is in there somewhere.... 3) whatever Phase1 authentication for 'device' authentication, and XAUTH for per-user. Main reason: This may be common, I guess. If there is no simple way for me to load a private certificate into a borrowed or shared device, this is not a bad answer. I have a private token card and can use shared devices. Smartcards would fix this one, but at the moment, the customer has SecurID tokens cards. So, in conclusion, strong legacy auth does seem to offer help in the face of off-line hacking, and point 3) just plain wants to carry on using old stuff because it's convenient. When I would not use XAUTH (with current IKE auth offerings): 1) with 'private public' key. 2) with 'secure' Smartcards devices that have a very low risk of being cracked off-line, and ideally have some bio reader to prevent me having passwords that could get written down. Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Wednesday, July 28, 1999 8:02 PM To: Stephane Beaulieu Cc: Scott G. Kelly; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Roy Pereira; Tamir Zegman Subject: Re: xauth requirements: vulnerabilities Stephane, Your description of XAUTH is very disingenous. Since the whole point of someone using XAUTH is because they do not want to deploy a PKI let's dismiss forever the notion that the IKE SA can be authenticated with a certificate and the two parties can proceed to XAUTH. You even admit this. It's for people who "can't (and won't) deploy a PKI". So that means you're stuck with pre-shared keys to authenticate the IKE SA. You can say in the largest font possible and underlined as much as you want, "Be extremely careful not to bypass IKE's security by choosing a weak shared secret" but the very use of this pre-shared key will make it weak! There is a fundamental limit in IKE that to use pre-shared keys (with Main Mode) means that the pre-shared key is bound to an IP address. Since you cannot know the IP address of these remote clients a priori you MUST use a shared group secret. That is by definition weak. FIPS 112 deals with passwords that are personal. You cannot use a FIPS 112 password in this environment. You also cannot go around changing the password every day because you'd orphan all the people out on the road (unless you somehow announced to all what the new "secret" was so they could update their laptops but the problem with that is, I hope, obvious). I don't know how you can say such things as "an implementation could easily restrict the network admin from using a 'global' shared secret" when you know that that is impossible. If a requirement of XAUTH is to provide legacy authentication without "diminishing the security of IPSec itself" please tell me how you intend to do this? The real problem I see with XAUTH is that it promotes and encourages and legitimizes an insecure use of IKE and IPSec. Dan. On Wed, 28 Jul 1999 13:30:18 EDT you wrote > Hi Scott, > > XAUTH was never intended to solve the vulnerabilities which you have > enumerated. I will attempt to clarify it's intent. > > The purpose of XAUTH is to give a migration path to those people who have > huge infrastructures that rely on RADIUS and other authentication mechanisms > to do their day-to-day business. These people would like to start using > IPSec, but can't (and won't) substitute their entire RADIUS infrastructure > overnight. Some will deploy a PKI and still use some of the RADIUS tools to > do their accounting, logging, and even authentication. Some will simply use > a shared secret along with XAUTH for authentication only. To these people > we must say "Be extremely careful not to bypass IKE's security by choosing a > weak shared secret". And I can assure you, this will be in our > documentation probably in bold and underlined three times. > > So I would say that the requirements are not what you have listed below but > rather: > "Provide the customer with a mechanism which will allow the use of legacy > authentication schemes in conjunction with IPSec, while not diminishing the > security of IPSec itself." > > Some have argued that XAUTH does diminish the security of IPSec by giving > security administrators a false sense of security, and allowing them to > choose a weak shared secret (which they could do with or without XAUTH). To > prevent this, an implementation could easily restrict the network admin from > using a "global" shared secret. You could also force them to use "good" > shared secrets with FIPS 112. You could even go as far as forcing them to > change their shared secret every day... although I'm sure you'd hear about > it. > > I don't want people to think that what we're trying to solve is what you've > listed below, although they are problems which I'm sure is of interest to > everyone on this list. From owner-ipsec@lists.tislabs.com Thu Jul 29 07:15:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA15237; Thu, 29 Jul 1999 07:15:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26035 Thu, 29 Jul 1999 08:40:58 -0400 (EDT) Message-ID: <37A04C92.9197AA36@checkpoint.com> Date: Thu, 29 Jul 1999 15:44:02 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: xauth requirements: vulnerabilities References: <199907281902.MAA10726@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Dan Harkins wrote: > Stephane, > > Your description of XAUTH is very disingenous. > > Since the whole point of someone using XAUTH is because they do not > want to deploy a PKI let's dismiss forever the notion that the IKE SA can > be authenticated with a certificate and the two parties can proceed to > XAUTH. You even admit this. It's for people who "can't (and won't) deploy > a PKI". So that means you're stuck with pre-shared keys to authenticate > the IKE SA. > Then why don't you use Hybrid? Yes, you need a PKI, but only a small scale PKI. From owner-ipsec@lists.tislabs.com Thu Jul 29 07:42:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA16104; Thu, 29 Jul 1999 07:42:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26093 Thu, 29 Jul 1999 09:05:18 -0400 (EDT) Message-ID: From: "Heyman, Michael" To: "'John Shriver'" , ipsec@lists.tislabs.com Subject: RE: weakness in IKE/DOI specs Date: Thu, 29 Jul 1999 06:04:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BED9C3.86F5DCE4" 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_01BED9C3.86F5DCE4 Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: John Shriver [mailto:jas@shiva.com] > >[SNIP] > I think it is perfectly appropriate to limit these to 32 bits, with > the range being 0 to (2^32)-1. I don't think there is any sensible > justification to allow 64 bit values, that's just too long a > lifetime. > Hmmm, Imagine in the near future (even now?) we have terabit networks. That is 2^40 bits/second. Protecting 2^32KBytes (=2^45 bits) gives me 32 seconds of coverage before a rekey is needed. In my opinion, 2^32, while more then adequate for today and probably :-) adequate for time based rekeying, is a bit small for the foreseeable future with respect to KByte lifetimes. > > Also, are there any restrictions on the value of an Attribute > Length? Is 1 a legal? Or must you use the short form when > Attribute Length would be less than 3? Also, is an attribute > length of 3 legal for a lifetime? I could want a lifetime of 128 > Kbytes, I could choose to code that as "00 02 00 03 01 00 00", > rather than the far more sensible "00 02 00 04 00 01 00 00". Can > ANYONE parse that 3 byte lifetime? I doubt it! Should we allow > it? I don't think so! > RFC 2407 section 4.5 (IPsec DOI) and the IKE draft appendix A seems to imply that any length is valid. The code I am working on does not parse anything but 2 and 4 byte values. I feel that this is adequate for the real world right now. I know it is not fully compliant with the draft IKE document and the IPsec and ISAKMP RFCs but that doesn't bother me. Other people may feel different. - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1b23 iQA/AwUBN6BRW7XbkJfuXzRQEQJEXQCg1wf5nYD4/R0GVM4oQ9i0aiyGQ68AoIrf l8z3WTfXA5cAwtter7tWpV/I =MJTl -----END PGP SIGNATURE----- ------_=_NextPart_001_01BED9C3.86F5DCE4 Content-Type: text/html; charset="iso-8859-1" RE: weakness in IKE/DOI specs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> From: John Shriver [mailto:jas@shiva.com]
>
>[SNIP]
> I think it is perfectly appropriate to limit these to 32 bits, with
> the range being 0 to (2^32)-1.  I don't think there is any sensible
> justification to allow 64 bit values, that's just too long a
> lifetime.
>
Hmmm,

Imagine in the near future (even now?) we have terabit networks. That
is 2^40 bits/second. Protecting 2^32KBytes (=2^45 bits) gives me 32
seconds of coverage before a rekey is needed.

In my opinion, 2^32, while more then adequate for today and probably
:-) adequate for time based rekeying, is a bit small for the
foreseeable future with respect to KByte lifetimes.
>
> Also, are there any restrictions on the value of an Attribute
> Length? Is 1 a legal?  Or must you use the short form when
> Attribute Length would be less than 3?  Also, is an attribute
> length of 3 legal for a lifetime?  I could want a lifetime of 128
> Kbytes, I could choose to code that as "00 02 00 03 01 00 00",
> rather than the far more sensible "00 02 00 04 00 01 00 00".  Can
> ANYONE parse that 3 byte lifetime?  I doubt it!  Should we allow
> it?  I don't think so!
>
RFC 2407 section 4.5 (IPsec DOI) and the IKE draft appendix A seems
to imply that any length is valid.

The code I am working on does not parse anything but 2 and 4 byte
values. I feel that this is adequate for the real world right now. I
know it is not fully compliant with the draft IKE document and the
IPsec and ISAKMP RFCs but that doesn't bother me. Other people may
feel different.

- -Michael Heyman

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1b23

iQA/AwUBN6BRW7XbkJfuXzRQEQJEXQCg1wf5nYD4/R0GVM4oQ9i0aiyGQ68AoIrf
l8z3WTfXA5cAwtter7tWpV/I
=MJTl
-----END PGP SIGNATURE-----

------_=_NextPart_001_01BED9C3.86F5DCE4-- From owner-ipsec@lists.tislabs.com Thu Jul 29 08:14:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA16757; Thu, 29 Jul 1999 08:14:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26237 Thu, 29 Jul 1999 09:43:41 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F94A@sothmxs06.entrust.com> From: Greg Carter To: "'Waters, Stephen'" , Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: xauth requirements: vulnerabilities Date: Thu, 29 Jul 1999 09:39:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] Sent: Thursday, July 29, 1999 7:14 AM To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: xauth requirements: vulnerabilities Main reason: Because the customer is happy with their investment in the legacy method and wants to use the same method for traditional RAS and VPN. The added benefit is that the token card can't be cracked off-line - it doesn't know what the secret, so it can't tell it to you. All DES based token cards (i.e.. all others besides SecurID) know a 'secret', SecurID is proprietary but it must know a secret as well. All token card vendors also have 'software' tokens which mimic hardware tokens. The DES or proprietary key is stored some how on disk with the soft token so it is susceptible to the same off line attacks as a shared key file, while I don't know of any specific technique to get DES keys off of hardware tokens I doubt they are tamper proof. I do know that unlike smartcards which generate the private key on board, DES based hardware token cards can have the secret downloaded via a serial port in the clear. Your GW can not discriminate between a user with a hardware token and one using a software token. Now, this off-line exposure could be 'fixed' just with pre-shared, if the client software did the right thing, i.e. challenge for a passphrase to unlock the pre-shared, derive a key, unencrypt the pre-shared, and just use whatever it recovers, without having anyway to verify it (e.g. hash signature). This would mean that the client would not know when you had answered the question correctly and prevent off-line hacking. The problem is that this relies on the implementation. I am a little confused on the above statement, but for what it is worth the same pass phrase that encrypts the shared secret file can be used to MAC the shared key file to prevent tampering. Bye. From owner-ipsec@lists.tislabs.com Thu Jul 29 10:06:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA18637; Thu, 29 Jul 1999 10:06:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26529 Thu, 29 Jul 1999 11:12:30 -0400 (EDT) Date: Thu, 29 Jul 1999 11:12:55 -0400 Message-Id: <199907291512.LAA01555@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael_Heyman@nai.com Cc: jas@shiva.com, ipsec@lists.tislabs.com Subject: RE: weakness in IKE/DOI specs References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Heyman," == Heyman, Michael writes: >> From: John Shriver [mailto:jas@shiva.com] >> >> [SNIP] I think it is perfectly appropriate to limit these to 32 >> bits, with the range being 0 to (2^32)-1. I don't think there is >> any sensible justification to allow 64 bit values, that's just too >> long a lifetime. >> Heyman,> Hmmm, Heyman,> Imagine in the near future (even now?) we have terabit Heyman,> networks. That is 2^40 bits/second. Protecting 2^32KBytes Heyman,> (=2^45 bits) gives me 32 seconds of coverage before a rekey Heyman,> is needed. Heyman,> In my opinion, 2^32, while more then adequate for today and Heyman,> probably :-) adequate for time based rekeying, is a bit Heyman,> small for the foreseeable future with respect to KByte Heyman,> lifetimes. I don't agree with this argument. The fact that links are getting faster is NOT a reason to increase the byte count life limits on keys. The appropriate value for the byte limit depends on the cipher used, and is independent of the link speed. By the way, while backbone links may scale that high, it's not clear to me that edge to edge or end system to end system paths will run anywhere near that fast anytime soon. SAs typically terminate near the network edge, not right in the core. Finally, if your security gateway is so fast that it can handle a Tb/s of ESP/AH, it is likely to be plenty fast enough to rekey at a measly twice per minute. paul From owner-ipsec@lists.tislabs.com Thu Jul 29 13:34:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA23387; Thu, 29 Jul 1999 13:34:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27310 Thu, 29 Jul 1999 14:52:11 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 29 Jul 1999 12:52:00 -0600 From: "Hilarie Orman" To: , Subject: Re: weakness in IKE/DOI specs 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 OAA27307 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Depends on the cipher and the key, doesn't it? One can foresee that the 32 bit limit will be too small, not in the immediate future, but almost surely within 10 years. Hilarie >>> John Shriver 07/28/99 01:29PM >>> Moreover, as a security feature, we know that you really don't want large lifetimes anyway. Too much ciphertext on too little key. I think it is perfectly appropriate to limit these to 32 bits, with the range being 0 to (2^32)-1. I don't think there is any sensible justification to allow 64 bit values, that's just too long a lifetime. From owner-ipsec@lists.tislabs.com Thu Jul 29 13:41:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA23430; Thu, 29 Jul 1999 13:41:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27341 Thu, 29 Jul 1999 15:07:55 -0400 (EDT) Message-ID: From: "Heyman, Michael" To: ipsec@lists.tislabs.com Subject: RE: weakness in IKE/DOI specs Date: Thu, 29 Jul 1999 12:06:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Paul Koning [mailto:pkoning@xedia.com] > >>>>> "Heyman," == Heyman, Michael writes: > >> From: John Shriver [mailto:jas@shiva.com] > >> > >> [SNIP] I think it is perfectly appropriate to limit these to 32 > >> bits, with the range being 0 to (2^32)-1. I don't think there > is > >> any sensible justification to allow 64 bit values, that's just > too > >> long a lifetime. > >> > Heyman,> Hmmm, > > Heyman,> Imagine in the near future (even now?) we have terabit > Heyman,> networks. That is 2^40 bits/second. Protecting 2^32KBytes > Heyman,> (=2^45 bits) gives me 32 seconds of coverage before a > rekey > Heyman,> is needed. > > Heyman,> In my opinion, 2^32, while more then adequate for today > and > Heyman,> probably :-) adequate for time based rekeying, is a bit > Heyman,> small for the foreseeable future with respect to KByte > Heyman,> lifetimes. > > I don't agree with this argument. The fact that links are getting > faster is NOT a reason to increase the byte count life limits on > keys. The appropriate value for the byte limit depends on the > cipher used, and is independent of the link speed. > I agree that the cipher and not the link speed should dictate the limit. Part of the problem is that know one knows a good limit based upon the cipher. I think the limit is much larger then it seems you are implying. Take DES, which has been broken by brute force attacks. I believe the best known plaintext attack takes 2^47 plaintext/ciphertext block pairs. This is 2^40KBytes. Already greater then a 4 byte integer can hold and this is for a broken algorithm. Also, this means _all_ the plaintext is known, in which case there is no reason to look for a key. > > By the way, while backbone links may scale that high, it's not > clear to me that edge to edge or end system to end system paths > will run anywhere near that fast anytime soon. SAs typically > terminate near the network edge, not right in the core. > How long is IKE supposed to last? 10 years? 20 years? 30 years? By Moore's law I should have terabit networking to my home in 22 years (assuming network speeds increase at the same rate as computer speeds). I want my hi-res 3D interactive home entertainment system by Holodeck Corp. secured by IPsec/IKE :-). I think that real world implementations can max out at 32 bits now (if that is the natural integer size) and re-write for 64 bits later when that becomes common. I don't think it is worth developing a system now that can handle all allowed attribute formats. - -Michael Heyman -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1b23 iQA/AwUBN6CmWLXbkJfuXzRQEQJvMgCg0KybnkiBZ31vZHhAB/q090cYA8QAnidD 25XxAiU+VbYJdwcUMITLOpyH =nmUS -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jul 30 01:56:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA03343; Fri, 30 Jul 1999 01:56:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA28878 Fri, 30 Jul 1999 03:15:26 -0400 (EDT) Message-Id: <37A1508C.CAF40F55@radguard.com> Date: Fri, 30 Jul 1999 10:13:16 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" , ipsra Cc: IPSec mailing list Subject: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> <379F2F41.9CE2E65C@redcreek.com> <37A08FCB.AFD6FF32@radguard.com> <37A0A366.441A00E7@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Scott! "Scott G. Kelly" wrote: > I've been thinking about this, and believe that perhaps the thread is > improperly named. Hence I've allowed myself to change the name of the thread. I think that this is the problem that we should discuss. > I began the discussion because I believe that we need > to understand the remote access problem space before we can > intelligently discuss solutions, and security vulnerabilities are a part > of the problem space. At the same time, I've been trying to get someone > to explicitly state the rationale for xauth in terms of requirements, > and I think this may be confusing people. I should have separated the > two discussions. The problem as I see it : provide IPSec with an authentication of a user with a non fixed or fixed IP address (i.e. the IP address he uses is irrelevant to the authentication process). Ofcourse security vulnerabilities are an important part of this problem, after all these are the issues we discuss in this area, but they exist in several levels. I think that the a possible architecture for a solution could be a modular architecture that consists of an authentication mechanism that provides user authentication and a protocol that conveys this information to either IPSec or IKE. This solution is different from the current IKE approach to authentication in which the authentication is an integral part of the IKE protocol. > > Even the stongest PKI and Public key cryptography used will not save you > > from > > an unprotected private key. > > Yes, I agree. In this proposed architecture, the above problem is a security vulnerability of the authentication mechanism, or to be precise, of the implementation of the authentication mechanism. > > > > I think we should separate the authentication mechanism (e.g. certificates, > > SecureID, RADIUS) > > from the suggested IKE extends authentication protocols. > > > > The vulnerabilities you've stated refer to the strength of authentication > > mechanism that is used > > , and to the correctness and the security of its implementation. > > They also refer to the motivation one might have for seeking to somehow > improve upon the authentication mechanisms built into IKE, which is what > I had speculated that xauth/hybrid might be meant to do. We all agree > that PK authentication may be very strong, but as you pointed out, an > unprotected private key invalidates this supposition. Again, the > vulnerabilities are but one aspect of the set of factors from which we > derive requirements. We are seeking to improve the authentication mechanism built into IKE. One possibility is to improve security, which is what you refer to. Another way is to improve the ability to deploy IPSec, and to increase the number of scenarios in which IPSec can be used. These two goals might be contradicting, but we as engineers must make the trade-offs and come up with a reasonable set of solutions. > > > > I think that we all agree that the preferred authentication mechanism is > > user certificates, but > > we also realize that reality and the market requirements require the work of > > other authentication > > mechanism. > > > > The purpose of the suggested extend authentication protocols is to convey > > these authentication mechanisms into the existing IKE protocol. > > This gets to the heart of it, I think. There seems to be a market > "requirement" which has driven xauth, that being that administrators > think they want security, but they also have a conflicting desire, i.e. > to continue using their currently installed weak authentication > mechanisms. A remote access working group has been proposed, and I would > hope that the purpose of this group would be to actually examine the > remote access problem in depth and propose good, solid solutions, as > opposed to simply rubber-stamping the existing proposed mechanisms > without further thought. "rubber-stamping" is one way of looking at the integration of legacy authentication into IPSec. There are others. > > Let's separate the requirement from the actual authentication mechanism, and > > > > the requirement's from IKE authentication protocols. > > Yes, I agree that we need to derive the remote access requirements > independently of any existing proposed solutions. > > > I suggest that we will enable this integration into IKE, and that we will > > have a set > > of minimal requirements from an authentication mechanism that fits into the > > (future) > > IP Secure Remote Access framework. An example requirement might be > > if you use two factor authentication, then store the > > two factors (password, smart card) in different places... > > > > I think is that we are trying to understand what XAUTH and the other > > protocol are solving > > and not solving, instead of stating what are the problems and the > > requirements. > > I think this is the wrong way to go. > > I think I agree with you, and I'll feed back what I think so you can > correct me if I'm missing the point. We need to discuss the requirements > for secure remote access using ipsec. It is important that we not be > confused by arguing about whether existing mechanisms meet the > requirements when we have yet to explicitly state them. We should first > determine the requirements, and then discuss how individual mechanisms > meet (or don't meet) subsets of them. I think we should go to the modular approach, this way we'll separate the authentication mechanism from the protocol. This way the protocol can be used to add to the security of an underlying authentication mechanism. As for the requirements from the authentication mechanisms. Here I suggest we keep in mind what Jeff has reminded us during the IPSec session in Oslo. We are an ENGINEERING task force. We already have a good, scalable and secure authentication mechanism, namely user certificates. The problem is that it is hard to deploy. I think that in this case we should try to avoid (if possible) inventing a new authentication mechanism. There is an existing wide variety of authentication mechanism, some of them (with the right protocol protecting them and relaying the authentication information to IKE/IPSec) might be appropriate for us. I think we should specify the requirements, and suggest several (preferably existing) authentication mechanism. For each mechanism we should specify the trade-off, and declare the security risks he and his organization are exposed to if he uses this mechanism. We should remember that security and engineering is all about trade-offs. Let's look at IKE as an example. We have authentication methods that use user certificates, and pre-shared secret. We all know that pre-shared secrets authentication has it security risks (in addition to the scalability problems). But if pre-shared secret authentication hadn't exist in IKE, IPSec would not have been as deployed as it is today ( I even think IPSec wasn't here today if pre-shared secret authentication hadn't exist). We had suggested a good authentication method, and a worse one. We've pointed out the trade-offs, and let the users make their choice. I think we should approach the IPSRA problem in a similar way, > > > Scott Thanks, Sara. From owner-ipsec@lists.tislabs.com Fri Jul 30 09:57:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA11924; Fri, 30 Jul 1999 09:57:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29958 Fri, 30 Jul 1999 11:07:31 -0400 (EDT) Message-ID: From: "Linn, John" To: "'Sara Bitan'" , "Scott G. Kelly" , ipsra Cc: IPSec mailing list Subject: RE: Using Legacy Authentication for IPSRA (was : xauth requiremen ts: vulnerabilities) Date: Fri, 30 Jul 1999 11:13:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sara wrote, excerpting: > The problem as I see it : provide IPSec with an > authentication of a user > with a non fixed or fixed IP address (i.e. the IP address he > uses is irrelevant to > > the authentication process). Ofcourse security > vulnerabilities are an important > part of this problem, after all these are the issues we > discuss in this area, but > they exist > in several levels. > I think that the a possible architecture for a solution could > be a modular > architecture > that consists of an authentication mechanism that provides > user authentication and > a protocol > that conveys this information to either IPSec or IKE. This > solution is different > from the current IKE > approach to authentication in which the authentication is an > integral part of the > IKE protocol. It seems to me that two distinct problems arise for IPSRA: authentication of an IPsec client (familiar from base IPsec) and authentication of an associated human user (arising more specifically in the IPSRA context). Both are relevant to IPSRA, carry different assumptions and constraints, and may therefore suggest different mechanisms. People are poorly suited to remembering and entering long secrets or performing exponentiation, but can perform operations with hardware tokens that are disconnected from the IPsec client system. Computers are good at remembering long secrets, but quite variable in terms of how well those secrets are protected from unintended disclosure. Whether IPsec client and human user authentication are addressed within the same mechanism or separately from one another, it seems important that both sets of concerns be satisfiable. Several general choices could arise as to what's authenticated on behalf of the remote accessor: (1) the client IPsec entity only, independent of its user: here, no user-level secrets would be involved in the IPsec-visible distributed authentication protocol(s), though they might be used locally (perhaps involving side-channel protocol transactions outside IPsec) to unlock client-level secrets for use (2) the user only, independent of the client: here, user-level secrets would be involved in performing IPsec-visible distributed authentication protocol(s), and it would not be assumed that any client-retained secrets are sufficiently fine-grained to authenticate an individual client (3) a compound principal, representing the bound combination between user and client: here, separate secrets representing both user and client would be applied within the IPsec-visible protocol(s), in such a way as to demonstrate their conjunction (4) the user and client, independently authenticated: here, independent IPsec-visible authentication transactions would be performed for both user and client, though the performance of one authentication might rely on a secure channel provided by the other Does this taxonomy help to clarify the possibilities? --jl From owner-ipsec@lists.tislabs.com Fri Jul 30 10:17:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA12160; Fri, 30 Jul 1999 10:16:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00133 Fri, 30 Jul 1999 11:47:49 -0400 (EDT) Message-ID: <37A1C94A.B34218E7@redcreek.com> Date: Fri, 30 Jul 1999 08:48:26 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sara Bitan CC: ipsra , IPSec mailing list Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> <379F2F41.9CE2E65C@redcreek.com> <37A08FCB.AFD6FF32@radguard.com> <37A0A366.441A00E7@redcreek.com> <37A1508C.CAF40F55@radguard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sara, One small clarification: Sara Bitan wrote: > > > The purpose of the suggested extend authentication protocols is to convey > > > these authentication mechanisms into the existing IKE protocol. > > > > This gets to the heart of it, I think. There seems to be a market > > "requirement" which has driven xauth, that being that administrators > > think they want security, but they also have a conflicting desire, i.e. > > to continue using their currently installed weak authentication > > mechanisms. A remote access working group has been proposed, and I would > > hope that the purpose of this group would be to actually examine the > > remote access problem in depth and propose good, solid solutions, as > > opposed to simply rubber-stamping the existing proposed mechanisms > > without further thought. > > "rubber-stamping" is one way of looking at the integration of legacy > authentication > into IPSec. There are others. The rubber-stamping I was referring to is with respect to xauth. I meant to say that I don't think we should go through the motions of forming a working group just so that we can standardize xauth with no real discussion. Scott From owner-ipsec@lists.tislabs.com Fri Jul 30 10:25:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA12264; Fri, 30 Jul 1999 10:25:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00217 Fri, 30 Jul 1999 11:58:24 -0400 (EDT) Message-ID: <37A1CBC0.3E6C4439@redcreek.com> Date: Fri, 30 Jul 1999 08:58:56 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn, John" CC: "'Sara Bitan'" , ipsra , IPSec mailing list Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi John, "Linn, John" wrote: > Several general choices could arise as to what's authenticated on behalf of > the remote accessor: > > (1) the client IPsec entity only, independent of its user: here, no > user-level secrets would be involved in the IPsec-visible distributed > authentication protocol(s), though they might be used locally (perhaps > involving side-channel protocol transactions outside IPsec) to unlock > client-level secrets for use > > (2) the user only, independent of the client: here, user-level secrets would > be involved in performing IPsec-visible distributed authentication > protocol(s), and it would not be assumed that any client-retained secrets > are sufficiently fine-grained to authenticate an individual client > > (3) a compound principal, representing the bound combination between user > and client: here, separate secrets representing both user and client would > be applied within the IPsec-visible protocol(s), in such a way as to > demonstrate their conjunction > > (4) the user and client, independently authenticated: here, independent > IPsec-visible authentication transactions would be performed for both user > and client, though the performance of one authentication might rely on a > secure channel provided by the other > > Does this taxonomy help to clarify the possibilities? Yes, I think so. I was headed in this direction with the vulnerabilities thread, but I had not reached this level of resolution yet. I think this very succinctly summarizes the available authentication subjects. The only thing missing seems to be the remote security gateway (the server?). In some cases the user may want to insist that the sgw be strongly authenticated, and in others, they may not care (or have the ability). Scott From owner-ipsec@lists.tislabs.com Fri Jul 30 12:18:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13537; Fri, 30 Jul 1999 12:18:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00488 Fri, 30 Jul 1999 12:49:31 -0400 (EDT) Message-ID: <811670B03A7DD211A2730008C709C209082FDF@daystrom.abatissys.com> From: "Li, Renwei" To: "'ipsec@lists.tislabs.com'" Subject: IPsec implementation Date: Fri, 30 Jul 1999 09:45:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi! I looking for some IPsec implementations with/without hardware acceleration for encryption. Your advice will be greatly appreciated! Thanks, Renwei From owner-ipsec@lists.tislabs.com Fri Jul 30 19:35:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA01290; Fri, 30 Jul 1999 19:35:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01554 Fri, 30 Jul 1999 20:53:24 -0400 (EDT) Message-ID: <37A24B71.1E5264B8@mail.sc.cninfo.net> Date: Sat, 31 Jul 1999 09:03:45 +0800 From: chenl Reply-To: chenl@mail.sc.cninfo.net X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586) MIME-Version: 1.0 To: "Li, Renwei" , "ipsec@lists.tislabs.com" Subject: Re: IPsec implementation References: <811670B03A7DD211A2730008C709C209082FDF@daystrom.abatissys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You may want to have a galance of Linux FreeS/Wan project. Li, Renwei wrote: > Hi! I looking for some IPsec implementations with/without hardware > acceleration for > encryption. Your advice will be greatly appreciated! > > Thanks, > Renwei